[kde-guidelines] HIG: Animations

[Heiko Tietze]

I put a draft about animations on the wiki (Presentation > Style > "Use low 
level animations to support usability."). It contains as well of a table with 
ideas where/when to add animations, additionally to the following general 
advises. 

References: 
Kanban: https://todo.kde.org/?controller=board&action=assign&task_id=71
Forums: https://forum.kde.org/viewtopic.php?f=285&t=121993
Wiki/HIG: https://techbase.kde.org/Projects/Usability/HIG/Animations

= 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 =
(Collection of ideas, to be completed by the VDG)