How pop is the new flicker
A long time ago when I worked on Windows 95, I wrote a version of the xeyes program mainly to play with the brand new SetWindowRegion function. I immediately got feedback that the eyes flickered when they were being updated. I fixed the problem and, even though I initially didn’t think the flicker was a big deal, comparing the before and after was like night and day. Removing the flicker made the app look much better and feel more polished.
After that I always was on the lookout for flicker and getting rid of it where I could. Modern graphics and UI frameworks have largely made flicker a thing of the past. On WPF you almost have to go out of your way to get things to flicker when updating. Also most UI developers are particularly sensitive to flicker and see it as a sign of an unpolished application.
When I joined the Surface team, one of my first tasks was to write a very simple application launcher. The user would first be presented with a list of application groups like “Board Games,” “Card Games,” etc. You would navigate in to a group and pick the application you wanted to start.
In the app launcher there was a requirement from Design for a smooth transition from the first menu to the second. It should not “pop” from menu to menu. You would also see the title of the group animate to the side as the new group of items transitioned in.
So, yes, in the context of this post, "pop" is a bad thing.
Below is a video of the early app launcher running on very early Surface hardware. (Apologies for the quality, I took it with my cell-phone.) Notice how the title of the section I select transitions to the title of the next menu.
UX experts can better elaborate than I on the benefits of avoiding “popping” from one UI state to another. From what I’ve observed, when you show the user how they got from “point a” to “point b” they are less likely to get lost. They know how they got to where they are and it gives clues to how they can get back. It’s also less jarring especially in a full screen app. Finally, like removing flicker, removing pop gives an application a more polished feel.
In the Surface Photos app we worked hard to smooth out the transition between a stack of photos and a grid of photos. The transition shows the user that they are viewing the same set of photos and that they are in the same place in the list of photos.
Photos transition between stack and grid (again, taken from my phone :-) )
We currently have to remove pop from UI transitions by hand. Unlike solving the flicker problem, UI frameworks don’t have a generalized method to transition you smoothly and clearly from one UI state to another. The mechanism we use to transition from “stack” to “grid” mode in Photos is not something that could be easily be reused to transition from a top-level menu to a second-level menu.
A great step in the right direction is the VisualStateManager that is in Silverlight and soon to be in WPF. It lets the you define your UI states and let a designer create storyboards that smoothly transition from state-to-state. I used it in a small side project and it worked as advertised. It doesn’t solve the full “pop” problem but can be a great building block.
Keep in mind that you still don’t want to annoy the user. Everyone’s appreciation and tolerances of animation in UI is different. You always want to keep it quick, have it serve a point, and not cause the system to bog down.
So my call to action is to put UI “pop” in the same category as UI “flicker” and work to eliminate wherever you see it. With the combination of end-users demanding a better experience, application developers looking to deliver that experience, and UI framework designers facilitating this, I know we can get there.
Do you have any other UI implementation pet peeves? Are smooth transitions gratuitous? Put your thoughts in the comments!