Tom Chi  

The end of WYSIWYG?

October 14th, 2005 by Tom Chi :: see related comic

We’ve had a lot of articles about web happenings recently, so it was high time for some good old client-app talk. Office has had its share of missteps in the past — the most notable of course is Clippy (although some would say it was this guy’s idea). That asidie, Microsoft Office 12 is starting to make some waves and there’s already buzz and FUD about all the UI changes that are coming. The UI has changed pretty drastically, and it has inspired a recent alertbox entitled “R.I.P. WYSIWYG”.

To summarize what has changed, toolbars and menus are gone. Instead you have the ribbon, which offers collections of tools centered around major tasks, and special contextual ribbons based on the type of object selected. New context menus and floaties help to bring useful verbs close to selected objects. There is also live-previewing which allows people to easily try permutations and options without having to commit changes. Lastly, many shared features have been standardized, and non-authoring features have been moved to a separate area. If you’ve got 40 minutes to spare you can watch the Channel 9 interview here (which is the most complete description of the changes that is publically available).

In his article Nielsen states that the influence of these changes will be significant throughout the UI world. I tend to agree with this, although not because WYSIWYG is dead or no longer useful. For the most part, other applications copy what Office does regardless of what makes sense. I’ve seen a dozen copies of the Outlook UI for a wide variety of applications, and people continue to wow over Outlook-like UI’s daily. Similarly, OpenOffice, StarOffice and others seem to be using MS Office to drive specifications.

Luckily for the world, the changes in Office 12 UI are for the most part extremely solid, and they make sense for large complex feature-rich applications. I expect that other companies that offer complex client apps will benefit from imitating these design ideas. Even those without complex apps can get some mileage from some of the work around context menus and previewing.

In the longer term, the battle between big client applications and webby ‘less is more’ applications will prove interesting — but that’s a topic for another day.

8 Responses to “The end of WYSIWYG?”
Tim Tucker wrote:

I’m glad for the changes — it sounds like some of the changes are finally bringing Word close to the functionality that Lotus WordPro has had for the last 10 years with its properties box…

The “ribbons” sounds pretty close to what the properties box did w/ a simple floating tabbed dialog (though it was probably slightly closer in feel to something like the pallet in most paint tools)

Among the things that you could do with it:
- change line/paragraph spacing without bringing up a modal dialog
- fine-tune the borders/sizing of tables
- generally “do stuff without interrupting your ability to edit the document”

It made me somewhat sad that few people ever realized just how great WordPro’s interface (or at least its properties box) really was, especially if you just wanted to make a document look good quickly.

Jon wrote:

This still doesn’t seem like a substantial shift forwards; it’s still WIMP, and it’s still PARCs idea.

I would love to see msft launch some sort of incubation-style startup that could create a competitive text editor to Word, abandoning all pre-conceived notions of what a tool like this should feel like. If the company didn’t have to think of the zillions of people already using the software (ie, adaptability), what could they come up with?

For that matter, consider new input devices, paradigms, etc …

I’m sick of “windows”. What stagnation.

Olly wrote:

Jon - You’ll never see huge strides in a company as big as Microsoft. It’s always going to be about evolution. And for them to be selling two competing word processors? Internal mangement peeps would see that as utter madness ;-)

sloan wrote:

There are still lots of limitations here. Each “ribbon” has only a set amount of real estate, and as a result, some of the icons are larger than others. In many ways, it looks like tabbed toolbars with context thrown in. But really, it seems the real “innovation” is simply organizing the “actions/effects” in a better manner.

There is still a searching through “menus” and now, you have to search for the words and translate the icons into results or wait for a preview to see if it matches up. Just the time to locate a target and hit it will slow down most people doing common, repeating tasks.

1,500 commands? That sounds like a job for a quick, indexed search right? And how about adding synonyms? Scale means the same thing as resize. Of course, until we can get our hands on it… who knows how it really works? A video isn’t so great to figure that out.

Michael Zuschlag wrote:

I like the idea of “one-stop-shopping” for all commands, rather than deciding between looking in the menu, toolbar, or taskpane. But as sloan suggests, you are still left searching a menu of one kind or another, which isn’t necessarily the best way to learn about a feature, little alone do regular tasks. Yes, users use an application’s menu to learn about features, but that’s really an improvisation. The primary purpose of the menu is to *execute* a feature. I fear that by trying to support an improvised purpose, MS is compromising the menu’s primary purpose.
Isn’t Help the proper tool for learning about a feature? The menubar and toolbar may need to be re-thought, but if your design goal is to encourage users to use advanced features, the focus should be on making Help actually helpful.

sloan wrote:

The other thing that occurred to me is that there was no mention of customization. For high end applications for things like video editing users can map keys and functions as they see fit. What kind of customization does this new version have? With previous versions you could at least edit the toolbars, but what options do you have now? 1,500 commands? How about letting advanced users set their own shortcut keys? Organize the “buttons” in the ribbon so that they make sense for their tasks?

Dom wrote:

I watched the video a little while back and I’m pretty certain that the ribbons can be customised.

Daniel Williams wrote:

Take a look at a post by Jensen Harris, who’s on the Office UI team, where he talks about how shortcut keys will work in relation to the ribbon. I think it’s a great idea, and does a good job of addressing one of sloan’s concerns.

Jensen’s blog has actually been pretty fascinating, and many of the posts really explore the thought processes and all the research that’s gone into every UI design decision.


Leave a Reply


OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?