¶Why the #&* did you put those commands next to each other

Through a convoluted series of weblinks, I ended up on this page, which describes the Windows User Experience Interaction Guidelines for ribbons:

http://msdn.microsoft.com/en-us/library/cc872782.aspx

From my experience, there's a pretty high chance that either you absolute adore the ribbon or you think it is the devil spawn of UI controls. I haven't decided yet, only having used ribbon-based applications for a short time, and while I didn't find it an especially amazing experience, I didn't despise it either. I figure that it isn't a bad idea to read through the guidelines and see what generally applicable wisdom is in the ribbon's design.

This particular sentence had me cheering:

Avoid placing destructive commands next to frequently used commands. A command is considered destructive if its effect is widespread and either it cannot be easily undone or the effect isn't immediately noticeable.

Don't know what I mean? Here's one example, from the Windows common file dialog:

See the first icon with a yellow folder on it? That's the "go up to parent" button. See the icon next to it with another yellow folder? That's the new folder button. I can't tell you how many times I've accidentally created a new folder while trying to go up. Even worse, if you hit the Escape key to abort the new folder, it just leaves a folder called New Folder that you have to manually delete. Argh!!!!

Here's another example, this time from the P4Win application, which is used to interact with a Perforce source code control depot. This is the context menu you get when right-clicking on a file in a pending changelist:

One of the things I do very frequently is integrate files between branches, and before doing so I often diff the changes, especially if the merge is involved. I'd like to know who decided to put the "Reopen for Edit" command right next to the Diff command. As you can probably guess, I have a habit of accidentally re-opening branched files for edit. Unlike the New Folder case with the file dialog, there's no easy way to undo this; if you're a purist and want to keep the integration changelist clean, you have to revert the file and re-branch it. Sigh.

So, basically, putting some separation between one command that the user might use a lot and another that has annoying effects seems like a good idea even if you're not using a ribbon.

P.S. I found this portion of the ribbon UI guidelines ironic, given how it was received when it first appeared in Microsoft Office:

Avoid marketing-based placement. Marketing objectives around the promotion of new features tend to change over time. Consider future versions of your product and how much frustration a constantly changing organization will cause.

Comments

This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.