Area fill options made consistent

Introduction

As in many other dialogs, Libreoffice provides a lot of functionality for tweaking the hell out of areas taken up by shapes, charts, frames, etc. You can have a solid background color, with or without transparency/opacity, you may fill areas with gradients that in turn have several options, it can be assigned to hatchings, patterns and bitmaps, each with numerous options again, etc.

Area settings may be done in its own dialog, for instance when you add a shape and start the area properties dialog from context menu, or as part of a style such as paragraph style where area has a tab with similar but not equal features.

Putting all peculiarities together, the area settings needed some love by the UX team.

Issue

• Current tab is not intuitive due to its dynamic content
• Controls are not appropriate to the function, e.g. color drop-down vs. color picker
• Some of the newly introduced features for the sidebar are not available
• All-in-one area tab for modifying object fill (tdf #94551) is needed

Current State

Figure 1: Area fill dialog with several functions.

To revisualize the current state just add a shape, right click it and choose Area from the context menu. In figure 1 the basic access to options via drop-down is shown in the Area tab. Please also take a look at the different tabs and notice the difference to the basic settings.

Solution

Our proposal is an evolution to the existing dialog, without the loss of any features. First of all, we have two basic levels of navigation: the parent options from paragraph style, for instance, plus the general access to shadow and transparency, both relevant for all types of area fill, and the kind of filling such as none, solid, gradient etc. These two levels need to be represented in the dialog by different controls: tabs (as today) for the parent options and toggle buttons for the area specific settings.

In order to harmonize the dialog layout and the workflow we propose to have always access to a couple of preset. The details for the selected preset (respectively the referenced object when the dialog is being opened) can be changed in the content area (Options). Users may save changes as new presets that would be available in other documents. And as third part of the UI there should be a WYSIWYG preview.

Figure 2: Concept for the user interface.

• Selection of type of area fill (none, solid, gradient…) per toggle button
• Left columns with
  • Presets, along with functions to add/delete user-defined options
  • WYSIWYG preview
• Right client area with options to tweak all properties
• Common functions for dialogs plus Apply, which adopts the settings to the document while the properties dialog remains open

An alternative layout could focus on the preview. Not only the presets get more space but also the preview has its own column.

Figure 3: Alternative UI concept with focus on the preview.

The drawback of this solution is that a) resizing more than two areas is awkward (although these types of dialogs wouldn’t be resizable), b) the space for the content area would be reduced in favor of the preview, and c) such a layout wouldn’t be an option for a default solution (we try to have a default layout that makes dialogs familiar). The two-column solution leads to more whitespace in the content area, which is not bad from the design and usability perspective.

Advantage of the three-column solution is that some types of area fill do have only a few options. The space is occupied better. And since the preview has a separate column it’s more in the focus.

Solid fill

Figure 3: Mockup for solid setting (two-column layout left hand, with three columns at right).

• Palette comprises of colors from the default palette selected below
• Active shows the actual color as in the referring object, or is empty/grayed out in case of a non-solid style
• New shows the color that is being modified on click via default color picker
• Both active and new allow also to read and set RGB or hex values

Gradient

Figure 4: Mockup for gradient setting.

• User may choose from one of the predefined gradients
• Options allow to modify
  • stops including color and opacity (the number of stops define how many colors are used in the gradient; with offset or the visual equivalent of sliders the slope of those colors/stops my be changed, for instance to configure a perfect sundown with small portions of yellow and red and larger in blue)
  • increments (aka sampling points) that define the final resolution of the gradient
  • the style how this gradient affects the area along with secondary options such as center, angle and border

Hatching

Figure 5: Mockup for hatches setting.

• Layout should be self-explanatory
  (Having a dedicated widget to enter angles as today (that are not adopted to the exact value input) seems to be an overkill)

Pattern

Figure 6: Mockups for pattern setting.

• Patterns are created by toggling color bits on/off
  (Currently, the pattern editor is placed at the bitmap section, available when the image is set to ‘blank’- this is a prefect example for inconsistency)

Bitmap

Figure 7: Mockup for bitmap setting.

• Users can select from the standard bitmaps or load own images
• Options how to place a bitmap (such as size, position, repetition etc.) are shown today only at the first area tab, and with a mutual dependency that is not very intuitive
• Suggestion is to have some kind of wallpaper-like placement, which might be a restriction in a few cases

Sidebar

Figure 8: Mockup for area section in the sidebar.

Of course, frequently applied properties should be available from the sidebar. But it make no sense to replicate each and every setting here; and the controls should also get adopted to the specific use case- that is to quickly change a property. That’s why we suggest to have a picker for recently applied colors and gradients only- but with easy access to the dialog where all options are available. (If there is no recently applied property the predefined set of colors and gradients is shown.)

By the way: that’s the way the sidebar is supposed to work in general.

Discussion

Open for discussion is the question if there is need for more quick-access features at the sidebar. If people often switch between, for instance hatching and solid area fill, we would need to add another row to the sidebar. On the other hand if only a minority benefits from such a control it’s better to keep the sidebar clean. And of course we want to hear your opinion about two or three columns.

What do you think about the changes? Is there anything missing. Discussing changes before the implementation starts makes it easier for developers and allows to improve code quality. So feel free to add your thoughts.