ubuntu 12.04 评测（一）：unity 界面 | 极客公园

极客公园 • 11年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

dash 和 lens

dash 是 unity 的应用管理和文件管理界面。点击左上角的 ubuntu 标志或者在桌面按下 super 键（windows 键/command 键）即可进入，lens 是 dash 界面下方的一行图标，点击每个图标都可以切换到对应标签页，每个标签页致力于满足用户的一类特定需求。dash 界面的基本结构如下：

dash 在首页上显示最近使用的应用、打开的文件和下载的内容，而其后的各个 lens 则分别满足各项特定的需求，默认的 lens 有软件（应用程序管理）、文件（文件管理）、音乐（音乐管理）和视频（视频管理）。每个 lens 都可以对相关的内容进行搜索、展示和分类过滤。

此外，用户还可以自行添加 lens 来满足特定的需求。例如社交网络 lens 可以快速地搜索、显示和过滤社交网络信息：

海盗湾的 lens，找种子什么的变得很简单：

当然，作为一种刚性需求，色情内容 lens 肯定也是有的：

并且和我们先前介绍过的 snatch.ly 一样，也可以按照自己的偏好来过滤结果：

dash 的这种界面布局和 lens 的可扩展设计看起来是比较理想的，然而，在真正使用的时候却并不一定能为用户提高效率。以最为人诟病的应用管理 lens 为例：

在采用 unity 界面之前，ubuntu 采用的是 gnome 2 的经典用户界面，在这个界面上，寻找特定的应用程序是一件非常简单的事情，因为所有的应用都得到了妥善的分类和直观的展示，三次鼠标点击之内就可以找到应用程序。

而在 unity 上，应用管理 lens 默认显示的三行程序中，第二行“已安装”程序是按照首字母顺序来排列的，这样的排列方式很难为用户提供快速定位应用的方便，因为很显然大多数情况下用户进入这个 lens 并不是为了寻找排在最前面的 “amd 显卡催化剂控制中心” 等应用。第三行“可供下载的软件”对于用户来说意义也并不大，当用户已经配置好各种软件之后，他是很少会再去软件中心额外安装更多软件的。

此时用户有两种选择，一种是展开第二行的所有“已安装”软件，然后通过右侧的类型过滤器对结果进行过滤。而过滤器的行为也是存在问题的，因为当用户在一个类型中找不到所需的软件而要转到另一个类型时，系统默认会同时选中这两个类型，而不是在两个类型中进行切换。用户会面对很多已经确定不需要的候选结果。

第二种选择是在上方的搜索栏中进行搜索。而 unity 的搜索栏并不智能，大部分情况下，除非你能记住程序的准确名称，否则你是很难通过搜索得到相应程序的。举例来说，在播放音乐方面，我比较喜欢 banshee 播放器而不是系统自带的 rhythmbox，而除非我每次都拼写和搜索“banshee”，否则常规的模糊查询词汇是无法找到这个程序的。例如搜索“音乐”，unity 只给出了 rhythmbox（因为其全名是“rhythmbox 音乐播放器”），而同样作为音乐播放器的 banshee 却不见踪影（因为其全名是“banshee 媒体播放器”，不包括“音乐”字样）。

与此形成对比的是，在 mac os x 上同样搜索“音乐”，系统将会识别和列出安装的所有音乐相关程序，即使结果中的 itunes，diumoo 和 garageband 在名称中都不包含“音乐”字样也毫无影响。

launcher 与 quicklist

unity 界面的最左侧部分是一条纵向的快速启动条，正式名称是 launcher。快速启动条上的图标有三类：系统强制放置的功能图标（dash 主页、工作区切换器和回收站），用户自定义放置的常用程序图标，以及正在运行中的应用程序图标。

launcher 的用户体验中规中矩，细节处理得相对比较理想。程序图标的左右两侧可以附加小三角形指示标志。正在运行的程序图标会在左侧有小三角形指示，如果正在运行的程序包括多个窗口，则小三角形的数量也会随之变化。而当前的活动窗口所属的程序，则同时还会在图标右侧显示一个小三角形进行指示。

