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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #12 from Mirek2 <mazelm at gmail.com> ---
Hi Jay,
I'll just comment on your answer here and comment on the issue later:

(In reply to comment #9)
> > * Additionally, I would propose to either get rid of the "Font Name"
> > dropdown or at least condense it into a drop-down menu with an icon. It's
> > bad practice both to use more than 3 fonts per document and to hard-format
> > fonts instead of using styles.
> 
> The concept of styles are foreign to many users and they will stick with
> using the font names dialog to select fonts they want to use and i doubt
> there is anything that will change this behaviour unless styles are
> introduced in a new manner that is very ease to grasp.

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

> > Step 2
> > ======
> > a)
> > * +1 to having a "Word functions" split button
> > * I disagree with having a Spelling menu item -- the current approach that
> > lets you work with the selection, the paragraph, or all text makes much more
> > sense to me.
> 
> Well i suggested the spelling menu, as a means of grouping spelling related
> items into the Tools menu, similar to having a language menu item in the
> Tools menu. I didnt quite get what you meant with 'work with the selection,
> the paragraph, or all text' when it comes to spelling.

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.

> > * Not keen on building Google or Bing into LibO. Wouldn't mind extensions
> > for this, though.
> 
> This was only a hope that something would show up like this in the future,
> as i think it would help many translators (especially those working on the
> release notes for LibO :D). If an open source alternative is around, i'm all
> for it, but was just suggesting how this drop down might get expanded in the
> future.

I understand.

> > * Error navigation is better suited for the "Navigate by" feature.
> 
> Where can i find this navigate by feature?

Either the navigator or the Find toolbar. In older versions, it used to be at
the bottom of the right-hand scrollbar.

> > b)
> > * Given that several of the alignment options are commonly used, I would not
> > make them into a group button. Because we have the Properties pane now, we
> > should just have individual buttons for the more important features in the
> > toolbar.
> > * The same with "Bullets and Numbering".
> 
> These are commonly used buttons, but unfortunately they take up more space
> than the more used trio - bold, italics and underline. In the alternative
> mockup i have suggested the use of a two button approach so it takes up the
> size of 2.5 buttons rather than 4 (this mockup also keeps the buttons and
> numbering separate).

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.

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.

(Ideally, LibreOffice would be responsive and group buttons into drop-down
menus when there is no room for them.)
> 
> > Step 3
> > ======
> > a)
> > * I'm torn about whether to add "Find" or "Find and Replace". Though
> > "Ctrl+F" is relatively well-known, 15% of users used the toolbar button
> > (more than "Undo", "Cut", "Copy", or "Paste"). The toolbar is also more
> > comfortable to use, already links to "Find and Replace" if it's needed, and
> > has navigation features not found in the dialog. I'm also hoping some basic
> > replace functionality will be added to the toolbar.
> 
> I was initially going to suggest a group find button, but unfortunately
> space was a limiting factor. The group button was going to have Find, Find &
> Replace, Goto Page (dialog), and Navigator.

A simple Find button is probably best, as it encompasses both search and
navigation.
> 
> > * Subscript/superscript should be individual buttons. (There's space freed
> > by the "Font name" removal suggested above.)
> 
> Yes if there is space, i'd have these as separate.

If there is no space, they should be in the sidebar.

> > * A single "Size Change" button would be hard to implement, it would feel
> > alien as it's not a native widget, and the small version would be hard to
> > target. It'd be preferable to replace the font size combo box (which
> > shouldn't be used anyway -- styles should be used for sizing text) with
> > "Increase font size" and "Decrease font size" buttons. Clicking one of these
> > buttons should show the new font size in a tooltip below the button.
> 
> Well i was going to suggest the 2 increase and decrease font buttons located
> on either side of the font size combo box, but space was an issue. I dont
> think eliminating the combo box was good as it would mean users couldnt jump
> to a particular size that they wanted and would have to waste time clicking
> till they got to the correct size. I think the combo box could be reduced as
> it seems that it has enough room for 4 characters, when most font sizes are
> only only 2 chars, except for '10.5'.

Reducing the box sounds good.

> > b)
> > * An "Insert Media" group doesn't seem necessary to me. It's extremely
> > unlikely for sounds or videos to be inserted into documents, spreadsheets,
> > or drawings, and, from my own experience, it's pretty rare for
> > presentations. The Gallery is in the sidebar and shouldn't have a toolbar
> > button (see [Bug 73151]). Fontwork should basically never be used. The only
> > buttons remaining are Insert Image ("From File...") and "Scan Image" -- the
> > former should be in the toolbar, the latter is, IMHO, not used frequently
> > enough to warrant its own button.
> 
> This proposal was limited to just writer. The ability to open up the
> gallery, whether it be in the current location or in the sidebar, from
> within the button group is still a useful feature, as it is possible that
> the user doesnt have the sidebar enabled or open. This would be no different
> than having the button in the Tools menu.

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.

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

> (In reply to comment #8)
> > I would caution against adding any more functionallity into the standard
> > toolbar. As it is, it's so crowded it makes it more difficult to navigate
> > than a menu in my opinion. This is my idea for how the standard toolbar
> > ought to be set up in conjunction with the sidebar: http://imgur.com/a/XyN4O
> > , althought I've since removed the spellcheck button, since it's already in
> > the status bar.
> 
> Yes it is crowded with junk that is rarely used, which is why the first
> thing in the proposal is the removal of the trash. Your standard toolbar +
> sidebar approach is a similar layout to IBM symphony and Calligra Words and
> i look forward to the day that it will be possible with LibO, but
> unfortunately i dont think that will happen within the next year or two.

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.

> Also you will have users who will choose not to use the sidebar, so i dont
> think LibO should force them to do so.

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.

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.

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