Limit the use of certain animations through the HIG
I may be underinformed but I want to say this nevertheless.
Yesterday I've seen some videos of the GALA window manager on YouTube. By the sound of it, this may be used in Luna+1 as a replacement for compiz. In the videos a whole range of animations is being displayed, including different types of fades and slides. Someone has even applied these effects within Switchboard. Though it may look cool at a first glance, it extremely slows down the user experience.
* Through this blueprint I want to limit the use of animations that slow down the user experience. *
elementary apps are extremely fast and powerful. On my computer, most apps load within half a second. That's with an intel i3 and no SSD. This speed is what makes elementary a great OS compared to sluggish OS'es like Windows 7. It's something to be very proud of. So what I don't want to see happening is for tons of animations to be added to interactions, that slow down the user.
For example: when you use slide effects in Switchboard, instead of instantly delivering the content on the screen (like BAM!), you make the user wait for the animation to finish.
- First of all this suggests that the app needs the animation to hide the fact that it's a slow app, which is not the case because it's the animation that slows down the app. Your app, in fact, represents a higher quality without the animation than it does with the animation because it gets to show how lightning fast it is.
-Secondly, you make your user wait for no sane reason! The animation does not help the user to get things done and while the animation is playing, the user can only wait for it to end because since the content is sliding over the screen, the user cannot prepare for their next step (e.g. clicking an icon). This is frustrating. Period.
We could set a maximum time for fade effects, like 2-3 ms, in the HIG to limit the implications of animations. However, my advise is to try to solely use animations that do not make the user wait. For example, instead of doing a fade-in on the entire window, try to make the window appear instantly and THEN play some sort of quick, blue glow-effect around the screen (though only for as long as the window is active, or it'll feel laggy). This makes launching apps fancy while still presenting content instantly.
Another simple usecase is that when you click the close button on a screen, you want the app to close. Nothing more, nothing less. Since there might be some latency between clicking "close" and the screen being gone (especially when closing multiple windows), having an animation upon closing is a bad idea. Make it swift.
Last of all, I think it's important to reimplement wobbly windows in GALA, because it is a very smooth, natural and fancy effect that gives the "wow" feeling without slowing down the user. Personally I find it to be the best effect on the linux desktop. Static boxes are static.
I am aware that it's considered to be a best practice not to give the user a lot of options but I do think the user should be allowed to choose/
Summary:
- Avoid animations that make the user wait;
- Limit them in the HIG;
- Try to come up with animations that occur after the content is shown;
- Put the user in control of their experience.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Danielle Foré
Related branches
Related bugs
Sprints
Whiteboard
The thing with switchboard.. I could make it a lot faster (actually I already did), but due to the nature of our socket system in there, their loading time is quite long. So this animations is actually supposed to cover this the best possible.
A switchboard plug for gala is already in planning, but quite low prio.
(I miss wobbly windows in gala too, but there's hope, someone already did this for gnome-shell!)
And lastly I would propose you to test gala yourself, my videos are quite outdated already.
Here's you can find the default effects or how they might look later https:/
~tom59
2-3 ms is too fast to be noticeable. 50ms is the rough minimum on top hardware, and older hardware won't render anything under 100ms in a visible manner.
The use of animations is in fact a complicated topic; sometimes using a rather lengthy animation is better than showing the final state instantly, because in the latter case it takes you some time to figure out what happened. And it's not just about time - animation save you some effort to understand what's going on; effect of that that really shows after working with computer for several hours.
So yes, there should be quite some research on animations done, and we don't want to end up being like GNOME Shell with their maximization animation taking an eternity to complete. Writing down some guidelines is also a good idea. ~shnatsel
@Tom, I'd love to test Gala myself. Actually I've been spending a lot of time lately trying to get elementary Luna running again, after I messed up a week ago. Anyway, thanks for the great response! Regarding switchboard: to make the animation look good, it cannot be too fast. When it's not too fast, you make users wait. That's the dilemma I'm addressing. -- Kevin
@shnatsel, sorry about the calculation mistake. I meant 0,2 to 0,3 seconds. I think I agree with the use of animations to help the user to understand what happened. We'd have to find a good balance though. When an app takes half a second to load but the animation takes another half a second... you basically make your app twice as slow. Poorly implemented animations can give the impression that you've got something to cover up. -- Kevin
Hi Kevin. This is precisely why I don't like when users stumble upon pre-release alpha-quality software. What you see implemented in a pre-release doesn't necessarily mean you'll see it in the final release. Often times, animations are testing with a much longer interval to make sure it's smooth and logical, then the animation is sped up for the final implementation. Our intention is never to provide such lengthy animations that it delays a users experience, but to provide better mental models of how to use/navigate software and to avoid jarring transitions. TL;DR Your lack of faith disturbs me. --DanRabbit
Hey Daniel. It's good to know that we are on the same page. I love everything you have done so far and I don't see why I wouldn't be able trust you or the rest of the team in future undertakings. "Lack of faith" sounds a bit unfriendly in this context. I was a bit sad to hear that. I do strongly believe in your skills as a professional GUI designer and I am very excited about what is yet to come. :)
The reason that I reacted so quickly is that I'm very content with the way animations are handled in the compiz version of elementary, especially when you compare it to Windows 7 which is generally slow. Gala will open up lots of new exciting possibilities for effects, yet the best practice would probably be to use as little of them as possible (tends to be hard). The real visual value would then be in the rounded corners and hotcorners, which I must say do totally rock. You should really keep the workspace switcher in there since I've never seen such accessible workspaces before. Mainstream users would love it. :)
I am sure you are objective enough to ensure the best possible experience but there will likely also be people who want to throw in just one more cool effect because it's possible. That was my concern. Anyway, it's good to know you're on top of it.
By the way, I've added a rather extensive note in the Google Doc about right-click menu's and indicators. It's just a brainstorm / idea so do with it whatever you'd like. You may close this blueprint as well.
Based on my experience with another project I'd rather speak my mind beforehand than suggesting something after a decision has been made and implemented, so please excuse me for reacting so quickly. Old habits... ;-)
Have a good weekend everyone! -- Kevin
