Thrown For a Loop

  • Article

The Ribbon is an example of what's called in academic circles "modal" design. 
Broadly, this means a design which is split into "modes", only one of which is
active at a time.  In the Ribbon's case, this means that the features are
grouped together into tabs, and only one tab is shown at a time.

Modal designs can have a lot of advantages.  Primarily, they help
constrain complexity.  As I talked about in my article on the

importance of context, a design that has commands arranged more contextually
can put less important commands an extra click away.  This simplifies the
core interface while giving more space to each individual mode or context. 
If people are very likely to use table layout commands in succession but less
likely to use a table layout command followed by editing the Mail Merge data
source, then you feel more confident about putting table commands one click away
from mail merge commands.  It doesn't work for all scenarios, but if you
can make enough of them work, you can build a more modal interface.

One of the potential pitfalls of interface modality is something we call
"command loops."  A command loop is created whenever someone needs to go
back and forth between two "modes" over and over again in order to complete a
common scenario.  If it happens enough, using the a modal UI can become inefficient.  For that reason,
removing the key command loops from Office 12 has been a top priority over the
last two years.

I remember using a very early prototype of Word with a Ribbon towards the end
of 2003.  i was trying to comment a document, and I kept repeating this
sequence:

  • Switch to "Commenting" tab
  • Click "New Comment."
  • Type some text in the comment balloon
  • Switch to "Main" tab
  • Make some text bold
  • Switch to "Commenting" tab
  • Click "New Comment"
  • etc.

In other words, I discovered a command loop between inserting a comment and
formatting text within the comment.  I was using commands in rapid
succession that were located on different tabs and, as a result, I wasn't
getting the full benefit of the Ribbon's toolbar-like efficiency.

As we went deeper into content designs looking for command loops, patterns
emerged.  Although certain unique command loops did pop up (such as
Inserting and Formatting shapes as part of making an overall drawing), almost
all other command loops in the product involved one particular set of commands:
text formatting.

Where we learn about unique command loops in common scenarios, we can usually
fix them by refining and reorganizing Ribbon content.  The upcoming beta
process will be valuable in helping us continue to identify and repair these.

In addition, we have built several "safety valves" into the product which
will help to solve command loop frustration in cases we don't find because some
people use the program in such a unique way.

Tomorrow, I'll introduce you to one of these safety valves that morphed into
a key feature of the new user interface.