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.
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.
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;
}
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%
|
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.
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.
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;">HEX;</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.
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.
This header bar has no drop menus. The items on the bar are pages in the application.
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;
This header bar only has drop menus. The items on the bar are topics, not pages.
Occaisionally, a third bar is needed for some page level information and scoped actions like searches.
This application has a single page or workspace. There are no other pages to navigate to. But the content area is subdivided into sections.
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 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 content
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.
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.
Mainly for desktop. (Less common on mobile. Typically a menu is a new screen on phones but could be an overlay on tablets.)
This menu appears up in the global brand header bar and has the same compact structure as a context menu, but no border.
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.
Top Level Page Second Level Page Current Page
The arrow separator is icon-arrow-right17
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.
.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.
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;
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;
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;
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;
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.
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 |
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.
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 |
Heading:
background-color: #00A8E3;
color: white;
Row banding:
background-color: #ececec;
Row hover:
background-color: #FDB823;
Row selection:
background-color: #fee1a9;
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 |
Heading:
background-color: #d9d9d9;
Row banding:
background-color: #ececec;
Row hover:
background-color: #FDB823;
Row selection:
background-color: #fee1a9;
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 |
Heading:
border-bottom: solid 1px #bfbfbf;
padding-bottom: 4px;
Row banding:
background-color: #ececec;
Row hover:
background-color: #FDB823;
Row selection:
background-color: #fee1a9;
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 |
Callidus table cells at desktop resolution only:
@media only screen and (min-width : 1200px) {
.cald_table TH, .cald_table TD {
padding: 2px 5px;
}
}
Example of creating a grid with a toolbar by combining a section header, toolbar and alternate grid inside.
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 |
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:
Icon should be located bottom center of the overall section/content, or to the right of headings. Never located on the left.
Expand
Example:
Page content
Example:
Collapse
Example:
Page content
...more content
Example:
Icon should be located on the left of the element to be expanded only.
Expand
Example:
Collapse
Example:
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
Example:
Page content
Example:
Back
Example:
...content
Example:
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).