提高用户体验的GUIdevise技巧
你知道什么技术\用于创build用户友好的graphics用户界面？
我可以命名以下技术，我觉得特别有用：
- 非阻塞通知（像Firefox3中的浮动对话框或Vista托盘区域的Vistapopup消息）
- 没有“保存”button
MS OneNote作为例子。
IM客户端可以自动保存对话logging - 综合search
search不仅通过帮助文件，而是使UI元素可search。
Vista向这样的GUI迈出了一大步。
侦察插件Microsoft Office是一个非常好的主意。 - 面向上下文的UI（MS Office 2007中的function栏）
你在你的软件中实现了像列出的技术的东西吗？
编辑：
正如Ryan P所说，创build可用应用程序的最好方法之一就是将自己置于用户的位置。 我完全同意这个观点，但是我想在这个主题中看到的是具体的技术（就像我之前提到的那样），而不是一般性的build议。
如果你给用户一个问题，不要说是/否的问题。 花时间做一个新的forms，并把动词作为select在Mac中。
例如：
Would you like to save? Yes No 应该：
Would you like to save? Save Don't Save
这里有一个更详细的解释。
看看这本好书不要让我想起史蒂夫·克鲁格（Steve Krug）。
这是networking焦点，但许多conepts可以适用于从搅拌机到汽车仪表板的任何东西。
涵盖的主题：
- 用户模式
- devise扫描
- 明智的使用副本
- 导航devise
- 主页的布局
- 可用性testing
他还有一个名为高级常识的博客
和一些随机的UI相关的链接：
– 由Joel Spolsky 编写的程序员用户界面devise
– 10可用性噩梦你应该知道
第一原则： 威尔弗雷德詹姆斯汉森
- 知道用户
- 尽量减less记忆
- 优化操作
- 工程师的错误
后续扩展： Theo Mandel博士
控制用户
- 使用模式审慎（无模式）
- 允许用户使用键盘或鼠标（灵活）
- 允许用户改变焦点（可中断）
- 显示描述性信息和文字（有帮助）
- 提供即时和可逆的行动和反馈（原谅）
- 提供有意义的path和退出（可导航）
- 适应不同技能水平的用户（可访问）
- 使用户界面透明（促进）
- 允许用户自定义界面（首选项）
- 允许用户直接操作界面对象（交互式）
减less用户的内存负载
- 解除短期记忆（记住）
- 依靠承认而不是召回（承认）
- 提供视觉线索（通知）
- 提供默认，撤销和重做（原谅）
- 提供界面快捷键（频率）
- 提升对象动作语法（直观）
- 使用现实世界的隐喻（转移）
- 用户渐进式披露（上下文）
- 提升视觉清晰度（组织）
使接口一致
- 维持用户任务的环境（连续性）
- 保持产品内和产品间的一致性（经验）
- 保持互动结果相同（期望）
- 提供美感和诚信（态度）
- 鼓励探索（可预测 ）
要join你的名单， 阿库 ，我会把可探测性作为我的最高优先事项之一。 基本上，我希望用户能够安全地尝试这些function。 他们永远不应该退缩，因为担心他们的行为可能是不可逆转的。 通常情况下，这是使用撤销/重做命令实现的，但其他选项无疑是可用的，例如自动备份。
而且，对于更加面向过程的应用程序（而不是数据input应用程序），我会考虑实现一个引导用户多一点的界面。 微软的“ 感应式用户界面”指南可以在这里帮助您，尽pipe您需要非常小心，不要过度使用它，因为您可能会过慢地减慢用户的速度。
最后，与包含文本的任何内容一样，尽可能使用户界面可扫描。 例如，如果您有指令/选项出现的标题，请考虑将动作词放在开头，而不是问题词。 Maudite所做的一点也是可扫描性的一个很好的例子，因为“不保存”button文本不依赖前面段落的上下文。
我从来没有看到任何人使用的一个有用的技术是添加一个禁用UI控件的工具提示，解释为什么控制被禁用。 所以，如果有一个被禁用的列表框，并且不清楚它为什么被禁用，我想把鼠标hover在它上面，它告诉我为什么它被禁用。 我想看到这样的东西：“它被禁用，因为屏幕上的两个文本框被留空，或者因为我没有input足够的字符在某个领域或因为我没有做出某种行动。”
我遇到很多这样的情况，这是令人沮丧的。 有时候我最终会在软件的论坛上发帖，询问为什么一个控件灰暗，当一个工具提示可以帮我一秒钟！ 这些软件中的大多数都有帮助文件，在这种情况下是无用的。
试着假装你对软件一无所知，并尝试使用它。 然而，这是不实际的，因为你已经有了一定的思路设置应用程序。 因此，观看开发人员或朋友使用应用程序，并寻找痛点，并要求反馈。
Donald Norman的“日常事物的devise”是帮助你思考devise的经典书籍之一。 他给了伟大的现实世界的例子。 例如，如果你devise的门很好，你不应该添加标签，说“推”和“拉”。 如果你想让他们拉，把手; 如果你想他们推，把一个平板。 没有办法做错了，他们甚至不需要考虑。
这是一个好目标：让事情变得明显。 很显然，用户从来不会发生错误的事情 。 如果炉子上有四个旋钮，每个旋钮都紧挨着一只眼睛，显然每个旋钮都可以控制它旁边的眼睛。 如果旋钮在一条直线上，所有的在左边，你必须标记他们，用户必须停下来思考。 糟糕的devise。 不要让他们想。
另一个原则：如果用户确实犯了一个错误，应该很容易撤消 。 Google的图像软件Picasa就是一个很好的例子。 您可以剪裁，重新着色和修改所有你喜欢的照片，如果你改变了主意 – 甚至一个月后 – 你可以撤销你的改变。 即使您明确地保存更改，Picasa也会进行备份。 这释放了用户玩和探索，因为你不会伤害任何东西。
我发现UI模式是这种事情的一个有用的参考。 它的排列非常像经典的GoFdevise模式书，每个模式描述都包含：
- 模式解决的问题
- 行动模式的一个例子
- 该模式的示例用例
- 实施模式的解决scheme
- 该解决scheme的理由
如果你执行一个search，就像Locate32和Google Suggest现在一样进行实时search。 我习惯于不在search框上按“Enter”。
好吧，有一点可能是显而易见的：如果屏幕之间button，菜单，链接等操作的types相同，则不要更改（甚至略微）button，菜单，链接等的位置，颜色，字体大小等。
真正好的反馈是非常重要的。 即使是简单的事情，比如明确什么可以点击也不能点击，可以忽略或者太微妙。 在后台发生什么事情的时候反馈很好。 在gmail中，最好有一个状态栏出现在顶部，让你知道是否发送或加载，但更好的是它让你知道某些东西已经成功发送或者正在加载。
RoR人群中的“黄色褪色”技术在其他方面也很受欢迎，它们完成了类似的事情。 你永远不希望用户提出这样的问题：“刚刚发生了什么？ 或者“当我这样做会发生什么？”。
另一个近来越来越受欢迎的技巧就是编辑。 而不是用一个单独的“编辑”屏幕（或跳过视图， 只有一个编辑屏幕）的一些数据的视图，它可以更好的用户友好，有一个很好的布局视图的一些数据，只需点击编辑它的一部分。 这种技术实际上只适用于读取比编辑更频繁的数据，并且不适合严格的数据input。
您列出的列表中的项目实际上取决于情况 – 它们将因应用程序而异。 有些应用程序需要保存button，有些则不需要。 有些条件将保证模式对话框，有些不会。
我devise可用界面的主要规则：遵循现有的UI惯例。 没有什么比用户界面更令用户感到困惑的是，他们以前用过的任何界面都不行。 Lotus Notes是有史以来最糟糕的用户界面之一，几乎完全是因为它们违背了常见的UI约定，几乎所有的事情都是这样。
如果您质疑如何devise某个用户界面，可以考虑一些提供类似function的标准/知名应用程序，并了解它们是如何实现的。
如果你正在做企业软件，很多用户会在低分辨率下拥有小型显示器。 或者，如果他们是老的，他们将在低分辨率，所以他们可以看到巨大的button（我已经看到一个24“ish显示器800×600）。我有一个旧的15”显示器在低分辨率（800×600）如此我可以看到什么程序看起来喜欢在不到闲置的条件下，每隔一段时间。 我知道企业用户几乎不得不接受他们给的东西，但是如果你devise出一个不适合800×600屏幕的winform，那么这对任何人都没有帮助。
尝试在决定使用软件时执行哪些个别任务之前，首先考虑用户的最终目标。 “ About Face”这本书在这方面有很好的讨论，虽然相当长，但是非常有趣和有见地的。 有趣的是，他们有多less关于改进软件devise的build议似乎在谷歌文档中使用…
另一件事，保持您的用户界面尽可能简单和干净。
这里有一个很棒的DotNetRocks播客插曲，Mark Miller谈论如何创build良好的用户界面 ; 尽pipe节目标题是.NET的岩石，这个插曲谈到如何创build一个用户界面，以提高程序用户的生产力的一般经验法则。
这是一段插曲
良好的用户界面devise可以通过坚持一些好的规则，避免常见的错误来完成。 你不需要成为一个拿铁咖啡的纹身忍者携带macbook的devise师来创build用户界面的工作。
我喜欢遵循以下三条准则：
- 标准 – 遵循已知的标准/模式，重用您尊重的所有产品的想法
- 简单 – 让您的解决scheme简单易行（如果需要）
- 优雅 – less用来完成更多
我发现的最好的方法就是把自己放在用户的鞋子里。 你想从GUI看到什么，并把它放在前面。 这也给了你优先考虑的能力，因为这些事情应该先完成，然后从那里开始。
要做到这一点，我尝试find“有用的层”，并添加/减去层，直到看起来干净。 基本上find层我列出了所有function的graphics用户界面需要具备的所有function，它应该有的，所有的function，它将是整齐的。 然后，我把它们分组，使每个事物都有逻辑顺序，组合成为“层”。 然后从各个层面添加最重要的function（或将用于日常操作的function），并成为最显着的部分，然后将这些function添加到围绕这些项目的function中。
最困难的事情之一是导航，因为你有这么多的使用，你如何使它有用，这是图层真正帮助的地方。 它可以很容易地看到如何布局菜单，其他部分如何相互作用，可以隐藏哪些部分等等。
我发现最简单的方法就是先看看你的用户在日常工作中是怎样工作的，这样可以让他们更容易find自己的鞋子（更好的办法是做几天的工作） 。 然后做一些示范，把它们放在用户面前，即使它们是纸质原型（这个过程中有一本书叫Carolyn Snyder的Paper Prototyping）。 然后开始build设它，并将其放在用户面前，因为它经常build立。
我还会推荐由O'Reilly出版的Jenifer Tidwelldevise的接口
如果您的用户界面涉及数据input或操作（典型的业务应用程序），那么我build议您的用户尽可能地对数据项进行操作。 也可以尝试以这样一种方式进行devise，即有经验的用户可以非常随机地与UI进行交互，而不是按顺序方式（加速键，超链接等）进行交互。
Sung Meister提到Mark Miller。 您可以在Developer Express博客上find他的一些关于优秀UI的博客文章 。 下面是他的“伟大的用户界面展示科学”的屏幕录像： part1和part2 。 （都需要Veoh球员 ）。
您还可以在dnrTV上find他：伟大的用户体验科学：第1部分和第2 部分 。
这是一个关于用户体验的Google技术人员，由Jen Fitzpatrick提供。
干杯
使用下拉菜单时，默认下拉高度通常太低 （例如，对于winforms，默认为8个项目）。
如果项目数量较less，增加它可以节省用户点击次数，或者在项目数量较多的情况下更容易search下拉菜单。
事实上，我没有看到使用所有可用空间的一点意思！
现在对我来说这是非常明显的，但是例如，甚至VisualStudio的devise者也没有想到（顺便提一句，如果你手动增加Intellisense的高度，它将保持这种方式，但这是offtopic :)）
我会给我的个人最爱之一：不惜一切代价避免对话框。 一个真正好的UI几乎不需要popup一个对话框。 将它们添加到您的程序只是作为一个真正的最后手段。
更多的，你可能想看看开发人员易于理解的UI技巧 。
编码恐怖博客定期给出伟大的想法。 只是一些例子：
- 探索和增量学习
- 自我logging用户界面
- 增量searchfunction/智能键盘访问
- 面向任务的devise（function区而不是菜单和工具栏）
- 提供撤销而不是持续的确认
另一方面： 使用可缩放的图标来解决多个用户屏幕分辨率的问题，而不需要维护不同的分辨率位图。
圆angular！
（是的，这是在脸颊舌头）
