It is important to be clear about what user interface guidelines are, what they can do, and what they cannot do. User interface guidelines provide a reference for common user interface patterns to ensure that whenever a user sees a particular pattern, they can comprehend exactly how it will work before they attempt to use it. What guidelines will do is ensure that products visually will appear uniform and cohesive while allowing some differentiation appropriate to specfic tasks and usage of the products.

What guideliness cannot do is ensure that a user interface is usable. It is possible to follow the guidelines to the letter and still create a user interface where people are unable to successfully complete tasks. This is because the look and feel provided by following guidelines only covers the visuals, which, while affecting usability, is only one dimension of usability and does nothing to ensure that terminology in use is understandable and that UI elements are laid out in a manner expected by the user to be intuitive. There still needs to be proper analysis of the user's tasks to design the flow of screens and craft the interaction to be intuitive, and investigation into nomenclature familiar to the target users and so forth to ensure the user interface is understandable and usable.

First, it is vital to understand the tasks users will carry out with the UI and understand the path they need to take through the UI to complete tasks. It's also important to know the priority of the tasks and the elements of the UI in support of those tasks. This information is what is needed to apply the guidelines in a way that will make complex UIs easier to use, as much as is possible with visual changes alone.

Avoid more than one "Primary" heading per page.

Try to avoid more than two "Secondary" headings per page.

There should never be more than one Primary (or Default) action button per page. (The "Primary" or "Default" action is what will happen if the user loads the page and hits the Enter key without doing anything else.)

By way of example, let's suppose in the Workflow product UI the most primary thing the user will do is take some kind of action, and the second-most thing the user will do is assign team members or reassign tasks to team members. Armed with that information, we can apply the primary heading style to the Actions section and the Secondary heading style to the Team Members area, and apply Tertiary and alternate section styles to remaining areas of the UI, based on relative priority, as seen in this example.

For more background information to help apply visual styles from the guideline to UI, please review this presentation.

Info:Note: It's important that the resulting UI look like what is presented in the guidelines, moreso than the actual CSS specification to achieve it. It may take more or less CSS attributes and values to achieve the look presented in the guidelines for any particular product.

All elements are in a flat, borderless style (with some exceptions, e.g. form inputs). Fonts are Helvetica Neue / sans-serif. This is both the state of the art in UI and makes it very easy for applications to appear consistent on multiple target devices and operating systems. There is a detriment that some visual affordances to indicate interaction are compromised with a flat style (3-D makes it obvious what can be pressed, flat requires other ways to distinguish), so opportunities to integrate interaction affordances back in will be identified as the guidelines mature.

Everything should be laid out on a 5-pixel grid as much as possible. Margins and padding for the page should be 20 pixels, major content areas should be either 10 or 20 pixels to separate sections of text. Margins should 'collapse' between content areas. In other words, avoid having two content areas next to each other with margins resulting in 40 pixels in between them but only 20 pixels around the outside. Margins need to be set so that there is never more than a 20-pixel combined margin around content areas.

In mobile, just about everything is interactive. Almost everything can be touched, dragged, swiped, resized. But across devices and platforms, if a decision must be made for the visual style, prefer square corners for static content and round corners for interactive content.

Square = Static

123

Status
Warning:Warning! A warning message.


CSS

border-radius: 0px;

Rounded = Interactive


CSS

border-radius: 5px;


Info:Note: to create a round profile picture, the border-radius of the img tag is set to 50% of the height/width dimension of the image itself. Bootstrap provides img-circle for this, or a Callidus CSS class can be created (e.g. cald_profile_pic) where border-radius: 50%;


Bootstrap

It's recommended to consider Bootstrap if possible (current version is 3.3.x at time of writing). Bootstrap provides a notable amount of UI styles that are useful for aligning with these guidelines.

Font face is Helvetica Neue. In CSS, the spec including fallback fonts is font-family: "Helvetice Neue", "HelveticeNeue", Helvetica, Arial, sans-serif;. Font size should start with the browser default, and prefer using relative CSS font sizes to handle setting variations in size. For example, use font-size: smaller; or font-size: larger; only when absolutely necessary to distinguish specific lines of text. Additionally, semantic markup like <strong> rather than <b> should be used. Otherwise, structural markup appropriate for the content (e.g. H1, H2, H3, etc.) should be relied on to provide the size and weight for text.

Examples

H1

H2

H3

H4

H5
H6
This sentence has something to be emphasized and stated strongly.
Using font-size: larger;
Default browser font size.
Using font-size: smaller;


CSS

