This topic covers some general UI guidelines for developing applications with LabKey.
Buttons and links can provide similar functionality. When trying to decide what to use, ask yourself:
"Am I going somewhere? Or, am I doing something?"
What about popup windows? You're doing a next step, so launching with a button makes sense.
What about hover content (panels, tooltips, etc)? These can be activated with buttons or links. Sometimes "additional info" or "help" panels are activated with a "?" button or link.
| Button Label | Action | Shortcut Key |
|---|---|---|
| Save | Commit something new or updated to the database, and remain on the page. | (key) |
| Save & Close | Commit something new or updated to the database, and go to the next logical page, a summary view of the data entered, or if neither of these exist, to wherever the user came from before. | (key) |
| Delete | Remove something from the database. | |
| Revert | Revert to a previous state. | |
| Cancel | Stop an action, discard all changes without prompting and return user to where they were before. | |
| Reset | Before saving, clear all entries or reset to defaults. | |
| Add | Add an element to the page or form | |
| Upload | Upload files and data | |
| Import | Pull data into a LabKey format | |
| Export | Push data out in another format | |
| Infer | Reconciling data (?) | |
| Activate | Toggle something on | |
| Deactivate | Toggle something off | |
| Browse | Open a file browser window | |
| Search | Initiate a search query | |
| Reload | Reload the page to refresh the view | |
| Send | Send something somewhere or to someone | |
| Run | Execute a script or process | |
When placing buttons, use the following decision tree:
1. first choice: directly below the related fields or form, especially if there is more than one form element (i.e. several text fields, radio buttons, etc that are processed together – button should appear directly below)
2. second choice: to the right of the field or form, especially when there is only one form element (i.e., webpart dropdown, single search field) or it makes sense to directly relate the button to the form element (i.e. a Browse button by text field)
3. third choice: if there is a long table or form that requires scrolling, buttons may appear at the top and the bottom so the user has quick access in either direction.
In addition...
When placing buttons side-by-side: Leave xx pixels of space between each button to minimize the chance of clicking the wrong choice.
When placing the "Cancel" button: Always place to the right of other buttons, so "Cancel" is always the last (rightmost) button in a group.
Use this component to reduce the number of text links within webparts, cleaning up the visual display.
What goes in a webpart nav menu... or, what remains a link? Where webpart menus are concerned, it might be easier to think about what *doesn't* go in a menu. When placing a text link, ask:
If a link can pass these tests, it might be appropriate to leave as a link, always visible, outside the menu. Otherwise, consider moving as many text links as possible into a logical menu system.
How to word the menu items: Like buttons, use words as sparingly as possible. If you're tempted to add words, ask: do they *really* provide clarity, or differentiation between similar menu items? If not, resist!
If you do write multi-word menu items, follow standard headline/subhead style, i.e. capitalize all major words while leaving prepositions and conjunctions lower case ("at", "the", "and", "but", "to", etc.)
Its definitely a good thing to let users know what's happening. Here are some general guidelines:
Navigating away: If the user tries to leave a page with unsaved changes, the UI should prompt the user with an alert box and opportunity to save first.
Required Fields: When a form field is required, place a "*" next to the field names and note at the bottom of the form: *=required.
Error messages: Error messages should appear within the visible region of the window, and should be comprehensible to non-developers. Ideally, provide suggestions about how the user might correct the error.
| previousnext |
| expand allcollapse all |
