User interface 角色用户界面有前途吗？

我们已经用GUI和CHUI构建了产品。展望未来，我们将重新设计我们的许多软件，主要采用全GUI的方式。我向小组提出的问题是，我们是否需要解释为什么要保留一个崔？与GUI相比，CHUI有哪些优势？过去很多次，人们都说崔的速度更快，因为你不需要鼠标。我认为GUI可以和右键盘快捷键、热键和/或触摸屏一样快

是不是如果硬件不再提供约束，我们就不再考虑？ 同样要澄清的是，当我谈到CHUI时，我指的是一个基于字符的用户界面，我还主要关注的是向最终用户有效地展示数据

---

有一些精彩的回应强调了为自动化和基于脚本的任务提供基于命令行的界面的重要性，当我们开始设计时，我一定会牢记这一点

CHUI的执行速度更快，而不是用户交互速度。我编写嵌入式系统（以及GUI），所以我将永远使用命令行应用程序。

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

现在，如果不知道你的应用程序的功能，很难说你是否需要一个特定应用程序的命令行版本。您需要自动化和脚本吗？可能有人想使用VPN，并在一个非常糟糕的连接上运行它，从而欣赏低带宽

---

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

您应该调查您的客户，而不是程序员。如果使用您的应用程序的客户想要CHUI，即使您的所有开发人员都认为这是浪费时间，您也可以构建它，因为客户总是对的（除非他们错了）。

即使像Firefox这样的GUI应用程序也可以从类似的命令行界面中受益。如果有一种方法可以从GUI中提供命令行，那么为什么不同时做到两全其美呢

许多CAD程序都有命令行界面，可以向您显示刚才在命令行中执行的GUI交互等同于什么。通过这种方式，您可以了解您经常做的事情的命令行操作，并且命令行可以更快地与仍然具有GUI界面可发现性的whist进行交互

---

请参见Rhino3D的命令行

我同意Eli的观点，即您的客户应该拥有最终发言权，但是如果您可以避免程序的内容与GUI（或CHUI）过于交织，然后，使这两个应用程序都可用的生产成本应该是最低的。

如果您为unix编写应用程序，并且需要处理将telnet/ssh发送到您的设备的用户，那么您将需要命令行界面

我认为这取决于你的目标。您是否从其他应用程序编写代码脚本？这将是保持交互式版本（或避免GUI启动的部分）的要求

---

我们通常做一个或另一个。但有时我们有一些UTIL，它们必须通过ftp部署并运行ssh。或者我们有一些工具，用户可以将它们嵌入到他们的应用程序中，并且不想公开UI（数据迁移/转换）。

当我第一次读到这篇文章时，我的直接想法是，这可能是一个基本上是一系列表单的应用程序之一，但显示在终端中。你经常看到这样的恐龙在收银机上奔跑。我还记得在我买车的时候看到过这样一个应用程序用来申请贷款。这种类型的应用程序在现代世界似乎没有一席之地——如今，任何具有一点点处理能力的系统都可以处理普通的GUI。除非您试图支持真正的低端遗留客户，否则请摆脱此用户界面。一个有不错的键盘快捷键的GUI（请，请，请，请把一些想法放在只使用键盘的GUI程序上…）对于来自旧CHUI系统的用户来说同样有效，并且对于那些使用GUI的用户来说更加友好，而不必有两个版本的应用程序

---

我不明白为什么每个人都在使用命令行应用程序。我想大多数人都知道命令行不会消失。对于许多任务来说，它比GUI快得多，这主要是因为程序往往是非交互式的（因此很容易编写脚本）。一旦你的应用程序变成交互式的（或者，至少，没有一个参数使它成为非交互式的），从命令行运行它就不那么重要了。即使是像Vim这样基于终端的很棒的程序也在向图形化程序（gVim）过渡，因为它能让你两全其美。

CHUI（有表单和字段，不一定是命令行界面）的主要优点是导航和一致布局的键盘。这是关键

如果您的GUI能够完全、高效地进行键盘导航，那么您的CHUI用户群应该会感到高兴。这是因为随着时间的推移，用户只需在系统中“键入”他们的命令，而不会“看到界面”。他们不需要“发现”界面，这是GUI的主要功能

虽然Chui看起来像恐龙，但它们仍然具有功能和可用性。大多数人经过培训后（尤其是POS/柜台工作人员，但即使是工厂或仓库地板等后台办公场景），使用CHUI也没有问题

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

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