Concept – Contextual Toolbar with Add-Button

classic Classic list List threaded Threaded
7 messages Options
Thibaut Brandscheid Thibaut Brandscheid
Reply | Threaded
Open this post in threaded view
|

Concept – Contextual Toolbar with Add-Button

 Here my concept about how the LO Writer toolbar could be improved. I have
spend around 20 hours on it and to my surprising it is quite similar to the
current default design. I spend a good amount of time thinking about
use-cases, button positioning and alignment. In the end there are a lot of
buttons (actions) that are expected to be there, which keeps the
possibilities to change things at a low level. Unversed users expect to
find e.g. copy & paste buttons, so I could not rationalize them away, same
for a lot of other functionality.

Let me know what you think!

960 px low-width mode:
https://drive.google.com/file/d/0B6yaM-XqO5AOUEQ5WC00SnpLTzg/view?usp=sharing
1280 px normal-width mode:
https://drive.google.com/file/d/0B6yaM-XqO5AONDM4X3R4Q2YxUzA/view?usp=sharing
Zip with GIMP files:
https://drive.google.com/file/d/0B6yaM-XqO5AObnFSSFB6S1diLUk/view?usp=sharing
(ctrl+shift+t to toggle show-guides in GIMP)


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


*Overview*

This design is based on the Notebookbar concept. It borrows the idea of big
icons with text to build visual groups and extends it with the idea of
having a low and normal width interface. The low-width UI introduces the
add-button which aggregates all add-a-thing actions, like adding a table or
page break. The content of the last visual toolbar group adapts contextual
to the currently focused UI-element and is therefor not always visible.


*Spacing*

This toolbar design is based on an 8 px grid.


   - Top, left and bottom padding of the toolbar: 24 px
   - Padding between buttons: 16 px
   - Padding between button and vertical line: 12 px (padding left & right
   from line = 24)
   - Padding between toolbar and document sheet: 24 px


Application window size:
normal 1280 px  (160 x 8)
low        960 px  (120 x 8)


*Low & Normal Width Mode *

If the application window is less than 1280 px wide, the low-width mode is
activated and only there the add-button is present. Since the content of
the last toolbar group is context based, it must always contain an
add-button in low-width mode – a small version is sufficient – e.g. to
insert media into a table.

In normal-mode the add-button content is displayed as separate toolbar
group and the add-button is not present.


*Explanation*

Office applications by nature incorporate complexity. To allow unversed
users to carry basic tasks, the UI has to be simple and straight forward.
Advanced actions should be present – but easily ignoble.

All displayed buttons are either expected to be there (save, copy, paste…),
are needed to provide basic functionality (bold, text-size, left-align …)
or are lesser accessed but handy actions (add-table, comment,
page-settings...).

The ruler is not displayed by default because it is an advanced feature.

--
To unsubscribe e-mail to: [hidden email]
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
Heiko Tietze-2 Heiko Tietze-2
Reply | Threaded
Open this post in threaded view
|

Re: Concept – Contextual Toolbar with Add-Button

Hi Thibaut,

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. Therefore all icons have a label, sections are labeled, and only the most relevant features are present. Big buttons should stand out, ideally with more detailed and colored icons so that the visual focus goes to those buttons. Your layout is rather balanced, and with the sparingly use of labels there is enough space to provide more functions. 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 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.

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.

So far from my side. Many thanks for sharing your idea,
Heiko

On 02/15/2017 08:55 PM, Thibaut Brandscheid wrote:

