Difference between revisions of "Projects/Usability/HIG/Animations"
(Created page with "__NOTOC__ ==Purpose== Both the interaction with controls as well as the workflow itself should be clear to users. For instance it has to be obvious if a button can be pressed ...")
Revision as of 14:39, 25 July 2014
Both the interaction with controls as well as the workflow itself should be clear to users. For instance it has to be obvious if a button can be pressed at all, if it is in focus and one could use space or enter to execute the function, and whether or not it just has been pressed; Usually, disabled buttons are grayed out, if the focus is on the button it gets an extra frame, and when pressed it has a lowered appearance. Another method to support perception, especially for flat designs, is to use animations. An animation is a very short sequence of intermediate states between initial and final state. It should be discriminated from high level animations, like wobbling windows, that only serve emotional purpose.
- Use animations only if it serves functional purpose.
- Guide the user’s attention by animations and focus through multiple steps of a process or procedure.
- Make animations as much unobtrusive as possible. Good animations are those that users do not notice.
- Use the same kind of animation of similar interactions. For instance, expanding the main menu, a context menu or an accordion should be equally animated.
- Do not use animation that take longer than 200ms.
- Follow physical principles when using animations.
- Accelerate and decelerate movement as if has a mass. Consider to correlate control size with mass and apply acceleration accordingly.
- Start animations from their origin.
- Avoid linear spatial paths, except when movement is constrained to an axis or moving towards/away from a specific point in concert with other elements.
- Make interactions responsive.
- Show a surface reaction on input (like a drop into water).
- Make the material responding (like pressing a button).
- When building a transition, consider both the order in which elements move and the timing of their movement.
- Make sure that the direction in which elements move is cohesive across the transition. Avoid conflicting movements and overlapping paths.
- Consider the depth story: what moves under what, and why?
- Support spatial relationships through consistent motions for incoming and outgoing elements.
|Main menu||-||shown from hidden||F10, expand on click||item selection||item clicked||menu closed||-|
|Statusbar||-||shown from hidden||-||-||-||-||-|
|Contextmenu||-||-||expand on click||item selection||item clicked||menu closed||-|
|Toolbar||-||-||on dock||-||-||on undock||-|
|Push Button||-||-||mouse hoover||focus on button (cf. tab order)||button pressed||focus lost||-|
|Toggle Button||-||-||-||-||toggle on/off||-||-|
|Command Link||-||-||currently underline on hoover||-||link gets clicked||-||-|
|Dialogs||-||dialog shows up||in case of non-modal dialogs||-||-||-||dialog is being closed|
|Splitter||-||-||-||-||indicate the ability to resize||-||-|
|Tabs||-||-||-||indicate options when tabcontrol is focused, e.g. switch to next||-||OnLeave||OnDestroy|
Parts of the guideline were inspired by Google's guideline on animations.