Skip to content

Latest commit

 

History

History
138 lines (94 loc) · 5.72 KB

dialogs.md

File metadata and controls

138 lines (94 loc) · 5.72 KB
layout title category status tags
page
Dialogs
elements
ready
prompt
confirmation
error
modal
window

Layout

This section provides information on layout specifications for dialogs. Dialogs typically contain the following areas:

  • Title
  • Content area for instructional text
  • Footer for providing commit buttons

Alt text

Content Area

Single page dialog

The content area of a single page dialog should have uniform padding of 20px.

Alt text

Single page dialog example

Alt text

Multiple page dialog

For multiple page dialogs, the top and left padding should stay consistent at 20px. The right and bottom padding will vary between pages but the page with the largest content area should have 20px padding. The dialog should not change size between pages.

Alt text

Tabbed dialog

The tabs within a tabbed dialog will be flush against the window frame but the content of each tab should use the standard padding. The dialog should be as large as the tab with the most content. The dialog should not change size between tabs.

Alt text

Content controls & text

Alt text

Control Spacing

Alt text

Text spacing

Text is measured from the baseline of one line to the top of the capital letter on the next line.

Alt text

Footer

Control spacing

Alt text

XAML code snippet

This is a snippet of code for creating a footer in a dialog.

{% highlight xml %} <Grid.RowDefinitions> </Grid.RowDefinitions> <!—This is the main content section—>

<!—End main content section—>

<!--This is the footer section-->
<Border Background="{StaticResource NIBackgroundBrush}"  BorderBrush="{StaticResource NIGrayNeutral68Brush}" BorderThickness="0,1,0,0" Height="45" VerticalAlignment="Bottom" Grid.Row="1">
    <StackPanel Orientation="Horizontal" VerticalAlignment="Stretch" Margin="20,0,10,0" HorizontalAlignment="Right">
        <StackPanel.Resources>
            <Style TargetType="{x:Type shell:ShellButton}">
                <Setter Property="Margin" Value="0,0,10,0"/>
            </Style>
        </StackPanel.Resources>
        <shell:ShellButton Content="Fake button" Height="24" MinWidth="70" Padding="10,0,10,1" />
        <shell:ShellButton Content="Close" Height="24" MinWidth="70" IsCancel="True" Padding="10,0,10,1" />
    </StackPanel>
</Border>
{% endhighlight %}

Don't show this (item) again
Provide this option to allow the user to ignore a recurring dialog box when it is the only option. Try to eliminate the need for the dialog, if possible. Set the value to false by default.

Alt text

Commit buttons

Selecting which commit button to use

Label When to use
OK Applies the changes or commits the task and closes the dialog.
Don't use for error messages (errors are never OK). Instead, use Close.
If a dialog performs a specific task, use a specific label convention [Do it / Don't do it] instead.
Don't use to respond to questions.
Apply Applies the pending changes but leaves the dialog open.
Yes / No Response to Yes⁄No questions.
Must always be in a pair.
If phrasing a specific response is long or awkward.
Don't use if the meaning of No is unclear.
[Do it] ⁄ [Don't do it] When you can provide specific button labels.
Cancel Discards all changes, reverts to the previous state with no side effect, and closes the window.
When all pending changes or actions can be discarded and side effects undone.
Don't use if the meaning on Cancel is unclear.
Close Closes the window without discarding changes and side effects.
When users can’t make changes, such as informational dialogs.
Stop Stops a currently running task and closes the window.
When work in progress can't be discarded. Typically used with progress bars.

Order of commit buttons

For Windows OS, the order of the commit buttons are:

  1. OK ⁄ [Do it] ⁄ Yes
  2. [Don't do it] ⁄ No
  3. Cancel ⁄ Close
  4. Apply (if present)

Using Help commit buttons

Do not use generic Help buttons, if possible. Strive to give user contextual content when/where they need it instead of using a generic Help button. Put the Help button last if it is unavoidable.

When to confirm commit buttons

Generally, commit confirmations are unnecessary and annoying. But confirming a commit may be appropriate if the action is potentially catastrophic and/or might result in a significant loss of user data, time, or effort.

Miscellaneous

Close button on the title bar must have the same effect as clicking Cancel or Close. Don't include instructions in the text, such as “Press OK to continue”, or “Cancel to stay on the current page”. Instead, use specific commit button labels or change the text.