It didn’t take long for me to look at the GUI widgets rather than the story they were supposed to tell me and, once again, I thought to myself: spatio temporal continuity in UI rules.
What does that mean? I actually didn’t coined the term or brought it to bear in the UI world. That was a term that the folks at Macromedia used when talking about the Flash way to showing/hidding info on the screen: the slick sort of slow motion way of things to appear and disappear, the important thing of course is that the motion gives you a cue of “where” the thing disappeared and, indeed, how to get it back.
Pattern languages being a well infused meme in Silicon Valley, folks there tried, somewhat successfully to devise a set of basic components and effects that could be used in general situations. The thinking being that, a little bit like buttons and check boxes became prevalent widgets in UI through the seminal Apple UI Guidelines, some basic components could become the fundamental elements of a new UI language, one that would integrate animation and this concept of spatio temporal continuity.
Question: Do we need Flash for that? Is that a Flash inherent breakthrough? An accidental revolution they stumbled upon?
Answer: No. As often (always?), this concept was first used by Apple in the very first Mac UI. Remember closing a folder window? To help users identify which folder it was, the Mac OS animated a wireframe rectangle that would resize down and vanish on the relevant folder icon present on the desktop. This was a fantastic boon to usability at the time. Since then, Apple confirmed their love of spatio temporal continuity with sheet dialogs and drawers in Cocoa and Exposé, Fast User Switching and, recently, Time Machine in the OS. It’s always the same idea: don’t pop up things out of nowhere to the user, slide and expose so to reveal the relationship between the before and after state and how those states are reversible.
So, what about Chandler? Sadly, the wxWidgets framework does not support animations of that kind. The only way to implement something like that would be for us to draw the whole darn animation (meaning that we also draw the whole widget), reducing the use of the framework to a glorified bitblitting machine… Unless… wxTNG takes this one into account in its set of target goals. Well, it’s not in there yet.
Would that be a good idea? You guessed that I’ll be quick to say “yes” and I will, for all the good reasons listed above. Another more urgent reason though is that it’s clear that with the Sparkle/Avalon combo, even laggers using Vista will be exposed and start demanding such UI.
So, for the same reason buttons and checkboxes replaced “semi graphic” spreadsheet like UI in the 90s (if you don’t know what it is or don’t remember, you can still see them at work at your dry cleaner or local garage…), sliding panels, accordions, animated trees and toasts will likely become the norm in the next few years.
We better get wxWidgets updated with the program…