根据我的经验，UI编程非常耗时，昂贵（设计师，图形等）并且容易出错 - 根据定义，UI错误或故障是非常明显的尴尬。
您如何缓解此问题？
您是否知道可以自动将API转换为用户界面（最好是Web用户界面？）的解决方案。
可能类似于JMX控制台
答案 0 :(得分：10)
开发用户界面非常耗时且容易出错，因为它涉及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。
答案 1 :(得分：7)
我不相信UI编程比任何其他类型的编程更耗时，也不会更容易出错。但是，UI中的错误通常更为明显。在编译器中发现错误通常要困难得多。
UI编程之间的一个明显区别是，你在另一端有一个人，而不是另一个程序，这通常是你编写编译器，协议解析器，调试器和其他与其他人交谈的代码的情况。程序和计算机。这意味着您正在与之通信的实体没有明确指定，并且可能表现得非常不稳定。
编辑：“不可预测”可能是一个更合适的术语。 /的Jesper
您将API转换为用户界面的问题对我来说没有意义。你在说什么？
答案 2 :(得分：2)
看起来你正在寻找'Naked Objects'建筑模式。有各种各样的实现。
答案 3 :(得分：2)
我没有提供解决方案，但我会尝试回答原因。
所以我不是每个人都说话，但至少对我来说，我相信一个原因是因为程序员倾向于专注于功能而不是可用性而且他们往往不太艺术化。我认为他们只是倾向于拥有不同类型的创造力。我发现创建正确的图形需要花费很长时间，与编写代码需要多长时间相比（尽管在大多数情况下，我还没有完成任何具有太多图形要求的项目）。
答案 4 :(得分：1)
在某种程度上可以自动生成用户界面，因为它可以生成所需输入和输出数据的控件。但是UI设计比简单地将所需的控件放到屏幕上更为复杂。为了创建可用的，用户友好的UI，必须结合来自诸如图形设计，人体工程学，心理学等学科的知识。有一个原因，人机交互正在成为一个自己的学科：创建一个体面的用户界面并非易事。
所以我不认为你的问题有一个真正的解决方案。 UI设计是一项复杂的任务，只需要时间来正确完成。获得一段时间相对容易获得的唯一方面是使用工具：如果您有强大的工具来实现用户界面的设计，则您不必亲自手动编写UI的每个像素。
答案 5 :(得分：1)
当你说UI耗时，昂贵且容易出错时，你绝对正确！
我发现的一个很大的妥协如下......
我意识到可以使用简单的表（例如JTable）呈现大量数据（如果不是大多数），而不是不断尝试创建自定义面板和花哨的GUI。起初看起来并不明显，但它相当不错，可用且具有视觉吸引力。
为什么这么快？因为我能够创建一个可以接受一组具体模型的可重用框架，并且几乎没有任何努力可以在表格中呈现所有这些模型。如此多的代码重用，令人难以置信。
通过在窗口上方添加工具栏，我的框架可以添加，删除或编辑表格中的条目。使用JTables的全部功能，我可以隐藏（通过过滤）并根据需要通过扩展各种类进行排序（但仅当/需要时）。
每当我想显示和管理新模型时，我发现自己会重复使用大量代码。我广泛使用图标（每列，行或单元格等）来美化屏幕。我使用大图标作为窗口标题，使每个屏幕“显得”不同且吸引人，并且它总是看起来像新的和不同的屏幕，但它背后总是相同的代码。
首先需要做很多工作和努力才能完成框架，但现在它付出了很大的代价。
我可以为一个全新的应用程序编写GUI，其中包含多达30到50种不同的模型，包含尽可能多的屏幕，只需花费很少的时间就可以使用“自定义UI方法”。
我建议你评估并探索这种方法！
答案 6 :(得分：0)
如果您已经知道或可以学会使用Ruby on Rails，那么ActiveScaffold就非常适合。
答案 7 :(得分：0)
一个原因是我们没有完善的UTDD模式 - 用户测试驱动开发。我也没有看到很多将用户故事映射到单元测试的好例子。例如，为什么这么少的教程讨论用户故事？
答案 8 :(得分：0)
ASP.NET Dynamic Data是您应该调查的内容。它符合大多数（如果不是全部）要求
答案 9 :(得分：0)
这很难，因为大多数用户/客户都是愚蠢的，不能直接思考！ :) 这是耗时的，因为UI开发人员/设计师是如此强迫性的！ ：）