9

我们已经用 GUI 和 CHUI 构建了产品。展望未来,我们正在考虑重新设计我们的许多软件,主要是走全 GUI 的路线。我向小组提出的问题是,我们是否需要考虑让 CUI 留在身边?CUI 与 GUI 相比有什么优势?过去很多时候人们都说 CUI 更快,因为你不需要鼠标。我认为 GUI 可以与正确的键盘快捷键、热键和/或触摸屏一样快。

如果硬件不再提供约束,我们是否应该不再考虑 CUI?

另外澄清一下,当我谈到 CHUI 时,我指的是基于字符的用户界面,而且我还主要关注向最终用户有效呈现数据。

有一些很棒的回应强调了为自动化和基于脚本的任务提供基于命令行的界面的重要性,当我们开始设计时,我一定会牢记在心!

4

15 回答 15

14

你应该调查你的客户,而不是程序员。如果使用您的应用程序的客户想要一个 CHUI,即使您的所有开发人员都认为这是浪费时间,您也要构建它,因为客户总是正确的(除非他们错了)。

于 2008-10-31T14:20:45.417 回答
14

CHUI 的主要好处(即带有表单和字段的东西,不一定是命令行界面)是用于导航和一致布局的键盘。那是关键。

如果您的 GUI 可以完全有效地通过键盘导航,那么您的 CHUI 用户群应该会很高兴。这是因为及时,用户只是将他们的命令“输入”到系统中,而没有“看到界面”。他们不需要“发现”界面,这是 GUI 的主要特性。

虽然 CHUI 看起来像恐龙,但它们仍然可以正常工作和使用。大多数人一旦接受过培训(尤其是 POS/柜台工作人员,甚至是工厂或仓库等后台办公场景),使用 CHUI 都没有问题。

但关键是键盘支持,因此用户不必等待屏幕赶上他们。看到熟练的操作员精通键盘可以使应用程序飞起来。你几乎没有机会看到弹出窗口等等。

于 2008-10-31T15:06:45.730 回答
10

你绝对应该考虑它。最重要的是,命令行程序可以比 GUI(通常)更容易自动化(并在脚本中链接在一起)。我无法想象使用没有命令行界面的源代码控制工具 - 尽管显然拥有 GUI 也很有用。

现在,如果不知道您的应用程序是做什么的,就很难说您是否需要特定应用程序的命令行版本。您需要自动化和脚本吗?可能有人想要 VPN 并从非常糟糕的连接中运行它,从而欣赏低带宽?

请注意,MS 当然不相信命令行已经死了——否则他们就不会创建 PowerShell。

于 2008-10-31T14:20:03.953 回答
5

我同意 Eli 的观点,即您的客户应该拥有最终决定权,但是如果您可以防止程序的内容与 GUI(或 CHUI)过于交织,那么同时提供两者的生产成本应该是最低的。

于 2008-10-31T14:27:14.140 回答
5

如果您为 unix 编写应用程序并且您需要处理通过 telnet / ssh 访问您的机器的用户,那么您将需要命令行界面。

我会说这取决于你的目标。您是否从其他应用程序编写代码?这将是保持交互式版本(或避免 GUI 启动的一部分)的要求。

我们通常做其中之一。但有时我们有必须通过 ftp 部署并运行 ssh 的实用程序。或者我们有我们的用户嵌入到他们的应用程序中并且不想暴露 UI(数据迁移/转换)的工具。

于 2008-10-31T14:28:56.213 回答
4

时至今日,我见过的一些最高效的用户界面都是基于终端的普通字符界面。

轶事:我曾经参与过一个让 500 名客户服务代表使用的终端应用程序“现代化”的项目。我们发布了性感的 GUI 模型,包括用户在内的每个人都对它印象深刻。我们在应用程序上工作了六个月,所有的用户验收测试似乎都表明我们有一个赢家。

但是当应用程序最终启动时,它惨遭失败。事实证明,每天都会对 CSR 的绩效进行衡量,直至处理每个呼叫的平均秒数。而且无论他们如何努力,都无法在 GUI 中达到与终端界面相同的效率水平。他们可以通过标签和快捷方式接近,但不完全在那里。

惨痛的教训。现代程序员可能厌恶“恐龙”,但用户真的关心光滑的界面吗?通常他们只是想完成他们的工作。

于 2008-10-31T15:26:59.510 回答
3

当我第一次读到这篇文章时,我的第一反应是,这可能是那些基本上是一系列表单但显示在终端内的应用程序之一。您经常会在收银机上看到这样的恐龙。我还记得我买车的时候看到过这样一个申请贷款的应用程序。这种类型的应用程序似乎在现代世界中没有一席之地——任何具有一点处理能力的系统现在都可以处理普通的 GUI。除非您尝试支持真正低端的旧客户,否则请摆脱此用户界面。具有良好键盘快捷键的 GUI(请,请,请考虑一下仅使用键盘的 GUI 程序......)对于来自旧 CUI 系统的用户来说同样有效,并且对那些习惯于使用的用户更友好一个图形用户界面,

