开源软件开发者已经创建了大量的出色程序，这些程序提供了丰富的功能和良好的工作环境。在工作和家庭中，我经常在我的桌面上运行 Linux，使用 Firefox 和 LibreOffice 完成我的日常任务。我更喜欢运行开源软件工具，我认为大多数 Linux Journal 的读者也是如此。但是，尽管开源软件生态系统可能很舒适，但我们都分享或听到过关于我们最喜欢的一些 Linux 程序的相同评论

• “___ 是一个很棒的程序，一旦你弄清楚如何使用它。”

• “在 ___ 中你可以做很多事情，在你克服了笨拙的菜单之后。”

• “如果你能学会用户界面，你会喜欢使用 ___。”

这就是问题所在。无论程序多么强大，如果人们必须弄清楚如何使用程序才能解锁其秘密，那么该功能就会丢失。具有平均知识水平的普通用户应该能够操作通用程序。如果一个程序难以使用，那表明问题出在程序上，而不是用户身上。

可用性和开源软件

“可用性”指的是用户可以多么容易地学习和开始使用软件，或任何类似的“信息产品”。可用性与程序的功能是分开的，因此可用性测试与单元测试不同。相反，可用性测试使我们能够发现阻止用户使用我们程序的问题。

大多数开源软件程序是由开发者为其他开发者编写的。尽管一些大型开源程序，如 GNOME 和 Drupal，已经进行了可用性测试，但大多数项目缺乏资源或兴趣来进行可用性评估。因此，开源软件程序通常是功利主义的，专注于功能和特性，很少关注人们将如何使用它。应用可用性实践往往与开源软件的创建方式背道而驰。开源开发者更喜欢功能而不是外观。尽管一些项目可能有一个维护者来规定特定的设计美学，但更多的项目没有。在本文的一次采访中，开源倡导者埃里克·雷蒙德 (Eric Raymond) 向我评论说，大多数程序员将菜单和图标视为“你烤完蛋糕后在上面涂的糖霜”，这是一个恰当的比喻。开源软件开发者倾向于组装配料和烘烤蛋糕，而不是涂上糖霜使其看起来漂亮。

那么开源开发者如何才能轻松地将可用性应用于他们自己的程序呢？有很多方法可以实施可用性实践。爱丽丝·普雷斯顿 (Alice Preston) 在 STC 可用性 SIG 新闻通讯中描述了 11 种不同的评估可用性的技术。这些方法涵盖了从访谈和焦点小组到启发式评估和正式可用性测试的各种方法

1. 访谈和观察：与用户的一对一会话。

2. 焦点小组：通常在营销中使用，在任何类型的原型或产品进行测试之前，与来自目标用户群的多个参与者举行的有主持人的会议。

3. 小组评审或演练：主持人向多位参与者展示计划的工作流程，参与者对其进行评论。

4. 启发式评估：使用预定义的标准集，专业的可用性专家评审别人的产品或设计，并与设计师分享评论。

5. 走查式评审：设计或原型的副本被钉在会议室的墙壁上，并邀请测试人员检查它们并提出意见。

6. 自助式演练：制作设计的模型，并使用真实场景亲自演练设计。

7. 纸质原型测试：使用仍在设计中的虚假产品的真实场景。

8. 原型测试：比纸质原型更进一步，针对真实场景测试动画模型。

9. 正式可用性测试：使用稳定的产品、动画原型甚至纸质原型，针对受控的各种场景测试相当多的受试者。

10. 对照实验：对两种产品进行比较，并进行仔细的统计平衡。

11. 问卷调查：要求测试人员完成关于他们将如何使用设计的正式问卷。

然而，这种正式的可用性实践往往与开源开发者社区发生冲突，并且就像“逆着强大的文化逆风游泳”，借用埃里克·雷蒙德的比喻。考虑到这一点，开发者应该考虑适用于开源软件文化的一部分可用性方法。我提出以下列表

1. 启发式评估。

2. 原型测试。

3. 正式可用性测试。

4. 问卷调查。

您不需要多年的可用性经验即可在开源软件开发中应用良好的可用性实践。正如可用性专家 Janice (Ginny) Redish 在多篇文章中建议的那样，您只需与一些用户坐下来观看他们使用软件，就可以学到很多东西。

无论您选择哪种方法，可用性测试的价值在于在开发过程中实践它，而不是事后。在开发过程中迭代地应用可用性测试，使用原型，甚至是纸质模型。在每一轮测试中，您都会发现许多问题，您可以在下一个版本中解决这些问题。连续的可用性测试将发现更多问题，并进一步改进您的项目。