当 launcher 上图标增多，开始超出屏幕纵向范围时，最下侧的图标会自动进行折叠。

这样的做法显得新颖而美观，然而却在一定程度上给用户造成了不便。因为在系统操作中非常重要的“工作区切换器”和“回收站”这两个图标是强制固定在 launcher 最下方的，因此几乎无法逃脱被折叠的命运。当这两个图标被折叠时，无论是切换工作区还是将文件拖进回收站的操作都会变得不那么简单。

在图标上点击右键，可以调出 quicklist，quicklist 中包括一些与程序本身相关的常用任务。例如用户可以在 chrome 浏览器的 quicklist 中直接启动一个隐身窗口。

这样的右键菜单在 winodws 7 和 mac os x 中都有存在，而与这两者不同的是，unity 的 quicklist 可以自行编辑项目和添加常用任务。例如作为一个经常需要“科学上网”的人，经过我编辑定制的终端 quicklist 是这样的：

全局菜单

要让 firefox，thunderbird 和 openoffice 等程序支持全局菜单相对比较困难。

很多其它应用程序的开发者也应当做出一些优化，以将传统的“每个窗口有不同菜单栏”的显示方式转换到单一菜单栏上来。

——mark shuttleworth

上面这段话是 mark shuttleworth 第一次宣布采用全局菜单的决定时指出的两个问题。可以看到他对全局菜单存在的问题有着清醒的认识，并且很有自信在未来的开发中解决这些问题。然而很遗憾的是，两年时间过去了，ubuntu 的全局菜单依然实现得并不理想，上述两个突出问题依然存在。

unity 的全局菜单行为

unity 的全局菜单会在不同的状态下显示不同的内容。

当窗口未被最大化，且鼠标未悬停在全局菜单位置时，该位置只显示程序名称。
当窗口未被最大化，且鼠标悬停在全局菜单位置时，该位置显示部分窗口名称和菜单内容。
当窗口最大化，且鼠标未悬停在全局菜单位置时，该位置只显示程序名称。
当窗口最大化，且鼠标悬停在全局菜单位置时，该位置显示窗口控制按钮和菜单内容。

可见，当用户不需要使用全局菜单时，鼠标不会悬停在全局菜单位置，此时该位置只显示程序名称，以减少对用户的打扰。而当用户需要使用全局菜单时，鼠标会悬停在全局菜单位置，此时全局菜单才会出现。

一个显示出设计团队精细用心的地方是，当程序名称过长时，全局菜单会“吞掉”一部分程序名称，以确保不管处于什么状态，打开的是什么程序，全局菜单的各个项目都是基本对齐的，且第一个项目总是出现在同一个地方。

缺陷一：程序名称？窗口名称？

在 unity 中，顶部的全局菜单总是显示程序名称，而窗口的标题栏则总是显示窗口名称。

在大多数时候，这并不是一个问题，因为程序名称和窗口名称一般是一致的。然而当程序名称和窗口名称不一致时，用户将受到一定的困扰。

例如，文件管理器的程序名称是“主文件夹”，因而任何时候全局菜单栏都会显示“主文件夹”。而其窗口名称会随着打开文件夹名称的不同而变化。于是就会出现下面的情况：全局菜单栏上显示的是“主文件夹”，而窗口标题栏上显示的是“极客公园”。由于“主文件夹”也是文件系统的一部分，因而用户可能会对这样的不一致感到困扰。

在这个例子中，问题出在了“主文件夹”这个程序名称上。如果程序名称是“文件管理器”，那么这样的困扰便可以得到缓解。

缺陷二：全局菜单？窗口菜单？

