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


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

--- Comment #12 from Mirek2 <mazelm@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.

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.