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

Hi Astron,

2012/3/1 Stefan Knorr (Astron) <heinzlesspam@googlemail.com>

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

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

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

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

> 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

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