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

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

--- Comment #15 from Jay Philips <philipz85@hotmail.com> ---
(In reply to comment #13)
> Changing the design of something does not constitute "forcing" people to do
> anything. This mentality is an all-too-prevalent enemy of design. It may be
> a bit of a cliche by now, but design is not some kind of polish you put on
> software after you've made it to make it look nice--design is how it works,
> so if we can't make decisions about how LibreOffice works, then we can't
> expect it to be designed well. We shouldn't rely on the expectation that
> each user will "paint their own" ui--most people can't be bothered to do
> that. Most people don't use LibreOffice primarily for the ability to change
> the chrome--they use it to be productive. The sidebar is a much more natural
> way of laying out tools, which I would bet increases overall productivity. 

Presently, there are two choices to get access to the gallery. The first is the
old way of the gallery appearing between the toolbars and the ruler and the
second is the new way of the gallery appearing in the sidebar. By eliminating
one of these two choices, would this not limit a user's choice. For a user at
1024x768, when the gallery appears under the toolbar <
http://i.imgur.com/1I7K3sp.png >, he/she can view their document at 100% and
can see view more images than when the gallery appears in the sidebar. If the
sidebar gallery appeared at 1024x768 < http://i.imgur.com/YeXodS8.png >, it
would cause a significant portion of the document to be not viewable unless the
view is adjusted with the scrollbars or the zoom level. Yes most users dont
bother adjusting the default UI, but we do allow the users that do, the ability
to move toolbars to any of the four sides, so in the same spirit, we should
allow users to have the gallery at the top or in the sidebar.

> > 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.
>
> This is important. A toolbar with many items takes just as long to look
> through as a menu. 

Images are easier to recognize then words, especially if they are easy to see
(bug 82309) and easy to understand (bug 82272), and when toolbar buttons are
organized in a good manner representing a collection of features, they will be
quick to navigate. LibO has grouped similar features like bold, italics, and
underline together and in a similar manner, i had suggested the grouping of
various insert buttons like table, image, footnote, comment, etc. together. The
drop downs do not make it harder to access, as entries underneath the main
entry are very related to the main entry. This is no different than the
submenus in the context menu for styles or line spacing. Without this quick
access, users would have to always jump into the dialog boxes to get these
basic features lacking from the toolbar.

> In order to move forward, we need to: 
> (1) Recognize and agree that Writer's toolbars have a fixable problem.
> (2) (a) Create a whiteboard to work on this problem collaboratively, or
> (2) (b) Create different proposals separately
> (3) Decide on a solution
> (4) Get some developers to work on it.
>
> This bug report is great for addressing (1), but we can't move into part (2)
> without first completing part (1), which is answering the question: Are the
> standard and formatting toolbars in need of a redesign?
>
> I would say they are.

Yes this bug was mainly setup to address step 1 and demonstrate how it can be
fixed, so that the necessary individuals/teams could take these findings and
finalized it into a solution. I am willing to work with whomever can move this
proposal forward and believe step 4 can easily be achieved, as i can submit
patches to add/remove all non-group button entries and will find a developer to
implement the group buttons.

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