Ribbon界面介绍

http://hi.baidu.com/hoping/item/b257e10e99ed7312cd34ea1d

Ribbons

Ribbon是现代化的方式帮助用户高效和直接的查找、理解和使用工具命令——通过最少的点击，减少从“尝试-错误”（trainl-and-error）方式中恢复操作，寻找新的操作的需要，并且不再需要区查看软件帮助。

Ribbon是一种命令工具条（command bar），将软件的功能集成到窗口上方的一系列标签（tabs）中。使用Ribbon可以使得软件的功能和特性更容易被用户发现，加快软件整体学习的速度，使用户能够根据他们自身的经验更好的控制整个程序。Ribbon可以代替传统的菜单栏和工具栏。

图 1一个经典的Ribbon工具栏

Ribbon标签（tabs）有许多“组”（group）构成，这些组中一些密切相关的功能的集合。出了标签和组，ribbons还包括：

一个应用程序按钮（Application Button），会弹出一个命令菜单，其中的命令会对整个文档或者工作空间做一些操作（笔者注：如保存，设置属性等），或者利用文档或者工作空间做一些事情（笔者注：如打印，发送邮件等），比如一些和文件相关的操作。
一个快捷工具栏（Quick Access Toolbar）,是一个小的自定工具栏，显示常用的工具。
核心标签（Core tabs）：总是会显示的标签面板。
上下文标签（Contextual tabs），只用当特定标签的对象被选中时才会显示。一直会显示的标签成为核心标签（Core tabs）
标签集（tab set）是针对某一特定标签的对象的标签面板的集合。因为对象可能属于不同个类型（例如一个表格中带有图片的的标题具有三个类别），可以有多个上下文标签组同时显示。
模态标签（Modal tabs），是一类特殊的核心标签，能够显示特定的临时模块，比如打印预览。
库按钮（Galleries），是以图形化显示的命令或者选项的列表。一个基于结果的库按钮显示了这个命令或者选项的会产生的效果，而不仅仅是命令本身。一个Ribbon内的库按钮（In-Ribbon gallery）是在Ribbon内的库按钮，代替弹出窗口的作用。
加强型提示（Enhanced Tooltips），简明的解释他们对应的命令的，并提示对应的快捷键。这些提示往往还带有响应的图形和帮助参考。加强型提示减少了使用功能帮助的可能性。
对话框加载按钮（Dialog Box Launcher），是一些在“组”下面的按钮，使用这些按钮，会弹出包含和功能组相关的特性的对话框。

Ribbon最初是和Microsoft Office 2007一同发行的。如果想要学习为什么Office和许多其他的软件使用Ribbon界面作为界面解决方案，可以参考The Story of Ribbon。

如果希望更多的了解如何应用Ribbon界面取代传统使用的菜单栏和工具栏，可以参考Ribbon Design Process。

Note：对于菜单，工具栏，命令按钮和图标的指导会在不同的文章中进行讲述。

关于使用Office UI的授权，请参考Office UI Licensing。

源文档参考：http://msdn.microsoft.com/zh-cn/library/cc872782.aspx#rightui

这是不是合适的用户界面（Is this the right user interface?）

如果决定使用Ribbon，你需要考虑如下问题：

程序类型（Program Type）

你正在设计的程序是什么类型的？程序的类型是Ribbon是否合适的最佳风向标。Ribbon界面对于文档创建和写作是十分合适的，同样还有文档查看和浏览器。Ribbons可能在其他类型的程序也有良好的表现，但是其他类型的命令表达方法可能更加合适。一般来说，轻量级的程序应该配套响应的轻量级的命令表达方式。（对于程序类型，微软提供了一个程序类型列表，可以查看Program Command Patterns）。

功能和可发现性和一些关于程序学习的问题

用户是否在寻找响应命令时遇到困难？用户是否提出一些程序已经实现的需求问题？如果你遇到这种情况，使用Ribbon可以使得用户更加容易找到一些具有能够自己介绍和解释自己的标签和相关命令组。使用Ribbon可以在将来软件维护时相对于菜单和工具栏缩放更加容易（笔者注：原文是scales better，应该是更容易更改命令的排列而不引起Ribbon的大小的变化，进而对于整个用户界面影响很小。另外吐槽一下，其实很多人认为使用ribbon后他们更难找打需要的命令，他们认为图形不如文字直观，特别是对于一些他们已经熟悉的软件，这时在选用ribbon时应该更加的小心）。
用户是否无法理解程序的命令？他们是否凭借"尝试——失败"（trial and error）的方法来寻找正确的命令，判断哪一个命令是正确的？如果是这样的话，使用Ribbon和面向结果的命令，特别是库按钮和实时预览可以帮助命令更加容易理解。

命令特性

一些同样的命令是否会出现在程序的许多地方？如果你的程序已经存在，你的命令是不是会出现在菜单栏、工具栏、任务面板以及工作区域内？如果是这样，使用ribbon可以将一个命令放置到程序中唯一的位置上，使得这些命令更加容易被用户找到。
命令是对整个窗口有效还只仅仅只是对一些面板有效？Ribbons最适合与那些对整个窗口或者特定的对象有效的命令。现场命令（in-place command）对于单独的窗口面板更加合适。
是不是大部分的命令都可以直观的呈现给用户？也就是说，用户是不是能够仅点击一下鼠标就能够使用这些命令？如果命令在菜单或者对话中，这些命令的使用方式是不是能够称为直接？最然一些命令可以使用菜单或者对话框的而形式来表达，但是如果大部分命令使用这种方式表达，就会降低了ribbon的效率，这样的话传统的菜单栏可能是更好的选择。