将可用性测试应用于您自己的程序

让我们通过一个可用性测试示例来了解一下。请记住，可用性测试的目的是发现普通用户在使用程序时可能遇到的问题。它不是程序功能的函数测试，而是程序易用性的实际测试，因此，它与质量保证或单元测试不同。

首先，定义一组书面场景，这些场景代表具有平均知识水平的典型用户将如何使用该程序。不要关注程序的每个功能，只需描述大多数用户希望使用该软件完成的任务即可。使您的场景尽可能真实；提供每个场景的简短描述，并要求测试人员在该上下文中执行任务。使用简单的语言；不要通过使用产品自己的词语来描述菜单项或操作来引导测试人员，尤其是在具有平均知识水平的典型用户不太可能每天使用这些词语的情况下。例如，如果您想评估一个编辑器，您的场景可能会要求测试人员键入一个简短的文本文档，保存它并对文件进行基本的复制编辑。对于 Web 浏览器，您的场景可以要求用户搜索一个网站，将其添加到书签，并保存该网页的副本以供离线使用。

邀请测试人员加入您的可用性测试。尽管您可能认为您需要大量用户才能彻底评估程序的可用性，但正如可用性专家 Jakob Nielsen 在他的研究中声称的那样，您实际上只需要大约五个测试人员即可获得有用的结果。向测试人员展示场景，一次一个，每个场景在一张单独的纸上，并要求他们完成任务。然后简单地观察他们在程序中做什么，他们完成任务的路径以及他们遇到的问题。做大量的笔记。

可用性测试中最困难的部分是观看测试人员努力寻找菜单或按钮。尽管正确的操作对您来说可能立即显而易见，但其价值在于学习和识别对其他用户来说不明显的内容。不要给出提示。如果测试人员无法完成某个场景，没关系；只需继续下一个场景。

在场景结束时，花几分钟时间向您的测试人员提出后续问题。找出用户觉得特别困难的任何领域。例如，您可能会问“当您尝试做 X 时，您遇到了困难；什么会使它更容易？”或“当您在做 Y 时，您期望在屏幕上看到什么？” 作为最后的总结，询问测试人员描述程序中哪些功能运行良好，以及应该改进哪些功能。

欢迎来到我的可用性测试

我在正式的可用性测试中审查了三个常见的开源项目。我这样做既是为了演示可用性测试过程，也是为了生成可以普遍应用于其他开源程序的可用性测试结果。为我的研究选择程序需要仔细考虑。我的演示的理想程序需要平衡多个质量：不要太大，因为非常复杂的菜单可能会让观众迷失在细节中并混淆可用性测试结果，也不要太小，因为微不足道的程序将不支持普遍适用的结论。此外，这些程序需要易于普通用户接受。

我在几个在线论坛上征求了建议，询问哪些开源软件程序具有良好的可用性。在筛选建议后，有三个项目符合我的可用性测试的标准

1. Gedit（GNOME 的文本编辑器）。

2. Firefox（流行的 Web 浏览器）。

3. Nautilus（GNOME 的文件管理器）。

因为我在大学校园工作，所以我邀请学生、教职员工和公众成员参与可用性研究。我没有要求特定的技术专业水平，因为我正在寻找具有平均知识水平的典型用户。在大多数正式的可用性测试中，通常会向每位测试人员提供少量酬金；我给他们免费的汽水和糖果，让他们在测试后带回家。

尽管我首选的目标是大约十几个测试人员，但我对参加可用性测试的七个人感到满意。他们的年龄从 20 岁到 40 岁不等，其中男性三人，女性四人。大多数测试人员（五人）声称计算机经验“低”，几乎所有测试人员（六人）都使用 Windows 作为其主要桌面。测试人员在运行 Fedora 17 Desktop Edition 的笔记本电脑上使用单独的访客帐户，因此他们从相同的初始默认设置开始。

在可用性测试开始时，我向每位测试人员简要介绍了可用性研究的背景。我解释说这是一项可用性测试，因此它是关于软件的，而不是关于他们的。如果测试人员在测试过程中遇到问题，我会让他们知道这没关系，我们可以继续进行下一部分。我只是在那里观察他们与软件的互动，而不是判断他们的表现。在此过程中，我说我会做笔记并观察他们屏幕上发生的事情。

我还要求测试人员在可用性测试期间大声说出他们脑海中的想法。例如，如果他们正在寻找“打印”按钮，他们应该简单地说：“我正在寻找‘打印’按钮。” 而且，我鼓励他们用眼睛跟踪屏幕上的鼠标光标，这样我就可以观察到他们在哪里寻找菜单和按钮。

