Should the Ghost in the Machine be Invisible?
For anyone new to this weblog, I am developing an application named Charlie. At this point in time, I am seeking an interface convention to ensure that all administration screens act in a consistent and predictable way. To this end, I have been thinking a lot about interfaces and how users interact with software applications. Right now, I am considering two separate but related aspects of interface design. First, should Charlie itself be invisible to the user? Second, should Charlie’s mode changes be invisible to the user?
Now, should Charlie itself be invisible to the user? I have said earlier that software should stay out of the way while the user performs a task, but that is not the same thing as being invisible software. The original Mac operating system provides a great example. The OS never got in the way, but Apple did not hide it, either. To start with, the operating system had a face:
This is no mere gimmick. This is a message to the user: “I am here. Know me. Love me.” Apple did not hide the OS away; it brought it to the fore and made it a friend. Microsoft does not take this approach with its Windows operating system. The operating system is kept in the background, and makes no attempt to befriend the user. Both operating systems stay out of the way, but Windows walks behind the user, and the Mac walks beside the user. It is my opinion that the Mac approach brings with it two real benefits that I’d like for Charlie to exhibit too.
One benefit to making software a friend is that it enables the user to forgive the software if it displays any shortcomings. It is easy to get mad at Windows, because it operates like it has a bunch of goblins running about, out of sight, causing mischief. Windows is quite unapologetic about its screw ups. But it is hard to get mad at the Mac, because it operates like a friend who, on occasion, gets things a little wrong. The Mac will show you its face, tell you what’s gone wrong, and effectively says, “Look, I messed this one up. But we’re still friends, right?” Right!
Another benefit to making software a friend is that it makes the user reluctant to let it go. You just don’t discard friends. (Or if you do, I don’t want you as a friend or as a customer.) If the users of Charlie form an emotional attachment to the software, then they will not switch to another application just because it is a little cheaper or because it offers a few more features. Friends stick together.
The second aspect of interface design that is on my mind is whether Charlie’s mode changes should be invisible to the user. And what is a mode change? It is a switch to a different activity. (I don’t know the true definition of a mode change in software. And it’s not important anyway. What’s important is the principle being discussed, not the name applied.)
Say that the owner of Homunculus.com wants to edit his Carla Gugino page, because he wants to let the world know that she gets naked in Sin City. He opens his browser and navigates to Carla’s page. Right now, he’s in View mode. How should he switch to Edit mode?
If the change from View mode to Edit mode is invisible (which can almost be done), he’d simply place the cursor at the end of the page, and start typing the new content. If he navigates away, some Ajax trickery can send the updates to the server to be saved to the database. We might say that this is a zero-mode change.
If the change from View mode to Edit mode is explicit but occurs without fetching a new page (get a free account with BackPack to see this in action), he’d click on an “Edit this Content” button which replaces just a part of the page with a textbox. The website owner can add his comments about Carla’s curves and then click on a Save button. The textbox disappears and the new content is displayed (more Ajax trickery). Since a part of the page changes mode while the rest of the page stays the same, we might say this is a half-mode change.
The final main option is that the website owner can click on an “Edit this Content” button which fetches a whole new page which makes no attempt to look like the live page, and attempts only to present a form with which the owner can update his website. Since the entire page changes and there is an explicit switch between View mode and Edit mode, we might say that this is a full-mode change.
The question is, which type of mode change is best? Zero-mode, half-mode, or full-mode? The answer to this question means deciding just how transparent a mode change ought to be.
It is my belief that zero-mode changes are dumb. How many times have you been bothered by users who become completely confused because they mistakenly undocked a toolbar, or moved or resized the taskbar? The need to undock a toolbar or move a taskbar is so rare that it is dumb to make it a zero-mode-change operation; all it leads to is confused and annoyed users. Without an explicit mode change, the user has no idea where they are in the task they want to perform, what they can do at this point, and what they can do next.
It is also my belief that half-mode changes are an inadvisable goal for software. To start with, it can be disorienting for the user. There is no sense of “location within the task,” since a part of the screen is performing one task (showing content) and another part of the screen is performing another task (editing content). Another problem is that not all tasks can be undertaken with a half-mode change. That means that sometimes the Edit button will initiate a half-mode change, and sometimes the Edit button will initiate a full-mode change. This unpredictable behaviour provides for a poor user experience. A further problem is that such “in-place editing” provides no opportunity for draft content, because all changes are made to the live content. That’s okay for a narrow range of software, but for a website framework it is important that the owner can start to create a new page and then change his mind. If the website owner suddenly finds that he doesn’t have enough information to finish the content, then he should have the option to save the content in draft form, and finish it later.
It is my belief that full-mode changes are the only realistic target for an interface convention. By making full and explicit mode changes, the user will always know where he is within a given task, and what he can do next. Also, if the same full-mode change is made every time an Edit button is clicked, this will provide the user with consistent and predictable behaviour. Finally, full-mode changes allow for complete control over what to do with the data on the “edit this content” page; that data can be discarded, or saved in draft form, or published to the live website. Sure, full-mode changes are clunky and uncool, but they are flexible, predictable, and consistent.
Unless further investigation shows that my beliefs are mistaken, Charlie will be visible to users, and its administration pages will involve a full-mode change.
by Alister Jones | Next up: One Interface or Two? →
----
Post a Comment