传统上，linux 系统和其它大部分桌面操作系统一样，每个窗口都有自己的菜单。ubuntu 所做的“全局菜单”，在大部分情况下只是机械地把窗口上的菜单搬到顶部面板而已，而并没有针对全局菜单这一显示方式进行对应的优化。在使用中，这样简单粗暴的做法给用户造成了很多不便。

例如，在 mac os x 上，打开一个文件属性窗口的同时，如果想要再打开一个文件管理器窗口，则可以很方便地直接从全局菜单上选择“文件”-“打开新窗口”。因为文件属性窗口是附属于文件管理器的，而文件管理器只有一个唯一的全局菜单。

而在 ubuntu 12.04 中，打开一个文件属性窗口的同时，如果想要再打开一个文件管理器窗口，则必须先将焦点切换回文件管理器窗口，再从全局菜单上选择“文件”-“新建窗口”。因为文件属性窗口本身并没有菜单栏，因此当焦点处于文件属性窗口时，顶部的全局菜单面板上将不会有任何东西出现。

可见，一个合格的全局菜单系统，必须确保每个程序的所有窗口都只有单一的全局菜单内容，而 ubuntu 显然并没有做到这一点，在 ubuntu 中，同一程序之下的各个窗口是互相分裂的，各自有各自的全局菜单栏内容。

机械地把当前窗口菜单栏内容搬运到全局菜单位置的做法造成的另外一个不便之处是将很多原本不必要搬到全局菜单上的东西放到了全局菜单位置。例如当在 firefox 浏览器中打开 autoproxy 配置窗口时，这个窗口的菜单内容居然也会被搬到全局菜单位置上。

缺陷三：有效显示？无效显示？

ubuntu 的开发者们提供了一种方式，可以自动把窗口上的菜单栏搬到顶部面板显示，而不需要程序开发者额外做出任何修改。这种方式适用于普通 gtk 和 qt 程序。而其它特殊类型的程序则无法通过这种方式自动获得全局菜单特性。这就导致了非常尴尬的情况：大部分程序成功获得了全局菜单，而一小部分程序则无法使用全局菜单。

在系统预装的应用程序中，无法自动使用全局菜单的应用程序主要是 firefox、thunderbird 和 libreoffice 套件。ubuntu 的开发者们通过给 firefox 和 thunderbird 预装附加组件的形式变相解决了这两个程序中的全局菜单问题，而对于 libreoffice，这个问题则一直没有得到解决。

由于同样的原因，很多常用常用软件也无法使用全局菜单特性，例如基于 java 的脑图绘制软件 freemind，而常用的浏览器 google chrome 更是在各种配置方式下都无法与全局菜单和默认界面风格和谐相处。经常发生两套窗口控制按钮并存、或者界面风格互相冲突的混乱情况。

hud 菜单

hud 菜单（head-up display）是 ubuntu 12.04 最引人注目的新特性之一。mark shuttleworth 在宣布这一功能时自豪地表示这将是对传统菜单系统的一次革命。根据他的表述，hud 菜单的理念是“告诉系统你的需求，系统就会自动满足你”。hud 菜单将解决传统菜单的三项缺陷：

寻找不易。传统的多层式菜单结构对于用户来说不够友好，初级用户很难在层层叠叠的菜单中找到他们需要的选项。对于大型专业软件来说尤其如此。hud 菜单让用户提出需求，由系统自动挑选出合适的操作并推动到用户眼前。
效率低下。在传统的多层式菜单结构中，用户不得不使用鼠标多次展开菜单才能找到和点击所需项目。为了提高效率用户需要记忆各种复杂的快捷键组合。在 hud 菜单中，用户只需按 alt 键触发 hud 界面，然后直接用键盘搜索，用鼠标回车触发操作，全过程不需要依赖鼠标，也不需要记忆任何快捷键。
位置混乱。在不同的程序和不同的操作系统中，同一个菜单项的位置往往各不相同。例如 firefox 浏览器的“设置”菜单项在 windows 上位于“工具”下，而在 linux 上位于“编辑”下，而在 chrome 中“设置”菜单项又被藏到了地址栏左侧的按钮里。这样的混乱状况给用户带来了很大的不便。使用 hud 菜单之后，用户只需要告诉系统需要使用“设置”这个菜单项目，而无需记忆这个项目在不同的平台，不同的程序中分别位于哪里。