在可用性测试期间，我向测试人员展示了许多场景，每个场景都提供了一个简短的背景和他们要完成的操作。例如，在要求测试人员在 Firefox 浏览器中导航到 BBC 新闻网站后，一个场景要求他们增加屏幕上文本的大小。重要的是要注意，该场景没有使用与菜单操作中存在的措辞相同的措辞来应用字体大小更改

你没有戴眼镜，所以很难阅读 BBC 新闻网站上的文字。请将 BBC 新闻网站上的文字放大。

总的来说，可用性测试包括 19 个场景，测试人员在 30-40 分钟内完成。

可用性问题是什么？

热图是表示可用性测试期间发现的问题的好方法。在图 1 中，每一行代表一项任务，每个方块代表测试人员的体验。绿色方块表示测试人员能够轻松完成任务，通常是第一次尝试。橙色和红色方块表示测试人员遇到困难或无法完成任务的场景。

图 1. 可用性热图

有趣的是，几乎每个人都遇到了相同的四个问题

• G5：更改 Gedit 中的默认字体。

• G6：更改 Gedit 中的默认颜色。

• N4：在 Nautilus 中创建文件夹的书签或快捷方式。

• N6：在 Nautilus 中搜索文件。

在 Gedit 中，测试人员对于如何设置默认字体和颜色感到非常困惑。部分困惑源于将编辑器视为文字处理器，例如 Microsoft Word，它使用工具栏上的项目来完成任一操作。测试人员报告说他们正在寻找名为“字体”的菜单项。失败后，测试人员还在“文件”、“编辑”、“查看”和“工具”中查找。

图 2. Gedit 屏幕截图——“如何更改字体？”

在 Nautilus 中，测试人员在尝试创建文件夹的书签或快捷方式时感到沮丧，唯一成功创建书签的用户后来评论说她这样做是偶然的。正如场景中所解释的那样，该文件夹将用于收集照片的项目，并且位于“图片”文件夹中。

最常见的操作是进入“图片”文件夹，单击项目文件夹，然后选择“书签 - 添加书签”。Nautilus 不会显示“添加书签”仅创建当前位置的书签，而不是突出显示的项目”的效果的消息，因此测试人员在没有任何反应时感到困惑。

图 3. Nautilus 屏幕截图——“如何创建文件夹的书签或快捷方式？”

同样，大多数测试人员发现搜索 Nautilus 中的文件是一项困难的任务。他们没有意识到“搜索”功能从当前文件夹开始，而不是从他们的主目录开始。只有两位测试人员成功使用了“搜索”。在这些人中，有一位碰巧从主目录单击了“搜索”按钮。另一位尝试更改下拉“搜索”操作中的选项，直到最终选择了一个有效的组合。一位测试人员放弃了“搜索”，并依次导航到每个文件夹以查找文件。另一位用户选择根本不使用“搜索”，而是使用了相同的“查找”方法。

尽管 GNOME 不是可用性测试的一部分，但几乎所有测试人员都对 GNOME“活动”菜单热角感到困难。在 GNOME 桌面环境中，“活动”菜单显示可用程序列表以及正在运行的应用程序的视图。用户可以通过单击桌面左上角的菜单图标或将鼠标移动到该角（“热角”）来调出“活动”菜单。通常在第一个场景中，测试人员会“过冲”他们正在寻找的程序菜单，而是点击 GNOME 热角。这在整个可用性测试中也发生了几次。尽管测试人员能够从热角恢复，但它确实造成了频繁的干扰。

哪些方面对可用性有效？

在整个研究过程中，我观察到四个良好的可用性主题，这些主题使所有测试人员都能够快速通过可用性测试的这些部分

1. 熟悉性：测试人员评论说，这些程序的操作或多或少类似于 Windows 或 Mac OS X 中的对应程序。例如，Gedit 与 Windows 记事本甚至 Microsoft Word 没有太大区别。Firefox 看起来像其他 Web 浏览器。Nautilus 与 Windows 资源管理器或 Mac OS X Finder 非常相似。在某种程度上，这些测试人员已经在 Windows 或 Mac OS X 下接受了“培训”，因此拥有与 Windows 或 Mac OS X 体验大致等效的功能（以及这些功能的路径）是他们成功的关键部分。

2. 一致性：三个程序之间的用户界面一致性对测试人员非常有利，并且是良好可用性的一个反复出现的主题。右键单击在所有程序中都有效，可以调出上下文相关的菜单。程序看起来和行为方式相同，因此测试人员不必“重新学习”如何使用下一个程序。尽管工具栏有所不同，但所有程序都共享一个熟悉的菜单系统，其中包含“文件”、“编辑”、“查看”和“帮助”。

