This is an outline for best practices to make an application fit in well with other applications consistently in the dashboard. Consider this the go-to resource for any examples or guidelines. If an application does not reflect something shown in these guidelines, it is likely outdated and should be updated to match.
In most cases, paddings and margins should be set to 15px (in any and all directions). This is because Bootstrap defaults to 15px. Deviation from this rule should be rare.
A "blank slate" is when you have an empty space, but no actions or messages for the user to let them know how to proceed.
For example, the following is a bad example of how to handle an empty table.
| Header 1 | Header 2 | Header 3 |
|
|---|
Prefer to tell the user something, like so.
| Header 1 | Header 2 | Header 3 |
|
|---|---|---|---|
|
You currently have no data. Click here to add some.
|
|||
This applies to more than just tables (wells, drag & drop zones, etc), but the general idea is to let the user always have something actionable, so they don't assume empty space = bad space. In the example above, the "here" in "click here" and the "Add New" button do the same thing.
Buttons are pretty important, given that they're everywhere. Using them properly is also important, so as not to confuse users.
Button naming is good to keep consistent, so a user can associate button text with what the action behind the button is. Below is a listing of common actions and the labels associated with them.
| Label | Action |
|---|---|
| Submit | Insert |
| Update | Update |
| Remove | Delete |
Coloring buttons consistently and effectively can help a user navigate an application much more easily. Only the built-in Bootstrap colors should be used for this task, since those can be changed with a variable. Using custom colors will only lead to inconsistency down the line. Generally, colors should go similar to the table that follows.
| Label | Color | Example |
|---|---|---|
| Submit | .btn-primary |
|
| Update | .btn-info |
|
| Remove | .btn-danger |
|
| Close / Cancel | .btn-default |
|
There is no mention of .btn-success because there aren't really any situations in which it is appropriate.
Any unmentioned action is likely a .btn-info action.
Every button that has destructive or unrecoverable repercussions (delete, remove, etc) should have a confirmation dialog attached to them. If a button has to make an HTTP request, or has to wait to get a response before the action is completed, it should disable itself to prevent duplicate submissions. Where applicable, it should also block other actions on the page until the request completes.
Button groups are an often-used component (for example, an on/off switch, or a multi-select with <5 elements). As such, it's pretty important to color them appropriately. Even though I personally disagree with it, supposedly, the default Bootstrap coloration is too difficult to differentiate selected and unselected buttons. As a result, inactive choices should be greyed out. The following is a bad example.
The following are good examples.
Tables are everywhere and should be handled consistently everywhere.
Buttons should always be placed in the rightmost column of tables. They should also always be aligned to the right. Buttons inside of the table should not have text in them, due to wrapping / space concerns. If the table requires a "new" action, that should be placed in the header, alongside the other headers, so as not to be off in its own space.
| Header 1 | Header 2 | Header 3 |
|
|---|---|---|---|
| Data 1 | Data 2 | Data 3 |
|
| Header 1 | Header 2 | Header 3 |
|
|---|---|---|---|
| Data 1 | Data 2 | Data 3 |
|
Buttons are typically ordered from left to right, with the most destructive actions being farther away (ie, on the right). This is different from modals, where the more primary actions are on the right! The reason for this is because users will typically move left to right in a table, but most confirmation actions in a modal are on the bottom right.
| Header 1 | Header 2 | Header 3 |
|
|---|---|---|---|
| Data 1 | Data 2 | Data 3 |
|
| Header 1 | Header 2 | Header 3 |
|
|---|---|---|---|
| Data 1 | Data 2 | Data 3 |
|
The number of columns should be limited to 4 data columns (not counting buttons). Anything extra should be shown in an "info" popup. Normally the information popup doubles as an editing interface for convenience.
| Header 1 | Header 2 | Header 3 | Header 4 | Header 5 | Header 6 | Header 7 |
|
|---|---|---|---|---|---|---|---|
| Data 1 | Data 2 | Data 3 | Data 4 | Data 5 | Data 6 | Data 7 |
|
| Header 1 | Header 2 | Header 3 |
|
|---|---|---|---|
| Data 1 | Data 2 | Data 3 |
|
Forms are everywhere and should be made consistent.
All inputs should adhere to a few basic style rules. Primarily, they should always have placeholders.
However, there are some layout issues to be addressed too. Inputs should always have a label to their left,
and they should be laid out such that the label is in a .col-md-3, with the input in a .col-md-9.
When validating inputs, required fields should be encompassed, when empty or invalid, with a red border. Bootstrap has .has-error for this.
Modals are everywhere and should be made consistent.
Modals should always have multiple close buttons (one in the top right, one on the bottom) to allow users to close however they feel inclined. Buttons should have the most primary action on the right (ie, confirm, update, etc), with the close button always being on the left. Modals should also always have a title! No title means no context for the users.
Icons are everywhere and definitely need to be made consistent.
Anything that is supposed to be clickable should have have cursor: pointer; set.
Bootstrap does this with many things by default, but there are times when some considerations still have to be made.
v-icon is a directive that simplifies icon usage and consistency across every application.
Currently, there are plenty of actions defined here.
Sample usage is below.
<v-icon fw="true" icon="actions.remove">
This will expand to the following:
<i class="fa fa-trash fa-fw">
To understand the expansion, note that actions is a key in the root object, and it has a property remove that is set to 'fa fa-trash'.
You can specify the fw option to get a full-width icon. Doing so is recommended for situations where buttons (or icons) should be the same width.
It is important (and easier!) to use these icons for common actions such as adding, removal, editing, and anything defined in the list above. This exists simply to provide a simple mechanism for changing icons en masse later. Obviously, not all icons will be defined here. In those cases, using discretion is a wise choice for picking icons.