Design guideline
-
an action button should always do the same action, not a slightly different action depending on the conditional content of the page (at least if there are no strong reason to do that)
- e.g. of a wrong behavior:
if something is selected apply the action on the selection else if nothing is selected apply the action on all -
an action button with no reversible action should always have a confirm dialog alert to prevent click errors
-
an alternative option to skip the confirm dialog alert would be to depend on some condition/selection the user should have done voluntarily before clicking the action button
- e.g.:
if something is selected the button is enabled and can be clicked else if nothing is selected the button is disabled
Note : an objection can be attempted against the 2-clicks-way to go instead of just 1-click and go, but because of rule 1. and 2., either having a
1. select-all click
2. then click on the action button
or
1. click the action button with no selection to apply on all items
2. then click on the confirm dialog alert button
it will always be a 2-clicks-way to go
See this http://getbootstrap.com/css/#buttons-options
-
green: call to action, save action, send form -
yellow: warnings (very rarely used in a button) -
red: errors, deletions -
gray: close, cancel, download... side options that we dont need to highlight -
blue: info, help
Note : the set of colors is just an example
Bootstrap upstream default guide source
-
green: successfullness of an action, form submitted correctly, action performed as expected -
yellow: warnings of something to be fixed to continue (e.g. an empty field in a form) -
red: errors, failures of a performed action or a form submission -
blue: static info, help, not a feedback response of an action/submission [1]
[1] The blue bubble is meant to be a static information to be shown during the load of the page and to stay there, not a feedback from the server after applying an action or submitting a form. Whenever there is an interaction from the user to the server via the GUI, a feedback message is supposed to reflect the status
- success :
green, - warning :
yellow, - error :
red
Use the {info:
blue} only for delivering a non-action-related information
Yes, but only in case of a success feedback. If it is a warning or error message, it is not supposed to be removable/foldable because it means an action is needed before moving forward with the attempted action or something dangeous happened and need permanent attention.
The aimed behavior to chase is to have a counter for same messages that gets incremented. In case this is not possible, a limited number of messages can be shown. Default SUSE Manager/Uyuni number is fixed to 3.
Yes, it can scroll with the normal page scrolling unless the message is a highly important/dangerous information that cannot be overlooked.
A nice to have behavior is to show first the bubble message at the pointer position where the click happened (or where the cursor still is), but then on scrolling it can be moved at the normal bubble-placeholder and scroll with the page by default.
A feedback message is meant to deliver a usefull information to the user, and as a plus, if it can drive the user to a certain action directly, it is highly recommended to present links in order to lead the UX. It is highly recommended to not present links or call-to-actions if this cannot be well defined to ensure to not get the user confused.
Every column should be sortable by clicking the header cell name. Sort criteria can differ depending on the data listed in that column
Filters should be applicable to the table content view:
- if possible, one single shared filter to be and applied on every column
- if not possible, split filters into single ones only for special column cases