3. 菜单：测试人员更喜欢从菜单而不是通过工具栏上的“热键”或图标访问程序的功能。例如，测试人员在 Gedit 场景中使用的唯一工具栏图标是“保存”按钮。为了完成其他场景，测试人员使用了下拉菜单，例如“文件”、“编辑”、“查看”和“帮助”。

4. 显而易见性：当一个动作产生清晰的结果，或清楚地表明成功（例如在编辑器中保存文件、在文件管理器中创建文件夹、在 Web 浏览器中打开新选项卡）时，测试人员能够快速完成场景。当一个动作没有产生明显的反馈时，测试人员往往会感到困惑。当尝试在 Nautilus 文件管理器中创建书签或快捷方式时，这种对比非常明显。在这种情况下，Nautilus 没有指示书签是否已创建，因此测试人员不确定他们是否已成功完成该活动。

图 4. Firefox、Nautilus 和 Gedit 界面比较

这些是关于开源软件和可用性的良好教训。您的程序的用户界面不必是理解的漂亮障碍。相反，利用现有的用户界面范例。与同一平台上的其他程序保持一致，无论是其他开源软件还是专有程序。使用标签清晰的菜单。确保每个操作都有最终用户显而易见的结果，尤其是在该结果表明失败的情况下。

我们接下来该怎么做？

可用性不应该是仅仅附加到项目上的东西，或者仅在开发生命周期结束时在发布软件的下一个版本之前解决。可用性需要成为开源软件设计的一部分，并作为流程的一部分来解决。作为开源软件开发者，我们通常非常擅长将良好的软件开发实践应用于我们的工作。现在我们需要迈出下一步，将可用性纳入该方法论。

我们在开源软件中的下一个挑战是找到将可用性融入我们的开发者文化的方法。这是开源软件的一大步。迄今为止，可用性与开源开发者的工作方式背道而驰。大多数项目是由开发者为其他开发者编写的。制作新功能是首要任务，我们很少关注用户将如何尝试访问这些功能。

在开源软件项目中，用户社区在新版本的测试中发挥着重要作用。不幸的是，我们不能依靠典型的用户测试周期来提供良好的可用性反馈。在没有可用性测试结构的情况下，开源软件测试人员会做出平淡的错误报告，例如“此功能令人困惑。” 这对开发者没有帮助。此外，可用性研究人员 David Nichols 和 Michael Twidale 在他们发表的作品中评论说，开发者可能不会给予可用性问题与功能错误相同的地位，从而导致开发者对可用性错误的固有偏见。

因此，识别开源软件中的可用性问题的方法需要更加结构化。开源软件开发者可以应用多种方法，尽管理想的方法是与少数用户进行正式的可用性测试。请记住，您只需要大约五个测试人员即可获得有用的结果。

开源软件项目的可用性测试不需要在沉闷的实验室环境中进行；项目可以找到与用户社区“众包”可用性测试的方法。例如，开源 Web 内容管理系统 Drupal 在进行可用性测试时流式传输了测试人员的桌面。这使世界各地的 Drupal 开发者无需前往单个地点即可观察可用性测试。当开发者可以观看测试人员在使用他们的软件时遇到问题时，他们会更好地理解这些问题以及如何解决这些问题。

另一种简单的方法是通过“快闪”进行可用性测试，这是 Dana Chisnell 在她的 Usability Testing Howto 博客上提出的一个术语。要通过快闪进行测试，研究人员只需在公共场所拦截人们，并要求他们针对纸质原型尝试一些场景并分享他们的经验。如果每个受试者都愿意抽出几分钟时间，“一群”这样的测试人员将在短时间内提供有价值的反馈。这种“快闪”可用性测试的想法也可以扩展到其他领域。如果您的开源软件项目作为网站实施，您可以通过拦截网站访问者来进行类似的临时可用性测试。

您不必成为专家即可在开源软件中应用可用性测试。任何人都可以做到。您只需要观察用户尝试使用程序，可用性问题很快就会变得清晰。少数测试人员针对原型进行操作可以为您提供使您的开源软件更易于使用所需的反馈。有了良好的可用性，每个人都是赢家。

资源

开源软件和可用性（作者的博客）： http://opensource-usability.blogspot.com

关于可用性和可用性测试的更多信息： http://usability.gov

Janice (Ginny) Redish 论可用性（Web 开发者的良好参考）： http://www.redish.net

Jakob Nielsen 论可用性： http://www.useit.com