Cummins Web Design Standards v2.0
Visual and interaction guidelines for responsive website and application design
Cummins User Experience Team
January, 2015
TABLE OF CONTENTS Overview ...... 6 Introduction ...... 6 Target Browsers and Devices ...... 6 Responsive Design Guidance ...... 7 General Principles for Navigation ...... 8 Color Palette ...... 9 Main Colors ...... 9 Accent Colors...... 10 System Feedback Colors ...... 11 Gradients and Patterns ...... 11 Typography ...... 13 Weights and Styles ...... 14 Fonts Use Guidance ...... 14 CSS Font Properties ...... 18 Page Type ...... 20 Responsive Design Guidance ...... 20 Home Page ...... 21 Design and Layout ...... 21 UI Specifications ...... 22 Log In Page ...... 25 General Guidance ...... 25 Design and Layout ...... 26 Web Site Landing Page ...... 27 Design and Layout ...... 27 UI Specifications ...... 29 Web Application Landing Page ...... 32 Design and Layout ...... 32 Dashboard ...... 33 General Guidance ...... 33 Design and Layout ...... 33 Elements ...... 34 UI Specifications ...... 35 Interactions ...... 37 Internal Page ...... 38 Design and Layout ...... 38 Elements and UI Specifications ...... 39 Forms ...... 42 General Guidance ...... 42 Design and Layout ...... 44 Elements ...... 45 UI Specifications ...... 45 Interactions ...... 49 Search Results Page ...... 50 General Guidance ...... 50 Design and Layout ...... 51 UI Specifications ...... 52 Dialogs ...... 55 General Guidance ...... 55 Elements ...... 56 Design, Layout and UI Specifications ...... 57 Interactions ...... 60 Error Page ...... 61 General Guidance ...... 61 Design, Layout and UI Specifications ...... 62 UI Components ...... 64 Component Placement ...... 64 Headers and Footers ...... 64 Global Navigation ...... 64 Site ID and Primary Navigation ...... 67 Search Feature ...... 72 Banner Carousel ...... 76 Banner Image and Text Content ...... 82 Fat Footer ...... 85 Social Media Footer ...... 92 Slim Header ...... 93 Global Footer ...... 97 Slim Footer ...... 102 ePrivacy (Cookie) Widget ...... 106 Navigation ...... 108 Primary Navigation ...... 108 Left Navigation ...... 108 Breadcrumb Path ...... 114 Popular Links ...... 118 Step Wizard ...... 121 Pagination ...... 124 Tab Panels ...... 127 Accordion Panels ...... 131 In-page Carousel ...... 136 Small Promotion Block ...... 140 Content Table (Website) ...... 145 Data Table (Application) ...... 149 Charts ...... 161 Form Elements ...... 166 Drop-down List ...... 166 Radio Buttons and Checkboxes ...... 171 Multi-Select List ...... 174 List Builder ...... 177 Date Input ...... 180 Upload ...... 185 Contextual Help ...... 188 Field Set ...... 190 CAPTCHA ...... 190 Buttons (Website) ...... 194 Buttons (Application) ...... 195 Other Components ...... 202 Log In ...... 202 Delay ...... 208 Share ...... 214 Export ...... 219 Ratings ...... 223 Inline Messaging ...... 226 Future Work ...... 231 Reference ...... 231 Appendix ...... 232 Digital Icons System at Cummins ...... 232 UX Team Accessible Design Guidelines ...... 233
OVERVIEW Introduction This documentation of Cummins web design standards is created to support a consistent and usable user experience on all Cummins websites and applications. To identify usage of some components, W for websites or A for applications is denoted in the title. This documentation does not reference specific technologies. It should be referred to by anyone involved - whether directly or indirectly – in collecting requirements, designing, developing and implementing Cummins websites and applications. The audience includes but not limited to: Website or Application Owners, Project Managers, Business Analysts, Web Producers / Designers, Developers, Content Managers, Communication Managers and Associates.
Use this document as standards to follow when creating a new website or web application, or any time there are updates or redesign for existing ones. The guidelines are organized and structured in a hierarchy beneficial to Web production using either a content management system or a basic HTML authoring approach. It contains specific guidance for commonly used page types (e.g., Home Page, Search Result page) and user interface (UI) components (e.g., headers, footers, tables). Sample content is inserted when it is useful to communicate the application of these standards.
This document is not for native mobile applications. For native mobile applications please refer to Cummins Mobile UX, Interface, and Interaction Design Patterns Connections WIKI.
For icon images, please refer to Cummins Web Icon Library.
If there are any questions or clarifications required for this document, please contact Karen Falkner through [email protected]. Target Browsers and Devices Browser Device/Platform Browser Versions
Minimum Latest
Internet Explorer PC: Windows (7/8) 9 11
Windows Phone (7.8, 8)
Firefox PC: Windows (7/8)
Page 6 Overview Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Mac: OSX (10.6 +) 24.5 ESR 29
Android (4.0+)
Chrome PC: Windows (7/8)
Mac: OSX (10.6 +) 32 33
Android (4.0 +)
iOS (6.1 +)
Safari Mac OSX (10.6 +) 6.1.3 7.0.3
iOS (6.1 +)
Responsive Design Guidance Breakpoints, Viewports and Content Linearization
Cummins is committed to creating experiences that meet and exceed our customer expectations. For this reason, whenever possible and appropriate, all web projects should be developed to function on a range of viewports and device types, with keyboard, mouse and touchscreens. All web content should “linearize” on small screens to be readable and usable in mobile contexts.
Cummins has 3 primary breakpoints: 920px (for average desktop and laptop display), 750px (for average tablet display), and 320px (for mobile display on older devices and feature phones). At these breakpoints, the design changes to the specified layouts that follow in this document. All pages and design components in this document are fully-responsive, and scale to the width of the viewport. The design is specified and should be checked at least at these three viewports – 1024px, 800px and 320pxThe following are the breakpoints details in which the design shifts from one layout to another:
Device Viewport Breakpoint
Desktop & Laptops 1024px 920px
Tablets 800px 750px
Smartphones 320px 300px
Page 7 Overview Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Depending on the project, screens as small as 240px wide and larger than 1024px may need further guidance from the UX Team. Top navigation tabs change to the mobile “hamburger” menu icon (see Site ID and Primary Navigation) when tabs will not fit the screen width. Both portrait (vertical) and landscape (horizontal) display are equally-well supported on all devices. Switching orientations must not redraw the screen: all user selections or inputs on the page persist. All web pages and functions must be legible, usable and navigable on touchscreen devices, using a mouse and keyboard, as well as keyboard-only navigation. All web pages and functions must conform to Cummins Brand Standards. All web pages and functions must align with Cummins Accessible Design Guidelines. Unless otherwise specified, all text should be left-aligned on Cummins websites. This includes headers, accordion labels, footer links and page content. General Principles for Navigation These UI components should only link to pages within the site (open in the parent browser window):
Primary Navigation “tabs” and “hamburger” menu Banner Carousel on Home Page Left Navigation Popular Links menu These components may link to external pages on other sites (suggest new window for this):
Global navigation (specifically Other Cummins Sites) Fat Footer or Slim Footer Content Area Links (text or images) Promotional Area links (Small Promo Block) In-page Carousel links
Page 8 Overview Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 COLOR PALETTE Cummins color palette consists of a family of primary and accent colors, as well as gradients and patterns.
The main colors are used in the page headers, footers and navigation. Accent colors are used to provide additional focus and visual prominence; they should be used sparingly. The color teal is used in the Cummins Marketing pages to indicate links and as the on-hover state for most content-area navigation. Additional colors are used for system feedback.
All colors are web-safe colors and coordinate with the mobile application palette. Main Colors
Color Name Color Sample HEX # RGB Notes
Cummins D02323 208 The primary accent color in the top navigation, and used Digital Red 35 sparingly (rules, bullets) in content areas. Also the color of error 35 messaging on forms.
Red Selected 840909 132 Active and hover/tap state color for primary navigation tab. 9 9
Black 000000 0 Footer background color. Banner carousel background color. 0 Browser window background color. Header color. 0
White FFFFFF 2552 Primary content area background color. Color of Footer Links. 55 255
Text Grey #333333 51 Normal paragraph text and form label color. Hover State 51 background color for navigation links in Fat Footer, Slim Footer 51 and Global Footer.
Page 9 Color Palette Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Mid Grey 1 #666666 102 Drop-down menu text and bottom rule color. Optional grey for 102 color variation. 102
Mid Grey 2 #999999 153 Default color for global header icons. Optional grey for color 153 variation 153
Light Grey 1 #CCCCCC 204 Body Text Link underline color. Drop-down menu border color. 204 204
Light Grey 2 #E2E2E2 226 Alternating table row color. 226 226
Background #EEEEEE 238 Form background color. Grey 238 238
Accent Colors
Color Name Color Sample HEX # RGB Notes
Cummins #007C7C 0 Denotes clickable/tappable in general. Used as the “on-hover” Accent Teal 124 background color throughout the navigation system. This is the 124 color of text links.
Cummins #0E4E76 14 Use sparingly for items that need visual focus but are not Accent Blue 78 clickable/tappable. 118
Page 10 Color Palette Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 System Feedback Colors
Color Name Color Sample HEX # RGB Notes
Confirmation Green 8 Used to provide positive system feedback to users. Greens #08A74D 167 77 Light Green 232 #E8FCBC 252 188
Alert Yellows Yellow 246 Used to alert users to a potential problem or to highlight #F6BA29 186 something on screen that needs user input/attention. 41 Light Yellow 255 #FFF0C5 240 197
Error Red Red 208 Used to alert users to input errors on forms. This color should #D02323 35 be used for errors only if the user must remediate before 35 continuing. Light Red #FDEDED 253 237 237
Gradients and Patterns
Color Name Color Sample HEX # RGB
Red Gradient #D02323 208 Header and primary navigation background color. Website #B11314 35 Special Action button color. 35
Page 11 Color Palette Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 177 19 20
Black #666666 102 Website Primary Action button color. Application Secondary Gradient #000000 102 Action button color. 102
0 0 0
Light Grey #EEEEEE 238 Optional background gradient to use for differentiating content Gradient #CCCCCC 238 block 238
204 204 204
Teal Gradient #006666 0 Web application Primary Action button color. #003635 102 102
0 54 53
Accent Lines: 215 Subtle pattern to differentiate screen area dedicated to Pattern #D7D7D7 215 promotion and cross-selling. 215 Background:
#EEEEEE 238 238 238
Page 12 Color Palette Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 TYPOGRAPHY Cummins Corporate font is Helvetica Neuei. If that font is not available to the end user, the following fonts, in the following order, are specified: Arial, Default Sans Serif.
Helvetica Std., Helvetica LT, Helvetica Rounded and all other Helvetica font variations are considered off-brand. Italic versions of this font are available, but not recommended for general web use because they are not as easily readable. If italic fonts are required for emphasis, please use the
Page 13 Typography Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Weights and Styles Brand Font Display “Font Mapping” Values Arial Display
Helvetica Neue 55 Roman font-weight = 300 Helvetica Neue 65 Medium font-weight = 500 Helvetica Neue 75 Bold font-weight = 700 Helvetica Neue 85 Heavy font-weight = 800 Helvetica Neue 95 Black font-weight = 900
In CSS, specify font-weights with their correct font name, as well as by numeric font-weight values. Correct use of the font-weight property and the font stack ensures that, if users don’t have the Helvetica Neue font available, an appropriately corresponding weight of the font Arial will display. The table below specifies the correct font-weight property for each Helvetica Neue font within the current Style Guide. QA testing on multiple browsers/devices, and possible adjustments to these values, is required to display the proper weight. Note: context of site may change the appropriate value. Fonts Use Guidance
Text Name Text Sample Desktop Mobile (screens below 921px wide)
Heading 1 Text Text Helvetica Neue 85 Heavy Helvetica Neue 85 Heavy (one per 30/32px #000000 24/28px #000000 page) Rule Rule 2px tall (Same as Desktop)
#007C7C under the text and #CCCCCC after
Page 14 Typography Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 10px below text baseline Last text line only if multi-line header
Heading 2 Text Text Helvetica Neue 85 Heavy Helvetica Neue 85 Heavy
24/26px #000000 18/20px #000000
Rule Rule 2px tall (Same as Desktop) #CCCCCC under the text 6px below text baseline Last text line only if multi-line header
Heading 3 Helvetica Neue 85 Heavy Helvetica Neue 85 Heavy 18/20px #000000 15/17px #000000
Heading 4 Helvetica Neue 55 Roman Helvetica Neue 55 Roman 18/20px #000000 15/17px #000000
Page 15 Typography Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Normal Helvetica Neue 55 Roman Same as Desktop. Text / 13/20px #333333 (12/18px is also acceptable.) Paragraph Left aligned, no paragraph indent, 12px space between paragraphs
Link Text Same as Desktop.
Helvetica Neue 55 Roman (12/18px is also acceptable.) 13/20px #007C7C
Underline 1px tall #CCCCCC 4px below text baseline
Hovered Text Same as Desktop.
Link Helvetica Neue 55 Roman (12/18px is also acceptable.) 13/20px #003333 Underline 1px tall #CCCCCC 4px below text baseline
Visited Link Text Same as Desktop. Helvetica Neue 55 Roman (12/18px is also acceptable.) 13/20px #666666
Underline 1px tall #CCCCCC 4px below text baseline
Page 16 Typography Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Block Quote Text Quote Text Quote Helvetica Neue 55 Roman Helvetica Neue 55 Roman 18/24px #000000 15/17px #000000 (Left Left padding: 25px Left padding: 20px aligned Indent: 30px Indent: 24px
Source Text Source Text Helvetica Neue 55 Roman Helvetica Neue 55 Roman 13px #999999 10px #999999
Vertical Rule Vertical Rule 4px wide #007C7C 4px wide #007C7C Same height as quote block, left Same height as quote block, left aligned with body text on page aligned with body text on page
Unordered Text Text List Helvetica Neue 55 Roman Same as Desktop. 13/24px #333333 (12/18px is also acceptable.)
Bullets Bullets 20px hanging indent 16px hanging indent +15px additional line spacing +12px additional line spacing between bullet items between bullet items Top level: Square, 4px Top level: Square, 4px
Ordered Text Text List Helvetica Neue 55 Roman 13/24px Same as Desktop. #333333 (12/18px is also acceptable.)
Bullets Bullets 20px hanging indent 16px hanging indent +15px additional line spacing +12px additional line spacing between bullet items between bullet items Numbers are Helvetica Neue 65 Numbers are Helvetica Neue 65 Medium Medium
Page 17 Typography Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Hint Text Helvetica Neue 55 12/15px, #666666, Italic Padding: 10px, all sides
‘Field Label #333333
Drop-down #333333 List Text
CSS Font Properties HTML CSS Declaration Image Example Description Element Body font-family: “Helvetica Neue, Arial, Default Sans Serif";
H1 font-size: 30px; If the text container has appropriate padding, do not use line height: 32px; top padding for the H1 text. font-weight: 780; color: #000000; padding: 35px 0px 35px 0px;
H2 font-size: 24px; line height: 26px; font-weight: 800; color: #000000; padding: 35px 0px 20px 0px;
Page 18 Typography Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 H3 font-size: 18px; line height: 20px; font-weight: 700; color: #000000; padding: 35px 0px 20px 0px;
Page 19 Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 PAGE TYPE Responsive Design Guidance Viewports:
Maximum: 1800px Above that the page centers horizontally within the screen. Page background color: #000000. 300px to 1800px See each page type for details. Less than 300px Devices with viewports less than 300px should use this same layout, but the design is not optimized for these devices.
Page 20 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Home Page W1
Design and Layout 1024px Viewport 800px Viewport 320px Viewport
1 The W and A are used to identify usage: W standards for marketing website. A standards for transactional application.
Page 21 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Home page 1024px Viewport. For 921px and wider. Not to scale.
Page 22 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Home page 800px Viewport. For 751 – 920px wide. Not to scale.
Page 23 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Home page 320px Viewport. For 240 – 320px wide. Not to scale.
Page 24 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Log In Page W A All Cummins applications must use the Cummins Single Sign On System (COLA). However, this can be embedded as a component on a page in your site. This allows you to offer the brand experience, message to prospects and users, and reduce clicks/taps to access your secure products.
General Guidance Preserve the site formatting. The same template used for the rest of the site, including all brand items in the header and footer, will be displayed. Any navigation that can be accessed without authentication should be shown. Logged in users who return to this page should see all navigational items they have authority to access. Do not show navigational items that are not authorized for the user, which could create errors. Include information relevant to all users, or prospects, but be careful not to reveal proprietary information. Value of the service, the intended audience, and basic information such as service outage times are all good ideas. You may include relevant, appropriate graphics and link to other related sites or information. The Log In module is a component cannot be customized outside of the Single Sign On standards. Use the WWID as “Username.” Provide access to and leverage the Standard Cummins Password/Username retrieval process. If appropriate, provide access to a registration process. If your site uses a timer to force sessions to expire after a period of inactivity, load the Log In Page when the session expires. Include an Inline Message to indicate this is why the page is displayed.
Page 25 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Design and Layout A responsive sample Cummins Log In Page is provided below, using Cummins Standard Design components. Note that, in the examples below, no primary (top tabs), secondary (left navigation bar) or footer navigation display if the user is not logged in. The Global Header and Footer, as well as the Search Function and Site ID, should display and function as appropriate to the site context.
1024px Viewport 800px Viewport 320px Viewport
Page 26 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Inline Message
Web Site Landing Page W A
Design and Layout Landing Page 1024px Viewport Landing Page 800px Viewport Landing Page 320px Viewport
Page 27 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015
Page 28 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Landing Page 1024px Viewport
Page 29 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Landing Page 800px Viewport
Page 30 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Landing Page 320px Viewport
Page 31 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Web Application Landing Page A
Design and Layout Web Application 1024px Viewport Web Application 800px Viewport Web Application 320px Viewport
Page 32 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Dashboard A
General Guidance Dashboards, or portals, are composed of multiple modules (portlets) of information, display, input or control. They are most often used as the landing page for a site, or group of websites or web applications, to provide a summary of the actual content and controls, not just links to each of them. Dashboards summarize information to allow focus on changes or exceptions in the data. Dashboards can also be used organize tasks/functions and provide a central starting point instead of using tabs or hierarchical navigation structures. Each module or “portlet” in a dashboard should represent a piece of content that occupies its own space on the website/application or another one. The Dashboard design layout highlights essential content at a glance, in an organized and effective way. Dashboards provide a high-level view of what is happening, but not why it is happening. Users may drill down for more details to understand the data better. A Dashboard is useful in displaying and managing a large quantity of dynamic data that must be monitored. Focus on changes and exceptions in the most critical data. Information that deviates from “the norm” is often the most important information to the user. Content should be displayed live, and be interactive as much as practical. Do not display screenshots or static images of information. Follow guidelines in Charts & Graphs, Tables and others from this document. Content should be organized into meaningful groups, personalized to the user or user category.
Design and Layout
Page 33 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Elements
Page 34 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Dashboard Page 1024px and 800px Viewports
Page 35 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Dashboard Page 320px Viewports
Page 36 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Dashboard Portlet
Interactions
Page 37 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Internal Page W
Design and Layout Internal Page 1024px Viewport Internal Page 800px Viewport Internal Page 320px Viewport
Page 38 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Elements and UI Specifications Internal Page 1024px Viewport. For 921px and wider. Not to scale.
Page 39 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Internal Page 800px Viewport. For 751 – 920px wide. Not to scale.
Page 40 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Internal Page 320px Viewport. For 240 - 320px wide. Not to scale.
Page 41 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Forms W A
General Guidance Overall Use commonly accepted HTML form conventions, avoiding unnecessary customizations, whenever possible. If a form is 2-column, the read order and tab order should be top to bottom of left column first, then repeat for right column. Group related form inputs together logically with Fieldsets. Programmatically associate them with Fieldsets as well. Avoid requesting “optional” information; users rarely provide it and it makes the form longer. If a form has several optional inputs, clearly indicate required inputs with a red asterisk and provide a key. Use the language: “* Asterisks (*) indicate required information.” Avoid errors by providing selectable options whenever possible. Use CAPTCHA to validate that a human is working with your website/application only if no other option is available and ensure audio option is available. Note that CAPTCHA use carries a risk of form abandonment. Text entry fields should not be significantly longer or shorter than the inputs they request (we suggest 1 character longer than the maximum value), and should be able to display an input value of the maximum allowed characters at default browser text size. Avoid compound, multi-field inputs, such as 3-field phone number inputs. Linearize form for display on mobile device to display in a single column. Buttons may display at full width of viewport less than 751px wide. Ensure that at screens less than 751px wide, at least one form field is visible on page load. Limit instructions at the beginning of the page to support this. All forms display on a background of #EEEEEE. Labels, default values and hint text Use brief, consistent and unambiguous labeling conventions. Maintain consistency with other Cummins forms on common terms like “Log In,” “Log Out,” “Username” and “ZIP/Postal Code.” Consider international differences and use sentence case (only first word should be capitalized unless a proper noun.) Avoid all capital letters. Colons are not necessary, but if used, ensure that no space precedes them, and that a * Required indicator displays after the colon. Labels may display left of fields or above fields. New mobile and web trends are to stack labels on top of fields, but screen real estate and purpose of form factor in to this design decision. Avoid large gaps between fields and their associated labels by right-aligning labels that are displayed to the left of fields. Field labels should only be displayed within field if there is a backup mode of communicating field’s purpose (because the label will disappear on focus).
Page 42 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 “Hint text” that displays in field to clarify the function or requested input (like “Search”), should be #666666 grey and italics so field doesn’t look already filled in. In HTML5, this is called “placeholder text.” This data can’t be submitted and if not replaced by user input, field should be treated as “skipped”. Prepopulate fields with known or available information whenever possible (maintain editability). Avoid displaying “hint text” within text fields, and if necessary, display it and don’t allow form to submit if skipped. If contextual help text is needed, display them on focus to the right of the field. Avoid it if possible. Ensure that field labels and error messages are programmatically associated with each related field, and that field IDs are uniquely named. Buttons Primary action buttons display on the left; the “most destructive” actions go on the right. Sample button labels (from left to right): Submit | Cancel | Clear Form Use brief, descriptive button labels when possible. Do not use multi-line button labels. Form buttons should not be individual images; use scalable HTML buttons that are styled with CSS to support longer labels. Button label text should increase when users engage native browser text zoom functionality. Buttons are specified to have “on-hover” states for desktop contexts; mobile contexts do not display this state. Buttons are specified to have “on-tap/click” states for both desktop and touchscreen contexts. Disabled button states should be used if clicking/tapping the button might result in an error. In some cases, it is preferable to disable a button until it is relevant and appropriately actionable, such as after client-side validation has successfully confirmed that all required fields have been filled and that all fields have the correct input format. Do not suppress the display of buttons. Form validation and system feedback Avoid users generating forms that have errors whenever possible by validating at appropriate times: o Client-side for each field, “on blur” – validate for incorrect formats. o Server-side for skipped fields and fields that require back-end validation using AJAX to display as soon as possible, or if performance is an issue, on “Submit”. Prioritize early validation of service-related information such as user name, phone number, etc. Avoid errors by accepting multiple formats and stripping out dashes, parentheses, etc. Don’t put the burden on users to align with rigid format requirements. Avoid providing format suggestions and accept all formats. Don’t rely on color alone to communicate error. Include shape and value-contrast display to ensure users with colorblindness will perceive the messaging. Use inline messaging unless there are special reasons to use other format of messaging. Display confirmation messages on validated form submission – consider where user should “land” after submission and display confirmation at the top of that page if possible. Tell users what happened, what to expect next and what they can do immediately. Display specific, helpful remediation support, avoiding generic messaging whenever possible.
Page 43 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Display system feedback in-page, and locate message proximal to the error or, alternatively, near the “submit” button. If possible, display a confirmation or summary of errors at top of page. Disable the “Submit” button if errors are displayed on page.
Design and Layout Form Elements In Context
1024px Viewport 800px Viewport 320px Viewport
Page 44 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Elements For more details about form elements, refer to the Form Elements section in Design Components.
UI Specifications Form with labels on the left
Page 45 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Form with labels above
Page 46 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Messaging Problem or Error Messages
Page Level Errors
Page 47 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Field Level Errors/Alerts/Confirmations
Fields should be checked for validity as the user enters the data, or on-blur to assure completeness and validity. Only return errors on submit when absolutely required.
Page Level Errors/Alerts/Confirmations
Fields should be checked for validity as the user enters the data, or on-blur to assure completeness and validity. Only return errors on submit when absolutely required. When form-level errors are displayed this message will be displayed to summarize the condition that required recycling the form.
Error Messages
Alert Messages
Success Messages
Page 48 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Use common HTML conventions and native OS functionality whenever possible for mobile experiences. Avoid auto-advancing field focus. Clearly indicate focus. If a form is long, support saving and continuing, or auto-save in cache for duration of session. Default value for selectors should be “Select One” or “Select Options” unless there is a specific reason to default to one option. Default values for check boxes and radio buttons should be unselected, unless there is a specific reason to provide pre-selections. Don’t reset fields on submit if form display persists (such as in the event of errors).
Page 49 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Search Results Page W A
General Guidance The Search Results page can be one of the most powerful pages within a website. It provides the opportunity to deliver to users what they specifically request. Since it is a dynamic page, it also allows for the integration of related content that may “live” throughout a website, supporting cross-promotion and user-centered organization of content. The Cummins Search Results Page Type displays page titles and summaries, so that users can easily differentiate between results. It also contains an optional promotional “Right Rail” that can be used to promote content related to user’s search keywords or that the site owner wants to promote.
This page type is fully responsive and flexible. On smaller devices, one or more page links may display in the Pagination component, as appropriate to the viewport size. This page may also be used with the Slim Header and Slim Footer for Web Applications. Advanced Search Filtering will be added to a future version of the Cummins Web Design Standards.
Page 50 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Design and Layout 1024px Viewport 800px Viewport 320px Viewport
Page 51 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Search Result Page 1024px Viewport
Page 52 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Search Result Page 800px Viewport
Page 53 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Search Result Page 320px Viewport
Page 54 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Dialogs W A
General Guidance Dialogs are any component that are or appear to be laid on top of the parent web page. These are sometimes called “overlays,” “modals” or “lightboxes” when they are generated by the HTML, instead of being actual popup windows. Use dialogs sparingly, when it is necessary to completely interrupt users before they can continue. Many informational conditions can be better communicated to the user with Inline Messages instead of disrupting their process. There are three ways such dialogs can interact with the parent page, any of which can be used for any situation. Pick the proper one based on the needs of the system and the expectations of the user: o Modal – The dialog is a blocking condition, and the user must interact with it to proceed. To make this apparent to the user, the page behind the dialog is overlaid with 50% opacity black. This layer also is in the way of the page, so users cannot click/tap on items behind the dialog. There is no dismiss X icon for modal dialogs as the user must select a button. o Semi-Modal – Looks just like a modal dialog, but clicking/tapping anywhere outside the dialog will dismiss it. Can be used for critical informational notices, or functional processes the user may have initiated, but not for any required steps as the user can dismiss without indicating anything else. o Modeless – The dialog may operate alongside content on the page. It does not have a blocking layer behind, and when items on the page are clicked/tapped, they operate normally, without the dialog closing. Due to possible confusion with which item is in focus, this should be used rarely. Dismissal of a dialog is logically identical to the “Close” or a “Cancel” function, and is usually represented with an “X” icon in the upper-right corner of the dialog. When a dialog is functional, and user selections are made in it, dismissing the dialog will generally discard those changes. Icons should always be used in the dialog title, to communicate at a glance the category of function, information or if it is a critical alert or warning. Titles must be clear and specific to the user task at hand. Never use generic labels like “Alert,” or “Dialog.” Never use new windows to present this information. Never use alert boxes for any reason.
Page 55 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Elements
Page 56 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Design, Layout and UI Specifications
Page 57 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Optional Action (Modal or Semi-Modal)
Page 58 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015
Page 59 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Page 60 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Error Page W A
General Guidance Full page errors must be reserved for system-level, fatal-error issues. These should mostly be for numeric server errors, such as 404 and 500. All errors where the user may fix the condition by re-submitting different information, trying again, etc. should use the Inline Messaging, Dialog or Form errors. Full page errors present no information except for the error itself. Preserve the site formatting. The same template used for the rest of the site, including all navigational and brand items in the header and footer, will be displayed. An error icon precedes the text of the H1 to make it clear that this is not any other page. The page title is a user-friendly error message. Describe the issue in ways everyone will understand. Explain the problem in more detail, offering ways the user is likely to be able to fix it. Take blame when possible, do not assign blame or imply the user performed an error, even if this is likely. Include technical details, such as the webserver error number, at the end. Site wide options, such as the navigation and search, are provided to allow the user to navigate to the home page or attempt to find the information they were seeking. There is no need to add links within the body that do the same thing. Assure that errors do not forward to this page, to allow the user to press Back and return to the parent page. Otherwise, they will be incapable of escaping as the forwarder will always return to the fatal error.
Page 61 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Design, Layout and UI Specifications 404 Error
Page 62 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Log In Error Example
Page 63 Page Type Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI COMPONENTS Component Placement Most Cummins Components have 20px of spacing between them, both horizontally and vertically. Gutters between columns are 20px. Marketing Buttons have 15px of space between them. Application Buttons have 12px of space between them. On mobile devices, spacing between components and columns is generally 10px. Headers and Footers Global Navigation W General Guidance The Global Navigation bar provides a consistent location for users to:
Access customer support Select region and language Navigate between (selected) Cummins website/applications It is a common site element, but as appropriate, it may be omitted from certain site designs. It may be customized to meet the needs of the project, but should provide access to site-wide functions that support customers in using the whole site.
Page 64 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Elements
UI Specifications Languages display in the written language they reference, as shown here.
Global Header 1024px Viewport
Page 65 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Global Header 800px Viewport
Global Header 320px Viewport
Page 66 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Site ID and Primary Navigation W General Guidance The Cummins logo always displays in the upper left corner of the website/application, left aligned with the breadcrumbs, left navigation bar and all site content. The Cummins logo is 50px tall. There are 35px of horizontal space to the right of the Cummins logo, except on screens less than 751px wide, when that space is 10px. A minimum of 30px displays to the left of the logo (on screens above 750px wide). The BU Lockup or Site ID may be no taller than the Cummins logo. The BU Lockup or Site ID aligns with the top of the logo.
Page 67 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Elements
Page 68 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Site ID and Primary Navigation 1024px Viewport
Page 69 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Site ID and Primary Navigation 800px Viewport
Page 70 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Site ID and Primary Navigation 320px Viewport
Page 71 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interaction
Search Feature Elements Default Display
Triggered Search Feature Display
Page 72 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015
Suggested Search Term Display
UI and Interaction Specification Triggered Search Feature Display
Search Term Entry Display
Page 73 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015
Suggested Search Term Display
Search Results Display
Page 74 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interaction The entire site ID block is clickable/tappable and returns user to that site’s home page within the parent browser window.
Page 75 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Banner Carousel W Design and Layout The Banner Carousel displays only on the site’s Home Page, immediately under the primary navigation tabs for the full width of the screen. It may contain between 3 and 10 images and headline combinations (1 per image). Images must be selected or edited to create a dark area against which white text can easily be read. If using the available CSS, the style sheet will automatically create the darkened area in the photo. Images must not be stretched to fit either the static image or carousel banners. Images should have 72-96 dpi resolution when viewed at the browser’s default size. For optimal mobile performance and display, smaller size images may be required. The carousel navigation displays to the far left and right of the image. The carousel also has navigation at the bottom that indicates how many slides there are (white outline circles) and which one is currently displaying (white solid circle). The over state of the “pips” navigation displays in Cummins Digital Red (#D02323). The button is the “Special Action” button style, and follows those conventions.
Page 76 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Elements
Page 77 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Banner Carousel 1024px Viewport
Page 78 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Banner Carousel 800px Viewport
Page 79 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Banner Carousel 320px Viewport
Page 80 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Page 81 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Banner Image and Text Content W Elements
Design and Layout The page banner displays immediately under the primary navigation tabs for the full width of the screen. It contains a static image and HTML text. Do not embed text within the image. Images must be selected or edited to create a dark area against which white text can easily be read. If using the available CSS, the style sheet will automatically create the darkened area in the photo. Images must not be stretched to fit either the static image or carousel banners.
Page 82 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Banner Image 1024px Viewport
Page 83 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Banner Image 800px Viewport
Page 84 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Banner Image 320px Viewport
Fat Footer W General Guidance The Cummins Fat Footer Component is designed to be used primary on Marketing websites, or those that require categorized links to both internal and external websites. It is fully responsive and on small viewports, only the category headers display in Accordion Components. Since it consumes a lot of vertical screen space, it is not recommended for Web Applications; the Slim Footer Component should be used in these contexts. If used, the Fat Footer displays between the main page content and either the Social Media Component (if used) or the Cummins Global Footer Component.
Elements
Page 85 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015
If ePrivacy (“Cookie”) icon is required, it displays on every page in the site. Refer to ePrivacy Widget Specifications
Page 86 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Fat Footer 1024px Viewport
Page 87 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Fat Footer 800px Viewport
Page 88 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Fat Footer 320px Viewport
Page 89 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions Fat Footer 1024px and 800px Viewport
Links within the site always load in the same target (window or tab, based on browser default behavior). Links outside the site (shared Cummins items such as privacy policy, entirely other Cummins sites, and third parties) always load in a new target (window or tab, based on browser default behavior).
Page 90 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Fat Footer 320px Viewport
On screens 750px wide or narrower, the Fat Footer links display in a single column with accordion “twistees” that are collapsed by default.
Page 91 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Social Media Footer W General Guidance Cummins Web Design Standards supports the inclusion of a Social Media Footer with links to the following social media sites: Twitter, Facebook and YouTube. Custom Cummins icons are used to link to these sites; additional icons are available by request through the Cummins User Experience Team. The Social Media Footer is optional, but if used, it displays right-aligned immediately above the Global Footer. UI Specifications
Page 92 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Slim Header A Slim Headers are useful to: Minimize the amount of screen real estate occupied by top navigation and site identification Slim Headers are most useful when an application has no marketing goals and branding requirements are minimal Group content and functions into a few logical categories so that the tabs display on screen for the most commonly used viewports Make tab labels brief, unique and understandable A large number of categories and/or long tab labels will result in the “hamburger menu” display of primary navigation, so users must click/tap to view navigation options When global navigation items won’t fit on-screen, they will collapse under a “gear” icon and be accessible on tap/click, so the length/number of primary navigation items will also impact the global navigation on-screen display
Page 93 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Design and Layout Slim Header 1024px Viewport
Slim Header 800px Viewport
Slim Header 320px Viewport (hover state display and enlarged views)
Page 94 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Elements
Page 95 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications
Page 96 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Global Footer W General Guidance The Cummins Global Footer should be used to provide users with site-wide information and should not change from page to page within the site. It always displays at the very bottom of a web page and is used in conjunction with the Fat Footer. The Cummins Slim Footer Component integrates the Global Footer within it, so it is not necessary to use the Cummins Global Footer if the Slim Footer is included. Common links that are appropriate to display here are: Privacy Policy, Terms and Conditions and Site Map (if available.)
Page 97 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Links within the site always load in the same target (window or tab, based on browser default behavior). Links outside the site (shared Cummins items such as privacy policy, entirely other Cummins sites, and third parties) always load in a new target (window or tab, based on browser default behavior).
Maintain a current Copyright date and address for the website in this location. A Global-Footer-specific Cummins logo displays in the bottom left and is not clickable. This is the only location that this version of the logo may be used. Additionally, if required by law, the ePrivacy (“Cookie Widget”) Component displays, as shown in these examples. This component is provided by a third party and is only specified in this document for reference. If required for a website, please contact Cummins IT to acquire the code that may be inserted in a web page so that this legal requirement is met. UI Specifications Global Footer 1024px Viewport
Page 98 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Global Footer 800px Viewport
Page 99 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Global Footer 320px Viewport
Interactions Global Footer 1024px and 800px Viewport
Page 100 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Global Footer 320px Viewport
Page 101 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Slim Footer A General Guidance The Cummins Slim Footer Component is designed for Web Applications, and for use when links do not require categorization and space is at a premium. It has a modular design with a flexible display that can be configured to meet the needs of the site, but the elements should always display in the order (top to bottom) shown in the examples below. Design and Layout
Page 102 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Slim Footer 1024px Viewport
Slim Footer 800px Viewport
Slim Footer 320px Viewport
Page 103 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Elements
UI Specifications Slim Footer 1024px and 800px Viewport
Page 104 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Slim Footer 320px Viewport
Interactions
Page 105 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 ePrivacy (Cookie) Widget Cummins sites that are accessed within countries that require ePrivacy notification (if cookies are used by the site) must display the Cummins ePrivacy Widget. This widget cannot be styled or modified, so the display and interactions are described in this document for reference only.
It is recommended that this widget links to the Cummins Cookies Website Notice and Disclosure Statement. Note that links within the site always load in the same target (window or tab, based on browser default behavior). Links outside the site (shared Cummins items such as privacy policy, entirely other Cummins sites, and third parties) always load in a new target (window or tab, based on browser default behavior). UI Specifications ePrivacy Widget 1024px and 800px Viewport
ePrivacy Widget 320px Viewport
Page 106 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Descriptive Layer The ePrivacy Widget, once triggered, displays according to 3rd party Standards. The image below is a description of the display, with specifications for reference only.
Page 107 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Navigation
Primary Navigation See Headers and Footers Section
Left Navigation W A Elements
Design and Layout
Page 108 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 This navigation element supports browsing pages within a specific section of the site. It facilitates moving between pages and sub-sections. The navigation bar displays on the left side of the screen, under the breadcrumb path. The navigation elements can be opened and closed; an arrow icon displays to the left of each section, showing the open or closed state of the navigation element. All “child pages” of the parent section display under opened accordion navigation sections. Use commonly accepted HTML semantic markup conventions, especially “list” whenever possible. An accordion element’s label displays immediately to the right of the arrow icon that opens and closes the menu, accordion labels are always left-aligned. Controls that are to the right may be overlooked by users. Menu items beneath a primary category are indented 10px and display in a lighter weight to represent parent-child page relationships. Match the label of a navigation element as closely as possible to its destination page’s H1, especially the first few words. Semantically label the navigation container as “navigation.” Maintain 30px space minimum between Left Navigation bottom rule and Footer.
Page 109 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Left Navigation 1024px Viewport
Page 110 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Left Navigation 800px Viewport
Page 111 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Left Navigation 320px Viewport
Page 112 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions The navigation labels change only when users navigate to a new section by clicking/tapping on a top, primary navigation tab. The active page displays in white, with dark rules above and below it. The active state of the left navigation bar indicates, in combination with the primary navigation tab active state, the user’s location in the site. The navigation menus’ active states must align with the breadcrumb path.
Page 113 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Breadcrumb Path W General Guidance The Cummins Web Standard Breadcrumb is primarily designed to support Marketing Web Sites, but may optionally be used on Web Applications. The path represents the page’s location within the site, not the path the user took to arrive at the location. Breadcrumb paths are useful to orient users within a site as well as provide navigation “up the tree.” They are particularly useful when browser’s native “Back” button become disabled, such as if the browser cache empties. Elements
Design and Layout The breadcrumb path supports users in both navigating through a site and orienting themselves within a site. It is especially useful for “backing up” to a previously visited page. The breadcrumb path displays directly above the content in a light grey (#EEEEEE) horizontal bar. The breadcrumb path doesn’t display on the site’s home page. The breadcrumb path links display in a style similar to Cummins Web Design Standards for in-page text links: Cummins teal with a dark grey custom underline. Over and active states align with Cummins Web Design in-page link standards. Triangle icons (link separators) and 10px of horizontal space on either side of the icons separate the page titles.
Page 114 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Breadcrumb Path 1024px Viewport
Breadcrumb Path 800px Viewport
Page 115 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Breadcrumb Path 320px Viewport
Page 116 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions Page Titles (H1s) should be reflected as closely as possible in breadcrumb paths, and should be brief but meaningful and descriptive. Breadcrumb paths should display in a single row if possible. For long paths on any viewport size, it is recommended that the small viewport “truncation display” be used if the full path would display in more than one row. The breadcrumb path aligns with the site architecture and displays a user’s location within the site at all times. The Search Results page has only two links in the breadcrumb path: “Home” and “Search Results” The active page always displays as a non-link.
Page 117 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Popular Links W General Guidance Popular Links are useful if sites contain important or commonly used pages that may be difficult to navigate to using a site’s primary and secondary navigation. In a drop-down menu, many direct links to pages within a site may be accessed by users. The Cummins Web Design Standards specify that the Popular Links Component display in the “Right Rail” area reserved for promotional content. Although they may be contextual and vary from page to page, users may not expect the content of the drop-down menu to change. Be sure to allow sufficient space between this drop-down menu and promoted content displays in the Right Rail so that they do not appear to be related to each other. Elements
Page 118 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications (All Viewports)
Page 119 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Page 120 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Step Wizard W A General Guidance A wizard is a component that makes it easier for your users to understand and follow multi-page processes. Whenever possible, make forms dynamic, simple and single-page or single-step. Only use the wizard when absolutely required due to technical constraints such as systems that rely on processing by a previous system first.
Do not use the presence of the wizard to make your process complex. Use as few steps as possible still, and never exceed about 5-7 steps in any process.
Use different styling for past, current and future steps. Clearly label each step, so the user knows what to expect in the future, and on the current step. The user should be able to use the wizard to return to previous steps to change entry. Whenever possible, preserve user entry, so as subsequent already-completed steps are shown, they are partially filled in. The wizard cannot be used to skip steps and work ahead. They must select the Next button to submit the information and will then be presented the next page Elements
Page 121 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Step Wizard 1024px and 800px Viewport
Step Wizard 320px Viewport
(Refer to the 1024px and 800px viewport for specifications.)
Page 122 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 In Context
Interactions
Page 123 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015
Pagination W A General Guidance The Pagination Component displays at both the top and bottom of the Search Results page and allows users to navigate through multiple pages of results. The size of the viewport dictates how many page “buttons” can display; this component always displays in a single row. It is designed with target areas that are finger-tip sized so that users of touch screens can easily navigate them. On touch screens, the hovered display is assigned to “tap.” Elements
Page 124 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Pagination 1024px Viewport
Pagination 800px Viewport
Page 125 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Pagination 320px Viewport
Interactions
Page 126 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Tab Panels W A Elements
Design and Layout Tab panels display in the content area of a web page. Tab panels may be any width that fits in the content area, but tabs may never display in more than a single row. Tab labels expand to fit the width of the label. Tab labels may wrap to two lines, but no more. Tab labels should be brief and descriptive, and not change based on tab status. Tab panels display on a light grey background that defines the border of the panel. Content beneath the grey box is understood not to be part of the tab panel. Most types of content can display within tab panels, if space allows. UI Specifications Tab Panels 1024px Viewport
Page 127 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015
Page 128 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Tab Panel 800px Viewport
Tab Panel 320px Viewport
Interactions
Page 129 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Tab panels are used to maximize the amount of information that can display on a page and limit scrolling. Tab panels don’t support viewing or printing of all page content at once, so shouldn’t be used if this is required. Users may click/tap tabs to see different “facets” of the page’s content. The entire tab is clickable/tappable (not just the text). The left-most tab is always open by default and should contain the most important information. The font color and its background change on hover/tap and on click to display the tab’s status (active, inactive or hovered over). Tabs may never be used to launch new pages or to navigate away from the active page.
Page 130 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Accordion Panels W A Elements
Design and Layout Accordion panels may be used for Desktop views as well as smaller and touchscreen devices. Accordion panels display in the content area of a web page. Most types of content can display within Accordion panels, if space allows. Accordion panels expand to fit the width of the content area or screen, not the length of the label. Accordion labels are left-aligned. Accordion labels should be brief and descriptive, and not change based on tab status. Accordion labels may wrap to multiple lines if necessary on smaller devices, but 2 lines is the recommended maximum number of lines. Open/close icons always display to the left of the Accordion label.
Page 131 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Accordion Panels 1024px Viewport
Page 132 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Accordion Panels 800px Viewport
Page 133 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Accordion Panels 320px Viewport
Page 134 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions Accordion panels don’t change display based on viewport (as Tab Panels do). The font color and its background change on hover/tap and on click to display the accordion menu status (active, inactive or hovered over). The icon to the left of the label indicates the accordion element’s status (open or closed). The entire label block is clickable/tappable (not just the arrow). Accordion elements can only be opened and closed by users; no sections should automatically close or open. The single exception to this is that the TOP navigation element may be displayed as open by default. Accordion panels may never be used to launch new pages or to navigate away from the active page.
Page 135 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 In-page Carousel W A General Guidance In-page carousels are useful to:
Promote items, events and content within a site Link to important external content Regularly update page content that is timely Provide visual interest on a page Optimize screen use by displaying multiple “slides” in a small space Use Guidance:
The In-page Carousel may contain between 3 and 10 images and Headline combinations (1 per image). The layout is 2-column with the image on the left (consuming half of the available width) and text on the right, except on screens less than 751 px wide, which display as a single column. The carousel may vary in height by the height of the image, and text content should be roughly the same height as the image. Images must not be stretched to fit the space; crop images if necessary to be the correct proportion. Images should have 72-96 dpi resolution when viewed at the browser’s default size. For optimal mobile performance and display, smaller size images may be required.
Page 136 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Design and Layout
Elements
Page 137 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications
Page 138 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Page 139 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Small Promotion Block W A Elements
Page 140 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Small Promotion Block 1024px Viewport
Page 141 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Small Promotion Block 800px Viewport
Page 142 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Small Promotion Block 320px Viewport
Page 143 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Page 144 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Content Table (Website) W Elements
Page 145 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Content Table (Website) 1024px Viewport
Page 146 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Content Table (Website) 800px Viewport
Page 147 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Content Table (Website) 320px Viewport
Page 148 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Data Table (Application) A At Cummins, almost any complex information that needs to be displayed as raw data should be in a table. To better visualize the data, they should be accompanied by a Chart or Graph, and to allow the user to manipulate it themselves you may also wish to provide an Export function.
Tables should only be used for the display of tabular data. Do not use tables to control layout as these layouts will not meet Cummins' Only display as many columns will fit on the page. Never let tables scroll sideways. If more data is available, and important, add a function so the user can select which columns to show. If a single or key action is available for a row (such as viewing details) make the title a link to that action or page. When there are additional actions, or no one action, add an Actions column to the far right, with icons for all the possible functions. Remove actions not available for a particular row. If the same action is likely to need to be executed on multiple line items, add a batch action function. Checkboxes in front of each line allow selection of some or all items. Buttons below the table become active when at least one item is selected. If the user can change the data displayed in the table, try to provide this function organically. For example, add a row by making this function a row at the top or bottom of the table. When completed, the new row will appear in that location. If there has to be large sum of content, consider using (expandable) accordion format for each row. Allow inline editing if needed.
Page 149 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Design and Layout 1024px Viewport
Search section expanded
This can be the default status of the search section. If there are concerns about the space on the page, consider using the collapsed mode. Below.
Page 150 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Search section collapsed
If there are basic and advanced filters, the collapsed view can be the default view. Or if there are concerns about space on the page, this view can be used as default. Users can collapse and expand the section anytime.
If there need to be no distinguish between the expanded and collapsed modes, remove the link on the low right.
Page 151 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 With search results
Keep the search section expanded, if any of the filters that only show up in the expanded mode was used for that search. If not, showing the collapsed mode is fine.
Data Table 800px Viewport
Page 152 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Changing from 1024 to 750px view, shorten columns width or display less columns accordingly.
Page 153 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Data Table 320px Viewport
Elements
Page 154 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015
Page 155 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Data Table 1024px Viewport
Page 156 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015
Data Table 320px Viewport
Page 157 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions Search section expanded and collapsed
Page 158 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 With search results
Page 159 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 With Search Results and collapsed filters
Page 160 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Charts W A The visual display of data, as charts and graphs, is very helpful to communicate complex information, see trends and variations, and to monitor performance and behaviors. Provide charts whenever they will be useful, but abide by these standards to assure they integrate well with the rest of the site, work for all users, and support the Cummins brand: Keep data simple by default. Show the minimum amount of information needed to communicate the message. Provide access to the raw data. Allow the user to flip to a table view, or scroll down to see the data in tabular format. Especially when able to be downloaded as a spreadsheet, this provides users complex sorting and view controls, so edge cases do not have to be addressed in the web interface. Label all axes, and whenever possible start at zero to make data visualization truthful and clear. Use only Cummins Standard Chart Colors, and be sure appropriate contrast is used between colors and labels. Clearly label all data shown. Whenever there is room, label lines, bars and pie segments directly, or as close to the related chart segment as possible. Annotation lines may be used if labels cannot be located close enough to their related segments for clarity. Avoid labels on top of colored chart segments when possible. If labels must overlay the chart itself, maintain a 4:1 contrast ratio for legibility. Using the provided Cummins Chart Colors will ensure this requirement is met. When legends are needed, display them within or adjacent to the chart, preferably bound together with the chart, as shown in the provided examples, not elsewhere on the page. Charts do not have to be restricted to static content, but can reflect live information or visualize different information based on selections the user makes elsewhere in the page. Users can do things like change date ranges, add, and remove parameters. Do not embed raster (bitmap) images as charts. Generate charts using code, so they are responsive, resizable, and the data is accessible by screen readers and bots. Do not use technologies that are only partially supported or require plugins, such as Flash.
Page 161 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Cummins Standard Chart Colors
There is no need to develop your own charting software. There are numerous libraries that use modern technologies—Javascript and CSS Canvas. Charts may be created using external software that comply with Cummins Web Design Standards as long as you follow the colors, type and other guidelines outlined here. Do not use the default styles.
These are two industry-leading tools: http://www.rgraph.net/ http://www.highcharts.com/
Page 162 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Bar Use to compare metrics for a “snapshot” view
Only absolute values should be used as labels. If displaying percentages of a total, use a Pie Chart.
Page 163 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Pie Use to compare percentage metrics that add up to 100%, such as survey responses.
Page 164 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Line Use to compare metrics of multiple items over time
Use to visualize trends
Page 165 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Form Elements W A
Drop-down List General Guidance A Drop-down List is used when user needs to make one selection out of several, usually on a form. When there are very few selections, or space is not limited, consider using the Radio Buttons, but when the list of selections gets longer, or space is limited, a Drop-down List will often be a better solution. The Cummins Web Design Standards also uses this component styling in other components, such as the Global Header, Primary Navigation and Popular Links components. All drop-down controls on Cummins web sites and web applications should be consistent to improve usability. Design and Layout
Label Above Control Label to Left of Control Error States Default Display: Default Display:
Focused Display: Focused Display:
Page 166 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Elements
Default Display Focused Display
Post-selection Display: Error Display:
Page 167 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications
Page 168 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015
Page 169 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Page 170 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Radio Buttons and Checkboxes W A Radio buttons and checkboxes usually appear on forms. Both allow the user to make selections from a list of options. The difference is: radio buttons are used for selecting only one option from a list, while checkboxes allows the user to select multiple options. When the list of options gets long, drop-down menus and Multi-Select Lists are used. Error Messaging
The error messages for radio button and checkbox should be similar to this:
Radio buttons: “Please select one of these options” Checkboxes: “Please select one or more of these options” Design and Layout
Partially Selected Checkbox can be applied to, for example, the checkbox in the title row of a data table.
Page 171 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 In Context
Elements
Page 172 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications
Page 173 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Multi-Select List W A Multi-select Lists are appropriate when a form must allow a user to select multiple options for a single input, especially if screen space is tight.
Conventional Drop-down Lists can support multiple selections, but the user must press modifier keys, so this works poorly and is to be avoided. List Builders are also complex to use and use a lot of room on the page so are unsuitable for many contexts.
A Multi-Select List works like a conventional Drop-down List, but with checkboxes to the left of each item. The list can be exposed from a normal input field, so takes little room, or may appear from an icon or navigational menu items.
Do not use icons along with the text labels. It can confusingly be perceived as a set of columns instead of rows. Use the shortest possible labels, both to prevent the list from wrapping, and to be used as selected-item labels when committed and not in focus. Assure the form works well for users without exposing the selections made. There is likely to be insufficient room for all selections to be listed when the list is not in focus.
Page 174 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Design and Layout
In Context
Page 175 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Elements
UI Specifications
Page 176 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
URL mentioned above: http://www.jqueryrain.com/?iF5ue7jr
List Builder List builders allow users to create customized selections of arbitrarily-large sets of information. A source list of all the available options are on the left, and the user adds or removes items from their target list to the right. The target list is easy to see, so for lists of widely-spaced items, may be the easiest way to see if the list is correct.
List builders are multi-select functions. Never use one when only a single item can be added to the light on the right. Organize all items in the source (available) list in a simple to find, meaningful order, usually alphabetically, by date or by number. Only include the Add/Remove All buttons if it is likely users will select all items, or most of them (it can be easier to un-select a few than selecting many). If no one will use this function, then it just provides an accidental way for all previous selections to be over-written. Avoid limits on the number of items that can be added to the target (selected) list. List builders are not always the easiest thing to use, for several reasons. There is no undo within the list builder widget itself, and large numbers of selections may be made before submission. A user who has trouble making selections may abandon the process instead. When thinking of using a list builder, first consider if something else can fill the role better:
Checkboxes can be arranged within a fieldset and broken into multiple columns, to easily and clearly present 20 or more options. Radio buttons or Drop-down Lists (not the Multi-Select List) should be used when only one selection can be made. Multi-Select Lists are as user-friendly as list builders for selection, take up much less room, and are more suitable for small number of options, especially if they are likely to be close together.
Page 177 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Design and Layout 1024px and 800px Viewports 320px Viewport
Page 178 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Elements
UI Specifications
Page 179 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interaction
Date Input W A Dates require entry and display in a specific format to be comprehensible. Whenever a guess can be made—such as that the current date is the most likely date to be entered—pre-populate the value and allow the user to change it.
User date entry is prone to user input and format errors, so provide guidance whenever possible. Contemporary methods will be added to the date selector to assist the user and try to prevent improper entry. Date entry fields are a combination entry, with a text input area and a calendar widget.
1. Masking – When typing in the text side, the field is limited to numeric-only input, and masked so the system displays slashes as delimiters, and restricts entry between delimits to the allowed characters and valid values. Example - http://digitalbush.com/projects/masked-input- plugin/ 2. Regionalization – Regional standards, or when possible the user’s settings, will be detected and applied to the input field format. 3. HTML5 – When supported by the browser, selection of the calendar icon next to the input field will open a native browser picker. 4. JavaScript – When there is no HTML5 calendar input support, a JS solution will fall back to a styled calendar-picker layer. Example of HTML5 to JS fallback - http://tjvantoll.com/2012/06/30/creating-a-native-html5-datepicker-with-a-fallback-to-jquery-ui/ 5. Mobile – The display below the smallest breakpoint will not allow separate typed entry, since mobile browsers all support calendar pickers.
Page 180 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Design and Layout
In Context (Form)
Page 181 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Elements
Page 182 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications
Page 183 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Page 184 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Upload W A General Guidance The Upload (File) function is not really a component, but a specified combination of controls and accompanying interactions that define the user experience of uploading a file to a web application. It can be integrated into any form and leverages Cummins Standard Form Elements. The following example demonstrates the user interface and display sequence from initiating a file upload to completing the task.
If adherence to Cummins Confidentiality policies, follow the file upload model from Cummins Connect, and use this document’s UI Specifications to provide visual styling that aligns with Cummins Web Design Standards. Design and Layout
Elements and UI Specifications 1. User initiates upload by clicking on an text link labeled “Upload.” The link may include more specific context such as “Upload File” or “Upload Picture,” If appropriate. 2. The browser’s native “choose file” window is launched and the user browses for and selects (or alternatively, enters/pastes a path for) the desired file.
Page 185 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015
Start Upload and Progress Indication
3. Once the file is chosen and the upload window closes, the file name is displayed in the “Attachments” list with a progress indicator bar behind it. Clicking the “Cancel” icon cancels the upload and the file name is dismissed. 4. When the upload is complete, the file name displays as a link in the Attachments list and the file may either be opened by clicking on the link or the “View” icon, or deleted by clicking on the “Delete” icon next to it. 5. The “Upload” link/function always displays at the bottom of the Attachments list. 6. The interaction follows the Internet Explorer 11 Model, which may serve as reference.
Page 186 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 File Upload in Progress and Uploaded File
File upload confirmation message
Page 187 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Contextual Help W A General Guidance When space is at a premium and some users may require additional information to complete a form or task, Contextual Help should be provided. This information is available on demand and should directly relate to the adjacent field of form element.
Design and Layout
UI Specifications
Page 188 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions Default Display
Triggered Display (Preferred)
Page 189 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Triggered Display (Also Acceptable)
Field Set See the Form Section of this document.
CAPTCHA W A CAPTCHAs are tests used to automatically validate that a human is interacting with a website/application. They attempt to block “bad actors” that use automated attack tools like “spambots.” However, the most common CAPTCHA type—the match-the-letters visual type—does not work. Since at least 2009, technology has enabled computers to read such tests more effectively than humans. Determined actors can easily defeat website/applications protected only by visual CAPTCHAs.
CAPTCHAs are also a burden to the end user, and have accessibility issues, all of which prevent the use of a product by many legitimate users. There are three tactics UX suggests using instead of solutions the user can see or must interact with:
1. Honeypots – This tactic involves using standard HTML form fields, but displaying them off-screen or otherwise hiding them with CSS so that sighted end users do not see them. Spambots, however, will encounter these fields, and attempt to fill them in, thus falling into the “honeypot trap.” Any submitted form with a filled-in “honeypot field” is accepted by the server without error, but then discarded. An additional validation step (such as humans calling a provided phone number) may also be employed to confirm that all accepted forms have been filled in by real users. Since screen readers will also “see” the honeypot fields, include hint text to indicate that users of assistive technology should skip these fields.
Page 190 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 2. Traffic calming – Spambots make economic sense only by submitting hundreds or thousands of form requests a second. Humans cannot type that fast, so putting a timer on form submissions at human speeds removes the economic incentive of bots. If this approach is used, make sure the timer is adjustable, so it can be monitored and calibrated.
3. Traffic logging – If too many inputs come from a particular IP range, use the same data, or are captured by other methods above, flag it for human review or automatic blocking. Block lists are shared, much like email spam lists are, so this approach can be more powerful than independent efforts.
When these techniques cannot be implemented, the next recommendation is for human test questions that require human logic to answer. Provide a question, such as “Is fire hot or cold?” (in a format that cannot be read by bots) and the user must type “Hot” in the associated field. These questions must be carefully selected and coded to avoid bots guessing, or performing dictionary attacks. Avoid using idiom, or other culturally-specific information so the questions and responses can be translated into any language.
Only use traditional, obscured-text visual CAPTCHAs when no other options can be implemented.
Always be sure to implement all features that support use with assistive technology, such as audio-based alternatives. Elements Human Test Question
Page 191 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Visual CAPTCHA
UI Specifications Human Test Question
Page 192 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Visual CAPTCHA
Interactions Human Test Question
Page 193 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Visual CAPTCHA
Buttons (Website) Design and Layout
Page 194 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Buttons (Application) W A Design and Layout
Button Label Function Add Adds the record or item to the database or list Back Returns the user to the previous screen Browse Launches the file manager window during the file upload process Cancel Cancels the current action and returns to the precious state Continue Allows user to acknowledge and continue with an action Delete Removes the record or item from the database permanently Download Initiate the download process Edit Allows the record or item to be edited Next Display the nest step in a task flow or screen of information OK Accepts or confirms an action Previous Display the previous step in a task flow or screen of information Reset Resets the form or screen to the default settings Save Saves the record or item for later changes Search Initiates the search of the database using selected criteria or parameters
Page 195 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Submit Submits the form or record to the database Upload Uploads a file to the application or database View Display the record
Buttons Design and Layout Cummins Web Design Standards specify a common set of buttons to use across all Web Sites and Web Applications that are designed to be responsive, accessible and flexible. Using consistent buttons and following use guidelines will make Cummins web products less confusing for end users and easier for them to learn.
Web Applications
Web Applications use all of the same buttons that Web Sites do, but they do NOT use the Digital Red “Special Action” button. Instead, Web Applications have a Cummins Accent Teal-colored button that is the same height as the rest of the Cummins UX Standard buttons.
Button Style Button State Display Use Guidance Primary Action Default Use this button to indicate to the end user the most important or common action to take. In a button group, only one button should be a Primary Action Button. On Hover Assign for use with mouse or keyboard. Not used on touchscreen devices. On Tap/Click Assign for use with touchscreens, mouse or keyboard.
Disabled Disable the Primary Action button if clicking would result in an error, such as after client-side validation that shows skipped required fields or unacceptable formatting. This style may also be used to indicate to users that an option exists, but not available because of some action that must be taken by the user. Because this may be frustrating to users, it is advisable that additional guidance messaging be provided in this context. Sometimes, it is preferable to use a non-disabled button, let the user make a mistake, and provide Cummins a UX Standard error or alert message to help resolve the situation. Secondary Action Default Important, but not the MOST important, actions should use this button style. A button group may contain multiple Secondary Action buttons
Page 196 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 On Hover Assign for use with mouse or keyboard. Not used on touchscreen devices. On Tap/Click Assign for use with touchscreens, mouse or keyboard.
Disabled Disable the Secondary Action button if clicking would result in an error, such as after client-side validation that shows skipped required fields or unacceptable formatting. See additional guidance for the Primary Action Disabled Button display. Tertiary Action Default Use this button style for less-critical or less-common actions, such as “Cancel,” “Reset Form” or “Previous” (in a Wizard.) Tertiary Action buttons should only be applied to minimally destructive actions. On Hover Assign for use with mouse or keyboard. Not used on touchscreen devices. On Tap/Click Assign for use with touchscreens, mouse or keyboard.
Disabled Disable the Tertiary Action button if a less-critical action is not available until a user takes a specific action. This button would not usually be disabled. Form-Secondary Default This button style should be used on forms only, whenever a Secondary Action button would be appropriate. It is designed to be more visible against the Cummins UX Standard grey form (#EEEEEE) background. On Hover There is no hover state for disabled buttons.
On Tap/Click There is no Tap/Click state for disabled buttons.
Disabled See guidance for Secondary Action disabled button.
Marketing Web Sites
Marketing Web Sites share most buttons with Web Applications, but include a “Special Action” button that uses Cummins Digital Red and is 5 px taller than other Cummins UX Standard buttons.
Button Style Button State Display Use Guidance
Page 197 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Primary Action Default Use this button to indicate to the end user the most important or common action to take. In a button group, only one button should be a Primary Action Button. On Hover Assign for use with mouse or keyboard. Not used on touchscreen devices. On Tap/Click Assign for use with touchscreens, mouse or keyboard.
Disabled Disable the Primary Action button if clicking would result in an error, such as after client-side validation that shows skipped
required fields or unacceptable formatting. This style may also be used to indicate to users that an option exists, but not available because of some action that must be taken by the user. Because this may be frustrating to users, it is advisable that additional guidance messaging be provided in this context. Sometimes, it is preferable to use a non-disabled button, let the user make a mistake, and provide Cummins a UX Standard error or alert message to help resolve the situation. Secondary Action Default Important, but not the MOST important, actions should use this button style. A button group may contain multiple Secondary Action buttons On Hover Assign for use with mouse or keyboard. Not used on touchscreen devices. On Tap/Click Assign for use with touchscreens, mouse or keyboard.
Disabled Disable the Secondary Action button if clicking would result in an error, such as after client-side validation that shows skipped required fields or unacceptable formatting. See additional guidance for the Primary Action Disabled Button display. Special Action Default Use this button sparingly, for high-visibility and important actions only. This is the default button for all Marketing Carousels. Using more than one per page is not recommended, as each additional button takes focus away from the others, and multiple red buttons on a page may be perceived as error messaging, since the same color is used for errors in the Cummins Web Design Standards.
Page 198 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 On Hover Assign for use with mouse or keyboard. Not used on touchscreen devices. On Tap/Click Assign for use with touchscreens, mouse or keyboard.
Disabled N/A This button should not be used if it would ever be disabled. Use a Primary Action button instead.
Buttons UI Specifications Dark Grey Action Buttons
Page 199 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Light Grey Action Buttons
Secondary Form Action Buttons
These buttons are designed to display on the #EEEEEE Cummins Standard Form Background color.
Page 200 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Marketing Special Action Buttons
Web Application Primary Action Buttons
Page 201 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Other Components Log In W A Design and Layout Log In 1024px and 800px Viewport
Page 202 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 In Context
Page 203 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Forced Log Out
Page 204 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Log In 320px Viewport
Page 205 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Log In 1024px and 800px Viewport
Page 206 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Page 207 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Delay W A Delays should, whenever possible, be hidden from the user. When the system can predict user needs in advance, or the users can perform other tasks, do not make them wait or indicate delay.
When delay must be shown, such as to indicate progress, or because the user must wait for a task to complete before they can do the next task, indicate it in the proper way, based on what the system knows:
Wait
When only a brief delay is to be shown, or the delay has unknown and un-measurable length. Show activity as a spinning icon without units or an indication of completeness. A very good indicator is the upper-left one here: http://codepen.io/aurer/pen/jEGbA Progress
When you expect the user to have to wait more than 3-4 seconds, and the timing or progress is known, can be predicted, or is based on something else measurable (kb transferred, etc.). Also, show this for any file transfer, even if expected to be small, as it's a known size, the user often understands that more than all-internet tasks, and often even tiny uploads hang up so this shows the delay better than just a random spinning device. Show progress whenever possible by animating the progress bar constantly. Users will perceive progress even when there is none, and believe the total time is less than when there is no animation. Sample code for the animated activity style: http://codepen.io/joe-watkins/pen/cvxuJ Sample code for a flat bar as used behind other content: http://kimmobrunfeldt.github.io/progressbar.js/
Page 208 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Design and Layout Wait Indicator: Inline
When a function is small, localized or only changes information on the page, it can be associated to the area or action itself. This is most visible and clear when the action button or icon is replaced with a wait indicator during the loading or processing sequence. This also prevents the user from accidentally pressing the action multiple times by accident, out of frustration or because they do not perceive the action is taking place. There is no need for a label indicating processing as it is adjacent to a functional area and loads as soon as a user-initiated action has been performed.
Wait Indicator: Lockout
When the user must wait for a step to complete before proceeding, an informational overlay will be provided with the Wait Indicator, an indication of the exact process being performed, and any other key instructions when needed. This overlay can take over the entire page, or just sections, charts, tables, or other items that must be locked out during the delay. Small elements can forego the overlay shape, and simply lay a translucent color over the entire component, centering the Wait Indicator and labels.
Page 209 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Progress Indicator: Standalone
Progress on a page or major component level should be as a bar alone, with indicator text adjacent to it. The green part animates, constantly moving regardless of progress relative to the total length. Add as much status information as is useful, but at least the specific process being performed and percentage complete. This may also be overlaid on top of a grayed-out layer, preventing access to the parent page.
Progress Indicator: Integrated
Whenever the progress is related to a subsection of the page, or when more than one progress indictor exists at a time, such as loading a file to a list of files, display a flat bar underneath the content, status or existing context. Place file information such as the filename and size on top. Include the percentage complete at the far right end if space allows.
Page 210 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications
Wait Indicator: Inline
Wait Indicator: Lockout
Page 211 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Progress Indicator: Standalone
Progress Indicator: Integrated
Page 212 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Modal or Semi-Modal
Page 213 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions Progress Indicator: Integrated
Share W A Users already share information on web sites. Via email, they post links to pages; they post screenshots and text they have copied. Expanding this capability with simple buttons can greatly streamline the process, empowering users and increasing their satisfaction.
Social media sharing links have some risks, in that they are often accompanied by code that lets the service monitor users. This may even be a security concern on some websites.
Simply hiding the icons behind another user action is enough, so a single Share icon or selector drop-down will be used, depending on space and clarity of messaging. When activated, a Drop-down List will appear with the available services, and icons to the left.
Remember, sharing is not exclusively about public social media sites. You can add any relevant sharing functions, such as email, Cummins Connections and even Print functions. The items shown are examples designed to demonstrate the flexibility and scalability of the feature.
Messages are always very specific, and include an icon and corresponding color for the icon, border and background to denote the level of message: Success, Problem, or Error.
Page 214 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 1. Page Level – Most sharing includes a URL, so pages are the easiest items to share. If using on many or all pages in your site, use this in a consistent location that reflects this, and does not get confused with other social media links. To the right of the H1 page title, right-aligned with the page content, is usually a good place for it.
2. Component Level – Individual components can also be shared, but must also have their own unique URL. For example, if a chart should be shared, it must have a page where the chart is displayed alone. The sharing link must be immediately adjacent to the item, or within the title area of it, and when text is provided should indicate what will be shared, e.g. “Share this chart.”
Make sure that sharing links will work for all recipients. Don’t allow sharing if data is too transitory, or only would appear as shown for that user. For pages or other content that requires authentication, do not include external or general social media to share with as it will just result in errors.
Do not use third party services such as ShareThis. Aside from offering no customization so not complying with brand standards, they do not allow adding internal services, and they also monitor use of your site, so in essence steal your data (and resell it) in place of social media sites doing the same. Design and Layout
Multiple sizes and interactions of the share initiator are available to allow for use that meshes with different styles or spaces. Items in the list should be consistent within your site, but can be any set of options. Those show here are just an example.
Page 215 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Elements
Page 216 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications
Page 217 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Page 218 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Export W A Cummins applications often work with or expose to the user complex data. They may find it easier to store, share or analyze on their own, so a function to export the data and download is often provided. Provide data in formats your users need and which best express the information. Tabular data and database dumps should come in spreadsheets, not PDFs. Be as inclusive as possible, and provide alternative file formats, not only proprietary ones. For example, provide CSV as well as Excel. If there is only one export format do not use the drop-down selection, but display the link directly on the page and download or open with a single click/tap. Design and Layout When there are multiple formats or functions available, provide a list of options:
When there is only one file to download, provide an icon and link alone:
Page 219 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Elements When there are multiple formats to export into:
When there is only one format to export into (e.g. PDF):
Page 220 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications
Page 221 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Page 222 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 In Context
Ratings W A W A Ratings are commonly used on public content-consumption sites and stores, as a way to both allow other shoppers or viewers to understand value of items at a glance, and to build profiles of individual rating-user behavior. These will be rarely required within Cummins, and must only be used when there are many user - over 100,000, who are engaged with social media.
Users who are allowed to rate must be recognized in some manner, to avoid voting multiple times, and to block bot or other attacks intent on up- or down-voting content.
Page 223 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 The rating system is similar to those used throughout the Internet like on Amazon, or Netflix.
When the user has not selected a rating, the aggregate of all other ratings is displayed graphically. The aggregate is always displayed in text. Ratings are always displayed with the entire scale of five stars as the maximum value. The value of the aggregate rating is displayed by indicating how many others have rated the content. The user can rate the content, and it immediately switches from primarily an information radiator to an indication to the user they have engaged with the site. All ratings are out of five. There is no zero. The user can only select in whole numbers, but the aggregate feedback is in fractions, showing one decimal place, and parts of stars. The user selection updates as soon as the user makes it, without page refresh. Avoid use of descriptions on the rating, such as “loved it.” The scale, a rating out of five stars, should be sufficient by itself. Text labels can skew results. Do not display aggregate ratings until a statistically-significant number of individuals have rated the item. Displaying ratings from only a few users can badly skew the results, and encourage mistrust of the system. Do not refresh the page when a user rating is submitted. All changes must be immediate and within the page context. Be extremely careful if this is used in the same site as a Favorite feature so users do not confuse the two symbols or functions. Design and Layout The number of ratings needed to display an average is context-dependent. Make sure a statistically significant number of ratings are provided before showing the aggregate values. If user has already provided a rating, he can submit a new rating which over-writes the previous submission. Once a user has rated an item, their rating persists on the page, as shown in the last row here, and is displayed whenever the user visits a page where the rating for that item is visible. No or insufficient ratings:
Display of average rating:
Selecting a rating:
Page 224 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015
Display of user’s rating:
UI Specifications
Page 225 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Interactions
Inline Messaging W A In general, Inline Messages should be used instead of Dialogs for information or warnings. Inline Messages appear in the context of the page or component, so do not remove the user from the process, require a step to dismiss and carry out further actions or fixes, and can attract the eye just as much if placed properly.
Messages are always very specific, and include an icon and corresponding color for the icon, border and background to denote the level of message: Success, Problem, or Error.
1. Page-Level – Immediately above the page title (or in another suitable area when no H1 title exists) a strip of color as wide as the content area will be loaded. This indicates a problem with the entire page, or service. 2. Component-Level – When the status message is about a specific element, and not the entire page, To the far right edge is a close icon, allowing users to dismiss the message, and carry on with their work without the clutter, or by getting to elements behind the message strip. 3. Form Inline Messaging – refer to the Form Page section. Messages should always appear and disappear with animation, fading in over about 500 ms, and fading out over a period of around 1.5 seconds.
Page 226 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Status messages about the condition of a form being filled out by the user employ similar colors and icons, but are different. See the Form guidelines for details on these inline error messages. Design and Layout Page Level
Page 227 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Component Level
This component is shown as an example. The inline message can be success, warning, or error, and show in any context in which it is visible, sensible and adds value.
Page 228 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UI Specifications Page Level
Page 229 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Component Level
All specifications identical to the page-level design. Interactions Page Level
Component Level
Page 230 UI Components Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 FUTURE WORK Help/FAQ Page Type
Additional Form Error Message Guidance
In-page Video display
Site Map
Advanced Searching with Filters
Terms & Conditions, Privacy Policy
Wizard Page Type
Data table with more advanced functions (show/hide columns, add new data, upload data, etc.)
CRUD (Create, Read, Upload, Delete) Form example
Additional social media icons and functionality
REFERENCE Cummins Brand Guidelines
Cummins UX Mobile Application Standards WIKI
Responsive Design Patterns (Brad Frost)
Page 231 Future Work Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 APPENDIX Digital Icons System at Cummins A single, unified system of icons, using consistent shapes, radiuses, and weights:
Emphasizes and is consistent with the Cummins brand Provides less ambiguity for users Allows users to learn complex interfaces more easily due to consistent design Reduces time to design and approve digital products In general, Cummins icons are 20 px tall and have 10 padding on all sides
The full document, A System for Digital Icons at Cummins, with vector-based icon artwork, specifications and use guidance is available on Cummins Connect, or by contacting the Cummins User Experience Team.
Examples of the Cummins Icon System:
Function Bounded Unbounded Bounded Unbounded Bounded Unbounded Bounded Unbounded Interface Control
Contact & Share
System Feedback
Page 232 Appendix Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 UX Team Accessible Design Guidelines This document provides a summary of Cummins’ web accessibility guidelines. The intent of these guidelines is to improve the experience of all users of Cummins’ websites. These are not specific standards with associated testing criteria. Compliance with these guidelines does not imply compliance with Section 508 Standards, or the Americans with Disabilities Act.
1. Why bother making a website accessible?
The 2000 U.S. Census reported that 49.7 million people in the U.S. have a disability – almost 20% of us! Users with disabilities are strong online consumers, but are often unable to conduct business online due an inaccessible design. Types of common disabilities: - Blind or visually impaired - Hearing impaired - Physically disabled or temporarily injured - Cognitively disabled, including ADHD or short-term memory loss Aging demographic: 72,000,000 baby boomers are aging into retirement (by 2030) and experiencing disabilities related to normal aging. This phenomenon is often called the “Silver Tsunami.” It’s not rare: about 10% of all men have some form of colorblindness, and many older users have mild arthritis that makes it difficult to click on small targets with a mouse. Consider users’ context: loud repair shop, poor lighting conditions, older individuals with mild arthritis, forgotten reading glasses, and display on small screen, such as a tablet all impact users’ experiences. Changing legal landscape and legal risk assessment can help understand the legal context of accessibility. Often, making a website more accessible improves its overall usability, makes it more mobile- and tablet-friendly and optimizes its performance with search engines!
2. Strive for a great common experience, not separate experiences for people with disabilities
This concept is similar to a “basic experience” in a progressive enhancement approach. Adhere to the seven principles of Universal Design: - equitable use - flexible in use - simple and intuitive - perceivable info - tolerance for error - low physical effort - size and space for approach and use
Page 233 Appendix Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 3. Keyboard accessibility:
Cummins web sites should be completely navigable and operational with keyboard-only access; no functionality should be dependent on vision or use of a mouse, trackball, trackpad or tablet. If content is made visible or functionality is provided by style sheets through mouse action, also provide keyboard-triggered event handlers.
4. User preference respect:
Web sites shouldn’t override users’ selections related to visual display, such as custom style sheets. If a display options are provided, a range of options must be included for color contrast.
Existing browser functionality, such as text resizing, shouldn’t be disrupted or disabled. 5. Color: Color shouldn’t be the sole indicator of information, status, feedback or category/structure. The minimum color contrast ratio between foreground and background is 4 to 1. Color contrast for regular sized fonts (anything below 18pt) should be 4 to 1. Color contrast for large sized fonts (defined as 18pt and higher) should be 3 to 1. Use a color contrast analyzer tool to confirm color selections (recommend Juicy Studio’s Color Checker)
5. Flashing elements:
Avoid flashing or blinking elements.
6. Text:
Use at least a 10 pt (convert to ems) font size and strive for good value contrast between text and the page’s background (see above “color” section) Adhere to Cummins’ brand standards in terms on font selection, and avoid stylized and serif font styles. All text should support (browser) resizing to 200% of default size without loss of content, legibility or functionality and the layout should adjust to accommodate text resizing. Use standard text and html conventions for paragraphs, lists, quotes and captions. Every page should have one descriptive H1 title that is not duplicated on the site. Avoid the use of “ALL CAPS” to support better legibility. Limit line length to 150 characters when possible. Note that CSS can be written to support max and min line lengths.
7. Identification, status and function:
Page 234 Appendix Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 All navigation should appear clickable and indicate state at all times. Controls should be labeled to describe functionality.
8. Feedback and error messaging:
When an icon or visual element is used to identify controls or provide feedback, the meaning assigned to those images should be consistent throughout the website.
A general, summarizing error message should display at the top of a page when a user generates multiple errors, and more specific feedback/error messaging should display at the field level as part of a field label. See UX Guidelines for visual display of error messaging.
9. Multimedia and non-html formats:
Synchronized captioning should be provided for all videos. Avoid Flash elements, especially for navigation or essential information. If any software or plugin is required to access content or a file, provide a link to the location for downloading the software/plugin.
10. Text links:
Write text link labels so that they are meaningful out of context, and if users skim the page for links. Limit embedded text links in the page content to fewer than 10 and provide the same resulting interaction for each. Destination pages should have H1s that match the launching link labels. Links should generally be blue, and display an underline by default, which may be styled with CSS. If color is the only differentiator of a link, it may be missed by people with color blindness.
11. Navigation:
All buttons and “clickable” elements should have a hit area large enough for a user without fine motor control to accurately click on. Make buttons, tabs and links appear clickable. Support -through focus path. Items that have focus should be visually distinguishable from nonfocused elements.
12. Forms:
All forms should be fully keyboard navigable, and pay special attention to the tab order to ensure it’s logical. All fields and input elements should have associated labels that are not field default text.
Page 235 Appendix Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015 Group related elements together and identify the groups as fieldsets.
13. Images:
Avoid embedding text within images whenever possible. Always provide alt tag descriptions for images (within functional requirements). Don’t rely on images exclusively to communicate information; use them as supporting or illustrative elements.
14. Page Organization:
Text should be written for web delivery – in short, scannable chunks of information, grouped into logical categories. Follow a logical heading structure and ensure that it represents the information hierarchy appropriately. The most important information should be at the top of the page. The primary action should be “above the fold” at a 1024 x 768 screen resolution, allowing for browser chrome
i Can be requested as software within Cummins.
Page 236 Appendix Public Information | Cummins Web Design Standards | V2.0 | Jan. 2015