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 to
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.
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.
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)?
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.
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).
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 ?
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.
I believe there's no special feature that the overflow menu introduces that
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 for
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").
These thoughts be thine for nary 2 c.
Unsubscribe instructions: E-mail to firstname.lastname@example.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Impressum (Legal Info)
: 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