【发布时间】：2009-04-14 06:43:45
【问题描述】：
根据我的经验，UI 编程非常耗时、昂贵（设计师、图形等）并且容易出错 - 根据定义，UI 错误或故障非常明显，令人尴尬。
您采取了哪些措施来缓解这个问题？
您知道可以自动将 API 转换为用户界面（最好是 Web 用户界面）的解决方案吗？
可能类似于 JMX 控制台
- 具有良好的默认值
- 可以用 css 调整
- 其中字段可以配置为单选按钮或下拉列表、文本字段或文本区域等
- 可本地化
- 等
【问题讨论】：
【发布时间】：2009-04-14 06:43:45
【问题描述】：
开发 UI 既费时又容易出错，因为它涉及到design。不仅仅是视觉或声音设计，更重要的是交互设计。一个好的 API 始终是交互模型中立的，这意味着它对实际工作流程、本地化和信息表示的限制最小。这背后的主要驱动力是封装和代码重用。
因此，仅从 API 中提取足够的信息来构建一个适合 API 使用特定案例的良好用户界面是不可能的。
但是，有些 UI 生成器通常会根据给定的 API 生成 CRUD 屏幕。不用说，这种生成的 UI 不太适合需要更高 UI 效率的频繁用户，在更大的系统中也不是特别容易学习，因为它们不能很好地传达系统图像或交互顺序。
创建一个好的 UI 需要付出很多努力，因为它需要根据特定的用户需求进行设计，而不是因为一些可以完全自动化的普通 API-UI 转换任务。
为了加快构建 UI 的过程并降低风险，可以建议让 UI 专业人员参与或自己了解更多有关工作的信息。不幸的是，没有捷径或魔杖，可以这么说，它会产生完全基于 API 的高质量 UI，而无需大量额外的信息和分析。
另请参阅一个很好的问题：“Why is good UI design so hard for some developers?”有一些非常有见地和有价值的答案，特别是：
my own answer 的无耻插件。
Great answer Karl Fast。
【讨论】：
我不认为 UI 编程比任何其他类型的编程更耗时，也不会更容易出错。但是，UI 中的错误通常更明显。在编译器中发现错误通常要复杂得多。
UI 编程之间的一个明显区别是，您在另一端有一个人，而不是另一个程序，当您编写编译器、协议解析器、调试器和其他与其他程序通信的代码时，通常会出现这种情况程序和计算机。这意味着您正在与之通信的实体没有明确指定，并且可能表现得非常不稳定。
编辑：“不可预测”可能是一个更合适的术语。 /杰斯珀
您将 API 转换为用户界面的问题对我来说毫无意义。你在说什么？
【讨论】：
-
'没有很好地指定，可能表现得非常不稳定' - 多么真实！ +1
-
如果 API 不是程序员的用户界面，那么它是什么。
-
程序本身是由人类编写的，通常没有很好的说明并且行为不稳定。此外，您将用户解释为具有内在缺陷的实体是所有可用性问题的根源。
-
也许“不稳定”是错误的词。 “不可预测”可能更符合我的意思。
-
@Newtopian：现在我明白你的意思了。
看起来您正在寻找“裸对象”架构模式。有多种可用的实现。
【讨论】：
-
我不太确定你为什么会选择这个答案作为“答案”安迪？这是所有答案中最普遍/最模糊的答案。实际上，我什至看不到您如何才能找到解决问题的方法并使用 Naked Objects 缩短 UI 开发时间。是否可以就您在此解决方案中看到的内容提供反馈，让您认为它解决了您的问题？我不是在讽刺，我只是很好奇。谢谢！
-
显然我不能代表 OP，但 Naked Object Frameworks 完全符合他的要求：它们从 API 生成 UI
我没有提供解决方案，但我会尝试回答原因。
所以我并不代表所有人，但至少对我来说，我相信一个原因是因为程序员往往更关注功能而不是可用性，而且他们往往不太有艺术性。我认为他们只是倾向于具有不同类型的创造力。我发现创建正确的图形需要很长时间，而编写代码需要多长时间（尽管在大多数情况下，我没有做过任何图形要求太多的项目）。
【讨论】：
自动生成用户界面在某种程度上是可能的，因为它可以为所需的数据输入和输出生成控件。但是 UI 设计比简单地将所需的控件放在屏幕上要复杂得多。为了创建一个可用的、用户友好的 UI，必须结合图形设计、人体工程学、心理学等学科的知识。人机交互正在成为一门学科是有原因的：创建一个像样的 UI 并非易事。
所以我认为您的问题没有真正的解决方案。 UI 设计是一项复杂的任务，需要时间才能正确完成。唯一相对容易赢得时间的领域是工具：如果你有强大的工具来实现用户界面的设计，你就不必自己手动编码 UI 的每个像素。
【讨论】：
您说 UI 耗时、成本高且容易出错是绝对正确的！
我发现的一个很好的折衷方案如下......
我意识到可以使用简单的表格（例如 JTable）来呈现大量数据（如果不是大多数），而不是不断尝试创建自定义面板和精美的 GUI。起初看起来并不明显，但它相当不错，可用且具有视觉吸引力。
为什么这么快？因为我能够创建一个可重用的框架，它可以接受具体模型的集合，并且可以毫不费力地在表格中呈现所有这些模型。如此多的代码重用，令人难以置信。
通过在窗口上方添加工具栏，我的框架可以添加、删除或编辑表格中的条目。使用 JTables 的全部功能，我可以隐藏（通过过滤）并通过扩展各种类根据需要进行排序（但仅在需要时/在需要时）。
每次我想显示和管理新模型时，我都会重复使用大量代码。我广泛使用图标（每列、每行或单元格等）来美化屏幕。我使用大图标作为窗口标题，以使每个屏幕“看起来”不同且吸引人，它看起来总是新的和不同的屏幕，但它们背后的代码总是相同的。
一开始需要大量的工作和努力来完成这个框架，但现在它得到了很大的回报。
我可以为一个全新的应用程序编写 GUI，该应用程序包含多达 30 到 50 个不同的模型，由我使用“自定义 UI 方法”所花费的时间的一小部分组成。
我建议您评估和探索这种方法！
【讨论】：
-
用户到底为什么要查看数据模型。大多数时候用户不感兴趣。他们希望以尽可能少的努力执行目标导向的任务。 UI 应该用用户的语言来解释模型，而不是开发人员。
-
我不确定你在说什么 haqwin？我谈论实施方法和最佳实践……我一次也没有提到用户、他们的兴趣或他们的努力。再次阅读我的评论。如果您有 MVC 经验，您将准确理解其含义......总结为：1）通过自定义屏幕和面板避免复杂的 UI 2）标准化演示（我更喜欢使用 JTables）3）重用代码/框架，从而更快开发和更少的错误
如果您已经知道或可以学习使用Ruby on Rails，ActiveScaffold 非常适合。
【讨论】：
一个原因是我们没有完善的 UTDD 模式 - 用户测试驱动开发。我也没有看到很多将用户故事映射到单元测试的好例子。例如，为什么很少有教程讨论用户故事？
【讨论】：
ASP.NET Dynamic Data 是您应该调查的内容。它满足您的大部分要求，如果不是全部的话
【讨论】：
这很难，因为大多数用户/客户都是愚蠢的，无法思考！ :) 这很耗时，因为 UI 开发人员/设计师是如此的强迫症！ :)
【讨论】：