Adam Fields (weblog)

This blog is largely deprecated, but is being preserved here for historical interest. Check out my index page at adamfields.com for more up to date info. My main trade is technology strategy, process/project management, and performance optimization consulting, with a focus on enterprise and open source CMS and related technologies. More information. I write periodic long pieces here, shorter stuff goes on twitter or app.net.

10/5/2005

Unthrilled with the Office 12 UI

Screenshots for Office 12:

http://www.neowin.net/comments.php?id=30382&category=main

Okay, they’ve cleaned up the interface a bit by grouping related things into similar boxes that are actually labeled, and I’m told that the interface elements are all vector-based so you can resize them arbitrarily. That’s nice.

But.

Over many years of designing custom content management interfaces for lots of people to use, it became crystal clear that there’s a huge difference between a “tool” and a “task”. A tool is a function that lets the user do something, but a task is a function that lets the user accomplish something.

In my experience, most successful content management interfaces are primarily task-based. When the user sits down in front of the computer, the goal is to get something done, not just use some tools. Tasks are for most people (beginners and power users alike), but tools are for power users. If you know what you want to do, but it doesn’t fit nicely into the framework of getting something done, you need a tool. Tasks should be the default.

This is why the new Office UI is still confusing – it’s full of tools.

Let’s take Word as an example. The forefront example of tools vs. tasks is the question “why is there still a font box?”, and the corollary question “why do the font options still occupy a huge chunk of prime screen real estate?”. Changing the font is a “tool function”. When you change the font in a document, you haven’t really accomplished anything. Sure, you’ve made it look different, but “making it look different” probably wasn’t the goal. What you were really doing is the unspoken “drawing attention to this text” or “making it match the company colors” or any number of other things that aren’t just “making it look different”. With a tool, you can “make it look different”, but it requires a lot of input from the user in order to get the rationale right, and this is why expert users get frustrated when beginniners change the fonts and their results don’t match their intent. The software shouldn’t make it easy to change the font without understanding why. There should be tasks centered around things you might want to do, and the software should guide you. Importantly, if you do understand why, and you have different intentions than the software does, it should get out of your way – but that comes around to letting you use tools to get around the limitations of pre-defined tasks.

(An important note: a “wizard” is not a task-based interface. It’s a poor substitute that attempts to graft tasks onto what is primarily a tool-based interface.)

This goes right to the heart of the debate of semantic content vs. formatting. A huge portion of the tech community has been trying very hard to get people to think in ways that are structured, for various reasons. It’s not always the best approach, but it’s by far the best default if you don’t know what you’re doing. If you go through your document and decide “this needs to be 14 point Helvetica and this needs to be italic and this needs to be 24 point Times”, the onus is on you to understand why you’ve chosen those particular settings. “It looks nice” isn’t good enough, if it doesn’t match your intent. You’ve lowered the chances of getting the right result, and you’ve made things more difficult for the next person to go through and standardize your settings when your one-page memo gets reformatted to be used in the company brochure. You’ve probably also made things more difficult for yourself. Instead of trying to decide what it should look like, you could have just told the machine “this is a heading, that’s a title, and this paragraph is a summary of findings”, and made your life easier.

The UI appears to have some of this by grouping tools by tasks, but it doesn’t follow through — “Write”, “Insert”, “Page Layout”… but then, “References”? Nope. “Mailings” – maybe, but probably not. “Review” – we’re back. “Developer”? That’s a noun. Obviously there isn’t a consistent organizational structure here. Task-based interfaces are a radical shift from tool-based ones, and they require the UI designer to ask of every function put in front of the user: “Do I really want to give them this power? Am I making their life easier by doing so, or just giving them a shotgun to aim at their feet?”. It’s Microsoft Office, not Microsoft Fun with Fonts, Colors, and Margins. There’s a strong argument to be made that it shouldn’t be easier to use all of the features, because they’re a waste of time for most users.

Microsoft should have taken this opportunity to put together a new interface that’s not only prettier, but also radically easier to use, more intuitive, and above all, more productive. Instead, they’ve produced what appears to be more of the same.


2 Responses to “Unthrilled with the Office 12 UI”

  1. Dude Says:

    Do you work exclusively on a Mac? The font choices you have look pretty bad on Windows. 90% Verdana with -1px spacing makes your otherwise interesting site look bad, both Firefox and IE.

    Yours,

    Not dude

  2. adam Says:

    I’m mostly on Windows, and it’s pretty readable for me. I do have the system font size turned up to 125% (as I have on every machine since about 1992). Hmmm… thanks for the comment. I’m working on a new design, actually, and I’ll keep that in mind.

Powered by WordPress