Design/old guideline

    From The Document Foundation Wiki

    This page was marked as inactive and is retained for historical reference.
    Either the page is no longer relevant or consensus on its purpose has become unclear. To revive discussion, seek broader input via a forum such as one of our mailing lists.

    Refer to the latest GNOME HIG for things not listed here. Designs must also abide by all our UX Principles.


    Non-native Theming



    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.


    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


    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 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 offering solutions


    Infobar just informing


    Stacked infobars



    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.


    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.


    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


    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.