GUIdevise的最佳实践和原则
什么是您最好的实用的用户友好的用户界面devise或原则？
请提交您发现的实践，实际上使事情真正有用 – 无论如何 – 如果它为您的用户，共享它！
总结/整理
原则
- 吻。
- 要清楚具体地说明一个选项的实现方式：例如，使用动词来表示select后的动作（参见：内容1）。
- 使用适合用户需要/希望实现的明显的默认操作。
- 使用户界面的外观和行为与环境/stream程/观众相适应：独立应用程序，网页，便携式，科学分析，Flash游戏，专业人员/儿童，…
- 减less新用户的学习曲线。
- 不要禁用或隐藏选项，而是考虑在用户可以有替代scheme的情况下给出一个有用的信息，但只有在这些scheme存在的情况下。 如果没有其他替代方法可用，则最好禁用该选项 – 可视地指出该选项不可用 – 不隐藏不可用的选项，而是在鼠标hover的popup窗口中解释为什么禁用该选项。
- 保持一致和符合实践，并放置控制，如在广泛使用的成功应用程序中实施。
- 引导用户的期望，让你的程序按照这些期望行事。
- 坚持用户的词汇和知识，不要使用程序员/实现术语。
- 遵循基本的devise原则：对比（显而易见），重复（一致），alignment（外观）和接近（分组）。
履行
- （请参阅“由paiNie回答”）“尝试在对话框中使用动词”。
- 允许/实现撤消和重做。
参考
- Windows Vista用户体验指南[ http://msdn.microsoft.com/zh-cn/library/aa511258.aspx]
- 荷兰的网站 – “Drempelvrij”指南[ http://www.drempelvrij.nl/richtlijnen]
- 无障碍网页内容指引（WCAG 1.0）[ http://www.w3.org/TR/WCAG10/]
- 一致性[ http://www.amazon.com/Design-Everyday-Things-Donald-Norman/dp/0385267746]
- 不要让我想[ http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758/ref=pdbbssr_1?ie=UTF8&s=books&qid=1221726383&sr=8-1]
- 强大而简单[ http://msdn.microsoft.com/zh-cn/library/aa511332.aspx]
- 完形devise法[ http://www.squidoo.com/gestaltlaws]
我testing我的GUI对我的祖母。
遵循基本的devise原则
- C ontrast – 让不同的东西看起来不同
- 重复 – 在屏幕和其他屏幕上重复相同的样式
- 一个标志 – 线屏幕元素了！ 是的，这包括文字，图片，控件和标签。
- 紧密联系 – 将相关元素分组在一起。 input地址的一组input字段应该组合在一起，并且与input字段组不同，以input信用卡信息。 这是基本的格式塔devise法 。
永远不要问“你确定吗？” 只需允许无限可靠的撤消/重做。
试着想想你的用户想要达到什么要求，而不是什么要求。
用户将进入你的系统，并使用它来实现目标。 当你打开calc时，你需要在90％的时间内做一个简单的快速计算，所以这就是为什么默认情况下它被设置为简单模式。
所以，不要考虑应用程序必须做什么，而是要考虑将要做的事情的用户，可能无聊，并尝试根据他的意图进行devise，尽量让他的生活更轻松。
如果你正在为networking做任何事情，或任何面向这个问题的前沿软件应用程序，你真的应该自己阅读…
不要让我想 – 史蒂夫克鲁格
webapps中的面包屑：
告诉 – > – >用户 – >哪里 – >她 – > 是在系统中
在具有到相同数据的多条path的“dynamic”系统中，这很难做到，但是它通常有助于导航系统。
我尝试适应环境。
在开发Windows应用程序时，我使用Windows Vista用户体验指南，但在开发Web应用程序时，我使用了相应的指导原则，因为我开发荷兰网站时使用基于Web内容可访问性的“Drempelvrij”指导原则万维网联盟（W3C）的准则（WCAG 1.0 ）。
我这样做的原因是为了减less新用户的学习曲线。
我build议通过阅读“日常事物的devise ”一书来深入了解GUIdevise。 虽然主要的打印是来自Joel Spolsky的评论：当应用程序的行为与用户期望发生的不同时，那么你的graphics用户界面就有问题了。
最好的例子是，当有人在某些网站上的OK和Cancelbutton上交换时。 用户希望确定button位于左侧， 取消button位于右侧。 所以简而言之，当应用程序的行为不同于用户期望发生什么时，那么你就有一个用户界面devise问题。
尽pipe最好的build议，不pipe你遵循什么样的devise或者devise模式，在整个应用中都要保持devise和约定的一致性。
避免要求用户做出select（即不要使用configuration对话框创build分支）！
对于每个选项和每个消息框，问问自己：我可以拿出一些合理的默认行为
- 说得通？
- 没有得到用户的方式？
- 很容易学会，我把这个强加给他，对用户来说花费不多呢？
我可以使用我的Palm掌上电脑作为例子：设置是非常简约的，我对此非常满意。 基本的应用程序devise的很好，我可以简单地使用它们而不需要调整。 好的，有些事情是我做不到的，事实上，我不得不让自己适应这个工具（而不是相反），但最后这真的让我的生活更轻松。
这个网站是另一个例子：你不能configuration任何东西，但我觉得它真的很好用。
合理的默认值很难弄清楚，简单的可用性testing可以提供很多线索来帮助你。
将界面显示给一个用户样本。 要求他们执行一个典型的任务。 注意他们的错误。 听取他们的意见。 进行更改并重复。
日常事物的devise – Donald Norman
devise知识的经典和世界各地大学HCI课程的基础。 你不会在五分钟内用一个networking论坛的一些评论来devise一个好的graphics用户界面，但是有些原则会让你的思路指向正确的方向。
–
MC
在构build错误消息时，将错误消息作为这3个问题的答案（按此顺序）：
-
发生了什么？
-
为什么发生？
-
可以做些什么呢？
这是从“人机界面指南：苹果桌面接口”（1987年，国际标准书号0-201-17753-6），但它可以用于任何地方的任何错误消息。 有一个Mac OS X的更新版本 。Microsoft页面的用户界面消息说：“…在出现错误消息的情况下，你应该包括问题，原因，和用户的行动，以纠正这个问题“。
还包括程序已知的任何信息，而不仅仅是一些固定的string。 例如，对于“为什么会发生”部分错误信息，使用“原始光谱文件L：\ refDataForMascotParser \ TripleEncoding \ Q1LCMS190203_01D leArg.wiff不存在”而不是“文件不存在”。
将其与臭名昭着的错误消息进行对比：“发生错误”。
（从Joel窃取：o））
不要禁用/删除选项 – 而是在用户单击/select时给出有用的消息。
正如我的数据结构教授今天指出的：给你的程序如何工作，以普通用户的指示。 我们的程序员经常认为我们对程序非常合乎逻辑，但普通用户可能不知道该怎么做。
-
使用谨慎/简单的animationfunction创build从另一个部分的无缝过渡。 这有助于用户创build一个导航/结构的心理地图。
-
在button上使用短的（如果可能的话）一个字，这些标题清楚地描述了行动的本质。
-
在可能的情况下使用语义缩放（一个很好的例子就是如何在Google / Bing地图上进行缩放，当您关注某个区域时，可以看到更多信息）。
-
创build至less两种导航方式：垂直和水平。 在不同部分之间导航时垂直，而在导航部分或子部分的内容中导航时则为水平。
-
始终保持结构的主要选项节点可见（屏幕大小和设备types允许）。
-
当你深入到结构中时，始终保持一个可见的提示（即如path的forms），指示你在哪里。
-
当您希望用户专注于数据（如阅读文章或查看项目）时隐藏元素。 – 但要小心点＃5和＃4。
强大而简单
哦，并聘请devise师/学习devise技能。 🙂
使用GUI，标准是特定于平台的。 例如，在Eclipse中开发GUI时，该链接提供了体面的指导。
;){kind=link}
;){kind=link}