Developing UI is time consuming and error-prone because it involves design. Not just visual or sound design, but more importantly interaction design. A good API is always interaction model neutral, meaning it puts minimal constraints on actual workflow, localisation and info representation. The main driver behind this is encapsulation and code re-use.
As a result it is impossible to extract enough information from API alone to construct a good user interface tailored to a specific case of API use.
However there are UI generators that normally produce CRUD screens based on a given API. Needless to say that such generated UI's are not very well-suited for frequent users with demands for higher UI efficiency, nor are they particularly easy to learn in case of a larger system since they don't really communicate system image or interaction sequence well.
It takes a lot of effort to create a good UI because it needs to be designed according to specific user needs and not because of some mundane API-UI conversion task that can be fully automated.
To speed the process of building UI up and mitigate risks it is possible to suggest either involving UI professionals or learning more about the job yourself. Unfortunatelly, there is no shortcut or magic wand, so to speak that will produce a quality UI based entirely and only on an API without lots of additional info and analysis.
I don't believe UI programming is more time consuming than any other sort of programming, nor is it more error prone. However, bugs in the UI are often more obvious. Spotting an error in a compiler is often much more tricky.
One clear difference between UI programming is that you have a person at the other end, instead of another program, which is very often the case when you're writing compilers, protocol parsers, debuggers, and other code which talks to other programs and computers. This means that the entity you're communicating with is not well-specified and may behave very erratically.
EDIT: "unpredictable" is probably a more appropriate term. /Jesper
Your question of converting an API to a user interface just doesn't make sense to me. What are you talking about?
I'm not providing a solution, but I'll attempt to answer the why.
So I don't speak for everyone, but for me at least, I believe one reason is because programmers tend to concentrate on functionality more so than usability and they tend not to be too artistic. I think they just tend to have a different type of creativity. I find that it takes me a long to time to create the right graphics, compared to how long it takes me to write the code (Though, for the most part, I haven't done any projects with too many graphical requirements).
Automatically generating user interfaces may be possible to some extent, in that it can generate controls for the required input and output of data. But UI design is much more involved than simply putting the required controls onto a screen. In order to create a usable, user friendly UI, knowledge from disciplines such as graphics design, ergonomics, psychology, etc. has to be combined. There is a reason that human-computer interaction is becoming a discipline of its own: its not trivial to create a decent UI.
So I don't think there's a real solution to your problem. UI design is a complex task that simply takes time to do properly. The only area where it is relatively easy to win some time is with the tooling: if you have powerful tools to implement the design of the user interface, you don't have to hand-code every pixel of the UI yourself.
You are absolutely correct when you say that UI is time consuming, costly and error prone!
A great compromise I have found is as follows...
I realized that a lot of data (if not most) can be presented using a simple table (such as a JTable), rather than continuously try to create custom panels and fancy GUI's. It doesn't seem obvious at first, but it's quite decent, usable and visually appealing.
Why is it so fast? Because I was able to create a reusable framework which can accept a collection of concrete models and with little to no effort can render all these models within the table. So much code-reuse, its unbelievable.
By adding a toolbar above the window, my framework can add to, remove from or edit entries in the table. Using the full power of JTables, I can hide (by filtering) and sort as needed by extending various classes (but only if/when this is required).
I find myself reusing a heck of a lot of code every time I want to display and manage new models. I make extensive use of icons (per column, rows or cells, etc) to beautify the screens. I use large icons as a window header to make each screen 'appear' different and appealing and it always looks like new and different screens, but its always the same code behind them.
A lot of work and effort was required at first to do the framework, but now its paying off big time.
I can write the GUI for an entirely new application with as many as 30 to 50 different models, consisting of as many screens in a fraction of the time it would take me using the 'custom UI method'.
I would recommend you evaluate and explore this approach!
One reason is that we don't have a well-developed pattern for UTDD - User Test Driven Development. Nor have I seen many good examples of mapping User Stories to Unit Tests. Why, for example, do so few tutorials discuss User Stories?
It's hard because most users/customers are dumb and can't think straight! :) It's time consuming because UI devs/designers are so obsessive-compulsive! :)
发布评论
评论（10）
开发 UI 非常耗时且容易出错，因为它涉及到设计。 不仅仅是视觉或声音设计，更重要的是交互设计。 一个好的 API 始终是交互模型中立的，这意味着它对实际工作流程、本地化和信息表示的限制最小。 这背后的主要驱动力是封装和代码重用。
因此，不可能仅从 API 中提取足够的信息来构建适合特定 API 使用情况的良好用户界面。
然而，有些 UI 生成器通常会根据给定的 API 生成 CRUD 屏幕。 不用说，这样生成的 UI 不太适合需要更高 UI 效率的频繁用户，而且在较大系统的情况下也不是特别容易学习，因为它们不能真正很好地传达系统图像或交互序列。
创建一个好的 UI 需要花费大量的精力，因为它需要根据特定的用户需求进行设计，而不是因为一些可以完全自动化的普通 API-UI 转换任务。
为了加快建立 UI 的过程并降低风险，可以建议让 UI 专业人员参与或自己更多地了解这项工作。 不幸的是，没有捷径或魔杖，可以说，它可以产生完全基于 API 且仅基于 API 的高质量 UI，而无需大量附加信息和分析。
另请参阅一个很好的问题：“为什么是好的 UI对于一些开发人员来说设计这么难？” 其中有一些非常有见地和有价值的答案，特别是：
无耻插件 我自己的答案。
很好的答案 作者：Karl Fast。
Developing UI is time consuming and error-prone because it involves design. Not just visual or sound design, but more importantly interaction design. A good API is always interaction model neutral, meaning it puts minimal constraints on actual workflow, localisation and info representation. The main driver behind this is encapsulation and code re-use.
As a result it is impossible to extract enough information from API alone to construct a good user interface tailored to a specific case of API use.
However there are UI generators that normally produce CRUD screens based on a given API. Needless to say that such generated UI's are not very well-suited for frequent users with demands for higher UI efficiency, nor are they particularly easy to learn in case of a larger system since they don't really communicate system image or interaction sequence well.
It takes a lot of effort to create a good UI because it needs to be designed according to specific user needs and not because of some mundane API-UI conversion task that can be fully automated.
To speed the process of building UI up and mitigate risks it is possible to suggest either involving UI professionals or learning more about the job yourself. Unfortunatelly, there is no shortcut or magic wand, so to speak that will produce a quality UI based entirely and only on an API without lots of additional info and analysis.
Please also see an excellent question: "Why is good UI design so hard for some developers?" that has some very insightful and valuable answers, specifically:
Shameless plug for my own answer.
Great answer by Karl Fast.
我不认为 UI 编程比任何其他类型的编程更耗时，也更容易出错。 然而，用户界面中的错误通常更为明显。 发现编译器中的错误通常要棘手得多。
UI 编程之间的一个明显区别是，另一端有一个人，而不是另一个程序，当您编写编译器、协议解析器、调试器以及与其他程序和计算机通信的其他代码时，通常会出现这种情况。 这意味着与您通信的实体没有明确指定，并且行为可能非常不稳定。
编辑：“不可预测”可能是一个更合适的术语。 /Jesper
你将 API 转换为用户界面的问题对我来说毫无意义。 你在说什么？
I don't believe UI programming is more time consuming than any other sort of programming, nor is it more error prone. However, bugs in the UI are often more obvious. Spotting an error in a compiler is often much more tricky.
One clear difference between UI programming is that you have a person at the other end, instead of another program, which is very often the case when you're writing compilers, protocol parsers, debuggers, and other code which talks to other programs and computers. This means that the entity you're communicating with is not well-specified and may behave very erratically.
EDIT: "unpredictable" is probably a more appropriate term. /Jesper
Your question of converting an API to a user interface just doesn't make sense to me. What are you talking about?
看起来您正在寻找“裸对象”架构模式。 有多种可用的实现方式。
http://en.wikipedia.org/wiki/Naked_objects
Looks like you are looking for the 'Naked Objects' Architectual pattern. There are various implementations available.
http://en.wikipedia.org/wiki/Naked_objects
我不提供解决方案，但我会尝试回答原因。
所以我不代表所有人，但至少对我来说，我相信原因之一是因为程序员往往更关注功能而不是可用性，而且他们往往不太艺术化。 我认为他们只是倾向于拥有不同类型的创造力。 我发现与编写代码所花费的时间相比，我需要很长时间才能创建正确的图形（尽管在大多数情况下，我没有完成任何具有太多图形要求的项目）。
I'm not providing a solution, but I'll attempt to answer the why.
So I don't speak for everyone, but for me at least, I believe one reason is because programmers tend to concentrate on functionality more so than usability and they tend not to be too artistic. I think they just tend to have a different type of creativity. I find that it takes me a long to time to create the right graphics, compared to how long it takes me to write the code (Though, for the most part, I haven't done any projects with too many graphical requirements).
自动生成用户界面在某种程度上是可能的，因为它可以生成所需的数据输入和输出的控件。 但 UI 设计比简单地将所需的控件放置到屏幕上要复杂得多。 为了创建可用的、用户友好的 UI，必须结合图形设计、人体工程学、心理学等学科的知识。 人机交互正在成为一门独立的学科，这是有原因的：创建一个像样的 UI 并不简单。
所以我认为你的问题没有真正的解决方案。 UI 设计是一项复杂的任务，需要时间才能正确完成。 唯一相对容易赢得时间的领域是工具：如果您有强大的工具来实现用户界面的设计，您就不必自己手动编码 UI 的每个像素。
Automatically generating user interfaces may be possible to some extent, in that it can generate controls for the required input and output of data. But UI design is much more involved than simply putting the required controls onto a screen. In order to create a usable, user friendly UI, knowledge from disciplines such as graphics design, ergonomics, psychology, etc. has to be combined. There is a reason that human-computer interaction is becoming a discipline of its own: its not trivial to create a decent UI.
So I don't think there's a real solution to your problem. UI design is a complex task that simply takes time to do properly. The only area where it is relatively easy to win some time is with the tooling: if you have powerful tools to implement the design of the user interface, you don't have to hand-code every pixel of the UI yourself.
当您说 UI 耗时、成本高且容易出错时，您是完全正确的！
我发现的一个很好的妥协如下...
我意识到可以使用简单的表格（例如 JTable）来呈现大量数据（如果不是大多数），而不是不断尝试创建自定义面板和精美的 GUI。 乍一看似乎并不明显，但它相当不错、可用且具有视觉吸引力。
为什么这么快？ 因为我能够创建一个可重用的框架，它可以接受具体模型的集合，并且只需很少的努力就可以在表中呈现所有这些模型。 如此多的代码重用，令人难以置信。
通过在窗口上方添加工具栏，我的框架可以添加、删除或编辑表中的条目。 利用 JTables 的全部功能，我可以通过扩展各种类来根据需要隐藏（通过过滤）和排序（但仅当/当需要时）。
我发现每次想要显示和管理新模型时，我都会重复使用大量代码。 我广泛使用图标（每列、行或单元格等）来美化屏幕。 我使用大图标作为窗口标题，使每个屏幕“显得”不同且有吸引力，它总是看起来像新的和不同的屏幕，但它们背后的代码总是相同的。
最初做这个框架需要大量的工作和努力，但现在它得到了巨大的回报。
我可以为一个全新的应用程序编写 GUI，该应用程序具有多达 30 到 50 个不同的模型，其中包含尽可能多的屏幕，而所需的时间只是使用“自定义 UI 方法”的一小部分。
我建议您评估并探索这种方法！
You are absolutely correct when you say that UI is time consuming, costly and error prone!
A great compromise I have found is as follows...
I realized that a lot of data (if not most) can be presented using a simple table (such as a JTable), rather than continuously try to create custom panels and fancy GUI's. It doesn't seem obvious at first, but it's quite decent, usable and visually appealing.
Why is it so fast? Because I was able to create a reusable framework which can accept a collection of concrete models and with little to no effort can render all these models within the table. So much code-reuse, its unbelievable.
By adding a toolbar above the window, my framework can add to, remove from or edit entries in the table. Using the full power of JTables, I can hide (by filtering) and sort as needed by extending various classes (but only if/when this is required).
I find myself reusing a heck of a lot of code every time I want to display and manage new models. I make extensive use of icons (per column, rows or cells, etc) to beautify the screens. I use large icons as a window header to make each screen 'appear' different and appealing and it always looks like new and different screens, but its always the same code behind them.
A lot of work and effort was required at first to do the framework, but now its paying off big time.
I can write the GUI for an entirely new application with as many as 30 to 50 different models, consisting of as many screens in a fraction of the time it would take me using the 'custom UI method'.
I would recommend you evaluate and explore this approach!
如果您已经知道或可以学习使用 Ruby on Rails，ActiveScaffold 对此非常有用。
if you already know or could learn to use Ruby on Rails, ActiveScaffold is excellent for this.
原因之一是我们没有一个完善的 UTDD 模式——用户测试驱动开发。 我也没有看到很多将用户故事映射到单元测试的好例子。 例如，为什么很少有教程讨论用户故事？
One reason is that we don't have a well-developed pattern for UTDD - User Test Driven Development. Nor have I seen many good examples of mapping User Stories to Unit Tests. Why, for example, do so few tutorials discuss User Stories?
ASP.NET 动态数据 是您应该研究的内容。 它满足您的大多数（如果不是全部）要求
ASP.NET Dynamic Data is something that you should investigate. It meets most, if not all your requirements
这很难，因为大多数用户/客户都很愚蠢，无法正常思考！ :)
这很耗时，因为 UI 开发人员/设计师非常有强迫症！ :)
It's hard because most users/customers are dumb and can't think straight! :)
It's time consuming because UI devs/designers are so obsessive-compulsive! :)