BODY { background-color: white; color: #636466; font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 1em; } H1, H2, H3, H4, H5, H6, STRONG { color: black; }


How To Apply

Headings increase the size of the text, which consumes space on the page. Therefore, while heading usage should follow structure of the page (e.g. the primary topic would be H1 and sub sections would be H2) for most application UI, favor the section heading styles and utilize the text H# headings to call out information that needs the user's attention before proceeding but is not necessarily the primary 'work' area of the page.

For example, in the mockup provided, most all the functional areas of the UI are using the section heading styles, while the current case name, which orients the user to where they are and what data is loaded currently, simply utilizes the H# heading style to get their attention but is not necessarily where they would start working or where most of their task would take place.

The color palette is not just a range of colors to be used at will. Each color in the palette was chosen from the mockups where each color has a specific use. The palette was initialized from specific colors found in the Callidus corporate identity and in products of the suite. When two colors are adjacent, e.g. text on a background, it's important that the two colors have sufficient contrast to be perceptible.

Grayscale Palette

Color Usage Example
#000000
Headings

Example H4

#636466
Text content Example text
#bfbfbf
Gridlines and input borders
Example borders
#d9d9d9
Tertiary grid heading background
Tertiary grid heading
Row 1
Row 2
#e5e5e5
iOS expanded child menu background
Parent menu item
Child menu item
Child menu item
#ececec
Grid banding for even rows only
(secondary, tertiary, alternate grids only)
Heading
Row 1
Row 2 (banded)
#f3f3f3
Subsection heading background and subsection content background
Example Subsection Heading
and subsection content
#f2f2f2
Page background (below the global header and behind widgets)
Page background with white widget contents on top.
#FFFFFF
Global header background, primary page content (widget/section) backgrounds
ExampleExample

Color Palette

#2b6191
Button that is primary action (one per page only) Back to login screen
#00A8E3
Secondary headings and grid titles, global header bottom border

Example Secondary Section Heading

#1ea9e0
Links (do not use an underline) An example link
#72c9e9
Hover menu item or selected nav bar item
Menu item 1
Hover menu item 2
Menu item 3
#bee0ee
Banner menu background
EXAMPLE   BANNER   NAV  
SELECTED
#d3eef9
Grid banding for even rows only
(primary grids only)
Primary grid heading
Row 1
Row 2 (banded)
#FDB823
Hover or selected by the user, also warning color (without text on top)
Heading
Row 1
Row 2 hovered
#fee1a9
Selected but not in focus, or selected by the system.
Heading
Row 1
Row 2 selected, but focus/action is somewhere else
#f5efe3
Page background (below the global header and behind widgets)
Page background with white widget contents on top.

Reserved For Traffic Lighting / Status Notification

#ad3a3a
Traffic lighting with white text only over the color
100
Errors
#d9b500
Traffic lighting with white text only over the color
100
Warnings
#309030
Traffic lighting with white text only over the color
100
Success
#ff0000
Traffic lighting with no text over the color
100%
#FDB823
Traffic lighting with no text over the color, and hover/user selection
100%
#00c000
Traffic lighting with no text over the color
100%


Chart / Data Visualization Colors

Apply the cool series first. Use the warm series only if needed for large number of data series on one visualization. (Do not alternate the cool series on one visualization and the warm series on another visualization.) If there are significant number of data series to be displayed, wrap the series back to the first cool color in the cool series and use hover/highlighting to help the user identify a particular data series. The purple highlight is only to be used for temporal hover or selection of a data series on a visualization. Do not use purple as a fixed color for a data series on any visualization.

Cool Color Series must be applied to data series in this order
(Purple highlight only for showing hover/selection in a chart)
#1667bd
#00a5ef
#97b68c
#467dc8
#56b397
#277876
#529bbd
#8dd9b5
#899884
#9E57A2 hover select
Warm Color Series
#88714b
#cbc62e
#c38746
#7eb070
#ffc024
#6ca58a
#888016
#8dd9b5
#899884
#9E57A2 hover select


Example Usage

 
 
A very even pie chart
Legend
Data series 1
Data series 2
Data series 3
Data series 4
Data series 5
Data series 6
Data series 7
Data series 8


Iconography should be flat, solid color. It's recommended to start with the Icomoon library. (Reference information on the Icomoon web site.) Pay careful attention to file names and only use icons exactly as originally intended by the file names. DO NOT use icons simply because they look like something that might work. If an icon for a feature peculiar to Sales Management cannot be found in the library, based on file name not image, then a custom icon will need to be created with a new, unique visual metaphor for the purpose. AVOID using social media emojis / smileys. DO NOT use icons that are logos or trademarks of other companies without approval.

Depending on the context, either 16pt or 32pt are acceptable. Try to avoid 24pt as only multiples of 16 are clear with Icomoon.

16pt 24pt 32pt


Usage:
<head> <link href="fonts/icomoon/style.css" rel="stylesheet"> </head> <body> OPTION 1: <span class="icon-name"></span> OPTION 2: <span style="font-family:icomoon;">&#xeHEX;</span> </body>
Where icon-name is as found inside style.css. OR use HEX codes as seen below.

Also requires storing the files fonts/icomoon/fonts/icomoon.eot fonts/icomoon/fonts/icomoon.svg fonts/icomoon/fonts/icomoon.ttf fonts/icomoon/fonts/icomoon.woff on the server.

Samples

This is the complete set. Not all icons seen here should be used in products. Icons that have been standardized for particular use are highlighted in this color. Hover over the icon for usage details. Do not use icons marked in red without consulting UX and Legal.


The structure of the top banner area is a global Callidus suite bar and a product-level bar. The top-most bar is only global Lead To Money suite elements - the CallidusCloud brand, application switching navigation, options pertaining to the current login and possibly any global suite-level help that might be provided. The top banner is visually white in order to reserve darker/higher contrast for primary use areas of the UI. The second bar will be colored and have the navigation specific to the current product. The second product navigation bar could be hidden into a "hamburger" menu on mobile devices. Any other links or inputs should be avoided in the brand bar, other than perhaps global help for the suite.


Default Header Bar

This header bar has no drop menus. The items on the bar are pages in the application.

Application Name
Username
Page content


Visual Spec


CSS

Header bar: background-color: white; height: 64px; margin: 0px; padding: 10px 20px; border: 0px; border-bottom: solid 5px #00A8E3; text-align: center; vertical-align: middle; width: 100%;

Menubar: background-color: #bee0ee; height: 40px; margin: 0px; border: 0px; text-align: center; vertical-align: middle; width: 100%;

Menu item: background-color: #72c9e9; /* selected */ height: 40px; margin: 0px; padding: 10px 40px; border: 0px; border-radius: 0px; text-align: center; vertical-align: middle; color: white; /* selected */ font-weight: bold; /* selected */ text-transform: uppercase;

Header Area Variations

Dynamic Submenu

This header bar only has drop menus. The items on the bar are topics, not pages.

Application Name
Username



Tertiary Section Bar

Occaisionally, a third bar is needed for some page level information and scoped actions like searches.

Application Name
Username
Selected Page
Page content



No Sub Menu

This application has a single page or workspace. There are no other pages to navigate to. But the content area is subdivided into sections.

Application Name
Username
This style is for pages that have multiple content areas.
Content area two.



No Sub Menu, No Portlets/Panels

This application has a single page or workspace. There are no other pages to navigate to. And the content area is one single panel or form, no subsections. This style will likely only be used on mobile, so it is showing an iconic user account drop down and a hamburger menu for application switching. These should only be seen at resolutions below 768px wide.

This is for mobile, or pages where the entire UI is one panel or form.



Embedded In 3rd Party Applications

This header bar is when a product is embedded inside another 3rd party product. The global, app-switching brand bar goes away and only the product navigation bar is present. The logo is optional, but appears on the far right and is 50% of it's normal size.

3rd party application page

3rd party application page content

CallidusCloud content
Application switching and user account features are moved to the • • • menu. Logo is half normal header size.


Menus are temporal (except for in-page) therefore a dark color is used for hover to get attention. This is the same color used for selection on the default header bar that has no menus. Avoid iconography in menus, other than checkmarks for currently selected options for menu items that are not actions.

Heading Menu

CATEGORY
Menu item
Hover
Extremely wide menu item

In-Page menu



Menu item
Selected
Menu item
Hover
Selected page contents.



Mega Menu

Headings within a mega menu are optional but recommended. It's important that related menu items are together in the same column. Avoid having related menu items wrap to a second column.

CATEGORY
Heading
Menu item
Hover
Menu item
Menu item
Menu item
Heading
Menu item
Menu item
Menu item

Menu item



Context Menu

Mainly for desktop. (Less common on mobile. Typically a menu is a new screen on phones but could be an overlay on tablets.)



[Object clicked on]
Menu item
Hover
Menu item
Menu item










Heading Product Menu

This menu appears up in the global brand header bar and has the same compact structure as a context menu, but no border.










Context Menu Structure

[Object clicked on]
[Object clicked on] level
[Object clicked on] level

Current page level
Current page level
Current page level

Global product level



Visual Spec




CSS

Heading menu:
background-color:#bee0ee; color: #636466; box-shadow: 3px 5px 12px 0px #BBB; border: none; border-radius: 0px;

Heading menu item:
background-color:#bee0ee; color: #636466; height: 40px; margin: 0px; padding: 10px 20px; border: 0px; border-radius: 0px; text-align: center; vertical-align: middle;

Heading menu item selected:
background-color: #72c9e9; height: 40px; margin: 0px; padding: 10px 20px; border: 0px; border-radius: 0px; text-align: center; vertical-align: middle; color: white;

Context menu:
background-color: white; border: solid 1px #bfbfbf; /* no border in brand header bar */ border-radius: 0px; color: #636466; box-shadow: 3px 5px 12px 0px #BBB;

Context menu item:
height: 30px; margin: 0px; padding: 5px 20px; border: 0px; border-radius: 0px; text-align: left; vertical-align: middle;

Context menu item selected:
background-color: #72c9e9; color: white; height: 30px; margin: 0px; padding: 5px 20px; border: 0px; border-radius: 0px; text-align: left; vertical-align: middle;


In-page menu:
background-color: #f2f2f2; color: #636466; border: none; border-radius: 0px;

In-page menu item hover:
background-color: #72c9e9; color: white; height: 40px; margin: 0px; padding: 10px 20px; border: 0px; border-radius: 0px; text-align: left; vertical-align: middle; position: relative;

In-page menu item selected:
background-color: #bee0ee; height: 40px; margin: 0px; padding: 10px 20px; border: 0px; border-radius: 0px; text-align: left; vertical-align: middle; position: relative;

In-page menu item right pointer:
height: 40px; width: 20px; margin: 0px; border-top: solid 20px white; border-bottom: solid 20px white; border-left: solid 10px #bee0ee; border-radius: 0px; position: absolute; top: 0px; right: -20px;

In-page menu item left pointer:
height: 40px; width: 20px; margin: 0px; border-top: solid 20px white; border-bottom: solid 20px white; border-right: solid 10px #bee0ee; border-radius: 0px; position: absolute; top: 0px; right: -20px;

Keystrokes in use for interaction other than typing text should follow well-known OS and browser conventions. Keystrokes and special macros should not disrupt or disable browser or OS operations. Tabbing order for elements of the UI should follow the task of the user primarily, visual position on the page secondarily, and fall back to the logical order in the markup.


Breadcrumbs follow navigation structure of the application, not the history of the user. The leaf of the breadcrumb should be the current page and should not be interactive. The breadcrumb is secondary navigation and not a replacement for page headings or titles.

Example


Top Level Page Second Level Page Current Page


The arrow separator is icon-arrow-right17


Tabs

Traditional tabs should be avoided. Other ways of handling mutually exclusive / random access content exist. However this section exists to accomodate products that still have tabs in use that cannot be changed in the near term.

Example


.cald_tab a { color: #636466; text-decoration: none; background-color: #ececec; border: 1px solid #ddd !important; border-radius: 5px 5px 0px 0px !important; } .cald_tab.active > a { background-color: white !important; border-bottom-color: transparent !important; }

Page content needs to be visually prioritized based on frequency of use, or average duration of use per session, or sequence of tasks within a user's workflow. To aid in this, there are primary, secondary, tertiary styles. View an example of all these styles applied.

Info:Avoid putting interactive icons and buttons in headings and titlebars. Keep interactivity within the content area and leave the headings as static section dividers.


Primary Section Heading

Should only be one primary section per page. Avoid more than one per page.

Primary section heading h1: background-color: black; color: white; padding: 10px; font-size: 1em; margin: -10px -10px 10px -10px;

Section content: padding: 10px; margin: -20px -20px 20px -20px;

Secondary Section Heading

Preferably only one secondary section per page. Try to avoid more than two per page.

Secondary section heading h2: background-color: #00A8E3; color: white; padding: 10px; font-size: 1em; margin: -10px -10px 10px -10px;

Tertiary Section Heading

Preferably only one tertiary section per page. Try to avoid more than two or three per page.

Tertiary section heading h3: background-color: #d9d9d9; padding: 10px; font-size: 1em; margin: -10px -10px 10px -10px;

Alternate Section Heading

Once primary and secondary are established, the alternate section style can be used as needed per page.

Alternate section heading h4: border-bottom: solid 1px #bfbfbf; padding: 10px; padding-bottom: 9px; font-size: 1em; margin: -10px -10px 10px -10px;

Subsection Heading

Preferably only one subsection per page. This is used as kind of a callout. Try to avoid more than one per page.

Subsection heading h5: background-color: #f3f3f3; font-size: 1em; margin: 0px 0px 10px 0px; font-weight: bold;

Subsection content area: background-color: #f3f3f3; padding: 10px; margin: -20px -20px 20px -20px;

General content: background-color: white; color: #636466; font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;

Headings: color: black;

Overall content area: background-color: white; padding: 20px;


Page background: background-color: #f5efe3; padding: 20px;

View an example of all these styles applied.

Like sections of a page, grids and lists need to be visually prioritized based on frequency of use, or average duration of use per session, or sequence of tasks within a user's workflow. To aid in this, there are primary, secondary, tertiary grid styles.

Info:When a grid has a toolbar, use a primary, secondary or tertiary section style above to surround the grid, then have any interactive menus/toolbars after the title bar, and use the alternate grid style within the section. See example.


Primary Grid

Should only one primary grid per page. Avoid more than one per page.

Heading Heading
Non-banded row Data cell
Banded row Data cell
Hover row Data cell
Selected row Data cell
Heading Heading
Data cell Data cell
Data cell Data cell
Hover row Data cell
Selected row Data cell


Visual Spec


CSS

Heading: background-color: black; color: white;

Row banding: background-color: #d3eef9;

Row hover: background-color: #FDB823;

Row selection: background-color: #fee1a9;

Info:Refer to the general grid styles section also.


Secondary Grid

Preferably only one secondary grid per page. Try to avoid more than two per page.

Heading Heading
Non-banded row Data cell
Banded row Data cell
Hover row Data cell
Selected row Data cell
Heading Heading
Data cell Data cell
Data cell Data cell
Hover row Data cell
Selected row Data cell


CSS

Heading: background-color: #00A8E3; color: white;

Row banding: background-color: #ececec;

Row hover: background-color: #FDB823;

Row selection: background-color: #fee1a9;


Tertiary Grid

Should only one tertiary grid per page. Try to avoid more than one or two per page.

Heading Heading
Non-banded row Data cell
Banded row Data cell
Hover row Data cell
Selected row Data cell
Heading Heading
Data cell Data cell
Data cell Data cell
Hover row Data cell
Selected row Data cell


CSS

Heading: background-color: #d9d9d9;

Row banding: background-color: #ececec;

Row hover: background-color: #FDB823;

Row selection: background-color: #fee1a9;


Alternate Grid

This style can used for yet another, lower priority display of data in a page. But also, when a grid has a toolbar use a primary, secondary or tertiary section style from above to surround the grid, then have any interactive menus/toolbars after the title bar, and use the alternate grid style within the section. See example.

Heading Heading
Non-banded row Data cell
Banded row Data cell
Hover row Data cell
Selected row Data cell
Heading Heading
Data cell Data cell
Data cell Data cell
Hover row Data cell
Selected row Data cell


CSS

Heading: border-bottom: solid 1px #bfbfbf; padding-bottom: 4px;

Row banding: background-color: #ececec;

Row hover: background-color: #FDB823;

Row selection: background-color: #fee1a9;

Compact Grid desktop only

For listings on desktop resolution only. Reserved for read-only grids. Do not put interactive contents in compact cells, other than links.

Heading Heading
Non-banded row Data cell
Banded row Data cell
Hover row Data cell
Selected row Data cell


CSS

Callidus table cells at desktop resolution only: @media only screen and (min-width : 1200px) { .cald_table TH, .cald_table TD { padding: 2px 5px; } }

Primary Section Heading

|
Heading Heading Heading
Non-banded row Data cell Data cell
Banded row Data cell Data cell
Hover row Data cell Data cell
Selected row Data cell Data cell

Secondary Section Heading

|
Heading Heading Heading
Non-banded row Data cell Data cell
Banded row Data cell Data cell
Hover row Data cell Data cell
Selected row Data cell Data cell

Cells: padding: 5px 5px 4px 5px;

Rows: border-bottom: solid 1px #bfbfbf; padding: 5px 5px 4px 5px;

Banded rows: border: none;

Banded cells: border: none; padding: 5px;

Hover: background-color: #FDB823;

Selected: background-color: #fee1a9;

Expand / collapse can appear in multiple UI elements: trees, sections, accordions, lists. Do not use plus or minus icons for expand collapse. Plus should be reserved for "add." The basic algorithm should be:

Page Sections

Icon should be located bottom center of the overall section/content, or to the right of headings. Never located on the left.

Expand


icon-arrow-down

Example:

Page content

Example:

Expandable menu item    
Normal menu item
Normal menu item


Collapse


icon-arrow-up

Example:

Page content




...more content

Example:

Expanded menu item    
Menu item
Menu item
Menu item

Normal menu item
Normal menu item

Tree Sections

Icon should be located on the left of the element to be expanded only.

Expand


icon-arrow-right3

Example:

Parent tree node
Leaf tree node
Leaf tree node


Collapse


icon-arrow-down2

Example:

Parent tree node
Leaf tree node
Leaf tree node
Leaf tree node
Leaf tree node

Carousels

Icon should be located left/right center of the overall section/content, or to the right/left of headings, depending on when the navigation is forward or back.

Forward


icon-arrow-right2

Example:

Page content    

Example:

Page one menu item    
Normal menu item
Normal menu item


Back


icon-arrow-left

Example:

    ...content

Example:

Expandable menu item
Normal menu item
Normal menu item
    Page two
Menu item
Menu item
Menu item

Inputs and their labels should be lined up on a grid system to make them easier to visually scan and locate a particular field on a page. Inputs should be sized appropriately for the expected value. This further helps visually distinguish specific inputs and avoid errors by users attempting to put the wrong value in the incorrect field simply because all the inputs were the same size. Inputs should be seeded with valid defaults as much as possible so that potentially the user could simply hit submit without having to modify any inputs.

Labels primarily should be oriented above the input they identify to allow for translation text expansion and to maintain a uniform grid pattern, regardless of label length, along the left (or right margin depending on language direction) for easy visual scanning. The rare exception might be a login where there are only 2-3 inputs and whitespace, visual scanning and readability are not at risk. Sufficient whitespace should be used above form labels to ensure the label is only visually associated with the one input it identifies (if there are two inputs equidistant between a label, it can be ambiguous which field the label is identifying).


Alignment And Layout

If a well-known layout pattern for a set inputs is known (e.g. addresses) it should be used.



DO NOT DO THIS. Do not make all inputs the same length with 100% width and all stacked - despite a common, well-known and recognizable layout users would have expected.


Required Fields

The 'required' attribute should be set and the word 'Required' should be parenthetically suffixed to the label for the field. If all inputs in a form or page are required, there only needs to be a note to that effect at the start of the form. If only a few inputs are required, those inputs should be marked as required individually. If the majority of the inputs are required with only a few inputs optional, there should be a note at the start of the form that all inputs are required except as noted, and the optional fields marked accordingly.

Marking inputs as required (or optional)

Parenthetically append '(Required)' to the label. Technique should be the same, whether the word is 'Required' or 'Optional'


Note:Note: Radio controls do not need to be marked required because one should always be selected. Likewise, checkboxes are always in a valid state, either selected or not, so they should never need to be marked required.



Usage

Form With Only Required Fields

Use a note at the top of the form

All inputs are required


Form With Mostly Required Fields, Few Optional

Use a note at the top of the form and mark the optional fields individually

All inputs are required, except as noted


Form With Few Inputs Required

Mark the required fields individually



DO NOT DO THIS. Do not label every field when all fields are required.



Disabling

If a feature is disabled for a user via permissions and there is nothing the user could ever do during a login session to enable the feature, then it should not display on the UI. If removal from the UI of features disabled by permissions would result in an inexplicably blank screen, a human-readable message explaning the absence of any features should be displayed to the user. Otherwise, if the feature is disabled due to conditions during the user session and there are things the user could do to enable the feature, then it should not be hidden, it should be visible though disabled. Inputs and their labels should be disabled together.




DO NOT DO THIS. Do not disable an input and leave it's label active. Particularly, checkbox and radio labels are interactive and part of selecting, so it's confusing when half the control is still enabled.




Button Styles

Buttons should be left-aligned in-page and right-aligned centered in dialogs. * Button alignment open for discussion..

Flat Style


3-D Style (Preferred)


CSS

Flat primary (only one per page): border-radius: 5px; box-shadow: none; background-color: #337ab7;

Flat normal: border:solid 1px #bfbfbf; border-radius: 5px; box-shadow: none; background-color: #ffffff;

Flat disabled: border:solid 1px #bfbfbf; border-radius: 5px; box-shadow: none; background-color: #dddddd; color: #636466;

3-D primary (only one per page): border-radius: 5px; background:-webkit-linear-gradient(#47a9ff,#337ab7); background:linear-gradient(#47a9ff,#337ab7);

3-D primary hover, active background:-webkit-linear-gradient(#337ab7,#47a9ff); background:linear-gradient(#337ab7,#47a9ff);

3-D normal: border-radius: 5px; background:-webkit-linear-gradient(#ffffff,#dddddd); background:linear-gradient(#ffffff,#dddddd);

3-D normal hover, active background:-webkit-linear-gradient(#dddddd,#ffffff); background:linear-gradient(#dddddd,#ffffff); border-radius: 5px;

3-D disabled: border-radius: 5px; background:-webkit-linear-gradient(#ececec,#dddddd); background:linear-gradient(#ececec,#dddddd); color: #636466;

Note:Visuals and icons in this section are placeholders and will be changed.

Types

Loading spinner

Bar

Progress Meter

80% complete
 

Usage

Progress indication needs to appear where the user is looking, or where the action is taking place, or if not logical or possible to appear where the user interaction took place, progress indication needs to get the user's attention from where it is displayed.

  • Progress indication that is less than page or window-level should not obscure other areas of the UI from being readable if possible, or else should allow the user to drag the progress indication aside to view other content.
  • Progress indication should not disable interactivity unless the disabled actions are not valid while the current operation is in progress.
  • If certain interactions are invalid while the current operation is taking place, then either the specific elements (if only a few) or the overall UI should be visually and obviously disabled in appearance. For specific individual components, they each should be disabled individually. Form inputs and their labels should be disabled together. If it's page/dialog/widget-level, e.g. an entire panel, tab, page of the UI to be disabled, then having a transparent gray overlay should be used to cover the background, rather than iterate through everything in the UI and disable each individually when an entire page or window needs disabling.
  • Progress should offer the ability to cancel the operation whenever possible. Cancelling should revert to the previous state the product was in. Avoid other methods of dialog dismissal, like a corner X, as it is unclear to a user if that will cancel the operation or merely hide the dialog - which will leave them with no way to tell an operation is still in progress.
  • Text-based human-readable information about what is happening and how long it will take is advisable as much as possible.
  • Use a progress bar when there is sufficient space and it's possible to show time or number of steps remaining.
  • If a number of individual components in the UI need to load around the same time, it would be preferable to treat that as page-level loading with only one progress indicator.

Indicators should be an appropriate size for the element that is loading. For example, if loading a page, there shouldn't be only a 16 pixel spinner in the top left corner. Likewise, if loading a simple small list box, the page shouldn't be disabled showing a progress dialog (unless it's invalid to interact with the page while that list is loading).

Timing

If the operation will take...
> 1 second
Show a loading indicator.
> 10 seconds
Show a loading indicator with a general message conveying what is taking place.
> 1 minute
Show a loading indicator with a series of specific messages conveying what is taking place.
> 3 minutes
Show a progress meter with a series of specific messages conveying the steps that are taking place and/or time remaining. The user should be able to cancel the operation.
> 5 minutes
The user should be warned in advance how long the operation will take and have the option to bail out beforehand, as well as cancel during the operation. During the operation, show a progress meter with a series of specific messages conveying the steps that are taking place and time remaining.


Examples

Note:Visuals and icons in this section are preliminary and subject to change.


Component/input level (in page)

Spinner blocking or replacing the component space.

List is loading...


Panel level (in page)

Transparent gray overlay with spinner or progress bar.

Panel is loading...


Page level (progress dialog)
Transparent gray page overlay with progress dialog on top. Dialog title should say what is in progress. Dialog contents should have details of what actions/steps are currently in progress, and show count of steps completed vs steps total and/or time remaining for overall progress to complete. Avoid using an X in the corner to close the dialog as it is not clear if that will cancel the opration or not, and it leaves the user without a way to see whether an operation is still in progress to find out. Cancel is fine as that is explicit what it will do.
This dark gray area represents an entire browser page in the background.

Operation ABC In Progress

Retrieving column names from database. Step 3 of 5.

 
 
60% complete


Multiple cumulative progress
When multiple processes will add up to a total, the total needs to be emphasized more than the constituent processes. Therefore, higher contrast is needed, namely the black font color of heading tags and the visualization select/hover highlight color #9E57A2.

Installing selected features

Installing feature 2 of 3
 
 
55% complete overall


Feature one

 
100% complete


Feature two

 
 
75% complete


Feature three

 
Not started

CSS

Total progress bar: background-color: #9E57A2;

Total progress text: color: black;

Constituent progress bar: background-color: #72c9e9;

Constituent progress text: color: #636466;

Progress remaining color: background-color: #d9d9d9;

The title of a dialog should match the link that launched it. The default action should use the 'primary' button style as long as the default action is not destructive and does not require the user to respond to a question. There can be only one default action. Buttons should be aligned right centered in dialogs. * Button alignment open for discussion.


This dark gray area represents an entire browser page in the background.

Title

Dialog contents


CSS

Dialog window: background-color: white; box-shadow: 0px 5px 25px 0px #333; padding: 10px; padding-bottom: 0px; margin: -20px -20px 20px -20px;

Title bar: background-color: #00A8E3; color: white; padding: 10px; font-size: 1em; margin: -10px -10px 10px -10px;



DO NOT DO THIS. Do not set a destructive operation as the primary action. Either leave both normal and make the user choose, or opt for the safe option ("No" in this case) as the primary.

This dark gray area represents an entire browser page in the background.

Delete All Files

Alert: Are you sure you want to delete all files?



DO NOT DO THIS. Do not display minimize/maximize controls for a window that cannot be minimized or maximized, or for windows where there is no reason to minimize or maximize it.

This dark gray area represents an entire browser page in the background.

Success

Success:The new position was successfully saved.



DO NOT DO THIS. Do not leave 0 margin between dialog content and the edge of the dialog, and 0 margin between elements within the dialog.

This dark gray area represents an entire browser page in the background.

Title

Dialog content

Notifications should be in human-readable form and provide sufficient detail that a user understands the notice. Avoid surfacing system-generated messages like cryptic back-end object names and event codes that are not meaningful unless it's confirmed the user will recognize the specific message and know what follow up action to take. Notifications should be located on screen and in the area where the user is working or should be looking.

Info:Page or dialog-level information notification.

Warning:Page or dialog-level warning notification.

Error:Page or dialog-level error notification.

Success:Page or dialog-level success notification.


CSS

Notification boxes: padding: 10px; margin: 5px; border-radius: none;

(The following are Bootstrap colors, not from the Callidus palette.)

Info: background-color: #b9def0; border: solid 1px #9acfea; color: #31708f;

Warning: background-color: #f8efc0; border: solid 1px #f5e79e; color: #8a6d3b;

Error: background-color: #e7c3c3; border: solid 1px #dca7a7; color: #a94442;

Success: background-color: #c8e5bc; border: solid 1px #b2dba1; color: #3c763d;


Examples

These are examples. These do not imply that all success messages are dialogs and all warnings are toaster-style, by any means. Again, notifications should be located on screen and in the area where the user is working or should be looking.

In Page

Application Name
Username

Info:The application is currently working in 'offline' mode.


This represents an entire browser page.
Page content.
Page content.


Dialog

This dark gray area represents an entire browser page in the background.

Success

Success:The new position was successfully saved.


CSS

Dialog window: background-color: white; box-shadow: 0px 5px 25px 0px #333; padding: 10px; padding-bottom: 0px; margin: -20px -20px 20px -20px;

Dialog title bar: background-color: #00A8E3; color: white; padding: 10px; font-size: 1em; margin: -10px -10px 10px -10px;


"Toaster"

A toaster-style notification is one that slides in from the edge of the window and should automatically dismiss itself after sufficient time to read the message. Warning/error type messages should require the user to dismiss them if the user will be unable to proceed without addressing the issue cited in the message.

This area represents an entire browser page in the background.

Toaster

Warning message one.


Warning message two.


Warning message three.


CSS

Toaster window: box-shadow: 0px 7px 15px 0px #bbb; border: solid 1px #bfbfbf;

Toaster title bar: background-color: #d9d9d9; padding: 10px; font-size: 1em; margin: -10px -10px 10px -10px;

Toaster text: font-size: smaller;


Square

99%

Default

100

Success

50

Warning

0

Error


CSS

Square status: height: 84px; width: 84px; text-align: center; vertical-align: middle; padding: 5px; margin: 5px; color: white; display: inline-block; background-color: #72c9e9; /* or #ad3a3a for success, #d9b500 for warning, #309030 for error */

Square status text: padding: 0px; margin: 5px 0px; color: white; font-weight: normal;

Square status subtext: font-size: smaller;

Error messages should provide instructions for recovery from the error. Avoid surfacing system-generated messages like stack traces to the user unless it's confirmed they will recognize the specific message and know what follow up action to take. Avoid alarming, negative messages for situations where the user can easily recover.

Examples

An integer value is required


Error:The username or password was incorrect.


Warning: The transaction details could not be loaded because the database server could not be contacted. Wait 10 minutes and try again, or contact someone@example.com to restart the database server.


DO NOT DO THIS - It's not likely an end user could recognize backend objects or file names and won't know the path to the logs or have access to the logs and may not know who the specific adminstrator is.

Warning: An error occurred.
java.io.FileNotFoundException: 2uwerqu089723p9rulzjcno8awlcnwiefajodf89.php at java.io.FileInputStream.(FileInputStream.java) at java.io.FileInputStream.(FileInputStream.java) at ExTest.readMyFile(ExTest.java:19) at ExTest.main(ExTest.java:7)
See the log file, or contact the administrator.


How Not To Do Error Notification

DO NOT DO THIS - Do not put the error somewhere on the screen away from both where the problem is and where the user is interacting because the user might not see it.

Filling in the form, a required field was not distinguished as required.


The submit button was off-screen so it required scrolling to get to it, but then an error was thrown that was off-screen..


It required scrolling back up to find the problem.


The offending input was actually highlighted but blue is not an alert color, so it just looks selected. One of two things would have been better:

  1. Display the error in the area on-screen where the user was interacting.
  2. Put the error notification next to the offending input and auto-scroll the user to the notification.

Ideally, the UI shouldn't need help to complete tasks. The UI should be intuitive for the task with interactive elements located where users expect them to be and named using terminology they recognize.

If there is something that needs help documentation, the first step would be to get with real end users and investigate why they are having difficulty understanding and using the UI, then redesign the UI match user's expectations, as much as possible.

For anything beyond that, the UI should be as self-documenting as possible. This means using intuitive labels for elements, providing examples of valid input values, providing contextual help via tooltips or other temporal method that gives additional information about how to use the UI.

The UI should also use a progressive disclosure model for providing help so that the UI does not become cluttered with help before it's really needed.

Any help that exists should provide valuable information that the user would not otherwise be able to know.

As found in the top right corner of the brand header bar, the "Documentation" link would lead to documentation for the product. In the future, should be documentation for the entire suite (for the products the current customer/login has purchased). "Community" should link to the online Callidus Community. "About" should link to a product-specific about screen.

Help
Documentation
Community
About <Product>

Labels, Examples, Descriptions and Explanations

Labels should use clear, concise, intuitive terminology. Where necessary/useful, provide an example input value showing the required format. Hover tooltips should only be used to provide additional information not available anywhere else. Do not simply repeat the label name in a hover tooltip for the sake of consistency - this teaches users that the tooltips aren't useful and they will stop reading them.



DO NOT DO THIS. Do not use non-descript labels and then repeat the same information as help. (Hover over the input to see.)


Contextual help is brief assistance located directly adjecent to elements of the UI that need explanation. This can manifest as either a hover tooltip or with an obvious help icon that the user clicks or touches to popup additional information. Popups should only be used to provide additional information not available anywhere else. Do not simply repeat or restate information in popups for the sake of consistency. This teaches users that the popups are not useful and users will avoid using them.

The entry point for step-by-step guidance should be located where users are looking/interacting at the time they will need it. It should be obvious to find for new users, but not so prominent it becomes a distraction to experienced users. Ideal would be prominent upon first use with an obvious option for the user to dismiss the feature, with instructions for how to find it if they decide they need it later.

License and Domain information may not be used by all products. "Create account" may need to be renamed and linked to other promotional content for some products. All products should maintain this layout, however. This is one case where validation should not highlight the particular field in error as it helps hackers focus in on which part to hack. Reserve the top line for only the company logo and any notification messages. Keep the product name and username input label lined up on the line below the company logo.

Error:The username or password were incorrect.

Product Name

Version #.# Build ####


License information or instructions (optional, used for license/credit info for 3rd party integrated content)

©2015 Callidus Software Inc. All Rights Reserved.




Create account Forgot password

Product Name

Version #.# Build ####


License information (optional, used for license/credit info for 3rd party integrated content)

©2015 Callidus Software Inc. All Rights Reserved.

Changes

v1.0
Finalized.
v0.9.5
Fixed a defect in the button styles section.
v0.9
Updated Navigation section with breadcrumbs and tabs. Added Expand / Collapse section. Updated the Header Bar variations section with a Tertiary Section Bar.
v0.8
Added login screen section and updated menu section based on feedback from product teams.
v0.7
Updated menu section based on feedback from product teams.
v0.6
Added iconography section. Added information about header help menu system to both header bar and help sections.
v0.5
Added visual spec and compact style grid to grids, css for notifications, additional information for fonts, section headings and progress. Changed subsection background color.
v0.4
Added visual spec for default header bar and menus.
v0.3
Updated fonts section, updated 'how to use' section, filled in the dialogs section, updated header bars section for embedded products, additional menu information, updated notifications, and reformatted all the CSS sections.
v0.2
v0.1
Initial draft