Design/Guidelines/PropertyDialog

    From The Document Foundation Wiki
    < Design‎ | Guidelines(Redirected from Design/PropertyDialog)

    TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate


    In general, a dialog is a secondary window that allows users to perform a command, asks users a question, or provides users with information or progress feedback. Dialogs can be modal and require users to complete and close before continuing with the owner window, or modeless, i.e. users can switch between dialogs and parent window. This guideline does not cover OS specific dialog such as open/save files. And it’s not about confirmation dialogs that just ask a simple question with a few answer options, e.g. Yes/No/Cancel.

    General

    • Present a comprehensive set of properties regarding the referenced context.
    • Make property dialogs modal. For uninterrupted workflows, the toolbar and sidebar should be used.
    • Use controls for selection depending on content.

    Organization

    • Do not include a menu bar or status bar in dialogs.
    • Always keep dialogs on top of their parent.
    • Set input focus on confirmation button by default except in case of undo-able actions.
    • Provide the disruptive buttons Help, Reset, Ok/Apply, Cancel by default. But keep the system default as best as possible and place Ok/Cancel according the OS.
    • Do not nest multiple dialogs.
    • Design property dialogs to not require the use of a scroll bar.

    Appearance

    • Dialogs should work with a size of 800 × 600 pixels and should not be resizable. Take care about high resolution displays (i.e. QXGA and more).
    We decided to make dialogs non-resizable as they are controlled by the content. However, if the dialog provides controls with user input that might exceed the designed width or height, eg. lists, edit fields etc., the dialog should be resizable.

    • Do not overload the dialog and make sure there is at least one third white space.
    Too many controls makes it harder to understand the workflow. White-space helps the user to find the way through the controls.
    • Consider the common reading direction from left to right and top to bottom.
    Start with most important controls on top-left and continue according the workflow.
    • Ideally, the dialog has a 3-column layout with presets, properties, and preview. If that's not appropriate, prefer a single column layout. Add a second column in case the content exceeds the vertical space.
    Figure 1: Three-column layout left and two columns right
    Figure 1: Three-column layout left and two columns right
    • Use GtkFrames to group the content in meaningful sections. Make the frame label’s weight bold.
    By using frames the layout becomes more consistent.
    • Name controls consistently.
    Consistent naming makes the identification easy, in particular with sizegroups. For example, use lbLabel1, lbLabel2… with lb* for GtkLabel, cbCombobox1, cbCombobox2… with cb* for GtkComboBox, spSinner1 etc.

    Alignment

    • Use a spacing of 6/12 for frames, 24 to separate columns, and 3 for related controls.
    White-space between sections respectively a close distance between two UI elements provides valuable information for the user. The same is true for indentation of underlying controls that needs to get enabled first. The consistent spacing makes this rule intuitive for the user.
    Figure 2: Use a spacing of 6/12
    Figure 2: Use a spacing of 6/12 (ressource)
    • Do not add margins to controls; use the spacing of containers.
    Margins spoil the basic layout of the dialog. If you think some more pixels are required better consider a redesign.
    Figure 3: Do not add margins; the alignment of labels is done with the spacing of the container
    Figure 3: Do not add margins; the alignment of labels is done with the spacing of the container
    • Size numeric controls such as GtkSpinButton together and size textual controls such as GtkComboBox together but do not put numerical and textual controls in the same size group.
    Textual content can be much larger than designed, for example when it’s translated. If numerical controls are sized similarly it may become ridiculous large.
    Figure 4: Numeric controls should not size with textual; the right example falsly assumes the combobox items to stay short
    Figure 4: Numeric controls should not size with textual; the right example falsly assumes the combobox items to stay short
    • Align controls across frames.
    Use sizegroups if the container does not provide proper alignment.
    Figure 5: Labels of Frame3 and Frame4 are joined in a sizegroup
    Figure 5: Labels of Frame3 and Frame4 are joined in a sizegroup

    Text

    • Add a colon after labels that have a relation to buddy controls. Do not add colons at section headers (GtkFrame).
    Figure 6: Colons denote the relation between caption and buddy control
    Figure 6: Colons denote the relation between caption and buddy control
    • Ensure proper accessibility by enabling “use_underline” with the ”mnemonic_widget” as target control. In case of widgets without label like a GtkCheckButton, the a11y "Label For" and "Labelled By" properties should be used.
    Learn more at Accessibility for Developers.
    • Provide tooltips for unlabeled controls or when the label doesn't make the function perfectly clear.
    • Always left-align labels. Phrase the text so captions have similar length.
    There are advantage for both, right and left aligned labels as well for placing the caption above the control. While right aligned fits better for labels with different width, the left alignment supports reading. Plus, dialogs looks cleaner and more familiar. We decided to use left-alignment.
    Figure 7: LibreOffice uses left aligned labels
    Figure 7: LibreOffice uses left aligned labels

    References

    Retrieved from "https://wiki.documentfoundation.org/index.php?title=Design/Guidelines/PropertyDialog&oldid=522850"