Re: [libreoffice-design] Concept – Contextual Toolbar with Add-Button

On Thu, Feb 16, 2017 at 10:41 PM Heiko Tietze <tietze.heiko@googlemail.com>
wrote:

> looks like a really cool Notebookbar focusing on the average user with a
> broad spectrum of needs - Eve. The current 'contextual sections' variant
> was made having Benjamin in mind.


My toolbar concept targets mainly Benjamin. The left part of the interface
contains only actions targeted at Benjamin, as further you go to the right,
the more advanced features are present.

Toolbar Group 1 - 05 of 05 items target Benjamin (100%)
Toolbar Group 2 - 05 of 05 items target Benjamin (100%)
Toolbar Group 3 - 07 of 11 items target Benjamin (64%)
Toolbar Group 4 - 04 of 09 items target Benjamin (44%)
Toolbar Group 5 - 00 of 05 items target Benjamin (0%)

Overall 21 of 35 items are targeted at Benjamin (60%).

Of course it depends how someone rates the buttons/actions – I did it
reserved (for example I didn't count remove-formatting as
Benjamin-targeted).

Therefore all icons have a label, sections are labeled...

Labeling everything comes at a high price, label take a lot of
screen-space. I think that labeling is not that important, what rather
matters is to group similar actions together → grouping over labeling. Not
using section labels allows to be not forced to have only actions of a
certain section-group in one group – e.g. in the mock-up I have the
comment-button in the same group as the text-size button.

... only the most relevant features are present.

This is a controversial topic. Some years ago I helped an older man to
accomplish the needed computer-tasks to get his music businesses done. He
never used the mouse right-click menu nor any keyboard shortcuts. Soto-say,
he was a real live Benjamin user. When watching him write his songs on the
computer, I saw that he used the copy & paste buttons quite a lot – I've
also seen other average users use them. So I would argue that they are
essential. And this is the problem, office applications have a lot of
functionality that could be described as essential, even when focusing at
Benjamin type of user.
If I had labeled the first two of my toolbar groups, I would probably have
used more than half of the toolbar screen width without having any office
functionality, only open, save, copy, paste...


> Users with not so perfect sight may struggle with bullets vs. numbers, for
> instance, that are distinguished by only a few pixels. Casual users may not
> recognize some functions and need to read the tooltips.
The concept interface is designed from the left to the right. I would
expect users to read tool-tips or ignore icons that are further on the
right side. This is expected behavior, not a failure of the UI. Like in the
real world, I don't need to understand how to use every tool in a toolbox
to get work done. The icons on the left should be known from other
applications or speak for them-self.

To help users with less sight there should be a high-contrast icon theme.
Labeling all buttons would IMHO not help here, because not all
basic-actions (controversial, I know) can be present in the toolbar. Which
leads to that the actions must be present somewhere else → side bar. In the
sidebar they currently have no label. Even if they had labels, it would
mean that the sidebar would have more menus or that you would have to
scroll down, which is in both cases not that great. From thinking about
that problem I don't see what else beside of having a high-contrast icon
theme and a good default navigation scheme could be done in this respect.
If labels are primary there to help less sight people, than I disagree, a
UI should never be bend to serve mainly a minority.


> The idea to show a menu when the width is not sufficient for all icons is
> quite interesting. You may compare it with the implementation at the tabbed
> variant. But I wouldn't use Add and a plus icon, though.
It is just an idea. The add-button is there to solve an inconsistency in
the current LO Writer UI (also present in Microsoft Writer), let me explain.

We could say that there are different write-modes, which need different
toolbar buttons to manipulate their behavior. The default-mode is to write
text and needs many always visible buttons, e.g. the formatting buttons.
When adding a table, the table is a sub-mode, lets call it table-mode. To
handle the behavior of the table-mode we need some more buttons, plus the
buttons from the default-mode to handle text written inside the table. The
add-button orders the visibility of the sub-mode buttons and solves
therefor the above described problem, the UI no longer needs to mix buttons
from different modes.


> And last but not least about user expectation. This was also a question
> when we created the contextual sections. But on the other hand we have a
> sidebar that allows very efficient access with widescreen displays. And why
> not show a few functions in the toolbar and everything else in the sidebar?
> Calligra did this and has only New, Open, Save, Undo, Redo, Cut, Copy,
> Paste, and Find in the toolbar.

I'm currently not sold on that idea. Mainly because it means to split
actions to different places. There is the problem of
mouse-distance-to-target and for small screens screen space doubts, also it
is a quite uncommon approach and breaks therefor with common user habits –
why even have a toolbar at all? There seems to bee some agreement that the
sidebar is a good thing here, I would like to learn about the reasoning
behind it. Has some user testing been done that indicates the sidebar is
better than a traditional toolbar? Why did Microsoft go with such a feature
packed toolbar and not a sidebar? Did someone evaluate if a sidebar only
approach would work, if it works it could be quite an interesting idea.

That's it for now, sorry for the long reply ^^

Thibaut

-- 
To unsubscribe e-mail to: design+unsubscribe@global.libreoffice.org
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