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

Hi Astron,

2012/3/1 Stefan Knorr (Astron) <>

Hi Mirek, Christoph,

sorry for the late response...
tl;dr: I am not quite sure about where I stand with regard to the
Overflow menu any more... Personally, I am still sure I'd like it, but
I don't have an idea how useful it is to the average user.

First, I'm a bit unsure about the primary goal(s) of the change. Is the
goal to provide access to the hidden (per default) items, or is the goal
to reduce the number of elements in the toolbars and provide access to
those icons being removed / being invisible?

The goal is to provide access to hidden items as well as to enable users
quickly set the visibility of items.

So, I've had a little bit of a discussion with Christoph and the
problem with that argument is that in many cases no one really needs
the elements that are hidden. Have a look at what's hidden today in
the standard toolbar in Writer:
* Save As – is used rather seldomly to save a copy of a file/no need
for a toolbar shortcut
* New Document from Template – the New icon offers the same
functionality via New/Documents and Templates
* Load URL – maybe used once per century
* Zoom – we've got that also in the status bar
* What's This – could easily be replaced by better tooltips

Even some of the stuff that is there doesn't make much sense:
* Print Preview – I'd argue that most people never use that
* AutoSpellcheck – almost no one turns that off
* Hyperlink – the most clumsy way to add a hyperlink, usually text
that looks like a link is autocorrected to also become a link
* Gallery – arguably not very useful in its current state, even though
GSoC might bring a revelation
* Non-Printing Characters – people either love this or hate this, but
they only need that button once
* Data Sources – I guess the usage of those is pretty low, too

This only goes to show that, so far, we'll be enabling users to access
a bunch of random functionality that they likely won't need. Thus, I
believe, we should also make some plans on what to about the fill
status of our toolbars.

Frankly, I don't think most of the stuff in the Standard toolbar should be
shown up front. The user shouldn't see "New" and "Open" at all while
editing the document, since they don't pertain to the document and only
distract. I also can't imagine a user would need to repeatedly use "Edit
file", "Document as e-mail", or "Non-printing characters" buttons. (The
first thing I do after I install LibO is remove the Standard, Navigation,
and Find toolbars.)

If we wanted to streamline the UI, the overflow menu would be a big help.
Users would know that even though we hid some commands, they're always
accessible from the overflow menu.

Finally, Christoph brought up a really interesting argument: 3.5
removed most of the toolbar customisability from the eyes of the
public (by hiding the arrow at the end of toolbars), but so far, I
haven't really seen or heard any protests.

I believe it was a good decision to remove the arrow pointer -- made the UI
simpler and nicer to look at. The functionality is still there, under the
right-click menu.

So, do users actually want all that customisability? Or are there
other conclusions we should draw from that (e. g. functionality wasn't
adequate, thus no one liked it)?

One of the main purposes of the overflow menu is to let the user keep a
streamlined interface. While users are not asking for customizability, they
are asking for a simpler, more focused UI. The overflow menu allows the
user to quickly chuck rarely-used commands under a menu, where they're
always available should the user have a need for them. It also allows users
to find commands quickly, without having to wade through a formatting

Menus, dialogs, context menus, and keyboard shortcuts are all quite
unfriendly to a novice user.

That's not a good argument. Add enough elements to a toolbar and add
enough toolbars to the window and you're in Adobe hell.

Not if you have contextual toolbars. If you're working with text, you get a
text toolbar. Once you click on an image, text commands disappear and image
commands appear. Doesn't overload the UI at all.

What I meant by "unfriendly to a novice user" is that going through these
UI elements takes a long time for a new user. The problem with menus is
that they're not contextual -- the menus are filled with irrelevant
commands that the user can't use. Once the user is done reading through
menus, he also has to read through commands in dialog windows. This is
hard, because these windows are unwieldy, with multiple tabs, subdialogs,
and a strange organizational structure. The most infamous example of this
is LibO's Options dialog.

When a new user is presented with a well-organized set of toolbars, though,
he's usually ready to work right away.

Menus and dialogs can be frustratingly
unwieldy and it'd be silly to use them frequently. (Imagine working on a
presentation for chemistry and going to the font dialog every time you
needed to add a superscript.)

That is a good argument, though, from my perspective.

Moreover, all four of these are suited specifically for
mouse/keyboard-based interaction. Neither Android nor iOS feature menus,
context menus, or keyboard shortcuts, dialogs are sparse and simple.
Ubuntu's Unity hides menus by default. Web applications have never used
menus. If we want to make LibO at least somewhat touch-friendly and
consistent between the desktop, web, and Android versions, the overflow
menu is a step in the right direction.

Being touch-friendly and consistent between platforms doesn't mean the
software fits in everywhere though. And as far as I heard, Android
should get a new interface written in Java which means that while we
could share UI concepts, it doesn't come naturally.
Next, there is the problem that each and every mobile platform we
might target with LibO has its own look, feel and developer tools
(we'll get Blackberry tablets for ~free with the Android version, but
that's about it).

Yes, but know that many platforms are becoming touch/mouse+keyboard
hybrids. Windows 8 is supposed to work equally well with both, Gnome 3 is
being designed to be touch-friendly, and there are rumors that the next
version of Android will be more mouse+keyboard-friendly.

I'm also unsure whether the regrouping of the elements in the overflow
menu helps people to understand the functionality. In the overflow menu,
the items seem to be extracted, so that e.g. setting the font size is
far away from the (logical) position of the dropdown font size.

That might be a smaller problem, but I don't see that as very
critical. Actually, I like the fact that the Overflow menu is not so
overladen with elements.

How does the change relate to the recent removal of the drop-down
element in the toolbars [2]?

To me, it relates insofar as that it'd bring the useful part of the
old functionality back without being so clumsy to use (I hope).

And just for the record, I'm not sure whether "overflow" menu really
fits. According to what I've experienced with Android, the overflow menu
incorporates all items that do not fit into the topmost application bar
(whilst the application bar only accommodates functionality for the
given context / screen). Here, it is rather meant to be "further /
more". But I'm not a native speaker ...

Sure, but the other function of it is that it *does* contain
everythign that doesn't fit in the toolbar any more.

Back to "ellipsis menu", then? (I have to say I prefer that name.)

I'd hate to tie the name of it to a symbol. What if, for instance, a
theme were to use another symbol? Our documentation would refer to an
ellipsis menu with an ellipsis nowhere to be found.

 to "ellipsis menu", then? (I have to say I prefer that name.)

I'd hate to tie the name of it to a symbol. What if, for instance, a

theme were to use another symbol? Our documentation would refer to an

ellipsis menu with an ellipsis nowhere to be found.

OK, staying with "overflow menu", then.

I believe there's no special feature that the overflow menu introduces
would require a keyboard shortcut.
Accessing toolbar buttons (including the overflow menu) via a keyboard
shortcut might be nice, but that should be within a different proposal.
Having a shortcut for buttons in the overflow menu and not having them
shown toolbar icons, which are used more often, seems a bit illogical.

Kind of makes sense. However, if we're at it, why not try to specify
keyboard bindings for toolbars (MSO used something like "press Alt,
then Tab, and then you can move through the toolbar").

If you'd like to, start a thread for this.

These thoughts be thine for nary 2 c.



Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be

Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


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.