This topic covers some general UI guidelines for developing applications with LabKey.

Button or Link?

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?"

  • If you're going somewhere, you're navigating, and links are traditional. This includes drilling down to another level of content, or going to another page to perform a related action.
  • If you're doing something, use a button. This includes committing changes to the database, sending a message, adding or removing fields in a form - something is functionally happening or changing, you're not just moving to another screen.

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 Labeling

  1. Be brief. Use an icon or one verb whenever possible (see the core button list below).
  2. Stick with the following "core" buttons as-is, whenever possible:
Button LabelActionShortcut Key
SaveCommit something new or updated to the database, and remain on the page.(key)
Save & CloseCommit 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)
DeleteRemove something from the database. 
RevertRevert to a previous state. 
CancelStop an action, discard all changes without prompting and return user to where they were before. 
ResetBefore saving, clear all entries or reset to defaults. 
AddAdd an element to the page or form 
UploadUpload files and data 
ImportPull data into a LabKey format 
ExportPush data out in another format 
InferReconciling data (?) 
ActivateToggle something on 
DeactivateToggle something off 
BrowseOpen a file browser window 
SearchInitiate a search query 
ReloadReload the page to refresh the view 
SendSend something somewhere or to someone 
RunExecute a script or process 
   
   

 

Button Positioning

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.

 

Using the Webpart Nav Menu

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:

  • Will this link be used by everyone?
  • Is the link specific to a function within the webpart, where proximity is crucial?
  • Is the link going to be used alot? Is it right in the path of action?

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.)

Notifications

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.

Discussion

Was this content helpful?

Log in or register an account to provide feedback


previousnext
 
expand all collapse all