sorry for the long mail, but we already had too much incomplete and
misunderstood communication, sometimes it is necessary to talk about the
details. Please read carefully and try to understand what I think should
be and is the motivation for a changed UI in OOo. Maybe then you will
agree that the noise about "ribbon aping" is too much ado about nothing.

Tommy27 wrote:

> PETITION: http://www.petitionspot.com/petitions/stoprenaissance/ 
> Some OpenOffice developers announced, few time ago, a great (in their minds)
> project: Trying to copy ugly, unusable Ribbon interface, made by Micro$oft
> for Word and other Office products 
> http://blogs.sun.com/GullFOSS/entry/prototyping_a_new_ui_july 
> http://blogs.sun.com/GullFOSS/entry/prototyping_a_new_user_interface 
> This Ribbonized GUI has already several negative comments by Micro$oft
> users, so, why trying to copy a poor GUi instead to analyze and solve
> serious issues present in OpenOffice? (it has many serious issues) 
> if you Agree with me (and many other) please sign petition, so we can stop
> OpenOffice renaissance (or middle age?) not useful project, and developpers
> can avoid to stress and go to solve issues.
> The petition has already collected 176 signatures. please, add yours

I think your "petition" is completely useless as it preaches to the
converted. Nobody wants to or will just "copy" the ribbon interace.

The blog entries you quoted are perfect examples for a complete
misunderstanding, caused by a badly prepared presentation of a
prototype, a communication that forget to tell about the background and
by reactions from people that talk before finding out what they are
talking about. Too many people commented the blog entries that neither
understood what a prototype is nor what the particular prototype in
question wants to show. Many other people read these comments and even
without having a look on the prototype parotted "OOo wants to copy the
ribbon"! Rubbish.

So what's the fuss all about?

OOo will never "copy" the ribbon, that would be aping the look without
caring for the ideas and working style behind it and if this is what we
want. Our starting point is how we want our users to operate OOo.
Whatever will come out of this: as all Office applications have
something in common it is not surprising that their UI concepts will
have some similarities. So don't think that an apple is an orange just
because their look has something in common if you look at them from a

What we are trying to achieve is a context sensitive user interface.
With an important limitation: context sensitivity is wanted for
toolbars, not for menus. From what I know it is common sense that our
menus will stay in the new UI and they won't be "context sensitive"
(like in the different rather lame attempts from Microsoft with
"personalized" menus etc.). That alone is a major difference to the
Office 2007 UI that makes OOo much better.

Menus are a tool for browsing through the functionality of an
application and rearrangig the menu elements is counter productive. But
for other UI elements, especially those that consume more screen space,
it is a useful concept to reduce clutter.

This is neither new nor is it invented by Microsoft and especially the
"ribbon" is not the only way to implement it.

In fact OOo 1.x had a lot of context sensitivity in its user interface,
but it was implemented in a rather unintuitive way, and so many people
couldn't cope with it. The result was the UI change in OOo 2.0: many
toolbars that automatically pop up when it appeared that they could be
used. IMHO this was a huge step back in terms of usability and I'm glad
that our UX people want to correct that error. The number of complaints
about this toolbar mess is pretty huge, so it's necessary to do
something against it.

You can't show all possible buttons at once, this consumes too much
screen real estate, you have to select some. Without context sensitivity
you could get a "lean" interface with the absolut minimum of toolbars
shown. Users then have to add and remove toolbars manually when they
need them.

But users shouldn't be forced to do that, if the program is able to find
the usable toolbars (and OOo is), it should help the user. This is the
basic idea of context sensitivity: if e.g. a user has selected a
picture, it doesn't make sense to waste precious screen space with a
text formatting toolbar (that for a good reason is visible by default in
all rich text applications), it should be replaced by a toolbar with
buttons offering functionality that can be applied to the selected
picture. So far, so good.

But even with this preselection of toolbars there are still too much
toolbars in some situations. Consider the case of a user editing a list
in a table cell. Here it might be possible to either work on the text
attributes, the list attributes or the cell or table attributes. Showing
toolbars for all of them all will create the toolbar mess whe currently
have in OOo. Showing only one of them will create another problem: which
of them might suits the user best is pure speculation. So the program
must select one by educated guessing, but it's essential to allow user
invervention to overrule this decision.

In OOo 1.x we showed the table toolbar by default in that situation, but
we had a small blue triangle at the right end of the toolbar where the
user could "rotate" the toolbar content between the three possible sets
(text, list, table). As a "special service" the last selected set was
remembered and restored in case the user again entered this context.

Admittedly that's not a very intuitive user interface, mainly because
the blue triangle didn't tell what it was meant to to. But the idea in
general was a good one (IMHO). It's better than the current situation
where you either have to keep all three toolbars open evertime you are
working in a table or always switching toolbars on and off manually (as
in Word prior to Word 2007).

So for me the basic idea behind the OOo prototype is: only show toolbars
that make sense in a particular context; if more of them might make
sense, find a simple and intuitive way to switch between them.

In a certain way the MS Office ribbon amongst other concepts also
implements this idea. So even without copying it it's very probable that
whatever we implement will have some similarities with it. If someone
presents another way to also implement the idea of context sensitivity
with user intervention, that doesn't make this a "copy" of the ribbon,
in the same way as e.g. the Gnome File Picker isn't a "copy" of the
Windows File Picker, they are just different, though unvoidable somewhat
similar implementations of the same idea (selecting files in a
hierarchical file system).

So, please cool down and think about the concept that shall be
implemented, not how it looks in a prototype that is barely more than a

We should concentrate on which contexts we want to have, which toolbars
they should get assigned to, which buttons should be in the toolbars,
how the switching between different button sets can be implemented with
as less screen space consumption as possible but as understandable and
intuitive as possible. And if the result has some similarity with parts
of MS's ribbon implementation - so what?

Other interesting questions are how big the buttons should be, if we
should show symbols or texts or both etc. Much more interesting than
diccussing how similar something looks to ribbons or not.

Additionally, let's discuss if the old toolbars should be used as an
alternative UI. Possibly people prefer a mediocre UI just because they
are used to it - that's a valid decision and IMHO shouldn't be ignored.
Especially as at the moment, where nothing except the prototype has been
implemented, it should be easy to plan for this.


Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamfor...@gmx.de".
I use it for the OOo lists and only rarely read other mails sent to it.

To unsubscribe, e-mail: users-unsubscr...@openoffice.org
For additional commands, e-mail: users-h...@openoffice.org

Reply via email to