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.
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.