Ready for the developer team?

classic Classic list List threaded Threaded
9 messages Options
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Ready for the developer team?

Hi everyone,
I feel that there are four whiteboards that are almost ready:

   - https://wiki.documentfoundation.org/Design/Whiteboards/Add_buttons
   - https://wiki.documentfoundation.org/Design/Whiteboards/Page_handles
   - https://wiki.documentfoundation.org/Design/Whiteboards/Overflow_menu
   - https://wiki.documentfoundation.org/Design/Whiteboards/Insert_bar

Could you give some feedback or help add more details so that I could pass
these on to the developer team?
Thanks. :)

--
Unsubscribe instructions: E-mail to [hidden email]
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

Bhaavan Merchant Bhaavan Merchant
Reply | Threaded
Open this post in threaded view
|

Re: Ready for the developer team?

I would love to see these whiteboards implemented.

However, I am still not convinced that within the overflow menu, it is
correct to have 3 buttons to choose line spacing. This point IMO should be
reconsidered before being implemented. But then at the same time, I am also
not sure that if the overflow menu whiteboard is the one where this point
needs to be considered. (Possibly this issue needs to be disussed for the
http://wiki.documentfoundation.org/Design/Whiteboards/Toolbars . I am not
sure.)

--
Unsubscribe instructions: E-mail to [hidden email]
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

Stefan Knorr (Astron) Stefan Knorr (Astron)
Reply | Threaded
Open this post in threaded view
|

Re: Ready for the developer team?

Hi Mirek, Bhaavan,

first of all: great to have you here, doing all those Whiteboards and
I really have high hopes.
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.
Accessibility is one of them (as in: are there fallback mechanisms for
accessing the show/hide functionality that would usually d/d
reliant?)... Also, can you make some more mockups, please (i. e.
opening, dragging, context menu etc.)? Preferably, could you try with
wireframes (the jist: instead of drawing attention to graphics, they
help visualise the concept).
I personally use Pencil (Firefox addon, but hasn't been updated for
some time, so some things quite broken, including export), but
https://gomockingbird.com/ is a pretty good online alternative (only I
am an Arial hater and they don't allow me to change font, so I don't
use it). If you like Inkscape better, then just use that.

Next thing is that there's still things that can only be found on the
discussion page, would be great to move those over.


On 19 February 2012 14:49, Bhaavan Merchant <[hidden email]> wrote:
> However, I am still not convinced that within the overflow menu, it is
> correct to have 3 buttons to choose line spacing. This point IMO should be
> reconsidered before being implemented.

This is a completely different thing. So we all don't forget, could
you please open a bug about that, describing what you'd expect?


Hope this helps,
Astron.

--
Unsubscribe instructions: E-mail to [hidden email]
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
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Re: Ready for the developer team?

Hi Astron,

2012/2/19 Stefan Knorr (Astron) <[hidden email]>

> Hi Mirek, Bhaavan,
>
> first of all: great to have you here, doing all those Whiteboards and
> I really have high hopes.
> 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.
> 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...

> Also, can you make some more mockups, please (i. e.
> opening, dragging, context menu etc.)? Preferably, could you try with
> wireframes (the jist: instead of drawing attention to graphics, they
> help visualise the concept).
> I personally use Pencil (Firefox addon, but hasn't been updated for
> some time, so some things quite broken, including export), but
> https://gomockingbird.com/ is a pretty good online alternative (only I
> am an Arial hater and they don't allow me to change font, so I don't
> use it). If you like Inkscape better, then just use that.
>
:) Okay. Will get on this when I have more time (that might take a while).

>
> Next thing is that there's still things that can only be found on the
> discussion page, would be great to move those over.
>

I think you took care of that. Or is there still something missing?

>
>
> On 19 February 2012 14:49, Bhaavan Merchant <[hidden email]>
> wrote:
> > However, I am still not convinced that within the overflow menu, it is
> > correct to have 3 buttons to choose line spacing. This point IMO should
> be
> > reconsidered before being implemented.
>
> This is a completely different thing. So we all don't forget, could
> you please open a bug about that, describing what you'd expect?
>
>
> Hope this helps,
> Astron.
>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> 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 [hidden email]
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

Andrew Pullins Andrew Pullins
Reply | Threaded
Open this post in threaded view
|

Re: Ready for the developer team?

about the Add page/Add section buttons. does this only apear at the end of
the document. what about if you want to add a page or section to the middel
of the document. should these not remain in between the pages. also does
clicking one the Add section button still bring up the menu that lets the
user choose how the next section will appear as we did in our mock ups, or
did you go away from that. I think that this should stay, I would like to
keep it like the impress menu.


with the insertion bar. can you mock and discuss how a drop down button
would work. sence its doced left would it be a pop right menu?

--
Unsubscribe instructions: E-mail to [hidden email]
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

Christoph Noack Christoph Noack
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by mirek2
Hi Mirek, Astron, all!

Am Sonntag, den 19.02.2012, 16:39 +0100 schrieb Mirek M.:
> 2012/2/19 Stefan Knorr (Astron) <[hidden email]>
> > 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 [hidden email]
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
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

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

Hi Christoph,

2012/2/22 Christoph Noack <[hidden email]>

> Hi Mirek, Astron, all!
>
> Am Sonntag, den 19.02.2012, 16:39 +0100 schrieb Mirek M.:
> > 2012/2/19 Stefan Knorr (Astron) <[hidden email]>
> > > 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 [hidden email]
> 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 [hidden email]
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

Stefan Knorr (Astron) Stefan Knorr (Astron)
Reply | Threaded
Open this post in threaded view
|

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 [hidden email]
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
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

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

Hi Astron,

2012/3/1 Stefan Knorr (Astron) <[hidden email]>

> 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 [hidden email]
> 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 [hidden email]
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