Okay, so I am officially fed up with the notion that graphical user interfaces are "intuitive" and "easy to use." There is nothing inherently intuitive or easy in a GUI. It all comes down to the design. Moving a mouse pointer over an icon and clicking it may look cool, may feel cool, but how easy is it for the average person? The answer depends on a variety of factors, like hand eye coordination and icon design. Half the time my screen has a bunch of icons on it the meaning of which is less than obvious. In other words, I have to learn what the icon means, I cannot simply intuit the meaning. Surely a word would be better? Yes, I know that you can turn on words for some icons, but this is inconsistent between applications and operating systems. And when you get to the web all bets are off. Some sites underline links, others don't. Some use rollovers, others don't. The same function is given different names on different sites, and so on and so forth.
How did we arrive at this situation, where computers and software are designed with interfaces that are non-obvious? Obstacles and not enablers? There are several parties to blame. Let's start with the industry giants and the wars between them that did not help (a great case study for MBA students--how the free market influences interface design--does the
iPod dominate MP3 players due to interface? Did the windows wars between Apple and Microsoft help or hinder the interface evolution?).
Competition is great for some things, but when companies get fixated with one-upping the competition (in order to sell more product) there is a tendency to force software and hardware developers to add bells and whistles and do things different, even when an unadorned standard
config is working fine. There is a whole book in this phenomenon, but consider one example, an interface issue that may well be the single greatest cause of lost productivity in the late nineties and
early oughties (or whatever this current decade is called).
I'm talking about the way File Save works. Back in the old days, somewhere between the Pterodactyls and the 386 chip, it was "standard" for the File Save command to require confirmation, much the same way that the File Save As command does today. Suppose you had opened up the spreadsheet of weekly sales figures and updated them. When you selected File Save the spreadsheet application would ask you: Yes or No? The reason for this was obvious: You might want both versions of the spreadsheet, the one that you opened and the edited one . The latter might be very different. For example, the original might be the
Megabank proposal which you had edited to become the
Ultrabank proposal. You might have deleted a lot of information from the original on the way to the new version.
Obviously the File Save As command is for just such situations, but if there was one instruction that was drummed into the brains of early adopters of PC technology, back in the days when they were prone to disk crashes and brownouts and OS flakiness, it was this: Save now and save often. At that time, saving was not a destructive process. But it became one. And the Apple Mac was where it started. The Mac introduced "File Save with no overwrite confirmation." This meant you could have a problem if you opened a 10 page report, spent an hour re-writing the last 5 pages, hit File Save, then changed your mind about the changes. Even worse, open the document, perform Select All , Cut, File Save, and think about what happens if the machine hiccups before you Paste.
In all these scenarios there were workarounds that prevented them from being problematic, but they required a significant change in work flow. And for what? To make it easier to save work, a goal not necessarily accomplished
without some hard lessons and tough data losses in the interim. Arguably things got worse when Microsoft Windows apps aped this style of File Save. (I well recall long distance arguments as a beta-tester with
Borland as it struggled to choose the file save style for
Quattro Pro--go with the new Excel/Mac "overwrite" style or stick with the
traditional "confirm overwrite" style of Lotus 1-2-3.)
Windows aspired to be like Mac only different. That led to several File Save issues. One of the benefits of a graphical OS is the ability to convey more information in the same space. For example, an application could show if File Save was necessary by graying out and disabling the File Save command when the version of the document in memory was the same as that stored on the hard drive. But that feature has never been implemented consistently. That's a pity because it is really handy to know if changes have been made. Consider the task of editing a large image where the File Save command can take a long time to execute; performing unnecessary file saves in this situation is a real waste of time. The Canvas graphics program is one application that conforms to the "gray=saved" convention.
The current "saved" status of a document is particularly important when you are dealing with files that exist in two places, such as a web site you are editing locally before uploading. Fittingly,
Dreamweaver MX is another app that uses the "gray=saved" convention.
I like the "gray=saved" convention but like a lot of interface conventions one cannot rely on it being there across apps or platforms. Why is this a problem? Because better and more consistent interfaces improve productivity and safety. We're all familiar with
steering wheels. They allow us to jump behind the wheel of any car and navigate through traffic with a high level of expectation of success. They are a convention that car makers mess with at their peril, however much they want to "out-innovate" or "one-up" the competition. And we don't teach our kids to drive cars by telling them clockwise for starboard, anti-clockwise for port, because those are not the conventions used in driving cars. Port and starboard are for boats, where steering is sometimes a matter of push the tiller right to go left and so on. But in the early days of automobiles, some used tillers. Most people agree the wheel thing was a step forward and it has been the automotive interface standard for navigation for nearly a century. Maybe computers could use a similar period of interface standardization and stability.
.
In techno-speak and biz-think, the role of the electric milk float meshes perfectly with the traditional characteristics of an electric vehicle. The range was 30 miles, plenty for the inner city delivery route I covered. The speed topped out at 30 mph, the highest speed limit of any of the roads on the route. The float pictured on the right is pretty much the same as the one I drove. It is even in the livery of the Unigate company, the same dairy I worked for, owned by food giant Unilever. The image is from the amazing milkfloats.org.uk web site. Amazing because yes, there is a whole web site devoted to these vehicles.
