Partager via

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.

Comments

  • Anonymous
    October 05, 2005
    Jensen, do you know that song by Stevie Wonder - "Ribbon In The Sky"? :)

    http://www.lyricsfreak.com/s/stevie-wonder/131889.html
  • Anonymous
    October 05, 2005
    My guess is that you will have some type of floating command bar that is context aware to the current cursor or content selection.

    For instance, with normal text editing, selecting a word or group of words would give you commands from the Word 2003 formatting toolbar.

    This will probably only be for text and not fully context aware. To be truly useful, we should get things like select a table and not only does the ribbon change to table but the context floater provides quick access to Word 2003 tables and borders toolbar.
  • Anonymous
    October 05, 2005
    In the original Access ribbon designs, a similar command loop was found in designing forms and reports - the tendency is to go back and forth between the Form Design and Layout tabs and the text formatting commands on the data tab.

    Based on that, I'm guessing if the feature he's aluding to isn't "Floaties" (someone after me is going to add something like "heh heh, he said floaties"), it's "Duplicating commands on multiple tabs" (we did the latter)
  • Anonymous
    October 05, 2005
    Yes, It sounds like you're going to cover the "Floatie" (gotta get a better name - hmmmmmm). I'd really like to hear just a bit about what other valves are built in also.

    Kawiqi, please tell me you have or know of a blog about Access 12?!

    Oh, and Jensen (and others working on this stuff) please know you're inspiring me as I work on a design document to dramatically improve our very complex instrument's interface. I had already been working on it before hearing of Office 12, but seeing what you've done has helped me have a fresh view and approach.

    It is very exciting to see the possibilities of ease of use and reduced training "just" by properly designing an interface. :)
  • Anonymous
    October 05, 2005
    Ask and you shall recieve!

    The newly christened Access blog:
    http://blogs.msdn.com/access/
  • Anonymous
    October 05, 2005
    lol

    Thanks, zz. If only it was always that easy... :)
  • Anonymous
    October 06, 2005
    Just what I was going to say, they just told us they were starting that blog yesterday :-)
  • Anonymous
    October 07, 2005
    Allowing users to customise the tabs would be another good way out of the modal maze - adding that commonly used command from another tab to the tab where they use it rather than cramming it into the File menu/toolbar (which I expect will look like the Quick Launch bar on my husband's PC: currently 2/3rds of a 17" screen wide). I know how much of the current Office logjam is down to too many ways to customise toolbars, but don't veer too far the other way, please! Personally, I'd like to see an option like the Windows taskbar lock, to allow advanced users to customise things without confusing novices.
  • Anonymous
    October 14, 2005
    By far the biggest offender of loop that I run across on a daily basis is un-hiding sheets.

    It's 5 clicks for each sheet you want to un-hide (assuming you don't have to scroll the list to find the sheet, then it's more):

    Format->Sheets->Unhide->Select sheet->OK
    then repeat x times to unhide each sheet. If you're un-hinging 10 sheets, that 50 clicks (minimum) - it's horrible!

  • Anonymous
    October 27, 2008
    PingBack from http://mstechnews.info/2008/10/the-office-2007-ui-bible/