Thank you for posting a rational explanation of what's happening. Light is
so much better than heat!
--
Jim
--On Tuesday, September 01, 2009 08:28:41 PM +0200 Mathias Bauer
<nospamfor...@gmx.de> wrote:
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.
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
distance.
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
fake.
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.
Regards,
Mathias
--
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@openoffice.org
For additional commands, e-mail: users-h...@openoffice.org
