[Libreoffice-ux-advise] [Bug 81475] Meta: enhancing Writer's standard and formatting toolbars

Wed Aug 13 04:11:43 PDT 2014

https://bugs.freedesktop.org/show_bug.cgi?id=81475

--- Comment #14 from Jay Philips <philipz85 at hotmail.com> ---
Created attachment 104556
  --> https://bugs.freedesktop.org/attachment.cgi?id=104556&action=edit
IBM Symphony single toolbar line with standard and contextual toolbars

Hi Mirek,

(In reply to comment #12)
> Yes, but the font name drop-down is rarely used, which means it should
> either be removed from the toolbar and left to the sidebar or it should at
> least occupy less space (as a drop-down with an icon).

Well i guess that we'll have to disagree on how used the font name drop-down
is. You also have to take into consideration that styles arent highly used in
calc and impress, as there isnt a style drop down in the toolbar. Here are
responses about this issue from the ux mailing list.

Jean-Francois Nifenecker: Could you elaborate, please? When I see the people
around me (corporate environment, 400+ users) who don't use styles (most of
them, unfortunately), the font drop-down *is* used very often.

David: I really do get irritated with this argument about styles. Yes, they are
the right way and yes, we should use them all the time. But the real world
isn't
like that and a significant proportion, if not majority, of LO users just
don't get styles. Period. I use styles and have taught their use in offices
I've managed for many years. But for short 1 to 2 page documents it is
irrelevant whether users will be bothered about spending time styling their
documents. Please do not reduce the choice of users to use fonts and direct
formatting if they wish, and do not make it harder for them to do so.

> Spelling is an integral part of the Language menu under tools --
> spell-checking and grammar-checking are the only reasons to apply a language
> to parts of text. What I meant to say is that there's no need for a separate
> Spelling menu -- it would just duplicate the Language menu.

Well if you'd prefer to have 'Spelling and Grammar' and 'AutoSpellcheck'
underneath the Language submenu, then i'm fine with that, though i think it
maybe confusing for some users. The reason for suggesting the spelling menu was
that i didnt want to suggest cluttering up the main Tools menu with an
'AutoSpellcheck' entry, but maybe it would be worth it so users didnt have to
go digging through a submenu for it.

> The thing is, we don't need to save space. We should keep all the common
> options as accessible for users as possible and relegate all the lesser-used
> commands to the sidebar.

LibO has a plethora of useful features that can be brought forward to users, so
they dont have to go through menus, dialogs, and sidebars. And in order to
bring some of these features to the toolbar, space needs to be freed up.

> Button groups make things harder to access, and if the formatting toolbar is
> supposed to provide quick access to the most common commands, it should
> avoid them when possible.

Button groups do not make things harder to access, as we already have button
groups for open, new, paste, table, font color, highlight color, background
color, and all the shapes in the drawing toolbar. You could easily consider the
style, font name and font size a button group.

As an example, lets take my proposed 'Insert Internal Link' group button.
Instead of a user having to go into Insert > Footnote/Endnote and then the
dialog opens up and then them select 'Endnote' under type, they would click on
the down button in the group button and click the endnote entry. This is easier
access. This functionality isnt available in the sidebar as well.

> (Ideally, LibreOffice would be responsive and group buttons into drop-down
> menus when there is no room for them.)

It would be great if LibO was smart enough to do that, but as it isnt, we can
still help. :)

> A simple Find button is probably best, as it encompasses both search and
> navigation.

Presently there isnt a Find button available.

> The problem around panes being duplicated in the sidebar is still a hot
> topic now, but, generally, we should either promote one or the other, and
> since the sidebar has panes that aren't available individually, we should
> prefer the sidebar over the panes.

Yes i've seen the discussions around this issue and thought to comment on it,
but chose not to. Ultimately, i think users who use the sidebar would like the
panes in the sidebar, but users who dont, would prefer it the old way.

> Rather than buttons for individual panes, then, how about having a button
> for the sidebar?

I think it would be useful to have a sidebar/toolbar mode button that would
allow users to choose what they prefer to use. If they are in toolbar mode, it
works as it has always done. If they are in sidebar mode, only a single toolbar
line should be visible that primarily hosts the standard toolbar, and there
shouldnt be drawing, table, and find toolbars popping up at the bottom (similar
to how IBM Symphony had it).

> We have the same sidebar that Symphony had -- IBM donated the code to AOO
> and now we have it -- we just refined it a bit. We're already there.

I am aware that the sidebar was brought from IBM Symphony, but the additional
toolbar functionality wasnt brought over. In IBM Symphony, there was a single
top toolbar line that had a small standard toolbar and then an additional
contextual toolbar, which changed when you were on/in an object (see attached
image). This contextual toolbar took the place of all the bottom popup toolbars
(table, picture, etc) as well as the toolbars that that switch with the
formatting toolbar (frame, ole-object, drawing object properties, etc).

> The toolbar is for quick access. If you need lesser-used commands, you'll
> have to open either the sidebar or the formatting dialog. The sidebar is
> easier to work with and some may just view it all the time. It's not being
> forced on anyone, though.

The toolbar is quick access just like the sidebar, but as the sidebar is a
non-experimental feature introduced in 4.2 and is not enabled by default, many
users may not be aware of it or prefer not to use it. If the styles, navigator,
and gallery are decided to be exclusively kept in the sidebar, then they will
be forced to use it.

> I'm just saying that putting common things into harder-to-access group
> drop-downs to make room for lesser-used commands goes against the quick
> access nature of toolbars.

Group drop-downs are not hard-to-access and most entries proposed for the
drop-downs are for highly used commands, as the statistics have already shown.
If you look at the WordPerfect screenshot, you will notice that they have
similar group drop-downs for underline (this is in the sidebar already),
alignment, and symbols.

--------------------

Regarding the sidebar, I believe there are two types of users who use writer.
One type of user who will use the sidebar and one type that wont. I think the
use of the sidebar will likely come down to the user's screen size, but the
maturity of the sidebar will also likely effect some users decision.

If you look at these stats, < http://www.w3counter.com/globalstats.php > and <
http://gs.statcounter.com/#resolution-ww-monthly-201307-201407 >, you will see
that the second most used screen size is 1024x768. A user at this small 4x3
screen size, is highly unlikely to use the sidebar over the toolbar, as the
sidebar takes up 1/3 of the screen (the smallest size of the sidebar is 317
pixels). Such a user wouldnt be able to handle that huge chunk of space taken
away from him/her and would prefer the formatting toolbar.

This proposal was done for toolbar users who may not know about the sidebar, as
its not enabled by default, and for users who choose not to use it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.