Menubar on Windows???

[Richard Gaskin]

Ian Wood wrote:
> On 12 Dec 2007, at 14:16, Eric Chatonet wrote: 
>> But if you 'really' want to display different menu bars in the same  
>> window when running Windows, just create as many menu bars as needed  
>> and show/hide the right corresponding group according to your needs.
>>
>> But I repeat: this is not compliant with Win guide lines :-)
> 
> I thought this was *roughly* what the new version Office does,  
> depending on what kind of object you have selected? ;-)

On all systems except those from Apple, the menu bar is commonly
attached to the top of each window, with each window's menu bar
containing only those items relevant to that view.  Individual menu
items may be enabled or disabled depending on context, but it's very
rare that the menus themselves will change.

Office 12 turns the whole menu paradigm inside out, with almost no menus
at all.  A very small set of menus is still present, but most of the
commands are in a group at the top of the window just below the menus
which their designers call a "Ribbon".

Ribbons are like toolbars in some respects, but without the limitations
of a toolbar:  icons with cryptic images requiring tooltips to decipher,
and few in number representing a fixed subset of commands that barely
touches the depth of a good feature set.  No matter how many toolbar
icons you squeeze in, most of the commands remained hidden in menus,
requiring the user to still hunt around through the pull-downs to find
the command they're looking for.

In contrast, most controls in Ribbons generally have visible labels, or
at least have icons large and detailed enough to make their function
self-evident.  But more importantly, the Ribbon is constantly updated to
show different controls in different contexts, exposing a far greater
range of commands available than in the older fixed toolbars.

Dan Shafer brought this to our attention on this list last year with
these two links:

R.I.P. WYSIWYG: Results-Oriented UI Coming - Jakob Nielsen's overview of
Ribbons:
<http://www.useit.com/alertbox/wysiwyg.html>

Jensen Harris blog - lead UI designer for Office 12:
<http://blogs.msdn.com/jensenh/>

In theory, Ribbons make the feature set more self-evident by displaying
commands right in front of the user, without requiring them to hunt for
them among sometimes-long pull-down menus.  By changing the Ribbon
controls based on context, the goal is to provide access to all commands
a program offers, showing the relevant ones at each step of the user's
progress through the workflow.

In practice, it seems the jury is still out.  Most tellingly, after all
the research investment MS put into the new Ribbons paradigm, they
didn't bother implementing it for the OS itself or even any other
programs outside of the Office suite.  We can assume that if Ribbons had
their confidence at all, they'd jump on the opportunity to avoid the
inevitable confusion from mixing paradigms, with Office working one way
and everything else working very differently.

The progress with the design of Ribbons was blogged almost daily by
Jensen Harris during the Office 12 dev cycle, but it's perhaps a hint of
the failure of that paradigm that activity on his blog has almost
completely stopped since Office 12 shipped.  If MS had plans to
implement Ribbons across their system I would expect his blog to be busier.

In all fairness, it may still be the case that Ribbons is seen as a
success within the company, and they're just being quiet about future
rollouts in other products.  It's just too early to know for sure.

But whether Ribbons as a whole is a success or a failure, that MS was
willing to break new ground with regard to command access is laudable,
and some aspects of Ribbons will no doubt influence toolbar design for
years to come.

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com