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

Hi Christoph,

2012/2/22 Christoph Noack <christoph@dogmatux.com>

> Hi Mirek, Astron, all!
>
> Am Sonntag, den 19.02.2012, 16:39 +0100 schrieb Mirek M.:
> > 2012/2/19 Stefan Knorr (Astron) <heinzlesspam@googlemail.com>
> > > first of all: great to have you here, doing all those Whiteboards and
> > > I really have high hopes.
>
> +1 :-)
>
> > > With regard to the completeness of the Whiteboards, I will only speak
> > > about Overflow Menu for now, as that's the one I have been most in
> > > contact with. I think there's lots of things that still needs to be
> > > thought-out.
>
> I also had a look at the documents and the mails from January, and I'd
> like to ask some questions ... I hope I haven't missed the answers.
>
> 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.

> Do you plan to adapt the other means to access functionality? If not,

then I fear it gets even more complicated for many users, since we have
> too many access points for features:

     * application menu / dialogs
>      * toolbars (shown, hidden) with elements (shown, via overlfow,
>        hidden)
via overflow = those that don't fit within the window + (seperator) + hidden

It's less complicated than the old double-arrow menu, where you had to
choose commands one by one under the "visible items" menu and only then
were you able to actually use those commands.

     * context menus
>

If you mean the "Visible buttons" menu under the Toolbar's context menu,
then that's not needed anymore.

     * keyboard shortcuts

Given the nature of toolbars, providing quick access besides a given
> application menu structure, it might be too much.

Menus, dialogs, context menus, and keyboard shortcuts are all quite
unfriendly to a novice user. 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.) Context menus aren't transparent (you never
know what you might find in a context menu) and many people simply don't
use them (a number of people I know were shocked to discover that you can
right-click on a MacBook). Keyboard shortcuts have to be learned or set,
and LibreOffice doesn't come with many by default.

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.

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 wasn't intentional. The "Increase font" and "Decrease font" buttons
should be next to the font size drop-down, but within a separate group.

> Next, is it planned to have an overflow menu for each toolbar? I noticed
> that your mockup [1] only shows the formatting toolbar, but LibO enables
> numerous toolbars per default (dependent on the application).
Yes.

> How does the change relate to the recent removal of the drop-down
> element in the toolbars [2]? Do you plan to add that functionality?

No.
The commands missing are "Visible buttons", "Customize toolbar", "Lock
toolbar position", and "Close toolbar". The latter three will remain within
the toolbar's contextual menu. "Visible buttons" isn't necessary anymore,
as the toolbar can be easily customized with drag-and-drop. The
functionality "Customize toolbar" and "Close toolbar" will still be
accessible through the menu structure. "Customize toolbar" and "Lock
toolbar position" will be there for people who want a deeper level of
customization and for people who are unable to drag-and-drop.

These commands are not something that a user should use recurrently, and
they're not something an touch-screen user couldn't do without.

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

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

> > > Accessibility is one of them (as in: are there fallback mechanisms for
> > > accessing the show/hide functionality that would usually d/d
> > > reliant?)...
> >
> > There's always the trusty old "Customize..." dialog. I don't think
> there's
> > anything about the overflow menu that would require special
>  accessibility
> > considerations...
>
> I think it would be beneficial for many people if feature access via
> keyboard is specified.

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.

> [...]
>
> That's what I had in mind ... thanks in advance!
>
> Cheers,
> Christoph
>
> [1] http://wiki.documentfoundation.org/File:Overflow.png
>
> [2]
>
> http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2011-06.html#2011-06-14T10_29_17.htm
>
>
> --
> 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