mark shuttleworth 表示，hud 菜单的长远目标是彻底取代掉传统菜单栏，而未来也会向语音方向继续改进，未来用户甚至不需要动用键盘，直接把需求说出来就能自动得到满足。

hud 菜单的概念为我们展示了 linux 桌面系统在人机交互上的美好未来，然而当前阶段的 hud 菜单实现方式却显得相当原始：系统只是简单地索引了程序的菜单内容和通知区域的各种内容，用户可以按下 alt 键触发 hud 菜单界面，然后在搜索框中直接搜索和执行菜单中的项目和通知区域的各种功能。当前阶段用户已经可以通过 hud 菜单做到以下一些任务：

快速寻找菜单项目。在 gimp 和 inkscape 等大型软件中，用户可以不再从层叠的菜单中慢慢寻找需要的选项，通过 hud 菜单可以快速找到选项完成任务。
快速打开浏览器书签和历史地址。由于 firefox 浏览器会直接把书签内容和历史地址放在菜单里，因此用户现在可以方便地通过搜索来打开书签和浏览历史中的项目。
快速处理社交信息。由于 ubuntu 将各种社交工具的信息聚合到了通知区域的信息指示器图标里，因此用户现在可以直接通过 hud 菜单来完成修改即时聊天工具状态、撰写和查看邮件和发微博等常见任务。
快速修改系统状态。由于 ubuntu 系统将与系统状态相关的各种选项都聚合到了通知区域的各种指示器里，用户现在可以直接在 hud 菜单中完成连接 vpn、锁定屏幕、关机和重启等相关的操作。

虽然尚处于初级阶段的 hud 菜单已经可以让用户完成一定的工作，但是当前版本的 hud 菜单仍然存在很多突出的缺陷，使其无法被广泛应用，对于中国用户来说更是如此。

适用性不高

从前文对全局菜单的分析中我们可以看到，目前全局菜单尚未被完整地应用到整个系统。随之而来的坏消息是，hud 菜单目前却仅支持有全局菜单的应用程序。那些希望从此不再埋头于 libreoffice 办公套件谜一样的层叠菜单里的用户要失望了，指望借助 hud 菜单快速画出脑图的 freemind 用户也要失望了。情况类似的应用程序还有很多。

快捷键冲突

hud 菜单通过 alt 键进行触发且这一设置无法修改。而 alt 键在其它程序中有很多用途，二者会发生冲突。例如：

由于 linux 版 qq 不给力，linux 用户广泛使用 webqq，而最新版 webqq 的发送消息快捷键中使用到了 alt
很多 linux 用户通过 wine 运行《魔兽争霸 3》以便玩 dota 等流行的游戏，在 dota 中，显示人物生命值的快捷键是 alt
几乎所有的韩语 linux 用户都使用 alt 键来切换输入状态，当不胜其烦的韩语用户向开发团队报告这一冲突问题时才发现，原来开发团队成员武断地以为全世界的输入法用户都使用 ctrl+space 来切换输入法

事实上，mac os x 提供了一个与 hud 菜单理念不同但功能类似的菜单项目搜索特性，触发这个特性的快捷键是 command+shift+/，mac os x 用三键组合的方式规避了可能的快捷键冲突，而 ubuntu 让 hud 菜单独占 alt 键，导致冲突几乎是不可避免的。

匹配内容广度和精度低下

目前阶段 hud 菜单能够进行匹配的内容范围很小，仅限于程序本身的菜单项目和通知区域的内容。因此如果你想要通过 hud 搜索到某项东西，必须先让它出现在菜单里。这样机械的行为大大限制了 hud 菜单的能力。

