Try to think about what your user wants to achieve instead of what the requirements are.
The user will enter your system and use it to achieve a goal. When you open up calc you need to make a simple fast calculation 90% of the time so that's why by default it is set to simple mode.
So don't think about what the application must do but think about the user which will be doing it, probably bored, and try to design based on what his intentions are, try to make his life easier.
I would recommend to get a good solid understanding of GUI design by reading the book The Design of Everyday Things. Although the main printable is a comment from Joel Spolsky: When the behavior of the application differs to what the user expects to happen then you have a problem with your graphical user interface.
The best example is, when somebody swaps around the OK and Cancel button on some web sites. The user expects the OK button to be on the left, and the Cancel button to be on the right. So in short, when the application behavior differs to what the user expects what to happen then you have a user interface design problem.
Although, the best advice, in no matter what design or design pattern you follow, is to keep the design and conventions consistent throughout the application.
Avoid asking the user to make choices whenever you can (i.e. don't create a fork with a configuration dialog!)
For every option and every message box, ask yourself: can I instead come up with some reasonable default behavior that
makes sense?
does not get in the user's way?
is easy enough to learn that it costs little to the user that I impose this on him?
I can use my Palm handheld as an example: the settings are really minimalistic, and I'm quite happy with that. The basic applications are well designed enough that I can simply use them without feeling the need for tweaking. Ok, there are some things I can't do, and in fact I sort of had to adapt myself to the tool (instead of the opposite), but in the end this really makes my life easier.
This website is another example: you can't configure anything, and yet I find it really nice to use.
Reasonable defaults can be hard to figure out, and simple usability tests can provide a lot of clues to help you with that.
A canon of design lore and the basis of many HCI courses at universities around the world. You won't design a great GUI in five minutes with a few comments from a web forum, but some principles will get your thinking pointed the right way.
这来自“人机界面指南：Apple 桌面 Interface”（1987，ISBN 0-201-17753-6），但可以使用 对于任何地方的任何错误消息。 有一个适用于 Mac OS X 的更新版本。 微软页面 用户界面消息 说了同样的话：“......在出现错误消息的情况下， 您应该包括问题、原因和用户操作 纠正问题。”
When constructing error messages make the error message be the answers to these 3 questions (in that order):
What happened?
Why did it happen?
What can be done about it?
This is from "Human Interface Guidelines: The Apple Desktop Interface" (1987, ISBN 0-201-17753-6), but it can be used for any error message anywhere. There is an updated version for Mac OS X. The Microsoft page User Interface Messages says the same thing: "... in the case of an error message, you should include the issue, the cause, and the user action to correct the problem."
Also include any information that is known by the program, not just some fixed string. E.g. for the "Why did it happen" part of the error message use "Raw spectrum file L:\refDataForMascotParser\TripleEncoding\Q1LCMS190203_01Doub leArg.wiff does not exist" instead of just "File does not exist".
Contrast this with the infamous error message: "An error happend.".
As my data structure professor pointed today: Give instructions on how your program works to the average user. We programmers often think we're pretty logical with our programs, but the average user probably won't know what to do.
Use discreet/simple animated features to create seamless transitions from one section the the other. This helps the user to create a mental map of navigation/structure.
Use short (one word if possible) titles on the buttons that describe clearly the essence of the action.
Use semantic zooming where possible (a good example is how zooming works on Google/Bing maps, where more information is visible when you focus on an area).
Create at least two ways to navigate: Vertical and horizontal. Vertical when you navigate between different sections and horizontal when you navigate within the contents of the section or subsection.
Always keep the main options nodes of your structure visible (where the size of the screen and the type of device allows it).
When you go deep into the structure always keep a visible hint (i.e. such as in the form of a path) indicating where you are.
Hide elements when you want the user to focus on data (such as reading an article or viewing a project). - however beware of point #5 and #4.
I've read most of the above and one thing that I'm not seeing mentioned:
If users are meant to use the interface ONCE, showing only what they need to use if possible is great.
If the user interface is going to be used repeatedly by the same user, but maybe not very often, disabling controls is better than hiding them: the user interface changing and hidden features not being obvious (or remembered) by an occasional user is frustrating to the user.
If the user interface is going to be used VERY REGULARLY by the same user (and there is not a lot of turnover in the job i.e. not a lot of new users coming online all the time) disabling controls is absolutely helpful and the user will become accustomed to the reasons why things happen but preventing them from using controls accidentally in improper contexts appreciated and prevents errors.
Just my opinion, but it all goes back to understanding your user profile, not just what a single user session might entail.
Show the interface to a sample of users. Ask them to perform a typical task. Watch for their mistakes. Listen to their comments. Make changes and repeat.
Contrast - Make things that are different look different
Repetition - Repeat the same style in a screen and for other screens
Alignment - Line screen elements up! Yes, that includes text, images, controls and labels.
Proximity - Group related elements together. A set of input fields to enter an address should be grouped together and be distinct from the group of input fields to enter credit card info. This is basic Gestalt Design Laws.
发布评论
评论（19）
永远不要问“你确定吗？”。 只需允许无限、可靠的撤消/重做。
Never ask "Are you sure?". Just allow unlimited, reliable undo/redo.
尝试考虑用户想要实现什么，而不是需求是什么。
用户将进入您的系统并使用它来实现目标。 当您打开 calc 时，90% 的时间您都需要进行简单的快速计算，因此默认将其设置为简单模式。
因此，不要考虑应用程序必须做什么，而是考虑将要执行此操作的用户，可能很无聊，并尝试根据他的意图进行设计，尝试让他的生活更轻松。
Try to think about what your user wants to achieve instead of what the requirements are.
The user will enter your system and use it to achieve a goal. When you open up calc you need to make a simple fast calculation 90% of the time so that's why by default it is set to simple mode.
So don't think about what the application must do but think about the user which will be doing it, probably bored, and try to design based on what his intentions are, try to make his life easier.
我努力适应环境。
在开发 Windows 应用程序时，我使用 Windows Vista 用户体验指南 但是当我开发 Web 应用程序时，我使用适当的指南，因为我开发荷兰网站，我使用 "Drempelvrij " 指南，基于网页内容无障碍指南 (WCAG 1.0)由万维网联盟 (W3C) 制定。
我这样做的原因是为了减少新用户的学习曲线。
I try to adapt to the environment.
When developing for an Windows application, I use the Windows Vista User Experience Guidelines but when I'm developing an web application I use the appropriate guidelines, because I develop Dutch websites I use the "Drempelvrij" guidelines which are based on the Web Content Accessibility Guidelines (WCAG 1.0) by the World Wide Web Consortium (W3C).
The reason I do this is to reduce the learning curve of a new user.
网络应用程序中的面包屑：
告诉-> -> 用户-> 哪里-> 她-> 在系统中
在具有相同数据的多个路径的“动态”系统中，这很难做到，但它通常有助于导航系统。
Breadcrumbs in webapps:
Tell -> The -> User -> Where -> She -> Is in the system
This is pretty hard to do in "dynamic" systems with multiple paths to the same data, but it often helps navigate the system.
如果您正在为网络或任何前端软件应用程序做任何事情，那么您确实应该阅读...
别让我思考 - 史蒂夫·克鲁格
If you're doing anything for the web, or any front-facing software application for that matter, you really owe it to yourself to read...
Don't make me think - Steve Krug
我建议通过阅读这本书来深入了解 GUI 设计 The日常事物的设计。 尽管主要打印内容是 Joel Spolsky 的评论：如果应用程序的行为与用户期望发生的情况不同，那么您的图形用户界面就会出现问题。
最好的例子是，当有人在某些网站上交换确定和取消按钮时。 用户期望确定按钮位于左侧，取消按钮位于右侧。 简而言之，当应用程序行为与用户期望发生的情况不同时，就会出现用户界面设计问题。
尽管如此，无论您遵循什么设计或设计模式，最好的建议是在整个应用程序中保持设计和约定一致。
I would recommend to get a good solid understanding of GUI design by reading the book The Design of Everyday Things. Although the main printable is a comment from Joel Spolsky: When the behavior of the application differs to what the user expects to happen then you have a problem with your graphical user interface.
The best example is, when somebody swaps around the OK and Cancel button on some web sites. The user expects the OK button to be on the left, and the Cancel button to be on the right. So in short, when the application behavior differs to what the user expects what to happen then you have a user interface design problem.
Although, the best advice, in no matter what design or design pattern you follow, is to keep the design and conventions consistent throughout the application.
尽可能避免要求用户做出选择（即不要创建带有配置对话框的分叉！）
对于每个选项和每个消息框，问问自己：我可以提出一些合理的默认行为
我可以用我的掌上电脑作为例子：设置非常简约，我对此非常满意。 基本应用程序设计得足够好，我可以简单地使用它们，而不需要进行调整。 好吧，有些事情我不能做，事实上我不得不让自己适应这个工具（而不是相反），但最终这确实让我的生活变得更轻松。
这个网站是另一个例子：你无法配置任何东西，但我发现它非常好用。
合理的默认值可能很难弄清楚，简单的可用性测试可以提供很多线索来帮助您解决这个问题。
Avoid asking the user to make choices whenever you can (i.e. don't create a fork with a configuration dialog!)
For every option and every message box, ask yourself: can I instead come up with some reasonable default behavior that
I can use my Palm handheld as an example: the settings are really minimalistic, and I'm quite happy with that. The basic applications are well designed enough that I can simply use them without feeling the need for tweaking. Ok, there are some things I can't do, and in fact I sort of had to adapt myself to the tool (instead of the opposite), but in the end this really makes my life easier.
This website is another example: you can't configure anything, and yet I find it really nice to use.
Reasonable defaults can be hard to figure out, and simple usability tests can provide a lot of clues to help you with that.
日常事物的设计 - Donald Norman
设计知识的经典，也是世界各地大学许多 HCI 课程的基础。 仅凭网络论坛的一些评论，您不可能在五分钟内设计出出色的 GUI，但一些原则将使您的思维指向正确的方向。
——
主持人
The Design of Everyday Things - Donald Norman
A canon of design lore and the basis of many HCI courses at universities around the world. You won't design a great GUI in five minutes with a few comments from a web forum, but some principles will get your thinking pointed the right way.
--
MC
构造错误消息时，使错误消息为
这 3 个问题的答案（按顺序）：
发生了什么？
为什么会发生？
对此可以采取什么措施？
这来自“人机界面指南：Apple 桌面
Interface”（1987，ISBN 0-201-17753-6），但可以使用
对于任何地方的任何错误消息。
有一个适用于 Mac OS X 的更新版本。
微软页面
用户界面消息
说了同样的话：“......在出现错误消息的情况下，
您应该包括问题、原因和用户操作
纠正问题。”
还包括程序已知的任何信息，
不仅仅是一些固定的字符串。 例如，对于错误消息的“为什么会发生”部分，请使用“原始频谱文件”
L:\refDataForMascotParser\TripleEncoding\Q1LCMS190203_01Doub
leArg.wiff 不存在”而不仅仅是“文件存在”
不存在”。
将此与臭名昭著的错误消息进行对比：“错误
发生。”。
When constructing error messages make the error message be
the answers to these 3 questions (in that order):
What happened?
Why did it happen?
What can be done about it?
This is from "Human Interface Guidelines: The Apple Desktop
Interface" (1987, ISBN 0-201-17753-6), but it can be used
for any error message anywhere.
There is an updated version for Mac OS X.
The Microsoft page
User Interface Messages
says the same thing: "... in the case of an error message,
you should include the issue, the cause, and the user action
to correct the problem."
Also include any information that is known by the program,
not just some fixed string. E.g. for the "Why did it happen" part of the error message use "Raw spectrum file
L:\refDataForMascotParser\TripleEncoding\Q1LCMS190203_01Doub
leArg.wiff does not exist" instead of just "File does
not exist".
Contrast this with the infamous error message: "An error
happend.".
（从 Joel 窃取：o））
不要禁用/删除选项 - 而是在用户单击/选择它时给出有用的消息。
(Stolen from Joel :o) )
Don't disable/remove options - rather give a helpful message when the user click/select it.
正如我的数据结构教授今天指出的那样：向普通用户提供有关程序如何工作的说明。 我们程序员常常认为我们的程序非常合乎逻辑，但普通用户可能不知道该怎么做。
As my data structure professor pointed today: Give instructions on how your program works to the average user. We programmers often think we're pretty logical with our programs, but the average user probably won't know what to do.
使用谨慎/简单的动画功能来创建从一个部分到另一个部分的无缝过渡。 这有助于用户创建导航/结构的思维导图。
在按钮上使用简短的（如果可能的话，一个词）标题，清楚地描述操作的本质。
尽可能使用语义缩放（一个很好的例子是缩放在 Google/Bing 地图上的工作方式，当您聚焦于某个区域时可以看到更多信息）。
尽可能
创建至少两种导航方式：垂直和水平。 当您在不同部分之间导航时垂直，当您在部分或子部分的内容内导航时水平。
始终保持结构的主要选项节点可见（屏幕大小和设备类型允许的情况下）。
始终
当你深入结构时，始终保留一个可见的提示（即，以路径的形式）指示你所在的位置。
当您希望用户专注于数据（例如阅读文章或查看项目）时隐藏元素。 - 但请注意第 #5 点和第 #4 点。
Use discreet/simple animated features to create seamless transitions from one section the the other. This helps the user to create a mental map of navigation/structure.
Use short (one word if possible) titles on the buttons that describe clearly the essence of the action.
Use semantic zooming where possible (a good example is how zooming works on Google/Bing maps, where more information is visible when you focus on an area).
Create at least two ways to navigate: Vertical and horizontal. Vertical when you navigate between different sections and horizontal when you navigate within the contents of the section or subsection.
Always keep the main options nodes of your structure visible (where the size of the screen and the type of device allows it).
When you go deep into the structure always keep a visible hint (i.e. such as in the form of a path) indicating where you are.
Hide elements when you want the user to focus on data (such as reading an article or viewing a project). - however beware of point #5 and #4.
功能强大且简单
哦，还有聘请设计师/学习设计技能。 :)
Be Powerful and Simple
Oh, and hire a designer / learn design skills. :)
对于 GUI，标准是特定于平台的。 例如，在 Eclipse 中开发 GUI 时，此链接提供了不错的指南。
With GUIs, standards are kind of platform specific. E.g. While developing GUI in Eclipse this link provides decent guideline.
我已经阅读了上面的大部分内容，但我没有看到提到的一件事：
如果用户打算使用该界面一次，那么只显示他们需要使用的内容（如果可能）是很好的。
如果同一用户将重复使用用户界面，但可能不会经常使用，则禁用控件比隐藏它们更好：用户界面更改和隐藏功能对于偶尔的用户来说并不明显（或记住），这令人沮丧用户。
如果同一个用户非常经常地使用用户界面（并且工作中没有太多周转，即没有很多新用户一直在线），则禁用控件绝对有帮助，并且用户将变得习惯了事情发生的原因，但防止他们在不正确的环境中意外地使用控件，这会受到赞赏并防止错误。
这只是我的观点，但这一切都取决于了解您的用户配置文件，而不仅仅是单个用户会话可能需要的内容。
I've read most of the above and one thing that I'm not seeing mentioned:
If users are meant to use the interface ONCE, showing only what they need to use if possible is great.
If the user interface is going to be used repeatedly by the same user, but maybe not very often, disabling controls is better than hiding them: the user interface changing and hidden features not being obvious (or remembered) by an occasional user is frustrating to the user.
If the user interface is going to be used VERY REGULARLY by the same user (and there is not a lot of turnover in the job i.e. not a lot of new users coming online all the time) disabling controls is absolutely helpful and the user will become accustomed to the reasons why things happen but preventing them from using controls accidentally in improper contexts appreciated and prevents errors.
Just my opinion, but it all goes back to understanding your user profile, not just what a single user session might entail.
向用户示例显示界面。 要求他们执行一项典型任务。 注意他们的错误。 听听他们的评论。 进行更改并重复。
Show the interface to a sample of users. Ask them to perform a typical task. Watch for their mistakes. Listen to their comments. Make changes and repeat.
我针对我的祖母测试了我的 GUI。
I test my GUI against my grandma.
尝试在对话框中使用动词。
这意味着使用
而不是
Try to use verbs in your dialog boxes.
It means use
instead of
遵循基本设计原则
Follow basic design principles