Design/old guideline
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
 |
This page was marked as inactive and is retained for historical reference.
|
Refer to the latest GNOME HIG for things not listed here.
Designs must also abide by all our UX Principles.
Style
Non-native Theming
Mockups
Proposal for tabs in Impress
Proposal for sheets in Calc
Proposal for headers in Calc
Usage
Non-native theming should be used:
- For widgets that don't have an equivalent in the standard toolkit.
- When native theming feels out of place.
- Example: The current tabs in Impress awkwardly float in space.
- When native theming doesn't fit in with the platform.
- Example: The native Windows Vista/7 menubar and toolbar background is glossy, yet most Microsoft's own applications use a smooth gradient background for toolbars instead.
Design
The theme should fit well with the default icon set. Currently, that means non-native elements should use Tango colors, smooth gradients, and try to conform to the Tango lighting guidelines.
Building Blocks
Window
The minimum window size should be one under which all of the content is accessible, important content is easily accessible, and all visible UI elements are decipherable.
The minimum window size must be equal to or lower than the minimum supported screen resolution, which is 640x480 px. The UI must be modified to adapt to window size if that's needed to follow the guideline above.
Targets
Targets should be large enough to fit:
- a 6x6px square for a mouse target
- the arrow button in the spinbox in the current theme for theme-dependent controls
- a circle with a 7mm diameter for a touch target, an 8mm diameter for thumbs
- a circle with an 8mm diameter for a touch target together with its margins, a 10mm diameter for thumbs
Infobar
Mockups
- Infobar offering solutions
- Infobar just informing
- Stacked infobars
Usage
The infobar should be used to offer possible remedies to problems related to the current document, or at least to give information about them so that the user can remedy them himself. The actions found in the infobar must be accomplishable in another part of the user interface.
When a problem prevents basic interaction with the document, use a dialog instead.
Examples
Valid applications:
- The user doesn't have spell-checking support for the used language installed.
- There's no hyphenation support for some text due to the language used.
- Pictures linked to external webpages render slowly or not at all based on the internet connection.
Invalid applications:
- A new version of LibreOffice is available. Not document-related, would violate ux-natural-mapping and ux-interruption.
- User surveys are available. Same problem.
- Document is being saved in a lossy file format. This could lead to data loss, so a dialog should be used instead.
Contents
Every infobar should contain the following:
- 22x22 icon: This icon should represent the context of the infobar and should indicate where else in the UI the user can find the presented actions.
- Terse description
- If LibreOffice can offer problem solutions, then include:
- Action question
- Actions
- A "More info..." button if necessary
- If LibreOffice can't solve the problem itself, offer a "More info..." button
- A "Dismiss" button to leave the document as is
Layout
The infobar should stretch across the entire width of the window, below the top toolbars and above the document area. It should be organized into rows with the height of a standard button size and a 6px margin. Contents would be organized into three columns, with the first column reserved for the icon in the top left corner, the second for the text and buttons, and the third for the "Dismiss" button in the top right corner. Multiple infobars would stack.