Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index


Hi Michel,

2010/10/15 Michel Gagnon <michel@mgagnon.net>

Hello, I wonder what is the interest of Microsoft and others, including
you, to replace menus with a ribbon-like interface.

I think it brings the worst in terms of usability. Why?We have grown to use
a certain menu organization. File, Edit, Format, Tools, Windows and Help
are, in that order, fairly standard menu items in all applications, and even
the basic list of menu items is even fairly standardized. The ribbon
interface changes that to a certain extent and requires a relearning
process.There are a few menu items that are easily displayed with icons, but
most icons are either very hard to read or require a lot of real estate or
both. Look at Microsoft Word or at WordPad on System 7 and look at icons
used for page or paragraph margins, or for search and replace (very similar
to the one for spelling). Because of that, Ms Office 2010 and WordPad adds
text below many icons (more real estate) and a tool tip which is basically
the former menu item.Because of real estate requirements, there are a
limited number of buttons that may be displayed on a screen, whether it is
with a traditional set of buttonsla Office 3.2 or with a ribbonla Microsoft
Office 2007-2010. So there is a need for multiple menus that call different
ribbons like Ms Office. or buttons that need still another action like
custom margins.Using a typical menu item requires one move with the mouse:
move it to the top to select the menu and slide it toward the menu item,
then release. Sub menus require a little more dexterity.On the other hand,
using a typical ribbon "menu" item requires a move and two clicks: a first
click at the top to select the proper ribbon, then a click on the proper
icon. And because of the limited real estate, it is more likely that one
then falls onto yet another dialogue box.A traditional tool bar is always
there; so its commands may be accessed very quickly. But it works only
because of its limited number of icons.So what would be the best approach?
Probably a mix of both systems.A traditional menu system for structured
commands. In a word processor, I see comprehensive commands like Page setup,
Paragraph setup, Font setup, Style setup (with a dialog box like that of
Office 2003), Table setup, etc. Simple commands like "Align to the left"
could either be in a submenu or even forgotten altogether because they
already are accessible through the Paragraph Setup dialog box. Displaying
them in a submenu makes learning and training easier : the command is seen,
its shortcut is seen, etc.If a ribbon-like approach is used, there should be
shortcuts not only for items, but also for each of the ribbons. For
instance, I should be able to press alt-F for the File ribbon, alt-E to show
the Edit ribbon, etc... and each of these shortcuts should become as
standard as control-Z, X, C and V for the basic cut and paste
possibilities.

Of course, control-C for Cut and control-shift-L (or control-L) for
Align-left should also exist for a direct access to menus.Icons are good
when the graphic is obvious to all and when clicking on it has a direct
result. One of the major pitfalls I currently see is that most are
non-configurable (same problem with Microsoft Office and OpenOffice). So for
me, the Left-Align and Bold icons work (but the keyboard shortcuts are so
quicker), but the bullet icon doesn't work because it does not use my
preferred settings: I would like it to apply my "Bullet 1" setting (usually
a hanging indent of 1 pica with no further indent, but some documents have a
different style definition). Ditto for the 5 or 6 different Page Setting
icons that are defined in Ms Word 2007: none of them have the margins I need
for my documents!How would a mixed system work?One way to do it would be to
have the menus first, followed by ribbons. For instance, the new LibreOffice
would have File-Edit-Display (maybe)-Insert-Format-Table-Tools-Window menus,
then Basic (file and edit ribbon items)-Insert-Format (document, paragraph
and text items)-Table ribbons. The menu could appear either on a single line
or on two lines if/when the window is too narrow.Finally, should a ribbon
sit on the right or at the top? Why not have it either way? The ribbon is a
glorified toolbar and traditional toolbars have worked in either position,
either docked or undocked. So why not have the "ribbon menus" call a toolbar
anyway?By the way, since we talk of a new interface, one aspect I don't like
of OpenOffice 3.x are the toolbars that appear and disappear according to
paragraph styles. For instance, when bullets are chosen (or a bullet style),
the bullet toolbar appears (by default at the top) and shifts all text down
1 cm. Go back to a standard paragraph and it shifts up again. Why not have a
user interface made with one or two user-defined toolbars like we currently
have on OpenOffice 3.x and Ms Office 2003, plus one toolbar that would be
always there, albeit with variable content (a.k.a. the "ribbon"). Users
would decide where they want that big grey box and LibreOffice would fill in
the proper icons.

That gives me a lot to respond to -- I'll try to be as concise as possible.
a) Why the change in menu categorization? Because the old one wasn't good
enough. "File" contained tools that applied to both the currently-opened
file and to the office suite as a whole. "Edit" and "Tools" menus held
miscellaneous commands. There were commands under "Table" that weren't
specific to tables. It was a mess. But if anyone wants to revert back to the
classic UI, there definitely should be an option to do so.
b) I agree -- the Ribbon UI is less than ideal.
c) The interface definitely should be as flexible as possible.
d) Please read http://clickortap.wordpress.com/2010/10/15/the-citrus-menu/ :
I think it might answer some of your concerns.

-- 
E-mail to discuss+help@documentfoundation.org for instructions on how to unsubscribe
List archives are available at http://www.documentfoundation.org/lists/discuss/
All messages you send to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.