例如，在巨大的曲库中快速找到音乐并播放是很多音乐爱好者的重要需求，而官方的 hud 菜单演示视频里也确实显示 hud 菜单可以用来在 banshee 音乐播放器中控制乐曲的播放。但实际上，当你打开 banshee 音乐播放器，在 hud 菜单里搜索音乐内容不会看到任何结果：

带上放大镜仔细查看官方的视频演示之后发现，官方演示者居然在展示 hud 菜单控制音乐之前先把音乐全都加到了书签里，用这样的方法来强行使音乐名称出现在菜单中，然后才可以用功能有限的 hud 菜单来“控制”音乐播放。很显然官方为了展示这个功能，背弃了“书签”的正常用法。

中文支持非常差

和其它操作系统类似，ubuntu 预装的 ibus 输入法框架也不是同类产品中最好的。很多用户会另外安装 fcitx 等其它输入法解决方案。而由于种种原因当前版本的 unity 界面却仅支持使用 ibus 进行输入，其它类型的输入法无法在搜索框内输入汉字。这意味着大量中文用户将无法享受到 hud 菜单带来的便捷体验。

此外，从 mark shuttleworth 的介绍和相关的本地化文件中我们可以看到，为了让用户更好地搜索到想要的结果，hud 菜单对搜索结果采用了智能排序和模糊匹配的优化方法。例如当用户搜索“file”时，即使其不小心输入了“fiile”，也可以获得“file”这个想要的结果。

然而类似这样的模糊匹配却并未被应用到中文里来，中文用户要使用 hud 菜单，首先必须使用 ibus 输入法，其次还必须从头开始输入菜单内容，如果输入的信息只是菜单中的一个词，那么 hud 菜单将无法准确判断出用户的搜索意图。

例如，banshee 音乐播放器中有一个菜单项叫做“修复音乐元数据”，当在 hud 中搜索“修复”的时候，这个选项会出现在候选列表中，但是如果用户并不熟悉菜单项目的具体措辞，而仅仅输入了关键字“元数据”，那么用户什么结果都不会得到。

叠加式滚动条

叠加式滚动条（overlay scrollbar）是 unity 界面的另一个与众不同之处。叠加式滚动条由一个主滚动条和一个叠加滑块组成。传统滚动条上下两侧的箭头按钮被集成到叠加滑块上。在用户不需要操作滚动条时，窗口将只显示主滚动条，为了尽量减轻对用户的打扰，主滚动条被做得非常细。当用户将鼠标移动到滚动条上开始使用时，叠加滑块将自动出现，用户可以拖动滑块来滚动窗口内容，也可以用鼠标点击滑块上的上下箭头来滚动窗口内容。

根据 ubuntu 设计团队官方博客的说法，这样的做法主要是为了节省触摸屏和小屏幕设备上的空间，缩减滚动条的宽度，将最大的窗口显示面积留给用户，而当用户确实需要滚动窗口时，叠加滑块又可以即时出现来满足用户的需求。

这样的想法确实是很不错的，然而在实际的实现过程中却暴露出了种种缺陷，例如：

缺陷一：滚动条与滑块不同步

ubuntu 设计团队试图用滚动条和滑块分离的方式来优化小屏幕和触屏的滚动体验，然而在实际的使用中，主滚动条和叠加滑块的行为经常不同步，当主滚动条到达顶部或底部不再运动时，滑块却仍然可以运动，而这样的运动却又不会对窗口内容造成任何影响。如下面的视频所示：

缺陷二：滚动条样式不统一

与全局菜单和 hud 菜单的处境一样，这样的叠加式滚动条样式仅在一部分程序中有用。系统预装程序中的老大难问题依然是 firefox 和 libreoffice，而其它一些常用程序也无法使用这个滚动条样式。下面这张图展示了常用程序中的各种滚动条样式中的四种，从左到右依次为 gedit（标准叠加式滚动条）、hotot（彩色滚动条）、chrome（方形滚动条）和 firefox（圆角滚动条）。