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


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

Context


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.