• Ribbons界面介绍(2)——这是不是合适的用户界面


    上一篇文章发后收到很多朋友的鼓励和建议,在此特别感谢他们以及其他所有人对我的支持,你们的支持是我坚持下去最好的动力,谢谢。

    这是不是合适的用户界面(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实现一个计算器,微软的人也是真心有想法的……)

     

  • 相关阅读:
    高并发系统中的常见问题
    区块链需要解决诸多问题
    什么是“区块链”技术
    github源码开源区块链浏览器
    JavaScript 内存
    行为驱动开发(BDD)
    Vue.js
    Net程序员学习Linux
    Mybatis数据操作
    Metatable和Metamethod(转)
  • 原文地址:https://www.cnblogs.com/madhenry/p/2274777.html
Copyright © 2020-2023  润新知