为何 Linux 桌面应该按任务来组织管理？

【51CTO.com 快译】眼下不是桌面环境方面进行大胆创新的时候。用户反对KDE、GNOME和Unity的一幕还历历在目，开发人员不会试图 对桌面环境作出重大变化。相反，更偏爱没人容易心烦意乱的功能方面的调整和细小改进。我仍然认为，桌面早就该换成基于任务的设计了。

在过去，桌面按应用程序来组织管理。这种方法在个人计算的早期很适用，那时候应用程序数量不多。而如今，至少从两个方面来看，这种方法完全过时了。

首先，应用程序的名称往往很少体现功能。Amarok、K3B(哪怕使用完整的写法Burn Baby， Burn)和Shotwell都是一流的应用程序，但是没有人能从它们的名称中猜出其功能。连Libreoffice的名称也只是含糊地表明了用途。像 Pysol(Python   Solitaire)或digiKam(数码相机)这些应用程序的名称在普通菜单的应用程序中只占三分之一，连这样的名称，意思都不太明了。

应用程序名称含糊的这种情况，通常归因于基于任务的顶层菜单。比如说，当Scribus和Xsane都列在Graphics下方时，引导作用极其有限。

其次，也是更重要的是，普通的现代电脑有太多的应用程序，按名称来显示它们已变得越来越不切实际。

经典菜单不是对屏幕来说太长，就是子菜单溢出屏幕，直到它们几乎不被使用。替代办法也不是特别成功。只显示一小部分应用程序有可能让用户不知道已安装的全部程序，哪怕添加上搜索栏也是如此。

同样，虽然由于缺少空间，独立的菜单屏幕在移动设备上可以接受，但是在工作站上，只会让人分心。经典菜单的替代方法一直梦想的设计是：尽量减少鼠标点击次数，让用户可以尽快回去处理工作。

基于任务的替代方法

想解决这个设计问题，最快捷的办法很可能是基于任务的设计。可问题是，基于任务的设计只是偶尔在桌面环境中合情合理。除了在顶层菜单中以外，如果用户选择，它可以与虚拟工作区一起有限地实施；比如说，一个工作区专门用于上网冲浪，另一个工作区用于收阅电子邮件。

除此之外，实施基于任务的桌面的一大举措就是KDE Activities――它们似乎太激进了，缺乏详细的解释，未能流行起来。

然而，你设置好Activities后，最先一目了然的一点是，相比任何一种菜单，每个Activity需要的桌面图标比较少。即使工作区上有文档 和URL，KDE   Activity也很少需要十多个图标，常常五六个图标就可以了。因而，所有必要的资源都只要点击一下鼠标就能获取，极少需要搜索就能找到这些资源。

换句话说，你在使用某个特定的任务时，可以像个人计算的早期那样临时回到原来的情形，那时候应用程序数量不多，不至于让人无所适从。或者，换一种方式说，你使用一种更有针对性的Favorites(最喜爱的程式)菜单。

就个人而言，我很喜欢Activities；如果我使用除KDE之外的任何桌面，要是没有Activities就会觉得无计可施。不过，我很想知道它们能不能再迈进一步。

具体来说，何不让任务成为一直贯彻到菜单的组织原则?GNOME菜单中已经倾向于采用这种组织，“Document   Viewer”取代了“Evince”，“Movie Player”取代了“Totem”。从各方面来考虑的话，把“LibreOffice   Cals”换成“Spreadsheets”或者把“Firefox”换成“Web   Browser”不会是多大的变化。许多桌面图标用户已经进行了这种变化，几个次要的发行版也是如此。

这种解决办法有望消除应用程序名称与功能毫无关系的问题。让菜单项可以编辑，它们还会减少菜单的长度，让它们可以在单页上全部显示。

按名称组织的视图可能仍会留下来，完全用于参考，但在普通环境下，菜单只会显示任务；如果是替代方法，可能会显示子菜单。一些应用程序安装时已经为它们分配了任务，而额外的任务可以由用户来添加。

结果就是立即易于理解、高效、个性化，而这些都是Linux桌面用户所偏爱的。

改变的意愿

当然，我认识到，在当前情况下，不可能实现这种变化。在科幻作家Harlan  Ellison笔下的世界里，我不仅在搭建空中楼阁，还打算头一个月就搬进去。

不过，变化不会很大，适应变化也不会很难。大多数桌面环境已经允许选择默认的常用应用程序来打开文件。让整个菜单都基于任务只需要更多的同一选择，随之而来的高效很快会证明有必要花这番力气。

最重要的是，围绕任务构建桌面可以消除所有精心制作但常常很烦人的基本菜单的替代方法，让用户可以更快速地浏览。其实只要愿意实施变化，但假设这一幕果真出现的话，也不太可能会在几年内出现。

原文标题：Why the Linux Desktop Should Be Organized By Tasks，作者：Bruce Byfield

本文转载自 51CTO.com