Re: Overflow Menu (was: Re: [libreoffice-design] Re: Ready for the developer team?)

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 [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.


> 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.

Astron.

-- 
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
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