Hello my fellow designers!

I've started work on putting together some animation guidelines. This work includes a full survey of existing animation guidelines on other platforms to see what has been done and what might be applicable in the context of our design vision and principles.

I also wanted to solicit your ideas on what would be important to include in such guidelines. What not-so-great ideas on any platform would you like to avoid? What cool ideas would you love to make sure the guidelines account for? Review our design vision and principles and brainstorm what you might like to see in our animation guidelines.

Thanks for your participation and help!

Just my 2c about the overall ui animations. In my opinion they should guide the user and not hinder. They should be subtle.
All the animations should be rather fast to avoid the feeling of slowness/sloppiness especially for hover/popup actions. I can't stand that kind of animations if they take more than 200ms - context menus even less. Animations should be fluid even on lower spec machines.
Animations can be used to mask reloading of parts of the ui. All types of redrawing the ui should be avoided - for example when starting an app noticeable drawing/resizing/jumping of widgets. Unfortunately that is not uncommon in KDE... and leaves a very bad impression.

My impression is that we need to do away with effects that really contribute little to the overall experience of a workflow on the desktop. I generally remove any transparencies when moving objects, any wobbly effects when maximizing/unmaximizing, subtle highlights when focusing or hovering, etc. Maybe a good way to start into this subject is "not" to start from a desktop with effects already in place, but rather with a vanilla desktop without any effects, so as to only add the ones that are thought of helpful and intuitive.

This can be expanded indefinably - I mean lets first admit that whatever guidelines there are will be able to be changed by the user when it comes to the desktop. BUT that shouldn't stop us from
1) Creating sane defaults
2) Looking at how animations work in applications (a prime example would be Muon Discover forexample, thats severely overanimated - there is a thread where the devs ask for help here btw viewtopic.php?f=285&t=121810 )

In general I think the set goals SHOULD be (just me saying) that, as already stated, all animations need to have a usability purpose. If a clear usability case can't be done, the animation shouldn't be there by default.
An animation can hint at positions - and we can drag up the visual design goals drafted earlier this year here and say that they can by creating a sensation of space and placement help enforce a feeling of air, openness and depth to the overall design. It can show the user where she is through movement (take for example the slide when switching virtual desktop).

But for me one of the main reasons behind animation is to enforce a feeling - that doesn't mean "arbitrarily add new animations that fit the feeling" but that if criteria A is "Must have a usability reason", criteria B should be "Should reinforce the emotional goal of the desktop".
As an example, say if the Kickoff Launchers close animation was a wobbly bouncy animation where the launcher looked almost cartoonishly rubbery. That would clash with the rest of the desktop visuals. We need to hammer out what those visual goals should be, what kind of emotional response the animations should create in the users.

