为什么UI编程如此耗时,有什么方法可以缓解这种情况?

17

根据我的经验,UI编程非常费时、昂贵(设计师、图形等),而且容易出错- UI的错误或故障在定义上是非常明显的,令人尴尬。

您如何缓解这个问题?

您是否知道一种可以自动将API转换为用户界面(最好是Web用户界面)的解决方案?

可能类似于JMX控制台

  • 具有良好的默认设置
  • 可以使用CSS进行调整
  • 其中字段可以配置为单选按钮或下拉列表、文本字段或文本区域等
  • 可本地化
  • 等等
10个回答

10

开发 UI 很耗时且容易出错,因为它涉及设计。不仅仅是视觉或声音设计,更重要的是交互设计。一个好的 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?”,其中有一些非常有见地和有价值的答案,特别是:


7
我认为UI编程并不比其他类型的编程更费时间,也不会更容易出错。然而,UI中的错误通常更加明显。发现编译器中的错误通常要困难得多。
UI编程与其他编程之间一个明显的区别是,你在另一端有一个人,而不是另一个程序,当你编写编译器、协议解析器、调试器和其他与其他程序和计算机交互的代码时,情况很常见。这意味着你正在与一个未经充分说明且可能表现异常的实体进行通信。
您提出将API转换为用户界面的问题对我来说毫无意义。您在说什么?

"不是很明确,可能会表现得非常不稳定" - 真的啊! +1 - Treb
如果不是程序员的用户界面,那么API是什么? - Newtopian
程序本身是由人编写的,通常没有很好的规范,并且表现不稳定。此外,将用户解释为某种存在固有缺陷的实体是所有可用性问题的根源。 - Kurt Schelfthout
也许“erratically”这个词不太准确,更应该用“unpredictable”来表达我的意思。 - JesperE
@Newtopian:现在我明白你的意思了。 - JesperE

2

我不太确定你为什么会选择这个作为“答案”,安迪?这是所有答案中最泛化/模糊的答案。实际上,我甚至不明白你怎么可能通过Naked Objects找到解决问题并提高UI开发时间的解决方案。你能否给出反馈,说明你在这个解决方案中看到了什么,让你认为它能解决你在问题中提到的问题?我不是在挖苦你,只是真的很好奇。谢谢! - Jeach
显然我不能代表OP发言,但裸对象框架正是他所要求的:它们从API生成用户界面。 - Jens Schauder

2
我不会提供解决方案,但我会尝试回答为什么。
所以,我并不代表所有人,但至少对我来说,我认为一个原因是程序员往往更注重功能而不是易用性,并且他们不太艺术化。我认为他们只是有一种不同类型的创造力。我发现制作出正确的图形需要我花费很长时间,相比编写代码(虽然在大多数情况下,我没有做过太多具有图形要求的项目)。

1

自动生成用户界面在某种程度上是可能的,因为它可以生成所需输入和输出数据的控件。但是UI设计远比简单地将所需控件放到屏幕上要复杂得多。为了创建一个可用、用户友好的UI,必须结合来自图形设计、人体工程学、心理学等学科的知识。人机交互之所以成为一门学科是有原因的:创建一个体面的UI并不是一件轻松的事情。

因此,我认为你的问题没有真正的解决方案。UI设计是一项复杂的任务,需要花费足够的时间才能做好。唯一相对容易节省时间的领域是工具:如果你有强大的工具来实现用户界面的设计,就不必手动编写每个像素的UI。


1

当你说UI很费时、昂贵且容易出错时,你是完全正确的!

我发现一个很好的折中方案如下...

我意识到很多数据(如果不是大部分)可以使用简单的表格(如JTable)来呈现,而不是不断尝试创建自定义面板和花哨的GUI。一开始似乎并不明显,但它相当不错、可用和视觉上吸引人。

为什么这么快?因为我能够创建一个可重用的框架,可以接受一组具体的模型,并且几乎不需要任何努力就可以在表格中呈现所有这些模型。代码重用非常多,难以置信。

通过在窗口上方添加工具栏,我的框架可以向表格中添加、删除或编辑条目。使用JTables的全部功能,我可以通过扩展各种类(但仅在必要时)隐藏(通过过滤)和排序。

每当我想要显示和管理新模型时,我发现自己在重复使用大量的代码。我广泛使用图标(按列、行或单元格等)来美化屏幕。我使用大图标作为窗口标题,使每个屏幕“看起来”不同和吸引人,但它们背后的代码始终相同。

一开始需要大量的工作和努力来完成框架,但现在它正在大大地回报。

我可以在很短的时间内为全新的应用程序编写GUI,包括30到50个不同的模型,其中包含许多屏幕,而使用“自定义UI方法”则需要更长的时间。

我建议您评估并探索这种方法!


用户为什么要查看数据模型呢?大多数情况下,用户并不感兴趣。他们想要完成目标导向的任务,并尽可能少地付出努力。UI 应该以用户的语言进行模型解释,而不是开发人员。 - haqwin
我不确定你在说什么,Haqwin? 我谈论的是实施方法和最佳实践...我从未提到过用户、他们的兴趣或努力。请再次阅读我的评论。如果您有MVC经验,您将完全理解所指的内容...总结如下:1)通过拥有自定义屏幕和面板来避免复杂的UI 2)标准化演示文稿(我更喜欢使用JTables) 3)重用代码/框架,从而加快开发速度并减少错误 - Jeach

0

0
一个原因是我们没有一个成熟的UTDD - 用户测试驱动开发模式。我也没有看到很多将用户故事映射到单元测试的好例子。例如,为什么这么少的教程讨论用户故事呢?

0

ASP.NET动态数据是你应该调查的东西。它满足大多数,如果不是全部的要求。


0

这很困难,因为大多数用户/客户都很愚蠢,思维不清晰! :) 这很耗时,因为UI开发人员/设计师非常强迫症! :)


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接