Font size should start with the browser default of 1em and increment in "minor thirds" or a ratio of 1.2:1. Only use relative CSS em font sizes to handle setting variations in size. 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.
Iconography should be flat, solid color. It's recommended to start with the Icomoon library. (Reference information on the Icomoon web site.) The Font-Awesome web fonts should be used also, to support progress indication. The default Bootstrap icon library is possible as well. Pay careful attention to file names and only use icons exactly as originally intended by the file names. 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.
There are 10 scaled images per product per type of logo. 3 for Apple devices (@2x, @3x, @4x), 5 for Android devices (ldpi, mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) and 1 SVG. The mdpi file is the original 1x size of the logo.
Use stroke images for dashboards and entry points where a boundary around the logo will be provided by the context (e.g. in a widget frame or within a listing).
Use black and white images within applications where logo colors would otherwise disrupt highlighting of selections, traffic lighting status colors and notification colors.
Use circle images where a self-contained frame or border/margin is needed around logo, like on a dashboard or in a reports listing.
The top header section is global CallidusCloud navigation and actions. The top left navigation is reserved for switching between applications in the Lead To Money suite. The top right is reserved for help contents and profile management of the currently logged in user.
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 need to be set so that there is never more than a 20-pixel combined margin around content areas. Content should never be placed in the margin area, it is only to be used for spacing between content sections.
Callidus Bar 60px
Help
Username
Page Bar 40px
Heading
Page content
Margins vs Borders
Margins
Use margins to delineate sections that are loosely related. For example, interaction in one panel will not affect the contents of the other.
Application Name
Help
Username
My team information
Role: administrator
Members: 15
Lead: Soandso
Assistant: Moe
Member: Joe
My inbox
From
Subject
person@example.com
RE: subject line of email
person@example.com
RE: subject line of email
person@example.com
RE: subject line of email
Borders
Use lines or borders to delineate sections that are closely related. For example, interaction in one section will update the other.
Application Name
Help
Username
Territory Name
Executive
Manager
Manager2
Sales
Sales2
Manager3
Header Bars
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.
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.
When top menu has more than 10 items, a left menu can be applied to avoid needing an ellipses overflow menu. For navigation that has more than 1 level of depth we should apply carousel model (as in mobile apps)
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.
There should only be one primary section per page. Avoid more than one secondary heading also. There shouldn't be more than 2-3 tertiary headings. Use the alternate heading for any additional sections. The subsection is for callout panels, details, explanations, etc.
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.
Grid With A Toolbar
Reserve a row space for toolbar actions and filters. Use text for actions as much as feasible. For very common operations that have a well-known metaphor, an icon button is acceptable. If an action will be used frequently, then it should be a text-based button to make it a larger target, possibly style it as a primary action if that is the case.
Page Heading Used as Grid Heading
Heading
Heading
Heading
Non-banded row
Data cell
Data cell
Banded row
Data cell
Data cell
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
Grid Sort Indication
Sorted indicator persists. Sortable icon only shows on hover or selection.
Column hover is from the heading only. The column heading hover color sticks as the column heading selection color (This is an exception to the usage of the hover color). Row hover is anywhere on the row.
Usage: for all other tables on a page, or combine with an appropriate heading with buttons below the heading to create tables with a toolbar. See 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).
If a well-known layout pattern for a set inputs is known (e.g. addresses) it should be used.
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.
Disabling
Labels and the inputs must be disabled together.
If the user CAN do something to enable the inputs within the current session, render as disabled inputs.
If the user CANNOT do anything to enable the inputs within the current session, render as read-only text.
Button Styles
Labels should be short and in initial caps. Avoid long phrases and sentences on buttons. Consider using an adjacent info popup for clarification of the action instead.
Primary is the action that would take place if the user did nothing but hit the Enter key, Return key or spacebar.
Buttons pinned bottom right, always visible, primary far right.
Long Page not preferred, avoid
Buttons pinned top right, always visible, primary far right.
Long Page with Search / Filter This is an exception
This is a different pattern as the buttons here are intended as a toolbar for a page and not a form submit mechanism. Buttons pinned top left (always visible), primary far left. Search / filter always top right.
Dialogs and Mobile
Buttons centered (always visible), primary right. This puts the actions in proper proximity on screen for thumb / hand-held usage.
Dialogs
The title of a dialog should match the link that launched it. Use the secondary blue heading style for the title bar so the dialog stands out against the page. (Do not use the primary black heading style.) When there are multiple action buttons, 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. Using the primary button style is not required when there is only one action, though it should still have the behavior of a default action (e.g. hitting return without doing anything else first should result in executing the default action) Buttons should be centered in dialogs.
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.
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.
Whenever pages, components, grids, charts or other elements load but no data is available, a human-readible message should be displayed explaining the situation and providing instructions or options to take action, if necessary, to correct the problem. Do not use a dialog to notify about no data situations because dialogs can be dismissed and that leaves the area with no data blank and without explanation (if the user leaves and comes back, or prematurely dismissed the dialog without reading how to take corrective action.)
Error:The page cannot be displayed because the data source appears to be offline.
Session Expired
Session Expired
Error:The page contents cannot be displayed because the login session has expired. Log in again to access this page.
Grid
Grid Heading
Column Heading
Column Heading
Column Heading
No Matching Results
Warning:There are no records matching the current query. Try revising your query using less query terms or try partial query terms with the wildcard character * to retrieve more results.
Charts
No Data To Display
Warning:There is no data available to display for the period, product or persons selected.
Error Notification
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.
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.
Usage
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 progress indicator.
> 10 seconds
Show a progress indicator with a general message conveying what is taking place.
> 1 minute
Show a progress 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.
Types
There are 4 characteristics that intersect to create the different types: determinate vs. indeterminate (whether the duration is known or not known) and spinner vs. bar. The variations in border thickness are deliberate based on the context where it will be used. Refresh the page to see the examples run.
Spinner blocking or replacing the component space. Spinner would be replaced with loaded contents after a <1 second delay for the user to see the successful green state. Refresh the page to see the animation run.
Transparent gray overlay with spinner or progress bar. Overlay popup would dismiss itself (the user should not have to take action to dismiss this type) to reveal the loaded page or panel after a <1 second delay for the user to see the successful green state.
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.
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 darker highlight colors for the main summary/total bar. Do not hide bars as they complete as that changes the layout and makes it difficult to visually track which items are still in progress.
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
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. Also see the breadcrumb truncation section.
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.
More than one row of tabs is unacceptable. When the need for multi-layer navigation is needed, alternate methods of tab-like navigation should be used.
A number of libraries exist that solve this problem in different ways, like Slick or OwlCarousel. Bootstrap has a carousel built in. Whatever technology is used, it should be styled like and support behaviors as seen here.
There are two types of selection: location and objects.
Location
Location, the page you are on, uses blue background with white text in a menu system, or white background with bold black text otherwise.
Objects
Selected objects that are not pages or locations use yellow background with gray text. For selected data on a full-color chart, a purple background with white text is used.
Hover
Selected styles are not to be confused with hover states. Hover states only highlight the location of the cursor, and should be differentiated from selection styles.
Use an ellipses. Hover on desktop shows full value. Select on mobile show info-popup that shows full value. Avoid wrapping or scrolling text in the input (DO NOT make it so navigating the cursor is the only way to read the value.
Really long header content like you wouldn't believe a header could be
Heading
Non-banded row
Really long cell data content like a data cell really shouldn't be
Banded row
Data cell
Non-banded row
Data cell
Banded row
Data cell
Breadcrumb Truncation
Truncation algorithm should be responsive based on available screen real estate. Always show the current location in full. Always try to show the root location in full.
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.
Help Menu
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.
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.
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.
The label should be a user-friendly name or phrase no more than 4-5 words in length. Avoid sentences for labels.
The prompt text should be a sample value only. DO NOT USE THE PROMPT TEXT AS THE LABEL.
Use an info icon to provide additional details that are required to fill out the input.
The tooltip should provide additional details to fill out the input. Hover to see a proper usage of tooltips providing additional information.
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.
These are the generic CallidusCloud launch screens that can be used for any mobile offering.
iOS
Apple iOS guidelines specify having launch screens that appear like the actual app but without any text, giving the appearance the app is loading faster than it is. Until all those screens can be generated per product, these are the generic CallidusCloud launch screens that can be used for any mobile offering.
Example Launch Screens
Landscape 1024 x 768 @1x
Portrait 640 x 1136 @2x
Error:DO NOT MODIFY, CHANGE THE FILE FORMAT OR RESIZE THESE IMAGES. USE AS IS.
Added a presentation to the design section showing the vision for how the guidelines play into the end to end customer experience. Minor fixes to example charts for display.
v3.1.1
Fixed links in the changes section to prior versions of guidelines in archives.
Added margins vs borders section. Breadcrumbs updated to show mobile variant. Minor fix for heading examples (TOC styles were interfering with the Callidus heading styles.
v2.4
Added carousels section. Updated complex grids section. Code clean up. Fixes for in-page menu guidance. Removed Angular and some unused JQuery plugins.
Bugfix for TOC navigation. Previously, coordinates/positions of sections were not correctly calculated in Chrome, causing a single menu link to appear to toggle between two disparate, unrelated locations.
Added guidance on label placement for translation in the input layout section. Added info popup guidance to the Contextual Help section. Updated the font spec to a new and simpler method. Updated progress spinners to a new, lightweight Font-awesome method.
Added header guidance when products are embedded in other products.
v1.6.2
Buttons styles dropped flat color with '2.0', but examples across the guidelines needed to be updated to conform. Also addition of header guidance when products are embedded has been started. (In progress, not complete.)
Added a patterns section and restructured the document in a couple places.
v1.5.1
Updated email template incorporating changes necessary by Ops team to work across various supported email clients.
v1.5
Significant re-write and restructuring of the document. Now fully responsive. HTML/CSS code examples added for all sections. Visual Spec sections TBD. Expand/Collapse navigation section TBD.
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.