HIG: Dialogs

Modal dialogs in Cockpit should have consistent behavior. These are the Human Interface Guidelines for dialogs.

Look

Dialogs should be implemented as Patternfly modals.

This section is incomplete...

General Behavior

• Make primary input field got focused when the dialog shows up. Primary input field is usually the first input field which needs required input contents.
• Support Enter key for input fields and primary buttons in the dialog. (To be determined)
  1. Primary button is the button used for finishing the function of the dialog, is usually an affirmative button.
  2. If there is only one input field, pressing Enter key behaves the same as clicking primary button.
  3. If there are more than one input field, pressing Enter key moves the focus from the previous input field to the next one sequentially. When the last input field gets Enter key stroke, it behaves the same as clicking primary button.
• Support Tab key for all interactive elements, the sequence of tab indices should be determined according to the positions of the elements, from top to bottom, from left to right.

Operation Behavior

• The dialog operation happens with the dialog still open.
• Clicking the affirmative button starts the operation.
• While operation is happening, a spinner is displayed on left-hand side of the buttons.
• While operation is happening, everything in the dialog is disabled, except the Cancel button
• Clicking the cancel button during the operation cancels both the operation and closes the dialog.
• If the operation completes successfully, the dialog is closed.
• General (non-validation) errors are displayed in a patternfly alert above the dialog buttons, the dialog remains open, and controls become enabled again.

Conceptually some dialogs begin a long running 'job' or 'task' (like Formatting a disk). The dialog's operation is considered comtplete once that job is created and displayed appropriately (usually in other UI).

Input validation

• Fill out defaults where possible, for example name of a container, network bond, container etc.
• Put the fields that are required closer to the top
• Validate based on a set of conditions linked to their respective fields, for example:
  • Some action needs to be taken, for example: choose at least one disk
  • Invalid characters in a field
• Check for errors on form submit
• Show error messages directly below the input fields
• Messages should be as specific as possible and offer solutions if possible
  • Example: character "@" in "user@cockpit" not allowed, you could use "user_at_cockpit" instead
• Avoid reflow: use visibility: hidden to hide errors once a field linked to its condition has changed
• Remove the error for the condition on next submit, re-check

Example

See also

https://www.patternfly.org/wikis/patterns/pattern-development/draft-patterns/forms/#validation