下一个用户界面：为什么做，怎么做和何时做？

UI的未来将基于自然语言还是虚拟和增强现实？对自然语言的全面理解，就目前而言是不可能达到的（并且在以后的几年也几乎不可能）。虚拟现实迫使用户与现实完全隔离，这有时让人难以接受。AR是与相现实融合的GUI的变体，通常不被看作是一种UI。用户界面起源于感官和思维等人性化的东西。也就是说，二元论体现在命令行用户界面与图形用户界面之间，并可以在未来继续作为自然语言用户界面与虚拟和增强现实用户界面。还有其他可能吗？我们还需要其他的用户界面吗？

是的。预先存在的用户界面存在一定的缺陷，命令行界面存在认知缺陷。例如，每个命令和应用程序都会引入一种迷你语言，有时候会有一条重要的学习曲线，而且很难估计命令和应用程序的能力，因为它们隐藏在冗长的说明中。GUI试图通过视觉表达来克服这一缺点，其中所有特征都可见并且外显。但是同时它也带来了新的问题，可能会无法将应用程序中的所有内容压缩到小视觉区域。

因此，我们将使用长的GUI路径（点击开放式点击类型等），因为我们要通过不同的窗口分离信息。从理论上讲，最高效的用户界面包含用户可以记住并轻松访问的有限数量的用户界面元素。我们拥有的UI元素越多，UI效率越低，因为用户花费更多时间来寻找所需的控件。我们拥有的UI元素越少，我们就可以控制和显露的越少。我们要在灵活性，表现力，许多功能和可用性之间取得平衡。

理论上，通过允许以比GUI快甚至更快的速度执行灵活的命令，自然语言识别至少可以解决一部分问题。但现代应用程序为此做好准备了吗？现在，有的方法假设我们必须通过说GUI和文件路径到UI控件和信息部件来用语音来控制UI。也就是说，我们可以灵活地控制不灵活的用户界面，但是这种方法在自然语言识别的方式中并不适用。

为什么呢？也许，我们确信语义技术和自然语言处理可以通过与智能代理交互来解决所有问题。也许，缺乏对这样一种认识，UI可以并且必须自身吸收语义信息以使其更加灵活。无论如何，将语义感知技术应用于语义不明的应用程序不是很有效。使用语义技术将输入转换为低级UI命令并迫使用户根据后者进行思考是徒劳的。用户应该根据自己的意图以尽可能接近自然语言的，而不是像现在那样根据GUI和文件路径的方式进行思考。

自然语言如何转化为计算机实体（UI控件，文件等）？它会由算法自动完成吗？将来也许可以。但为什么我们要等呢？可以弥补这种差距的一种变体可以是语义标记，其一方面使用自然语言，另一方面可以附接到不同的计算机实体。我们是否应该等到将来算法给出可靠的结果？但是如果开发人员和高级用户的共同努力能够提供更快更可靠的结果，为什么还要等呢？

当然，我们需要让用户熟悉基本的语义，但这不是大问题。语义是自然语言固有的。语义可以被普通用户理解和使用。现代UI中使用了一些语义学原理。用文件类型表示的相似性（“是”）的关系，用目录表达组合性（“有”）的关系，随着搜索引擎的使用，出现了识别意识，这也迫使用户理解查询和结果的语义。下一步是使语义更加用户友好，这就是为什么需要标记。

不同计算机应用程序之间有什么共同点？假设我们用与行星系统和行星有关的信息为例。如果用GUI表示，那么我们的应用程序就具有用于行星系统和行星的窗口。如果用一个命令行应用程序表示，那么它具有参数，这些参数指定了行星系统和/或行星，并且定义了将要显示的内容。如果用数据库表示，那么它就由两个表组成，通过行星系统的id联系。

最后，它可以表示为包含超链接的网页。要查看太阳系行星列表，我们可以使用不同的方法：（a）在行星系统列表中选择一行并按下“显示行星”按钮，（b）定义行星系统“太阳系”参数，（c） 使用查询语句“SELECT * FROM pl_system ps，planets p where ps.id = p.ps_id”，（d）打开“太阳系”链接。从计算机表示的角度来看，这些方式是不同的。从用户的角度来看，它们都是一样的，因为它们都对应于自然语言中的同一个问题：“太阳系的行星有哪些？”

使用上述不同方法，我们如何得到答案？应用程序和用户界面应该知道什么和行星系统发生联系，对行星进行什么操作，它们是如何发生联系等等。这在每种情况下的完成方式是不同的（根据一些内部逻辑和语义），但是对于语义标记，我们需要一个稍微不同的方法：精确并且足够简单，恰当，明确，灵活，渐进和人性化的含义的使用。此外，含义必须影响UI，UI也必须作用于含义。

什么是含义的精确用法？行星系统应该以PlanetarySystemForm窗口，PSystem数据结构，PL_SYSTEM表或planet-system.html文件等词为特征词描述，而不是以PlanetarySystem类。这些标识符是计算机友好的，但对于人类来说，它们需要解码。这可能会引起歧义（在PSystem和PL_SYSTEM的情况下）。用户需要人性化且足够独特的标识符（这意味着他们可以包含额外的词语来辨别“行星”（天文星体）和“星球”（杂志）。

什么是含义的简单用法？用户可能不了解类和实例之间的区别，但理解自然语言中“是”的关系，并理解事物之间的相似性。当然，类和实例之间的区别很重要，但是，它可能有点绝对。”地球“可以是”星球类“的一个实例，但也可以是”类地球行星类“的基类。行星列表可能只有行星标识符或行星实例。也就是说，“实例”和“类”不是固定类别，而是角色。如果用户只知道“是”关系，那么只用“地球是一颗行星”句子就足够了，而不需要更精确的“地球就是行星的一个实例”。