命令范围（Command scale）

命令的数量是不是很少？最常用的命令是否能够在一个单独的、简单的工具栏上进行表达？如果添加一个核心标签或者一个上下文标签的结果是产生一个单独使用来完成大多数常用任务的主页标签，那么使用ribbon是很值得的。如果不是的话，那么对于少量的命令来书，使用ribbon的效益可能比造成应用程序体积臃肿带来的弊病更小。（吐槽一下，这段实在有点难翻译，看不懂的话，建议可以看一下原文）。
命令的数量是不是很多？如果使用Ribbon的话是否会多于7个核心标签？用户是否经常需要切换标签来寻找命令、完成任务？如果是这样的话，使用工具栏（不需要切换）以及命令集窗口（palette window，笔者任务可能是类似于PS右侧那样的窗口）（可能需要切换标签，但是可以同时打开数个）可能是更加的选择。
使用是否在大多数时间里只使用少数的命令？如果是这样，开发人员可以使用ribbon，并且将这些命令放在主页标签中来提高程序效率。经常的切换标签会降低ribbon的效率。
如果将内容区域尽可能的最大化是否可以优化程序的使用？如果是这样使用菜单栏和一个单独的工具栏会比ribbon提供更大的空间。但是如果程序需要3行或更多行的工具栏或用户任务面板，使用ribbon可以腾出更多的空间。
使用是否更加倾向于在一个大的窗口中的特定区域中工作相当长一段时间？如果是这样，他们可能更加喜欢紧密的迷你工具栏，命令集窗口和直接的命令。从工作区到Ribbon来回移动的操作方式效率很低。
对于效率和灵活性，用户是否会对命令表达的内容，位置和大小进行显著地修改？如果是这样，自定义和可扩展的工具栏和命令集窗口是更好的选择。注意，一些工具栏可以解锁成为命令集窗口，而命令集窗口可以移动、调整大小和自定义

最后，考虑如下的究极问题：在命令的可发现性、易学性、效率和生产力上的提升是否值得花费额外的空间，并需要使用标签来组织命令？如果是这样，使用ribbon吧，他是最棒的选择。如果你不确定，可以尝试使用ribbon验证一下他的可用性，并将它同其他最佳的选择进行对比。

Ribbon是最新的和最迷人的命令表达方式，是现代程序的很好的表达方式。但是考虑他们本身的特性，它并不适合所有的程序。

不正确的使用方式：

千万不要以这种方式使用ribbon（笔者注：使用Ribbon实现一个计算器，微软的人也是真心有想法的……）

设计思想

在一个现有的程序中应用ribbon

虽然你可能会只是简单的将传统的工具栏和菜单栏的设计转换成ribbon的形式，但是这样做就失去了使用ribbon的意义。当想要表达实时的、面向结果的命令（通常使用gallery和实时预览）时使用ribbon可以使其发挥最大的价值。面向结果的命令使得该命令更加容易被理解，提高操作的效率和生产率。所以如果想使用ribbon的话，你最好重新设计你程序中命令的表达方式，而不仅仅是将现有的菜单进行简单的转换。

不要轻视是设计一个高效的ribbon界面的挑战难度，还有就是不要想当然的认为使用ribbon一定会使你的程序获得更好的用户体验（笔者注：翻译到这里的时候，实在向吐槽一下3D电影，特别是国产的。很多导演都认为使用3D会让电影更好看，殊不知无论多先进的技术都无法挽救狗血的剧情，纯吐槽，不喜轻喷）。设计一个高效的ribbon会花费大量的时间和精力。在你决定使用ribbon的参考因素中，愿意花时间进行基于ribbon的重新设计是一个重要的因素。

如果你想要了解关于将命令迁徙到ribbon界面中的内容，可以参考Ribbon Design Process。

Ribbons的本质

同传统的菜单栏和工具栏相比，ribbon有如下特点：

一个对于所有命令的统一的用户界面。菜单栏内容全面而且容易学习，菜单栏效率更高并且更加直观。但是为什么不稍微多花费一点屏幕空间来创建一个统一的用户界面来完成所有这些任务。在一个统一的UI下，ribbons不需要用户找出究竟是哪个UI中有他们需要的命令。
可视化并且是自解释的。菜单栏通过他们的标签实现自解释功能，但是在大多数时间中他们都隐藏在视图中。为了节约屏幕空间，工具栏的命令大多数通过图标进行表达，而不是通过标签进行表示（虽然有些工具栏命令的确如此）。所以当图标无法解释他们的功能时，需要借助提示（tooltips）来解释。然而，一般用户只知道他们最常用的命令的图标。

Ribbon的命令是可视化并且是自解释的，通过带标签的图标来表达大多数命令。Tooltips只是提供额外的内容补充。没有必要去其他地方（比如帮助）来寻找关于命令的解释和使用帮助。