Design/old guideline

From The Document Foundation Wiki
Jump to: navigation, search


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

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

Font1.png

Infobar just informing

Font0.png

Stacked infobars

I-stacked.png

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.