< Projects | Usability | HIGRevision as of 15:47, 25 July 2014 by Htietze (talk | contribs)(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff) Under ConstructionThis is a new page, currently under construction! 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 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. By creating a sensation of space and placement, low level animations can help to enforce a feeling of air, openness and depth to the overall design. Guidelines Generic advices Use animations only if it serves functional purpose. Use animations to support users' consciousness on transition between two states that are not absolutely clear. 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, at least for frequently used functions. Make sure that animations run fluid even on lower spec machines. Always allow users to easily switch off animations. But consider as well to increase the timing to gain accessibility. Advices for creating an animation 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). Make interactions anticipative. 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. Best practice The life of an control follows a sequence from OnCreate -> OnShow -> OnActivate -> OnPaint -> OnResize -> OnPaint ... to … OnCloseQuery -> OnClose -> OnDeactivate -> OnHide -> OnDestroy. At some steps the support by an animation makes sense, others are well indicated right now by static visual features (like a frame around focused buttons). On the other hand, if a future animation is well conceivable the cell is marked with green color. This table should be filled up with small animations that illustrate the target behavior. Control OnCreate OnShow OnActivate OnFocus OnExecute OnLeave OnDestroy 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 (can) dock - - on undock - Scrollbar/Scrollbox - - - - indicate if first/last item or start/end is reached on scroll; accelerate/decelerate on big changes - - 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 Group Box - - - - - - - Splitter - - - - indicate the ability to resize - - Tabs - - - - animate tab switching (from/to) - - Accordion - - - indicate where to click animate accordion switching (from/to) - - List View - - - - (cf. scrolling) - - Tree View - - - - animate expand/collapse of nodes; cf. scrolling - - Radio Button - - - - indicate the change over (from/to) - - Check Box - - - - in case of checking a box with children indicate their auto checking - - Drop-down list - - Indicate the difference to (editable) combobox - animate expanding; indicate the bearing of selection on other controls animate collapsing - Combo box - - Indicate the difference to (non-editable) dropdown - animate expanding; indicate the bearing of selection on other controls; animate when an item is being added animate collapsing - Line edit - - Indicate if it's editable - Animate enter; indicate bearing on other controls - - Text edit - - - - Indicate copy/paste function; cf. scrolling - - Table - - - - Indicate add/del of col/row - - Spin box - - - - Animate the step on changing the value - - Slider - - - - - - - Tooltip - - - - - Indicate when a tip is closed soon (cf. fade out for notifications) - Notification - - - - - Indicate when the notification is closed soon - Progress bar - - - - Indicate operation as well on slow progress (e.g. as Microsoft does) - - Custom controls - - - - animate zoom - - References Parts of the guideline were inspired by Google's guideline on animations. Retrieved from "https://techbase.kde.org/index.php?title=Projects/Usability/HIG/Animations&oldid=82902" Categories: Under ConstructionUsabilityPresentationLayout Content is available under Creative Commons License SA 4.0 unless otherwise noted.