Hi Mirek, Astron, all! Am Sonntag, den 19.02.2012, 16:39 +0100 schrieb Mirek M.: > 2012/2/19 Stefan Knorr (Astron) <heinzless...@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? 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) * context menus * keyboard shortcuts Given the nature of toolbars, providing quick access besides a given application menu structure, it might be too much. 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. 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). 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? 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 ... > > 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. [...] 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+h...@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