Toolbars are a common toolkit control that have been around since the dawn of GUI applications, providing direct access to an application’s most frequently used functions. But with increasing scope, the number of frequently used functions grows to an extent that can have a detrimental impact on quickly locating a particular item.
Human perception is limited, but we are perfect in the processing of information. Pieces of information are stored together and build a mental model. In case of the classic toolbars, you likely know where to look for the Undo and Redo buttons, not precisely but approximately, and also remember a few functions next to these buttons. This ‘chunking’ is supported by the elaborated grouping of buttons and with separators between them. But sometimes those tiny features are not enough to convey useful information to the user.
Some attempts have been made to overcome this problem; for example LibreOffice has done it before with the Sidebar and is doing it again with another approach. We’ve implemented a toolbar, that we call the Notebookbar, as a blank canvas where designers have all the freedom to do whatever they want with the space.
With a blank canvas, a designer can place any UI widget on it, including the usual buttons with or without a label, a section label to identify the group of controls, or more advanced widgets like tabs. They also have the ability to define any dimension for buttons, so they serve as a visual attractor, and all together have a larger catalog of controls to choose from than couldn’t be found in classic toolbars. Furthermore, they can define that the main menu can be hidden, or whether it should have a particular icon theme, for instance.
Of course the classic toolbars will still remain and are enabled by default, so don’t be afraid of radical changes. Users interested in trying out the Notebookbar will be able to opt-in and will be able to try out multiple different implementations.
For the contextual groups implementation, the Notebookbar is split into labeled sections (similar to classic toolbar separators but more prominent), i.e. file operations, clipboard interactions, text formatting functions, and a context dependent section. Last but not least a small section for configuration of the toolbar itself at the right.
Three icon sizes are utilized: large icons with a label below being a perceptual attractor for the most important section interactions. Furthermore medium sized icons, two in a column, and small icons with three positioned together. Since this layout targets beginners, we label all buttons.
Figure 1: Notebookbar in the contextual group layout.
The contextual groups Notebookbar aims for consistency, which means also that it has to be as static as possible. Thus, Formatting remains available in all contexts, but gets disabled for objects like images. We also want to promote styles as the primary formatting tool. Having large icons for this leads the user to this function, which is not only valid for text (big A in the mockup at the formatting section) but also other objects such as tables (big T for table styles which have been introduced recently). To bring this idea more forward, we added an image style here having color modes like grayscale or watermark in mind.
Of course, the price to pay for various sized icons and text labels is limited space, and we had to remove some functions. That includes, among others, Find and Replace, Spellchecking, Non-Printing Characters, as well as Insert page breaks, Fields, and Special characters. Some could be added into the tools section, wherein the chevron indicator (») exemplifies how small screens or resized main window would behave in case of more content. But basically this variant of the Notebookbar is designed for beginners or simple tasks and should be as plain as possible.
Another challenge is to find good labels that are short enough to fit into the section. In the Chart contextual section, some labels were shortened, for instance Horizontal Grid, Data Table, or Format Selection. This section also has chart styles in a similar place as the Table and Image sections.
The goal is to have various toolbars for different users and scenarios, at best easily user-editable, and the user choose the appropriate at the right hand configuration section. It has (unlabeled) access to the configuration, a drop-down selection with a label below what is active.
Not only consistency at the different contexts is our goal but also familiarity over the programs. The Notebookbar for Calc and Impress looks very similar compared to Writer.
Figure 2: Notebookbar for Calc and Impress.
Likely a context dependent section is not necessary for Calc and Impress – chart manipulation, for instance, is available in the sidebar. The idea of animation and transition for Impress is to show the recently used options in this drop-down only, five or so, that overrides the factory setting.
In case of Draw the focus is not the formatting of text but to position objects. While text can be added to almost all objects, the formatting is rather relevant for a text box. And even when a text box has no styling capability today the context dependent section would ideally correspond to what is known from Writer.
Figure 3: Notebookbar for Draw.
As discussed in the introduction, we can also place tabs on the Notebookbar. This layout occupies a similar space as the main menu (which is hidden with this layout) and classic toolbars and organizes all menu functions across the tabs. An implementation similar to the single line toolbar is also possible, which can be contextual and horizontally centered.
Figure 4: Notebookbar in tabbed mode.
And of course it should also be possible to set-up configurations where the Notebookbar focuses on a special workflow like scientific writing.
Figure 5: Notebookbar in scientific writing mode.
Some crazy ideas were made in the community how the UI may look in a bright future. While it was far-fetched at the time being created the Notebookbar allows also these fancy configurations now.
Figure 6: Mockup by T6Uni (CC by SA 3.0).
The only limit is your creativity and the available list of functions known as ‘uno:commands’.
At this year’s Google Summer of Code, the Notebookbar was worked on by Szymon Kłos (aka eszka), continuing the development begun by Jan Holešovský (aka Kendy) and Samuel Mehrbrodt. We also made some configurations, that is the contextual group presented here as well as a contextual single line variant and the tabbed version. The flexibility of its development will allow the easy creation and testing of multiple implementations during the development cycle, something that wasn’t possible during OpenOffice.org’s Project Renaissance days.
The current implementation is in an experimental state, which means that you will have to unlock the menu entry first. This allows to switch the toolbar mode under View > Toolbar layout to Notebookbar. While the mockups have a dedicated section for the configuration that also allows to quickly switch the mode, this feature has not been finished yet. The modes are switched under View > Notebookbar.
Some of the implemented controls do not work perfectly, in particular that toggle buttons don’t appear toggled unless they are hovered over, drop-down menu lists are sometimes not filled or have entries that don’t function, section headers can’t be styled to have a good background color, and accessibility needs improvements (tdf#102059).
The classic toolbars are customizable and users can add or delete items from the pool of functions. This option is not available for the Notebookbar in this first stage of development; the only means of configuration is to deal with the Glade UI files. Eventually we hope to have a similar customization option like we have in Tools > Customization or we may possibly have an inline UI edit mode similar to what Mozilla allows for Firefox.
We are looking forward to your comments and ideas on how to configure a collection of toolbars. With a good set of options the individual configuration is less relevant.