>  Here my concept about how the LO Writer toolbar could be improved. I have
> spend around 20 hours on it and to my surprising it is quite similar to the
> current default design. I spend a good amount of time thinking about
> use-cases, button positioning and alignment. In the end there are a lot of
> buttons (actions) that are expected to be there, which keeps the
> possibilities to change things at a low level. Unversed users expect to
> find e.g. copy & paste buttons, so I could not rationalize them away, same
> for a lot of other functionality.
>
> Let me know what you think!
>
> 960 px low-width mode:
> https://drive.google.com/file/d/0B6yaM-XqO5AOUEQ5WC00SnpLTzg/view?usp=sharing
> 1280 px normal-width mode:
> https://drive.google.com/file/d/0B6yaM-XqO5AONDM4X3R4Q2YxUzA/view?usp=sharing
> Zip with GIMP files:
> https://drive.google.com/file/d/0B6yaM-XqO5AObnFSSFB6S1diLUk/view?usp=sharing
> (ctrl+shift+t to toggle show-guides in GIMP)
>
>
> -------------------------------------------------------------------
>
>
> *Overview*
>
> This design is based on the Notebookbar concept. It borrows the idea of big
> icons with text to build visual groups and extends it with the idea of
> having a low and normal width interface. The low-width UI introduces the
> add-button which aggregates all add-a-thing actions, like adding a table or
> page break. The content of the last visual toolbar group adapts contextual
> to the currently focused UI-element and is therefor not always visible.
>
>
> *Spacing*
>
> This toolbar design is based on an 8 px grid.
>
>
>    - Top, left and bottom padding of the toolbar: 24 px
>    - Padding between buttons: 16 px
>    - Padding between button and vertical line: 12 px (padding left & right
>    from line = 24)
>    - Padding between toolbar and document sheet: 24 px
>
>
> Application window size:
> normal 1280 px  (160 x 8)
> low        960 px  (120 x 8)
>
>
> *Low & Normal Width Mode *
>
> If the application window is less than 1280 px wide, the low-width mode is
> activated and only there the add-button is present. Since the content of
> the last toolbar group is context based, it must always contain an
> add-button in low-width mode – a small version is sufficient – e.g. to
> insert media into a table.
>
> In normal-mode the add-button content is displayed as separate toolbar
> group and the add-button is not present.
>
>
> *Explanation*
>
> Office applications by nature incorporate complexity. To allow unversed
> users to carry basic tasks, the UI has to be simple and straight forward.
> Advanced actions should be present – but easily ignoble.
>
> All displayed buttons are either expected to be there (save, copy, paste…),
> are needed to provide basic functionality (bold, text-size, left-align …)
> or are lesser accessed but handy actions (add-table, comment,
> page-settings...).
>
> The ruler is not displayed by default because it is an advanced feature.
>

--
Dr. Heiko Tietze
UX Designer
Tel. +49 (0)179/1268509


--
To unsubscribe e-mail to: [hidden email]
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
Thibaut Brandscheid Thibaut Brandscheid
Reply | Threaded
Open this post in threaded view
|

Re: Concept – Contextual Toolbar with Add-Button

On Thu, Feb 16, 2017 at 10:41 PM Heiko Tietze <[hidden email]>
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: [hidden email]
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
Heiko Tietze-2 Heiko Tietze-2
Reply | Threaded
Open this post in threaded view
|

Re: Concept – Contextual Toolbar with Add-Button

2017-02-17 15:30 GMT+01:00 Thibaut Brandscheid <[hidden email]>:
> On Thu, Feb 16, 2017 at 10:41 PM Heiko Tietze <[hidden email]>
> 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.

Disagree here as casual users may not be able to distinguish between
the new and open icons, have no clue what the pencil is good for (left
most icon above the font name), and will struggle with the right part.
Admitted that your layout is clean, better aligned, and space saving.

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

Forcing to do a clean design is good :-). Grouping without labels
shifts the comprehension of your design towards the user whether or
not she is able to understand what you had in mind. But of course I
would sign the grouping over labeling constitution if there is no
chance to have labels. So why not hide the labels when the screen size
is limited but show them by default?

>> ... only the most relevant features are present.
>
> ...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.

Accepted. The current design is based on usage data from the project
Renaissance (https://wiki.openoffice.org/wiki/Tracking_results or some
archive page).

>> 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.
>
> To help users with less sight there should be a high-contrast icon theme.

For users like me with a less defective sight of ~1-2dp it is rather a
lazy eyes thing when tiny differences of icons are not recognized at a
glance. And I don't want to use high contrast icons, rather a colored
theme. Or use labels.

Cheers,
Heiko

--
To unsubscribe e-mail to: [hidden email]
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
Thibaut Brandscheid Thibaut Brandscheid
Reply | Threaded
Open this post in threaded view
|

Re: Concept – Contextual Toolbar with Add-Button

On Tue, Feb 21, 2017 at 10:24 AM Heiko Tietze <[hidden email]>
wrote:

> Disagree here as casual users may not be able to distinguish between
> the new and open icons


I admit there is a problem, the icons are too similar, that's right.

have no clue what the pencil is good for (left most icon above the font
> name)


My argument here is, that someone has not to know all tools in a toolbox to
be able to do something useful with a toolbox, as long as the unversed user
is able to find his tools, all is fine.
The clone button has a pencil by convention → advanced office users coming
from other office suites expect the icon to look like a pencil (Microsoft
Word, Google Docs). The clone button is not targeted at Benjamin.

> 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.
>
> Forcing to do a clean design is good :-). Grouping without labels
> shifts the comprehension of your design towards the user whether or
> not she is able to understand what you had in mind. But of course I
> would sign the grouping over labeling constitution if there is no
> chance to have labels. So why not hide the labels when the screen size
> is limited but show them by default?
>

