UI Guide

UI examples

Autosave example

Continous Save with a continuously changed document (i.e. Wiki)

Have save time information and button just in case. Similar to Google Docs.

Last Saved: 2 minutes ago.

Save on Input control change

Show change alert that disappears after about 3 seconds.

Changes saved!

When you should NOT autosave:

  • If the edit is highly sensitive, never autosave. The extra step of saving adds a level of security.
  • If the edit is going to be public immediately think about implications. The step to save gives users a moment to revise.
  • When intermediate changes being applied would alter the layout or page. For example selecting to hide certain elements in a settings page should not hide those immediately and move the page around, resulting in the user losing location.
  • When one edit is related to another edit that is yet to be made. I.e. when the edit is not independent.

Feedback examples

Form validation

Use existing Bootstrap style to communicate errors related to forms. Don't use Growl notifications. Learn more here.

A block of help text that breaks onto a new line and may extend beyond one line. 

<div class="form-group has-error">
    <label for="inputHelpBlock">Input with help text</label>
    <input type="text" id="inputHelpBlock" class="form-control" aria-describedby="helpBlock">
    <span id="helpBlock" class="help-block">A block of help text that breaks onto a new line and may extend beyond one line.</span>
</div>

Error reporting

Site related errors should use Growl style error reporting. OSF uses Bootstrap Growl plugin to display messages. The advantage of this library is that is builds on top of bootstrap design and utilizes alert boxes, which means it already complies with the style guide.

Which feedback to use when?

Action examples Feedback type Auto vs manual dismiss
Mundane success events

Events that user expects to happen and occurs frequently.

  • Page loaded successfully
  • Login was successful
 Does not need feedback N/A
Expected but critical success events

Events that the user expects to succeed but it's success is important

  • File uploaded successfully
  • File deleted successfully
  • Wiki changes are saved
 Use text with "text-success" within the vicinity of the action elements.. i.e: Files uploaded! Auto dismiss
Not critical error events

Errors that are caused by events that will try to repeat action or are not breaking.

  • Dropbox files could not be loaded
  • Collaborative editing is not available at the moment
 Use text with "text-danger" within the vicinity of the action elements. i.e: Dropbox files could not be loaded! Auto dismiss
Input errors

Validation or input requirement errors that need the user to correct the error before moving on.

  • First name is required
  • Please enter DELETE to remove this item.
  • This user name already exists
 Use text with "text-danger" using the form validation error example above. If not using a form place near input field. See example in Validation section above. Dismiss when user fixes error or cancels.
Critical errors

Errors that break the user workflow and may result in problems, mainly due to connectivity

  • Profile settings could not be saved!
  • File did not upload
  • Wiki changes cannot be saved at the moment
 Use Growl box error Manual dismiss
Never use Javascript alerts! (except for onunload events).

Confirmations

Sometimes it's pertinent to stop the user to confirm the action they are taking. Often this is done as a Modal or onunload dialog boxes. This should be used in very rare instances.

USE confirmation when:

  • The action will override an existing content AND the content can't be easily reverted.(e.g. Deleting files, wiki pages)
  • The action will take effect for other users as well or have consequences for other users. (e.g. Make project public)
  • The action will have lasting consequences even if it is reverted (for instance making a project public may make it difficult to make it private again due to caching online)
  • There is unsaved content or settings

DON'T USE confirmation when

  • The action can easily be reverted (e.g instance settings changes that can be changed back)
  • The content can easily be reverted (e.g. editing wiki pages, since we save revisions)
  • Commonplace actions like navigating between pages.
  • Creating content that is expected and not affecting others (e.g. Creating a project)

Two-step Confirmation

This involves not just asking users if they want to apply the action but to add another step to make accidental actions impossible. In this case:

  • Add a process which requires additional conscious step, entering text to match a pre selected text is ideal. Avoid steps that can be completed with mouse clicks or pressing enter.
  • Show the button to apply the event as disabled and do not bind Enter key to it until the second step is done.
  • Make sure to test that the second step works, accesibility is especially important here

Use two step confirmation when the action is highly dangerous and should be done carefully. For intance deleting a project has repurcussions that can be serious and it is very difficult to reproduce aspects of it such as the unique ID that many links independent of the OSF uses.

Buttons and toggles

Button state feedback

Regular button
Active state button
Disabled state button

<h5>Regular button</h5>
<button class="btn btn-success">Save</button>

<h5>Active state button</h5>
<button class="btn btn-default"><i class="text-muted">Saving...</i></button>

<h5>Disabled state button</h5>
<button class="btn btn-default disabled"><span class="text-muted">Save</span></button>

Do not hide action buttons if the button is not yet available and show action buttons if action is possible but not yet available

Do this if action item is not possible (waiting for selection):
Do this if action item is available but there are validation errors:
Please correct errors above and try saving again.
Don't do this:
Save button becomes visible magically later

Often you will give users the opportunity to make a selection to either immediately save an option or to save together with the rest of the form. Follow these guidelines when making your decision about which component to use:

Selection between on or off states

Do not use single flip-flop buttons that show the current state. You can however use the action verbs and utilize a single button this way.

Do this:
Don't do this:
Don't do this:

