Imagine driving a car and every 10 seconds somebody covered your eyes for 2 seconds. Each time the road reappeared, you would have to totally reassess the situation before you felt confident again. The anxiety would be overwhelming.
Flashing gui's and full screen page reloads are the same thing. Even if nothing's really changing the user thinks it did. Things should change in proportion to how big a deal they are, and they should change in a way that relates the departure point to the destination.
Apple has been fantastic with transitions. My favorite is scrolling through photos on the iPhone. Qt is also redesigning their entire GUI engine to support transitions. Right now GUI toolkits focus on defined states. I imagine we are moving toward having defined transitions as well.
That's an interesting way of putting it, I hadn't really thought about it that way before. Most of the projects I work on use transitions extensively in their interfaces mainly for the aesthetic value but I hadn't considered the potential usability advantage too.
The thing is, personally I prefer interfaces without transitions (or at least those interfaces that have a way of disabling them). I suppose when you become very familiar with a piece of software you know exactly what happens when you perform a particular action so the visual cue becomes redundant. The more I use something that has transitions, no matter how fast or minimal they are, the more they get on my nerves! Disabling transitions where possible is one of the first things I do after installing a new OS, be it Windows or OSX.
That's the danger of transitions too, the desire to go overboard for the aesthetic and end up frustrating users as things take too long to happen, even if they delight the first time they are seen. I find Flash websites in particular fall into this trap too often.
You're spot on. Transitions can easily resemble a gratuitous 80's guitar solo. A window need not preform a corkscrewing swan dive into the dock every time it's minimized.
But I think that as developers you and I are privy to the game behind the scenes. I think of GUI garnishment like stage props in a play. A playwright would not need the sounds of hoofs, the cries of men and the clanging of swords to know that the Battle of Agincourt is raging on stage - Just as a developer doesn't need to know that pushing a button triggered a state change - But someone who's never read Shakespeare - or in our case someone who's never written software - would find them very elucidating.
Though like you said, the key is to preform these special effects with taste and meaning.
The key is perceived responsiveness. If transitions appear to be slowing down actions in the GUI then they become annoying. If there's a 1:1 correlation between the transition and the action being performed then they tend to work well I think. I good example is sliding between app screens on the iphone.
The window manager XMonad tries to make actions easy and predictable, thus bringing you faster to the point where you do not need transitions. (And it does not do transitions by default.)
I'm currently developing a UI system that has morphing built in. I do think it helps build more understandable designs. Sometimes you can even use transitions to subliminally teach things about your underlying information architecture.
Apple's Aqua window manager supports morphing windows using a warp grid, although the API isn't public. The "Genie" effect (when minimizing to the Dock) is accomplished by distorting the warp grid.
(Just in case someone doesn't know this: most of the UI animations on Mac OS X can be viewed in slow motion by simply holding down Shift. This works for all the Dock animations -- minimizing, stack popups, etc. -- and seems to work in many Core Animation situations as well.)
I've been playing with something similar for a desktop app. Not with the morphing per se, but with something quite similar.
Basically there is a sequence of related dialogs, chained by the Next button, and the content of these dialogs varies greatly from a lot to almost nothing. Using standard wizard-style fixed-size canvas lots of ugly empty space and produces visually inconsistent page-by-page layout.
What I ended up doing is using (fade out)-(resize)-(fade in) sequence for transitioning between the dialogs. The animated resize is a key as it demonstrates that two dialogs are related linearly and not hierarchically, and one replaces another and rather than poping over the old one. The fading animation is needed to prevent dialog content clipping during the resize. It takes 200 ms and simply makes the contents of the dialog disappear into the background and back.
The feedback so far was very positive. It looks nice, not in your face fancy and it is fast, so it doesn't detract attention from the primary user interaction. Some users do not even notice the transition, so it no harm done there either :-)
Any advanced effects are prone to stuttering in the animation loop. Javascript is bad with this, but OS level stuff can stutter too.
Stuttering can be destructive to User confidence as well.
---
Also with morphing there is a problem of Mystery Meat[1] navigation. In this depicted example the Morph is an alternative to another mystery meat, yet there are many problems that could have both cause and effect permanently visible.
I never saw OS X animations stutter. Sure, Expose drops frames now and then (dropping frames is the sensible approach, not displaying every frame and introducing stutter), but that's ok. That makes the animation jerky but just as quick and reduces the impression of stutter.
I think it is very plausible that seamless and low key animations can increase usability. Sure, user testing would be needed to verify that, but it seems intuitive enough to me. There are technical problems, sure, and stuttering animations should be avoided, but that's no reason to reject morphing out of hand.
Nice idea, but like other animation techniques most uses are probably unwarranted. The biggest problem with these things is that they take time, and after you've made the mental connection, you don't need to take that time to understand. So it just gets annoying.
Flashing gui's and full screen page reloads are the same thing. Even if nothing's really changing the user thinks it did. Things should change in proportion to how big a deal they are, and they should change in a way that relates the departure point to the destination.
Apple has been fantastic with transitions. My favorite is scrolling through photos on the iPhone. Qt is also redesigning their entire GUI engine to support transitions. Right now GUI toolkits focus on defined states. I imagine we are moving toward having defined transitions as well.