For the mock-up I decided against labels because I don't see them add much
value to the interface → they would clutter an already overloaded UI even
more. The only section where I see labels add value is for the last toolbar
group, because for the user it might be hard to grasp, that the section
content changes context-based.


> >> 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.
> >
> > To help users with less sight there should be a high-contrast icon theme.
>
> For users like me with a less defective sight of ~1-2dp it is rather a
> lazy eyes thing when tiny differences of icons are not recognized at a
> glance. And I don't want to use high contrast icons, rather a colored
> theme. Or use labels.
>

I selected the icons because I thought they somewhat look good, in the end
the design is more about to figure out what and what not to place on the UI
and how the buttons could be organized. For sure there is a lot of room for
icon-design improvements. Having a good distinguishable interface is very
important. Beside improving the shape, maybe the icons need to be bigger in
general. When the UI has a higher contrast (by shape/color) the UI should
also be more pleasant to view for people with normal sight.

For me a good UI:

* has as few icons/lines as possible (less content = less distraction)
* is grouped logically (makes finding actions predictable)
* does not distract the user from archiving is main goal (the UI should
accompany, not rule the content)

Seems like I should do another mock-up...

Greetings
Thibaut

--
To unsubscribe e-mail to: [hidden email]
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
Thibaut B. Thibaut B.
Reply | Threaded
Open this post in threaded view
|

Concept – Contextual Toolbar with Add-Button - Version 2

In reply to this post by Thibaut Brandscheid
Version 2 Mock-up:
https://drive.google.com/open?id=0B6yaM-XqO5AOVWVoSk5XZzl6Q1k

Changes:

* Changed the background color slightly of the context dependent area &
added a text label on the bottom.
* Stamped the color-picker into one button.
* New Add icon (user story: here is where the magic happens -> therefor the
wand as icon)
* Unified further the color usage in the toolbar. Main icons are most times
gray, additional context blue.

Any thoughts?

Greetings
Thibaut

On Wed, Feb 15, 2017 at 8:55 PM Thibaut Brandscheid wrote:

> 960 px low-width mode:
> https://drive.google.com/file/d/0B6yaM-XqO5AOUEQ5WC00SnpLTzg/view?usp=sharing
> 1280 px normal-width mode:
> https://drive.google.com/file/d/0B6yaM-XqO5AONDM4X3R4Q2YxUzA/view?usp=sharing
> Zip with GIMP files:
> https://drive.google.com/file/d/0B6yaM-XqO5AObnFSSFB6S1diLUk/view?usp=sharing
> (ctrl+shift+t to toggle show-guides in GIMP)
>

--
To unsubscribe e-mail to: [hidden email]
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
Heiko Tietze-2 Heiko Tietze-2
Reply | Threaded
Open this post in threaded view
|

Re: Concept – Contextual Toolbar with Add-Button - Version 2

To repeat what I commented directly at the Telegram channel: Great work! I like the minimal and screen-saving design. Without tooltips it's hard to understand the functions. And the right part looks a bit unfinished, guess the space will be filled when content is selected. The add icon is misleading as it looks like a wizard to me. And last but not least you could shrink the size even further by removing a few functions. Depends on the purpose of this idea.

On 03/02/2017 02:10 PM, Thibaut B. wrote:

> Version 2 Mock-up:
> https://drive.google.com/open?id=0B6yaM-XqO5AOVWVoSk5XZzl6Q1k
>
> Changes:
>
> * Changed the background color slightly of the context dependent area &
> added a text label on the bottom.
> * Stamped the color-picker into one button.
> * New Add icon (user story: here is where the magic happens -> therefor the
> wand as icon)
> * Unified further the color usage in the toolbar. Main icons are most times
> gray, additional context blue.
>
> Any thoughts?
>
> Greetings
> Thibaut
>
> On Wed, Feb 15, 2017 at 8:55 PM Thibaut Brandscheid wrote:
>
>> 960 px low-width mode:
>> https://drive.google.com/file/d/0B6yaM-XqO5AOUEQ5WC00SnpLTzg/view?usp=sharing
>> 1280 px normal-width mode:
>> https://drive.google.com/file/d/0B6yaM-XqO5AONDM4X3R4Q2YxUzA/view?usp=sharing
>> Zip with GIMP files:
>> https://drive.google.com/file/d/0B6yaM-XqO5AObnFSSFB6S1diLUk/view?usp=sharing
>> (ctrl+shift+t to toggle show-guides in GIMP)
>>
>

--
Dr. Heiko Tietze
UX Designer
Tel. +49 (0)179/1268509


--
To unsubscribe e-mail to: [hidden email]
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