Wednesday, October 12, 2005

menus, menus, menus

Earlier this week Jacob Neilson wrote of the impending death of the near-universal computer user interface he refers to interchangeably as Mac-Style or WYSIWYG and the inherent rise of a results-oriented interface.


Oh, where to start. Agenda: 1) Jacob, 2) WYSIWYG vs. Mac-Style, 3) results-oriented UI.

1) You gotta love Jacob. I love Jacob. I attended one of his seminars. He is easily the biggest rock-star of Web user interface and interactive design. He is also easy to pick on because he tends to give voice to ideals and extremes that usually fail quickly when introduced to real world situations. That said, I think he does a good job of staking out some interesting ideals and extremes that we can learn a lot from even if its part of an effort to argue against them.

2) Jacob largely equates WYSIWYG and Mac-Style as the same things. I disagree. Mac-Style, as Jacob refers to it here, is a standardized method for users to make choices and chose menu options from drop down lists and dialogue boxes. WYSIWYG is a display technique whereby the programming behind an application is hidden and the result of that programming is shown instead.

For instance, WordPerfect's old reveal codes command essentially toggled that application between WYSIWYG and non-WYSIWYG/code driven displays. The two are not the same. Any Web programmer familiar with HomeSite or even the differing display options in Dreamweaver can attest that WYSIWYG displays and Mac-style menu systems are completely independent choices in interface development.

Making this distinction is important because what Jacob is really arguing against is mac-style. What he describes as the solution to mac-style I guarantee will still have a WYSIWYG display. So, lets take points away for imprecise use of terms in order to try and create a new term of art (WYGIWYS or what you get is what you see) that isn't needed and proceed to his real point pretending he never drug WYSIWYG into this conversation.

3) So Jacob's point is that mac-style is an archaic dinosaur that no longer works well because we have too many choices and want to be able to quickly achieve a particular result without finding and executing 32 different commands. The answer? A results-oriented interface. Essentially described as picking from a choice of templates that dictate / encapsulate those 32 commands in one visual clue.

There is some logic here. Yes, many applications have too many choices and unless you use that program all day long, it is hard to know how to find them all or even what they all are in the first place. It also makes sense that templates can alleviate some of those concerns.

But making an entire suite of software based on those templates is going to have one result that I can see: reducing choice. No way is a series of templates going to correctly anticipate what I want my document to look like. This will be a design choice along the lines of WYSIWYG that makes thing "simpler" by hiding stuff from me and reducing my choices.

Sure, endless menus and dialogue boxes are not the answer, but reducing my word processing to 10 templates isn't either. Perhaps the answer is to stop trying to make every program all things to all people. Small specialized programs that work well and work with each other would probably work a hell of a lot better then trying to do Web site development and publishing layout with Microsoft Word regardless of how many templates you employee.


FWIW, WYSIWYG is an acronym for "What You See Is What You Get" and was originally used in discussions about variances in what was displayed on screen and printed output. Even as a Mac user, I don't see it as equivalent with "Mac-Style"—whatever that is.
So, I guess I'm saying that I agree with point #2. Having worked as a paste-up artist back in my college days, I know that this was a huge issue in the late-80s and early-90s. As a web developer now, I can see how it would morph into a similar problem with HTML and web page design.

I think the fundamental problem is whether it's possible to "tuck the complexity of HTML under the covers". It was incredibly hard to do when all you wanted were character glyphs, line breaks, and page breaks to fall where you saw them on your computer when you printed it out. HTML is a lot more complicated, so I'm not optimistic. Note, I'm not saying that we shouldn't try to make tools that bring web design to the masses (as MS-Word has done with desktop publishing), I'm just not sure how you simplify menus and Flash Animations. Perhaps those things that are too hard will go the way of ligatures, old-style numbers, and curly quotes. Notably, many software packages now automatically insert curly quotes, so perhaps we sacrifice some complexity for a time to achieve ease of use and reintroduce complicated things at a later date.

Comment by McCoy (12/15/2006 15:54)


"He is easily the biggest rock-star of Web user interface and interactive design."

Wow. Kind of like Peter Frampton?

Comment by cosmos (12/15/2006 15:54)


If each of those 32 option are merely binary options you'll need 4,294,967,296 templates to cover them all. Leave the options in, thanks.

If you want to add a few common templates more power to you but since this appears to be how modern word processing works anyway (you create a style and then re-use it), I'm not sure what the big deal is.

Comment by Nephlm (12/15/2006 15:54)

Add comment



Your name

Your email address (if any)

Your personal page (if any)