IMHO, the only animation related to usability is about progress: "Show a busy pointer when the operation takes longer than 500 ms and a progress bar in case of 5 seconds or more." (https://techbase.kde.org/Projects/Usabi ... sIndicator)
Changing input, blinking symbols, moving symbols etc. are a very strong attractors for perception, much more intense than space, for example. I would always try to direct the attention by more subtle solutions. So perhaps we should find some use cases first where animations makes sense, apart from the emotional aspect.

PS: First idea: graphs, or rather the zoom function should be animated because the function is a transition between two non-obvious states like 100% and 120%.

Heiko:
Well I can think of one good example that I've seen happen IRL and that is the animation when you switch virtual desktops. With a shortcut on the keyboard I've seen relatives and friends hit it by mistake and since they are unaccustomed to virtual desktops they simply don't get where the stuff went EXCEPT when there is an animation. It gives the user understanding of the space available AND where stuff went.

In web design there is a swath of texts on this (to either using peaking or animation in these cases)

jensreuterberg wrote:...the animation when you switch virtual desktops.

Sounds reasonable. And again, it's a transition between two states that are not absolutely clear like min/max, on/off, or step 1/2/3. It's the same for turning over a page (Okular in single page mode), flipping something upside down (Amarok, B side), adjusting an arbitrary value (color from red to blue). Just to extrapolate the idea.

No idea whether that might be helpful for you, but be.animated in https://sourceforge.net/p/bekwinfx/ will allow you to setup random animations in kwin.
It's uses the same class that powers the scripted animation effects, so the setups are 100% implementable as scripts as well.
The linked effect has the advance that you don't need to know how to write a kwin effect script but just select window types, animation types and parameters.

Here's also a screenshot of the config dialog:
http://kde-apps.org/CONTENT/content-pre1/145674-1.jpeg

This is a layman's perspective, but animations are one of the reasons I stopped using KDE after version 3. The transition time between menus is infuriating and by default everything has a quite long animation, to the point where it actually feels like lag. This new interface is a step in the right direction in my opinion, but it's worth nothing if an environment like XFCE still feels more usable.

I think the animations here (http://codepen.io/anon/pen/hnqHz), at 200ms, are a great starting point. At 400ms, http://codepen.io/anon/pen/zFpAg has become visibly slow. At 300ms, http://codepen.io/anon/pen/HkzDL is about where KDE's animations are currently: usable but slightly frustrating. At 150ms, http://codepen.io/anon/pen/Jjvwx seems to be a great balance between usability and "feeling". At 100ms, http://codepen.io/anon/pen/oqczn is barely noticeable if it's not being looked for, but still contributes to "feeling". At 50ms, http://codepen.io/anon/pen/kclzK seems to become very visible and almost a bit silly. Thus, I suggest that window animations, if there are any, should be between 150 and 200ms, and menu animations should be kept at either 100ms or off. Hover animations, as seen in the current environment, should be incredibly short or off, as they absolutely contribute to the clunky feeling.

spamyak wrote:I think the animations here (http://codepen.io/anon/pen/hnqHz), at 200ms, are a great starting point. At 400ms, http://codepen.io/anon/pen/zFpAg has become visibly slow. At 300ms, http://codepen.io/anon/pen/HkzDL is about where KDE's animations are currently: usable but slightly frustrating. At 150ms, http://codepen.io/anon/pen/Jjvwx seems to be a great balance between usability and "feeling". At 100ms, http://codepen.io/anon/pen/oqczn is barely noticeable if it's not being looked for, but still contributes to "feeling". At 50ms, http://codepen.io/anon/pen/kclzK seems to become very visible and almost a bit silly. Thus, I suggest that window animations, if there are any, should be between 150 and 200ms, and menu animations should be kept at either 100ms or off. Hover animations, as seen in the current environment, should be incredibly short or off, as they absolutely contribute to the clunky feeling.

Took the words right out of my mouth.

I completely agree with this. 200ms is the absolutely slowest animations we should have, and for menus they should be even faster.

Waiting for a computer is one of the most annoying things I experience during my day, and intentionally waiting for a computer is just silly.

spamyak wrote:Thus, I suggest that window animations, if there are any, should be between 150 and 200ms, and menu animations should be kept at either 100ms or off. Hover animations, as seen in the current environment, should be incredibly short or off, as they absolutely contribute to the clunky feeling.

Doesn't it depend on the kind of animation in terms of interruption the workflow how unobtrusive animations should be? For example, I do not switch my virtual desktop (meta + tab) to read some data there, I'd rather switch the windows (alt+tab). The first one could be animated with even 500ms and the other very short. Nevertheless, it might be a good idea to have options like off, fast, medium, and slow.

Heiko Tietze wrote:For example, I do not switch my virtual desktop (meta + tab) to read some data there, I'd rather switch the windows (alt+tab). The first one could be animated with even 500ms and the other very short. Nevertheless, it might be a good idea to have options like off, fast, medium, and slow.

I know from my own experience that when envisioning and creating animations I always think they're going to be awesome. And many times they actually are.

However, when using the software, I just as often find myself being annoyed by an animation taking too long, interrupting my workflow and breaking my concentration. As a "Wow"-element when trying out new software it's pretty cool, but when the user evolves into doing actual work with the software, unnecessary animations are just in the way.

Options for most categories of animations would probably be a good idea. As you say, some operations are done less often than others, and can perhaps (for the right user) afford to take longer time. But frequent operations - and especially hover animations! - must never give the feeling of an artificial delay of the workflow!

Well there is a trick to it which is essentially - if something happens "Once per day" the animation can be over two seconds, "Twice a day" it has to be UNDER two seconds and "More than twice a day" and it can't be more than half a second and should be able to only be counted in milliseconds.

It's like the difference between an intro, a splash and an animation.

An animation can never be seen. If you can spot the animation easily the animation has failed - it has to be intuitive and natural. Like for example the animation when you scroll and that little tiny bounce you get, or the extra slide in some RSS plasmoids which makes it feel "weighty" and "solid". You should never think about the animation - it should simply be something that lets your reptilian brain perceive the desktop better. Make sense of the fake space in front of you and make it feel natural and normal.

Some inspiration from
* Google (check as well the sidebar menu): http://www.google.com/design/spec/animation/
* Microsoft: http://msdn.microsoft.com/en-us/library ... 11854.aspx

jensreuterberg wrote:Well there is a trick to it which is essentially - if something happens "Once per day" the animation can be over two seconds, "Twice a day" it has to be UNDER two seconds and "More than twice a day" and it can't be more than half a second and should be able to only be counted in milliseconds.

It's like the difference between an intro, a splash and an animation.

An animation can never be seen. If you can spot the animation easily the animation has failed - it has to be intuitive and natural. Like for example the animation when you scroll and that little tiny bounce you get, or the extra slide in some RSS plasmoids which makes it feel "weighty" and "solid". You should never think about the animation - it should simply be something that lets your reptilian brain perceive the desktop better. Make sense of the fake space in front of you and make it feel natural and normal.

Agreed! Natural and neutral