Mark Freedman’s Blog

Archive for the ‘UI’ Category

Here’s an example of “user abuse“, which has remained throughout several versions of Microsoft Outlook . What do you think clicking the check box will do? If I’m never asked again, what would Outlook do automatically in the future? Would it always send a receipt? Would it never send a receipt? Would it always do what I select now (Yes or No )?

Always avoid this ambiguity in your applications. Would you like this type of message interrupting your flow? Would such a message cause you to avoid ever selecting the check box out of fear that you just told Outlook to always send a receipt for all future requests? You may certainly feel that if you change this default, you’d never be able to find the way to reverse your answer in the future, since Outlook options are so buried (a topic for a future article).

Always try to stand in your users’ shoes. You don’t want to be accused of “user abuse” I call this “user abuse”, and not just “user interface abuse”, because in the end, it’s how you treat your users that counts.

The easiest way to solve this is by changing the check box to read “Make my answer the default, and don’t ask me again.”

You may wonder why I don’t recommend adding multiple options. Quite simply, message boxes should be as unobtrusive as possible. Rarely, if ever, should a message box do more than ask a simple question. As a matter of fact, even the absence of a check box would be more acceptable than an ambiguous one like this. If it were easy to find the option to turn off receipts in general, it’s likely the Outlook developers would not have added this option to the message box at all.

Be kind to your users.

Your UI is not your father’s UI.

Back in the late 80’s, during the days of Windows 2.0, the big push was to make your applications SAA/CUA compliant. SAA (Systems Application Architecture) was IBM’s strategy for enterprise computing in the late 1980s and early 1990s, which defined three layers of service, one of which was Common User Access (CUA). This became the basis of what many graphical user interfaces look like under Windows, Mac, and the like.

I even started a company to develop an add-on tool for Clipper developers (CUAccess) back in 1990, which allowed developers to create compliant user interfaces for text-based applications (mainly to mimic Windows apps in an easier environment to develop under at the time).

Microsoft then came out with what was my bible for UI, The Windows Interface Guidelines for Software Design. Following these standards was all the rage. You could create consistent user interfaces. You’d only needed to teach a user one application following these guidelines, and they’d know how to use all the others. Everything was supposed to conform. Developers didn’t have to worry about how to lay out their presentation as much as what the application should do. It was all hunky dory.

But then the rumblings started. I believe it first came out of the gaming world. “Business application UIs should be as rich as these games,” the pundits would say. People intuitively knew how to navigate through games, no matter how different they looked from one another. It was obvious that to use a weapon, you needed to pick it up. To open a door, you just needed to click on it. To view a map, just click on something that looked like it could be a map. To change armor, just look for an armor icon and click on it.

Ah! Little pictures are all we need! So everyone started using toolbars in their Windows apps. These toolbars were made up of tiny “icons”, which became more numerous, and kept getting smaller and smaller, because you still needed room for those boring forms and controls.

Ah! I know! We’ll let the users customize their own toolbars, and choose from several standard groups, and they can put them anywhere on the screen!

And then came the attack of Microsoft Word…

So Microsoft went back to the drawing board, and said “I know where we went wrong! We don’t need toolbars, we need ribbons!” And then there were ribbons…

And Microsoft looked. And they said it was good. And so they slept.

The problem is, they missed the past dozen years. The browser changed everything.

Once upon a time, the software industry was yelling, “conform, conform!” Heck, I was yelling, “conform, conform!” I admit it — I was a “pixel counter”. But although I learned about the benefits of an intuitive user interface, I now somewhat disdain those ideas. I believe we missed the point, and we’re now starting to realize it.

The true goal of a rich user experience is intuitive and attractive user interfaces, which cause people to feel comfortable and even excited about using software to get their real work done. With technologies such as AJAX, Silverlight, and WPF, and tools such as Microsoft Expression Studio, the industry is finally realizing that you need the cooperative efforts of both developers and designers for creating satisfying user experiences. Developers used to try to go it alone, and we recognize that the earlier standards were necessary with the skill sets of the people writing these systems. But the world may be changing for the better.

When the Web started taking off, we reverted somewhat to garish user interfaces, while we used the excuse of the Web being, once again, the wild west where anything goes. The industry sort of rebelled against the conforming constraints the desktop UI development standards were restricting us to. But over the past few years, I believe we’ve started to find balance. We had our chance to play and experiment, but we’re finally finding a middle ground, and we’ll start seeing the most usable software the industry has seen so far.

At least that is my hope.

One of Alan Cooper’s arguments in user interface design has been that explicitly asking the user to save a file is a waste of time. I’ve always agreed with that, but I wonder if we’re too late in making autosave the standard. These days, many applications have an autosave feature in addition to an explicit save command.

For years, people have been taught, usually through an extremely painful episode or two, to constantly press CTRL-S while working on a document or any other type of data-centric application. I do that several times per paragraph. As a matter of fact, I’m doing it now, and this is where the problem lies. I’m typing in WordPress, in a web-based UI. CTRL-S in Firefox is not “Save” — it’s “Save Page As”, for the purpose of saving a web page to your hard drive. Thankfully, WordPress has a very cool autosave feature.

But habits die hard. You see, the fear of losing my work is so embedded that autosave is not enough for me. I regularly click “Save and Continue Editing” within WordPress, because I’ve been taught not to trust that my data is saved if I don’t explicitly do it. I’ve seen many others do the same.

And that’s what makes the implementation of this idea too late.

I’m currently working on the detailed design of a product for my software startup, and I’m trying so hard to convince myself that we’re going to help move the industry towards eliminating the need to explicitly save. But I just cannot get myself to commit. I’d feel like a hypocrite. This product has to be so incredibly easy to use in order for mass market acceptance, and I feel like if we eliminate the save button, it’ll slow people down looking for one, and expecting one. It would slow ME down.

Sorry, Mr. Cooper, but I’m afraid autosave will be forever regulated to the fall back position you see it in today.

Random Thought:
I love this post by Eric Sink on the Perils of Wikipedia, especially the punch line at the end. Classic!