什么是含义的恰当用法？它们至少意味着区分性、抽象性、相似性和可组合性比名词、动词、主语、谓语和宾语的区别都重要。简而言之，是“行星围绕恒星”或是“行星有围绕恒星的轨道”无关紧要。名词和动词之间的区别是自然语言所必需的，但实际上，大多数名词和动词都是对象和动作二元论或者是许多对象和动作的复合体（此外，有时我们将单词作为名词、动词只为有正确的句子顺序或短语，使句子听起来更好）。识别描述情境中的成分更重要，而不是关注用了什么样的词描述。

什么是含义的明确用法？它是关于有含义的标识符之间的明显的区别（区分“纽约建筑物”，“纽约的新建筑物”和“约克的新建筑物”）以及它们之间的关系。

什么是含义的灵活用法？任何应用程序的含义应该随时可以用任何信息来扩展，而这些信息并不是初始意图所能预期的，而是用户意图所需要的。

什么是含义的逐步用法？我们应该暗示用户能够为当前尽可能多和精确地指定含义（通过用几个字来描述1 TB的数据）。稍后再扩展它。

什么是含义的人性化用法？语义定义应尽可能接近自然语言，以尽量减少学习曲线。

含义如何作用于UI？任何问题都是有含义的，例如，“什么是行星系统？” （可能对应于简短的“行星系统”查询语句）包含一个未知事物和与“是”联系的“行星系统”。这个问题与“行星系统是一组围绕恒星或恒星系统的在轨道上受引力束缚的非恒星物体”和“太阳系是行星系统”都匹配。要回答这个问题，应用程序应该将“行星系统”标识符和自己的元素关联起来。因此，（a）GUI应用程序可以显示行星系统窗口，（b）控制台应用程序可以显示行星系统列表，（c）数据库可以输出行星系统表，（d）浏览器可以显示行星系统网页。

在“什么是太阳系行星？”的示例中，需要一个简单的推论得出“太阳系是一个行星系统”的结论。这意味着（a）GUI应用程序可以显示行星窗口，在行星系统中选择“太阳系”，（b）控制台应用程序将星球系统参数设置为“太阳系”， c）数据库可以将问题转换为“SELECT * FROM pl_system ps，planets p WHERE ps.id = ps_id.id AND ps.name ='Solar System'”查询，以及（d）浏览器可以显示太阳系页面。

语义，问题和答案与GUI，控制台，数据库和Web应用程序的某些部分之间的联系在自然语言的帮助下为更好地控制UI提供了可能（或至少是一组预定义的问题和答案，无论如何，这是向前迈进的一步）。但这也意味着用户界面可能会发生变化，因为不需要很多的点击次数。所有的UI元素都可以直接到达，比如说，由搜索输入框。应用程序可以回答的所有问题都可以在系统中注册，系统将进一步发布它们。当然，它不仅仅涉及应用程序和“什么？” 的问题。单独的用户界面元素可以回答像“哪个星球系中有地球？”这样的问题 。另一方面，应用程序也许能够解释为什么它的行为如此（例如，为什么一个特定的窗口不能够发挥作用或者显示）或者某些功能如何激活或者显示全部选项，这和特定的含义范围有关。

UI如何影响含义？UI意味着交互，含义范围（或上下文）。GUI意味着一部分上下文; 一个行星窗口包含只涉及指定行星的信息/控件。文件系统也是如此; 理论上，一个行星文件目录应该只包含行星相关的信息（尽管OS无法用它来限制内容）。但这还不够，含义范围和上下文控制应该是明确的，并应该影响整个工作环境。当我们打开行星窗口，行星表或行星相关文件时，我们应该转向行星范围/上下文，它可能包含更多关于行星的信息或某个指定的行星，用户界面（UI）控件会处理它。在行星窗口里面，术语的解释为应该与行星相关（或者更泛化的的概念天文学）。

任何含义和相应的含义范围都可以用一个完全不同长度的标识符（单词，短语，句子等）来表示，这是一种语义链接。语义链接是指与特定含义（对于不同的用户，计算机和环境而言，含义不同）相对应的一组资源的链接。这可能会改变搜索的范式。搜索会知道哪里可以找到答案（至少局部范围），而不是将信息积累并筛选之后。

你曾经有多少次搜索一些你知道但却不记得确切位置的信息？多少次搜索无法找到它？秘密很简单：通常我们会通过含义记住信息（可能不是很精确），而不是通过它在文件系统或GUI中的位置。上述方法可能会改变这种找不到信息的情况，因为信息将与含义相关联。与记忆长文件或GUI路径或甚至使用类似词语进行搜索相比，记住相似的含义更容易些。

所有这些都为UI向自然语言的迁移开辟了更多的可能性。仅用自然语言还不能够控制UI。相反，UI至少在某种程度上应该“理解”自然语言。另外，用户应该明白他们处理的信息是什么意思。如果用户不理解信息的解释方式，用户会感到不舒服。看看现代的搜索：它能够繁荣发展的部分原因是因为用户习惯于其检索信息的方式。

当然，相当复杂的语义算法还有很多提升空间，但是对于独立计算机的小空间来说，它们太大了。用户需要根据明确的规则自行组织自己的信息空间，这些规则允许以约定的方式获取信息。这就是为什么用户需要理解语义本身。可能采用小型语义标记的形式（正如meaningful.js库所示），也可能是其他方式，但他们真的需要它，用户界面需要它。