UI specific toggle with more than 2 states

If there is a UI component that shows more than 2 states and it's effects are immediate (such as toggling views) use a button group with a disabled button as label. This shows the user that these view changes belong together and work in a similar way.

Do this:
Don't do this:

Inline selection with multiple states without using Select

If for some reason you need to have users choose from multiple options that are not part of a UI change but still needs to be part of a toolbar you can use split button drop downs from Bootstrap.


 <div class="btn-group m-b-lg">
     <button type="button" class="btn btn-default">Detailed options</button>
     <button type="button" class="btn btn-default dropdown-toggle" data-toggle="dropdown" aria-expanded="false">
         <span class="caret"></span>
         <span class="sr-only">Toggle Dropdown</span>
     </button>
     <ul class="dropdown-menu" role="menu">
         <li class="active">
             <a href="#">
                 <div>Selected option</div>
                 <div class="text-smaller">With some more details here.</div>
             </a>
         </li>
         <li>
             <a href="#">
                 <div>Options can take HTML</div>
                 <div class="text-smaller">Make <b>Bold</b> or <i>Italic</i>.</div>
             </a>
         </li>
         <li><a href="#">Something else here</a></li>
         <li class="divider"></li>
         <li><a href="#">Separated link</a></li>
     </ul>
 </div>
Bootstrap documentation

Button Placement

When using multiple buttons with general save related actions (on forms, modals etc); use the following order:

When to alphabetize?

When using drop downs, think carefully about the ordering of the options. Is the a hierarchical, or temporal order to the options that could be used to order them? Are they're certain options that users should see before others, assuming they are scanning down the list [this is actually just good practice whether they are using drop downs, check boxes, or radical buttons]? If none of these apply, then the drop down options should be in alphabetical order.

Alphabetize general and equal structures like country names:

Don't alphabetize order and hierarchy

Break alphabetical order in favor of common uses

Input elements in forms

If the input changes are not part of a UI element, use regular form standards. Below is a general guideline about what forms to use

Multiple items can be selected and there are less than 6 items per group Default stacked checkboxes
Single item can be selected and there are less than 6 items per group Default stacked radio buttons
Multiple items can be selected and there are more than 6 items in a group Multiple select
Single item can be selected and there are more than 6 items in a group Default Select

More tips:

  • If the individual items are shorter than ~10 characters, keep your checkboxes and radio buttons inline (if you have space).
  • If the individual items are longer, keep each checkbox or radio button in its own line.

Modals

When should you use modals?

Modals should be used in rare instances when the content needs to be in full focus of the user because

  • they are making an important decision.
  • they are making a breaking change.
  • they need to read critical information.

When adding modals consider these questions:

  • Is the user going to expect a modal in this type of operation?
  • Is the modal going to hide content that will still be needed
  • Is this modal important enough? Can it be added within the page?
  • How many modals are there in this work flow?
  • Modals are easily dismissed so if the action is very important (i.e. new registration) create a multi page workflow instead.

What to watch out for with modals

When adding modals also be cognizant of these implementation practices:

  • Always include a dismiss icon on the right top corner
  • Phrase the words in terms of the action, i.e. don't use "OK" if possible, use "I agree", or other verb.
  • Modals should not include too much text. If your modal needs to scroll in regular screens, look for a different method.
  • Check modal headers for narrow screen sizes by trying long names if the header is populated dynamically.

Using tooltips

Tooltips are a method where hovering over an element provides additional information in a hovering text element. It's an addition to the default "title" html attribute and default browser behavior.

The implementation and styling of tooltip should be exactly as standard bootstrap. Hovering over items is not always intutitive so don't use tooltips unless necessary.

USE with items that users are expected to move their mouse to

Do this:
Don't do this (hint: hover on "rows"):
Some of these rows are editable.

USE if the tooltip text is in fact longer and useful.

Do this:
Don't do this:

Using label

Why do we need to use label?

Label is used with input element. It provides a usability improvement for mouse users. Because if the user click on the text within a label element, it will toggles the control. See the example below.Click on one of the text labels to toggle the related control.

Female 
<!-- With label, it will toggle the checkbox if clicking text -->
<label for="male">Male</label>
<input type="radio" name="sex" id="male" value="male"><br>

<!-- Without label, no action will happen if clicking text -->
<span>Female</span>
<input type="radio" name="sex" id="female" value="female"><br>

How to use label

Following the accessibility rules, whenever possible, use the label element to explicitly associate text with form elements. The for attribute of the label must exactly match the id of the form control. 
<!-- Recommended -->
<label for="Dataverse">Dataverse</label>
<input type="checkbox" name="dataverse" id="Dataverse" class="addon-select">

<!-- Not Recommended -->
<label>Dataverse<input type="checkbox" name="dataverse" class="addon-select"></label>

Using datetime

All dates are to be displayed in UTC and should be precise down to minute. Ideally dates should be bolded and appear with a explainatory tooltip. You may also want to include information about the timezone if many datetimes are listed.

2015-01-23 1:42 PM

Further reading

Resources below will give you good ideas about general UI principles. If the contents differ from guidance in this document remember that the Style Guide should be applied in OSF.