我不明白为什么每个人都提出命令行应用程序。我认为大多数人都认识到命令行不会消失。对于许多任务来说,它比 GUI 快得多,主要是因为程序往往是非交互式的(因此很容易编写脚本)。一旦您的应用程序变为交互式(或者,至少没有参数使其成为非交互式),从命令行运行它就变得不那么重要了。甚至像 Vim 这样基于终端的出色程序也正在过渡到其图形对应程序 (gVim),因为它为您提供了两全其美的优势。

于 2008-10-31T14:44:40.877 回答
2

即使是像 Firefox 这样的 GUI 应用程序也可以从像Ubiquity这样的命令行界面中受益。如果有一种方法可以从 GUI 中提供命令行,那么为什么不能两全其美呢?

许多 CAD 程序都有命令行界面,可以向您显示刚刚执行的 GUI 交互在命令行中的含义。通过这种方式,您可以了解您经常做的事情的命令行操作,并且命令行可以更快地与惠斯特交互,同时仍然具有 GUI 界面的可发现性。

观看演示 ​​Rhino3D 命令行的youtube 视频

于 2008-10-31T14:22:58.830 回答
1

CHUI 的执行速度更快,而不是用户交互速度。我编写嵌入式系统(以及 GUI),因此我将始终使用命令行应用程序。

于 2008-10-31T14:19:15.967 回答
1

我读过的每一项研究都表明,对于有经验的用户来说,CHUI 的速度要快得多。GUI 对于新用户和仅偶尔使用的应用程序来说更容易。同样对于给定的屏幕尺寸,您可以在 CHUI 上显示更多信息,而不是在 GUI 上。一个好的 GUI 可以让您一目了然地快速浏览。

于 2008-10-31T15:44:30.677 回答
1

除了上面提到的其他好处之外,我经常发现另一个保留替代 UI 的理由——它让你和你的界面保持诚实。当应用程序仅使用一个用户界面构建时,让设计原则滑动变得容易得多,并且您的业务逻辑等和您的 GUI 成为一个交织在一起的意大利面条球——尽管有最好的意图。不管您的客户拥有命令行界面的重要性如何,很快就会有可能需要替代 GUI(阅读:表示层)的时候,并且您需要做好准备。这可能与您的要求无关,但我认为记住这一点很好......

于 2008-12-28T17:11:53.023 回答
1

我们遇到的一个大问题是多会话功能,这在我见过的 GUI 技术中几乎不存在。我们的用户很快指出,使用当前基于字符的界面,他们可以在他们的 PC 屏幕上同时进行十几个基于 Telnet 的终端会话,这使他们能够高效地进行多任务或任务切换。他们认为多任务处理是他们在我们快节奏的环境中受益匪浅的杀手级功能,中断频繁。能够同时访问特定 ERP 应用程序或多个不同 ERP 应用程序的多个实例,同时始终保持会话状态对我们的用户社区来说非常重要。

于 2009-08-07T02:38:02.650 回答
1

我认为问题来自 GUI 表单中的设计实践。我们倾向于在它们上放置更多对象,尤其是具有垂直滚动条和选项卡功能的对象。这也使加载速度变慢。一旦您记住了这些序列并且不需要按住 Ctrl 键,使用键盘浏览 CHUI 菜单会更快。Windows 中的菜单栏有一些东西,其中快捷键描述位于右侧。一段时间后,基于字符的菜单似乎更容易记住。

A) - This Menu
B) - That Menu
C) - Some other Menu

或者您可以通过箭头浏览选项,并且您似乎有一些肌肉记忆,其中该菜单是第二选择。

于 2010-01-04T20:20:50.840 回答
0

一旦您提供一些数据,就会有人想要查询它。您可以将其与 gui 集成,没问题。如果您认为您的一些客户想要编写某些任务的脚本。设置它。任何与自动化有关的事情都最好从命令行完成(y harlo thar cron job!)

我喜欢吉斯。我是mac用户。但是 CLI 是有时间和地点的。

于 2008-10-31T15:10:28.233 回答
0

当注册系统从使用 telnet 的基于字符的系统转变为 PeopleSoft 应用程序上的 gui 系统时,我是一所大学数学系的系统管理员。

前台的女士们讨厌新系统。现在,其中一部分是关于旧鞋更舒适的全部内容。但是当我问起这件事时,克里斯汀说,即使经过一周每天进行数百次注册,新系统也需要数倍的时间才能完成任何事情。很多事情只能用鼠标完成。旧系统可以尽可能快地接受输入。屏幕重绘不到十分之一秒。新系统有很多 3/4 到 2 秒的停顿——只是长到让人讨厌,长到不能做任何其他事情。

于 2019-11-15T15:40:44.720 回答