Development/Usability Principles - Revision history

MatterHackers: MatterHackers moved page Usability Principles to Development/Usability Principles

2016-11-30T22:17:48Z

MatterHackers moved page Usability Principles to Development/Usability Principles

MatterHackers at 18:21, 8 December 2015

2015-12-08T18:21:40Z

MatterHackers: Created page with "When designing or improving UI in MatterControl these are the things we should think about. These are also often describe holistically as, "don't make me think". == Consisten..."

2015-12-08T18:21:11Z

Created page with "When designing or improving UI in MatterControl these are the things we should think about. These are also often describe holistically as, "don't make me think". == Consisten..."

New page

When designing or improving UI in MatterControl these are the things we should think about. These are also often describe holistically as, "don't make me think".

== Consistency ==

If a UI element behaves a certain way it should behave that way everywhere. If an icon is used to mean something it should have the same meaning anytime it is seen.

== Familiarity ==

Make sure we use elements the way people expect them to be used. If there is a standard on the web for the way a UI element works we should use it.

== Recognition Over Recall ==

Make our UIs and behaviors easy to discover and have visible cues as to what can be done. We don't want a user to have to remember what command to type we want to show them what commands are possible.

== Error Prevention ==

Make it challenging to make errors. Check using input and data. Validate that we have consistent information whenever possible.

== Feedback ==

Let the user know what is happening especially when they cannot interact with the software. Here are some rules we should work to follow.

- Always give feedback to a user action within 100 ms.
- Always show a busy cursor if something will take longer than 400 ms.
- Always run async and show progress if action will take longer than 1 s.
- Always show time to completion estimate if action will take longer than 10 s.

== Recovery from Mistakes ==

Whenever possible offer undo or a similar method of recovery. Always make the user feel that their actions are reversible, that it is safe to explore the UI.

== Simplicity ==

Whenever possible make our UI clear and easy to use. Use the most common word when it will do rather than the most technically accurate. Make options visible only to those who want to see them. A quick guide is that we should strive to have about 3 options with a recommendation for success and no more than 7 options or configurations without some type of nesting or drilling in to discover more depth.

== Goal-Oriented ==

Help the user achieve goals. Describe our UI in terms of what goal can be accomplished with any action.

[[Category:Development]]

← Older revision	Revision as of 22:17, 30 November 2016
(No difference)

@@ Line 21: / Line 21: @@
 Let the user know what is happening especially when they cannot interact with the software. Here are some rules we should work to follow.
--   Always give feedback to a user action within 100 ms.
+*Always give feedback to a user action within 100 ms.
--   Always show a busy cursor if something will take longer than 400 ms.
+*Always show a busy cursor if something will take longer than 400 ms.
--   Always run async and show progress if action will take longer than 1 s.
+*Always run async and show progress if action will take longer than 1 s.
--   Always show time to completion estimate if action will take longer than 10 s.
+*Always show time to completion estimate if action will take longer than 10 s.
 == Recovery from Mistakes ==