General Rules for UI elements

Disclaimer

We can not mention UI Rules or guidelines without prefacing the discussion with an important note. SAMM is a web application that draws very heavily on User Experience patterns typically used in desktop and client-side applications. Therefore, it is difficult to define concrete rules based on either platform. Keeping this important fact in mind, most of the user experience and user interface guidelines established in this documentation will be heavily influenced by the rules and guidelines set forth in the Microsoft Windows Human Interface guidelines. Which can be found here.

It is the intention of the Emprise Corporation Visual Communication Department that the Windows guidelines be used solely as reference material when designing and developing SAMM. The following documentation is a living document, and as such, should be the groundwork for discussion on design and user interaction. If a question about design arises, Emprise Corporation’s design team should be consulted:

Sergio Barrera - Art Director
Liz Roy - Senior Designer
Jo Ray Tanchiatco - Senior Designer
Alan Nadaskay - Visual Designer
Kellie Semmelrock - Visual Designer

The CSS used in this document should not be considered production ready code. It is being used merely as a way to get the general idea of the styles across and as such should be used only as a reference for development purposes.

Please contact Troy Hawley or Mike Botsko for any questions regarding the usage of CSS from this document in the application.

Layout

The layout of the SAMM application is an important aspect of defining the standards for the user interface. Layout is based on spacing, sizes, and user interface element positioning. All of these aspects follow a standard that adheres to both common web application industry standards and a set of standards agreed upon by Emprise Corporation and its product owners.

Spacing - All of the spacing in the SAMM application is based on an even 2px standard unit of measurement. This is especially important when dealing with spacing between and around elements of the user interface. Where ever possible, there should be 20px of padding as margins around more macro elements of the SAMM UI, such as modal windows or navigation panels. Also the visual pacing of the application is based on increments of 2px. It should be noted that, as with any rule, there is no way that it can cover every possible scenario. The design, in every way possible will adhere to this rule, but there will be times that the rule will need to be broken in order to facilitate good design. These scenarios will need to be discussed with Product Owners and the Visual Communication Department before being implemented.

Positioning - When it comes to positioning, the SAMM user interface follows a somewhat standard format for web applications and adheres to many of the Microsoft Windows design standards as well.

Button Positioning - Following that general mentality when positioning buttons, especially in modal windows, the button with the negative connotation should be positioned in the terminal position for the element. In the case of modal windows or forms it would be the lower right hand corner in a footer. The button that contains the action considered most important for the particular window should use theAccented Button styles and should be positioned immediately adjacent to the terminal position, unless otherwise specified.

The Cursor

The cursor, in SAMM, will use the rules set forth in the Microsoft Window Human Interface Guidelines as a base and add to the rules where it is needed. Those rules can be found here.The vast majority of interface elements will display the "Normal Selector" (arrow). However, there will be a select few locations where the "Link Selector" (finger) will need to be used. An example of one of these locations is the "View all..." link in the footer of the main module grid. If other cursor types are be needed, they will be defined in the guidelines for the indiviual UI element.

Situational Language for Dialogs

Alerts

Alerts, in SAMM, are a set of dialogs that "alert" the user to actions that can cause problems in the future, possible loss of data, or substantial changes to that data that can occur if they continue their current course of action. These dialogs have yellow headers and Accented Buttons in order to emphasize that, while the current action is not critical to the functionality of the application, it could still have undesirable consiquences.

Please refer to the Dialogs section of this documentation for styling specifications pertaining to Alert Dialogs.

Example

Confirmation Dialogs

Confirmation dialogs, in SAMM, are a set of dialogs that provide additional information the user needs to perform their current action. These Dialogs use the typical blue headers and Accented Buttons for standard Modal Dialogs as these messages are intended to have a neutral tone.

Please refer to the Dialogs section of this documentation for styling specifications pertaining to Prompt Dialogs.

Example

Warnings

Warnings, in SAMM, are a set of dialogs that "warn" the user that their current action could have critical consequences to the functionality of the application. These dialogs have red headers and Accented Buttons in order to emphasize that the user's actions could result in critical failures of the application.

Please refer to the Dialogs section of this documentation for styling specifications pertaining to Warning Dialogs.

Example

Situational Language for Tooltip Validations

Below is a list of common tooltip validation messages that may appear when an error occurs in SAMM. These messages are designed to be straightforward and generic for scalability purposes. However, there may be instances within the application where none of the predefined messages suit a specific input field. In such cases, please reach out to the Emprise Corporation Visual Communication Department for guidance on the next steps.

Case	Input Type	Tooltip Message	Example
Invalid Format	Currency Date Picker Email Address Numeric	Invalid format.
Negative Integer Entered	Currency Numeric	Please enter a positive integer value.
Null Required Field	Checkbox Currency Date Picker Dropdown Ellipses Email Address Numeric Radios Text Text Area	This field is required.

Color Swatches

Examples

Specifications

Note: When a Pill is being used in a Grid as a status indicator it will have a min-width: 76px; associated with it. Otherwise the Pill will be a variable width based on the size of its content.

Examples

Specifications

• Fonts used in Breadcrumbs
• Dark Blue Regular Text (See the Typography section for details)

• icon-breadcrumbs
• color: #9a9ea3;
• height: 6px;
• width: 6px;

• Tooltip
• See the Tooltips section for details

Examples

Specifications

The Accented Buttons in SAMM may come in a variety of colors. Below is a listing of two of these color variations. More variations may arise in the future and are subject to change or approval by the Visual Communication Department at Emprise Corporation.

Business Rule: The ellipsis should be used on any clickable button or link that will prompt the user to perform further action after clicking the button or link.

Business Rule: In keeping with Microsoft Windows desktop patterns, the focus states for buttons in SAMM should be used primarily for indicating what element the user is currently acting upon while tabbing through the application. The other states of the buttons will almost always take precedence over the focus state. There will, of course, be exceptions to this rule. When this is the case it will be clearly documented for the individual element. Any questions regarding this rule should be fielded by the Emprise Visual Communication Department.

Blue Accented Buttons

CSS Note: The Normal state for Accented Buttons should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Examples	This State Trumps:	Fonts
Normal		None	White Body Copy
Hover		Normal, Focus	White Body Copy
Focus		Normal	White Body Copy
Active/Press		Normal, Hover, Focus	White Body Copy
Disabled		All	White Body Copy

Yellow Accented Buttons

CSS Note: The Normal state for Accented Buttons should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the normal state.

Name	Examples	This State Trumps:	Fonts
Normal		None	White Body Copy
Hover		Normal, Focus	White Body Copy
Focus		Normal	White Body Copy
Active/Press		Normal, Hover, Focus	White Body Copy
Disabled		All	White Body Copy

Red Accented Buttons

CSS Note: The Normal state for Accented Buttons should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the normal state.

Name	Examples	This State Trumps:	Fonts
Normal		None	White Body Copy
Hover		Normal, Focus	White Body Copy
Focus		Normal	White Body Copy
Active/Press		Normal, Hover, Focus	White Body Copy
Disabled		All	White Body Copy

Examples

Actions

• Action #1
• Action #2
• Action #3
• Action #4
• Action #5

Specifications

Button Dropdowns can use the styles from Accented Buttons, Primary Buttons and Secondary Buttons depending on where they are being used. The Visual Communication Department should be consulted when determining which style to use for any given scenario. Please refer to the respective sections of this documentation for styles specific to each of the aforementioned buttons.

Regardless of the button styles being used for the Button Dropdown itself, the Dropdown menu that appears when the user clicks on the button will be the same.

Business Rule: In keeping with Microsoft Windows desktop patterns, the focus states for buttons in SAMM should be used primarily for indicating what element the user is currently acting upon while tabbing through the application. The other states of the buttons will almost always take precedence over the focus state. There will, of course, be exceptions to this rule. When this is the case it will be clearly documented for the individual element. Any questions regarding this rule should be fielded by the Emprise Visual Communication Department.

Note: Please see the Context & Dropdown Menus section for details on the dropdown associated with these buttons.

Examples

Specifications

Button Groups can use the styles from Accented Buttons, Primary Buttons and Secondary Buttons depending on where they are being used. The Visual Communication Department should be consulted when determining which style to use for any given scenario.

Business Rule: In keeping with Microsoft Windows desktop patterns, the focus states for buttons in SAMM should be used primarily for indicating what element the user is currently acting upon while tabbing through the application. The other states of the buttons will almost always take precedence over the focus state. There will, of course, be exceptions to this rule. When this is the case it will be clearly documented for the individual element. Any questions regarding this rule should be fielded by the Emprise Visual Communication Department.

CSS Note: Please be aware that, while the examples below are defined using fonts for the content within button groups, most buttons groups will contain icons instead. We are using the fonts below in order to cover as many scenarios as we possibly can with this documentation. The icons will be sized to match their canvas size, unless otherwise stated elsewhere, and the fill color will be as defined above, unless otherwise stated.

Primary Button Groups

CSS Note: The Normal state for Button Groups should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Examples	This State Trumps:	Fonts
Normal		None	Dark Blue Regular Text
Hover		Normal, Focus	Dark Blue Regular Text
Focus		Normal	Dark Blue Regular Text
Error		Normal, Hover, Focus, Active/Pressed	Dark Blue Regular Text
Active/Press		Normal, Hover, Focus	Dark Blue Regular Text
Disabled		All	Dark Blue Regular Text

Secondary Button Groups

CSS Note: The Normal state for Button Groups should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Examples	This State Trumps:	Fonts
Normal		None	Dark Blue Regular Text
Hover		Normal, Focus	Dark Blue Regular Text
Focus		Normal	Dark Blue Regular Text
Error		Normal, Hover, Focus, Active/Pressed	Dark Blue Regular Text
Active/Press		Normal, Hover, Focus	Dark Blue Regular Text
Disabled		All	Dark Blue Regular Text

Examples

Specifications

All Icon Buttons use icons from the SAMM 2.0 Icon SVG package. The documentation for which can be found in the Iconography section of this document.

Business Rule: In keeping with Microsoft Windows desktop patterns, the focus states for buttons in SAMM should be used primarily for indicating what element the user is currently acting upon while tabbing through the application. The other states of the buttons will almost always take precedence over the focus state. There will, of course, be exceptions to this rule. When this is the case it will be clearly documented for the individual element. Any questions regarding this rule should be fielded by the Emprise Visual Communication Department.

Main Navigation Buttons

CSS Note: The Normal state for Icon Buttons should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Examples	This State Trumps:	Fonts
Normal		None	N/A
Hover		Normal, Focus	N/A
Focus		Normal	N/A
Active		Normal, Hover, Focus	N/A
Disabled		All	N/A

Window Header Buttons

CSS Note: The Normal state for Icon Buttons should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Examples	This State Trumps:	Fonts
Normal		None	N/A
Hover		Normal, Focus	N/A
Focus		Normal	N/A
Active		Normal, Hover, Focus	N/A
Disabled		All	N/A

Panel Header Buttons

CSS Note: The Normal state for Icon Buttons should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Examples	This State Trumps:	Fonts
Normal		None	N/A
Hover		Normal, Focus	N/A
Focus		Normal	N/A
Active		Normal, Hover, Focus	N/A
Disabled		All	N/A

Sidebar Navigation & Quick Edit Buttons

Navigation and Quick Edit Panel Buttons use the styles for Secondary Buttons aside from the Normal state which strips all styles off of the button accept for the icon itself. These buttons should be 10px apart from one another, both in the the horizantal and vertical layouts of the navigation.

CSS Note: The Normal state for Icon Buttons should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Examples	This State Trumps:	Fonts
Normal		None	N/A
Hover		Normal, Focus	N/A
Focus		Normal	N/A
Active		Normal, Hover, Focus	N/A
Disabled		All	N/A

Grid Icon Buttons

Icon buttons that appear in grids have a slightly more complicated behavior than other buttons.

When Grid Icon Buttons are static they will appear as icons in the grid, suach as the example below. This serves the purpose of allowing them to also be used as indicators.

When the row containing interactive buttons is hovered or selected the icons will display a button border as is the case in the example below.

Important Note: The check-knockout icon below does not have a border when the row is hovered because only icons that are interactive in the grids will get the row hovered and selected states.

CSS Note: The spacing between buttons in a cell, as well, as the spacing to the left and right of the group of buttons within that cell should be determined using this button border rather than the icon within it. This include non-interactive icons. It should be assumed that the same spacing exists around the non-interactive buttons as the interactive one even though they do not display a border when hovered. Refer to the example below.

In addition to the row hover and selected states each button has its own hover, focused, and disabled states.

CSS Note: Be advised that icons within these buttons will need to conform to a 14px x 14px viewbox as in the example above. If this requires new icon production files, please contact the Emprise Corporation Visual Communication Department to have them made.

CSS Note: All states for Grid Icon Buttons should have a transition: all 0.125s linear; on it. This is different from other buttons because these will be so tightly packed in the UI that we will need them to respond more quickly in order to not clutter the UI with unnecessary visuals.

Name	Examples	This State Trumps:	Fonts
Normal		None	N/A
Row Hover		Normal	N/A
Hover		Normal, Row Hover	N/A
Focus		Normal, Row Hover	N/A
Disabled		All	N/A

Examples

Specifications

Business Rule: The ellipsis should be used on any clickable button or link that will prompt the user to perform further action after clicking the button or link.

Business Rule: In keeping with Microsoft Windows desktop patterns, the focus states for buttons in SAMM should be used primarily for indicating what element the user is currently acting upon while tabbing through the application. The other states of the buttons will almost always take precedence over the focus state. There will, of course, be exceptions to this rule. When this is the case it will be clearly documented for the individual element. Any questions regarding this rule should be fielded by the Emprise Visual Communication Department.

CSS Note: The Normal state for Primary Buttons should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Examples	This state Trumps:	Fonts
Normal		None	Dark Blue Regular Text
Hover		Normal, Focus	Dark Blue Regular Text
Focus		Normal	Dark Blue Regular Text
Active		Normal, Hover, Focus	Dark Blue Regular Text
Disabled		All	Dark Blue Regular Text

Examples

Specifications

Business Rule: The ellipsis should be used on any clickable button or link that will prompt the user to perform further action after clicking the button or link.

Business Rule: In keeping with Microsoft Windows desktop patterns, the focus states for buttons in SAMM should be used primarily for indicating what element the user is currently acting upon while tabbing through the application. The other states of the buttons will almost always take precedence over the focus state. There will, of course, be exceptions to this rule. When this is the case it will be clearly documented for the individual element. Any questions regarding this rule should be fielded by the Emprise Visual Communication Department.

CSS Note: The Normal state for Secondary Buttons should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Examples	This state Trumps:	Fonts
Normal		None	Dark Blue Regular Text
Hover		Normal, Focus	Dark Blue Regular Text
Focus		Normal	Dark Blue Regular Text
Active		Normal, Hover, Focus	Dark Blue Regular Text
Disabled		All	Dark Blue Regular Text

Examples

Specifications

Split Buttons use the same style as Accented Buttons, Primary Buttons, and Secondary Buttons depending on where they are being used. The Visual Communication Department should be consulted when determining which style to use for any given scenario.

Business Rule: The ellipsis should be used on any clickable button or link that will prompt the user to perform further action after clicking the button or link.

Business Rule: In keeping with Microsoft Windows desktop patterns, the focus states for buttons in SAMM should be used primarily for indicating what element the user is currently acting upon while tabbing through the application. The other states of the buttons will almost always take precedence over the focus state. There will, of course, be exceptions to this rule. When this is the case it will be clearly documented for the individual element. Any questions regarding this rule should be fielded by the Emprise Visual Communication Department.

Primary

CSS Note: The Normal state for Primary Split Buttons should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Examples	This State Trumps:	Fonts
Primary Normal		None	Dark Blue Regular Text
Primary Hover		Normal, Focus	Dark Blue Regular Text
Primary Focus		Normal	Dark Blue Regular Text
Primary Active/Pressed		Normal, Hover, Focus	Dark Blue Regular Text
Primary Disabled		All	Dark Blue Regular Text

Secondary

CSS Note: The Normal state for Secondary Split Buttons should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Examples	This State Trumps:	Fonts
Secondary Normal		None	Dark Blue Regular Text
Secondary Hover		Normal, Focus	Dark Blue Regular Text
Secondary Focus		Normal	Dark Blue Regular Text
Secondary Active/Pressed		Normal, Hover, Focus	Dark Blue Regular Text
Secondary Disabled		All	Dark Blue Regular Text

Accented Blue

CSS Note: The Normal state for Blue Accented Split Buttons should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Examples	This State Trumps:	Fonts
Accented Blue Normal		None	Dark Blue Regular Text
Accented Blue Hover		Normal, Focus	Dark Blue Regular Text
Accented Blue Focus		Normal	Dark Blue Regular Text
Accented Blue Active/Pressed		Normal, Hover, Focus	Dark Blue Regular Text
Accented Blue Disabled		All	Dark Blue Regular Text

Accented Yellow

CSS Note: The Normal state for Yellow Accented Split Buttons should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Examples	This State Trumps:	Fonts
Accented Yellow Normal		None	Dark Blue Regular Text
Accented Yellow Hover		Normal, Focus	Dark Blue Regular Text
Accented Yellow Focus		Normal	Dark Blue Regular Text
Accented Yellow Active/Pressed		Normal, Hover, Focus	Dark Blue Regular Text
Accented Yellow Disabled		All	Dark Blue Regular Text

Examples

Specifications

The Checkboxes and Radio Buttons in SAMM 2.0 have been redesigned to fit the flat aesthetic of the application while also being easily identifiable as control elements for the application. Color and contrast choices were made to better suit the SAMM end user.

Checkboxes

CSS Note: The Unchecked state for Checkboxes should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Example	This State Trumps:	Fonts
Unchecked		None	Label: Dark Blue Regular Text
Hover		Unchecked	Label: Dark Blue Regular Text
Checked		Unchecked, Hover	Label: Small Blue Text
Disabled		Unchecked, Hover	Label: Dark Blue Regular Text
Checked Disabled		All	Label: Dark Blue Regular Text

Radio Buttons

CSS Note: The Unselected state for Radio Buttons should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Example	This State Trumps:	Fonts
Unselected		None	Label: Dark Blue Regular Text
Hover		Unselected	Label: Dark Blue Regular Text
Selected		Unselected, Hover	Label: Small Blue Text
Disabled		Unselected, Hover	Label: Dark Blue Regular Text
Disabled Selected		All	Label: Dark Blue Regular Text

Examples

Specifications

Whenever possible both Context and Dropdown Menus should adhere to the following rules. When it is not possible for the them to do so the Emprise Corporation Visual Communication Department should be consulted on how to proceed.

Business Rule: The menus should display 20 rows unless its content is less than 20 rows. If the content is more than 20 rows or the menu is forced to show less than 20 rows than the menu will scroll vertically in order to allow content not shown to be visible.

Business Rule: In the case of a Dropdown menu the menu’s width should be equal to that of the Selection Input it is coming from to a minimum of 160px. In both cases When the content of the menu forces it to be bigger than the min-width or the Input it is coming from, there should be 20px between the end of the text that forced the menu to be bigger and the right hand edge of the menu. This space takes into consideration the size of the Windows scroll bars plus some extra padding to improve readability.

Business Rule: Context and Dropdown menus are permitted to extend outside of the elements that contain them. Such as, modal windows or panels.

Business Rule: Context and Dropdown menus should open below cursor, or the selection input that it is coming from whenever possible. If the menu is obstructed from opening below than it may open above. If it is obstructed from opening both above and below the combobox it will cover the combobox and extend as tall as it possibly can with 10px padding between it and any objects that are obstructing it.

Business Rule: Context and Dropdown Menus should open to the currently selected values when it is available and close when clicked outside of.

CSS Note: Context and Dropdown Menus should have a min-width: 160px;.

CSS Note: The Normal state for menu items should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Example	This State Trumps:	Fonts
Menu Item Normal		None	N/A
Menu Item Hover		Normal	N/A
Menu Item Selected		Normal, Hover	N/A
Menu Item Disabled		All	N/A

Examples

Specifications

Examples

Specifications

CSS Note: The Normal state for the Day Indicators should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Examples

Specifications

CSS Note: The Normal state for the Day Indicators should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Examples

2019-03-11 10:07

Specifications

Users should always be directed to enter time in the following specified formats either via instruction or format locked inputs.

Date Format: YYYY-MM-DD

Time Format: HH:MM

Full Timestamp Format: YYYY-MM-DD HH:MM

CSS Note: When Timestamps need to be displayed visually, they can be displayed in any of the typographic styles defined in the Typography section of this documentation. Although, the typical styling should be that of Stamp Text. If there is any question as to what styling should be used for displaying Timestamps please contact the Emprise Corporation Visual Communication Department for guidance on how to proceed.

Gauge Examples

Run Scheduler

Gauge Specifications

The following specifications are for the Run Scheduler Gauges. There may be further style tweaks in the future when these gauges are implemented more throughout the application.

Run Scheduler

Examples

Specifications

Grids in SAMM contain a vast amount of complex data and therefore need to be made and readable as possible. Keeping this in mind the SAMM 2.0 grids have become more subtle in order to bring the data to the forefront. The subtlety of the visual user interface elements makes the text within the grid appear bolder and allows the human brain to better process and interprate what they are seeing.

Primary Grid

Business Rule - Text Alignment: The following business rules governing alignment apply to all numerical input values, in regards to the user interface. All numbers, currencies, and times should be right-aligned. All text IDs (even if numerical) and dates should be left-aligned. There will be no dollar signs ($) used in domain data. Dollar signs will only be used in the static grid row containing totals, as seen in the “Availabilities” grid. Totals will be displayed using the Accounting standard.

Business Rule - Multiple Item Selection: If the Grid has multiple items enabled, then a user can select multiple rows on the Grid by holding down the Shift or CTLR keys while selecting the rows with their mouse.

Business Rule - Keyboard Navigation:Upon selection of a grid row, a user can utilize the up or down keyboard arrow keys to navigate the grid vertically.

CSS Note: The Normal state for menu items should have a transition: background 0.3s ease-in; on it. All other states should have a transition: background 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Primary Grid - Column Headers

Name	Example	This State Trumps:	Fonts
Normal		None	Stamp Text
Hover		Normal, Focus	Stamp Text
Focus		Normal	Stamp Text
Pressed		Normal, Hover, Focus	Stamp Text
Disabled		All	Stamp Text

Primary Grid - Rows

Secondary Grid

Secondary Grid - Column Headers

Name	Example	This State Trumps	Fonts
Normal		None	Stamp Text
Hover		Normal, Focus	Stamp Text
Focused		Normal	Stamp Text
Pressed		Normal, Hover, Focus	Stamp Text
Disabled		All	Stamp Text

Secondary Grid - Rows

Grouped Checklist Grid

Grouped Secondary Grid

Icon Meanings

icon-home

icon-expand

icon-collapse

icon-folder-closed

icon-folder-opened

icon-leaf

icon-add

icon-subtract

icon-close

icon-maximize

icon-minimize

icon-sort-arrow

icon-import

icon-export

icon-import-all

icon-export-all

icon-upload

icon-download

icon-document

icon-create-report

icon-document-checked

icon-notifications

icon-gear

icon-feedback

icon-search

icon-pin

icon-thumbtack

icon-toggle

icon-attachments

icon-link

icon-calendar

icon-clear-knockout

icon-add-knockout

icon-subtract-knockout

icon-update-knockout

icon-error-knockout

icon-info-knockout

icon-comment-knockout

icon-email-knockout

icon-social-knockout

icon-clock

icon-edit

icon-social

icon-social-failed

icon-checkbox-unchecked

icon-checkbox-checked

icon-checkbox-indeterminate

icon-radio-unselected

icon-radio-selected

icon-reset

icon-printer

icon-help

icon-mdr-work-request

icon-word

icon-excel

icon-pdf

icon-zip

icon-msc-logo

icon-breadcrumbs

icon-last-page

icon-equipment-history

icon-gripper

icon-ellipsis

icon-alert

icon-complete

icon-delete

icon-cascade

icon-play

icon-grid-collapse

icon-grid-expand

icon-clipboard

icon-from-clipboard

icon-connected

icon-disconnected

icon-database-error

icon-grid

icon-grid-layout

icon-launch-peng

icon-tools

icon-oil-can

icon-line-chart

icon-diamond

icon-droplet

icon-engine

icon-star

icon-oil-barrel

icon-shopping-cart

icon-related

icon-check

icon-bold

icon-italic

icon-underline

icon-variable

icon-spellcheck

icon-image

icon-undo

icon-cut

icon-copy

icon-find-replace

icon-duplicate

Specifications

Icons, in SAMM, are visual metaphors representative of a particular action to be performed or set of information to be interpreted. They can stand alone or become part of a button, which is essentially a shell for the icon that helps to better emphasize that an action is required. As a clear message is crucial to the icon being understood, icons should be designed to be minimalistic, sticking to a flat, single color, unless more dimension is expressly required for the icon to be read and understood. These will be a very rare occurrence as the whole SAMM interface is being designed to take advantage of a "Flat" design aesthetic.

Examples

Specifications

Inputs in SAMM 2.0 are designed to blend seamlessly with the design of the buttons and are, therefore, similar in size, shape, and behavior.

Note: In some cases when the Inputs become disabled they will require a tooltip to indicate the reasons for the field being disabled. This will be handled on a case by case basis. Please contact the Emprise Corporation Visual Communication Department for any questions regarding when to add a tooltip to disabled inputs.

Business Rule - Form Vertical Alignment: In a form, when Inputs are stacked on top of one another the left edges of all of the inputs should be aligned 10px away from the longest Input label in order to maintain visual continuity. Examples of this can be seen in the Modal Windows section of this documentation.

Business Rule - Field Validation: The Field Validation Behavior for SAMM is a hybrid of a live validation procedure and a standard validation procedure. As a user initially enters a field, the field will become focused and receive the focus state detailed above. The field will remain in its focused state until the user manually leaves the field, at which time the field will validate and receive the invalid state detailed above, if it is indeed invalid. Upon returning to the field, it will remain in its invalid state and use a live validation procedure to determine when the user enters a valid value into it. When the value becomes valid the field will return to its focused state.

Business Rule - Permissions / Required Fields: Many modal screens within the SAMM application contain required fields. Normally, data entry is necessary for a required field to pass validation and allow the modal screen to be saved/closed. In the case where a user does not have permission to enter data into a required field, the logic for the required field should be disabled, the styling for the disabled state should be applied to the input, and the required marker (*) should be removed/hidden. This will allow the user to continue to save and close the modal without interference.

Business Rule - Multi-Select Inputs: When an Input is capable of accepting multiple input values it should follow the rules set in the table below as to what needs to be displayed in the field.

Text Input

A Text Input serves a the primary method of entering data into SAMM and therefore has had a particularly large amount of effort put into making it as clear and user-friendly as possible, while still maintaining our strict design aesthetic.

CSS Note: The Normal state for Inputs should have a transition: border 0.3s ease-in; on it. All other states should have a transition: border 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

CSS Note: Text within Inputs should truncate with an ellipsis 6px away from the right-most edge of the Input.

Name	Examples	This State Trumps	Fonts
Normal		None	Label: Dark Blue Regular Text Value: Dark Blue Regular Text
Hover		Normal, Focus	Label: Dark Blue Regular Text Placeholder: Small Grey Text
Focus		Normal	Label: Dark Blue Regular Text Placeholder: Small Grey Text
Disabled		All	Label: Dark Blue Regular Text Placeholder: N/A Value: Dark Blue Regular Text
Invalid		Normal, Hover, Focus	Label: Dark Blue Regular Text Value: Small Red Text

Input w/ Icon

Inputs will often contain icons to better represent to the user the action to be performed or the type of data to be entered. These icons will, in most cases, be justified to the right-hand side of the input. Some examples of these varients of inputs are the "Quick Search" inputs and Dropdown inputs (a.k.a. Select Boxes)

CSS Note: The icon-clear-knockout should have a transition: fill 0.3s ease-in; on it while its hover state should have a transition: fill 0.125s ease-out; on it.

Numeric Input

The numeric input in SAMM allows the user to enter numeric values into a form. Users may add, increase or decrease values by using the spin buttons (arrows) or by typing a numeric value in the field.

Utilizing the spin buttons will allow the user to incrementally increase or decrease the number in the field by intervals of 1. If a decimal place is required, the numbers after the decimal shall default to zeros and the user must manually enter the numbers following the decimal.

Time Entry Input

The Time Entry Input in SAMM uses a similar paradigm to the native time input. It is made up of two inputs, one for hours and one for minutes separated by a static text colon. These two input are then followed by the icon-clock glyph to better illustrate to the user the input's purpose.

CSS Note: The Time Input will need to override the min-width defined for normal Inputs. The two inputs that make up this single input should each be 26px. wide.

Currency Input

The Currency Input is a method of entering right-aligned numeric data into SAMM; this data follows the United States currency formatting rules and gets automatically formated in the input field.

Example: 10000 translates to 10,000.00 within the input field.

The US Dollar ($) symbol is static and left-aligned in the field to define the intended purpose.

Typeahead

The Typeahead feature provides suggestions of common words and phrases based on the letters being entered in the field.

Business Rule:

• Selection menu shall follow the styles defined for Context & Dropdown Menus.
• Typeahead feature can be applied to dropdown menus, text inputs, and email inputs.

Email Inputs

Email Inputs in SAMM provide a user with the ability to enter one or more email addresses.

Singular Email Address Input

The Singular Email Address Input can accept one validated email address.

Singular Email Address with Typeahead

The Singular Email Address Input with Typeahead can accept one validated email address and utilizes the typeahead functionality to assist users with searching for/entering the user's address.

Multiple Email Addresses with Typehead

The Multiple Email Addresses with Typeahead input can accept multiple validated email addresses and encases them inside a Pill with a remove icon. This input also utilizing the typeahead functionality.

Note: The input can expand vertically to allow for multiple lines of inputs as long as the layout of the screen allows for it. This will be handled on a case by case basis and each case shall be documented on the Wiki.

Email Address Validation

When an email address is inputted into the Email Input Field, validation using the below business rules will be conducted.

The singular Email Input Field follows the same style as SAMM's standard Invalid Input state, when an email validation fails.

When an email address in an Email Input Field fails validation, Tooltips are used to assist with error recovery, providing information on how to correct the email address in question.

Business Rule: Email addresses are 7-bit ascii; each character has a value from 1 to 127.

Business Rule: The email has a localpart on the left of an @, the domain on the right.  Neither the localpart nor the domain may be empty.

Business Rule:The localpart must be 64 characters or less.

Business Rule: The localpart can consist of labels separated by periods but there cannot be two successive periods, nor can it start or end with a period.

Business Rule: Labels can either be quoted or unquoted.

• Unquoted labels must have at least one character; this can only contain a-z, A-Z or 0-9.

Business Rule: The domain can be bracketed, unbracked

• An unbracketed domain can consist of labels separated by periods and less than 253 characters. No domain can start with a period, end with a period, or have two successive periods.
• Labels consist of a-z, A-Z or 0-9.
• Labels must be less than 63 characters.
• Labels must not start with a hyphen, end with a hyphen, or contain two successive hyphens.
• The right-most label must be all alphabetic.

Error Recovery Tooltip Language

An error recovery tooltip can contain one or more corrective messages to the user, upon mouseover of the email input field. This tooltip is only present when there is an error in the email input field.

Text Area

Text Areas are inputs that allow the user to enter a larger amount of data without their entry being truncated or otherwise limited to a fixed width and height.

CSS Note: Text within Text Areas, unlike other inputs, should not truncate. Rather, it should wrap to the next line. If the text wraps past the bottom of the Text Area, the whole input should scroll to accommodate this.

Inputs Specific to In-Grid Editing

These Inputs only differ from other standard Inputs in SAMM in that they are two pixels smaller than there standard counterparts. This is done to allow them to be able to fit into the standard SAMM grid rows when In-Grid Editing is present.

Examples

Specifications

Navigation Bar Buttons

Note: Please refer to the Buttons: Icon Buttons section to find specifications for the Icon Buttons in the Navigation that do not have dropdown menus associated with them.

CSS Note: The Navigation Bar Buttons that have Dropdown Menus associated with them should have a delay of 200ms from when the user's mouse leaves the menu to when the menu closes and the button hover state changes back to its normal state. This will help facilitate a more forgiving user experience.

CSS Note: The Normal state for Navigation Bar Buttons should have a transition: border 0.3s ease-in; on it. All other states should have a transition: border 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Example	This State Trumps:	Fonts
Normal		None	White Header Text
Hover		Normal, Focus	White Header Text
Focus		Normal	White Header Text
Active/Pressed		Normal, Hover, Focus	White Header Text
Disabled		All	White Header Text

Navigation Dropdown Menus

CSS Note: Navigation Dropdown Menus should have a min-width: 160px;. If the Navigation Bar Button that activates the Navigation Dropdown Menu is wider than 160px then the menu's width should be equal to the width of the button.

CSS Note: The Normal state for the Navigation Dropdown Menu Items should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Example	This State Trumps:	Fonts
Menu Items Normal		None	White Sub-Head Text
Menu Item Hover		Normal	White Sub-Head Text
Menu Item Focus		Normal	White Sub-Head Text
Menu Items Selected		Normal, Hover, Focus	White Sub-Head Text
Menu Items Disabled		All	White Sub-Head Text

Examples

Specifications

It is important to note that Panels are a major part of the application and future feature requests may require the design for Panels to change. When this occurs these changes will be documented here as separate variants of the Panel.

CSS Note: The height of the panel header includes the stroke on the bottom of the header but not the stroke on the top, as that can be created by border on the panel.

Detail Panels

The default widths of the Details and Additional Details panels is measured in percentages. This strategy is to account for the differences in the panel dimensions across the various modules and to keep the proportions of the panels widths consistent.

Example

CSS Note:The default width for the Details panel is 65% and the default width for the Additional Details panel is 35%.

Examples

Specifications

Background

Fill

Examples

Specifications

Both of the designs can be used in the horizontal format to adjust vertical sizes and in the vertical format to adjust horizontal sizes.

Business Rule: When hovering over any resizer, including the the version with no styles of its own, the cursor should change to the cursor: row-resize; cursor style.

Examples

Specifications

Primary Tabs

The Primary Tabs are typically used to switch data groupings on a more macro level. A good example of this is Modal Windows, where the main conceptual functions of some Modals are separated into different tabs to help with ease of use.

CSS Note: The Normal state for Primary Tabs should have a transition: background 0.3s ease-in, border 0.3s ease-in; on it. The Hover state should have transition: background 0.125s ease-out, border 0.125s ease-out; on it. The Focus state should have transition: border 0.125s ease-out; on it. The Active state should have transition: background 0.125s ease-out; on it. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

CSS Note: The white background of the Active Tab is a variable value. The color should match the background of the panel that it is controlling. Also the background color should bleed into the panel itself so that it appears that the active tab is apart of the current panel.

CSS Note: On rare occasions, a Primary Tab can be both Active and Disabled. When this is the case the text in the Active state simply becomes color: rgba(54, 62, 71, 0.55); while all other style stay the same.

Name	Example	This State Trumps:	Fonts
Normal		None	Body Copy
Hover		Normal, Focus	Body Copy
Focus		Normal	Body Copy
Active		Normal, Hover, Focus	Body Copy
Error		The red text color should trump all other states' text colors while not interfering with the other stylistic elements.	Body Copy
Disabled		All	Body Copy

Primary Tab Overflow

Specifications

Example

Secondary Tabs

The Secondary Tab system is used on a more micro level, when data belongs to a more overarching concept but still needs to have its own separate work flow. Again, a good example of this would be in Modal Windows, where a set of data needs to be organized into tabs while it is, itself within a tab.

CSS Note: The Normal state for Secondary Tabs should have a transition: border 0.3s ease-in; on it. All other states should have a transition: border 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

CSS Note: The Tabs themselves, in this system, should be centered horizontally in the well and should be centered vertically on the top border of the well. This will make the Tabs sit 50% inside and 50% outside of the well area.

CSS Note: On rare occasions, a Secondary Tab can be both Active and Disabled. When this is the case the text in the Active state simply becomes color: rgba(54, 62, 71, 0.55); while all other style stay the same.

Name	Example	This State Trumps:	Fonts
Normal		None	Dark Blue Regular Text
Hover		Normal, Focus	Dark Blue Regular Text
Focus		Normal	Dark Blue Regular Text
Active		Normal, Hover, Focus	Dark Blue Regular Text
Disabled		All	Dark Blue Regular Text
Error		The red text color should trump all other states' text colors while not interfering with the other stylistic elements.	Dark Blue Regular Text Filtered to #e57a68

Tertiary Tabs

The Tertiary Tab system is also used on a more macro level, like Primary Tabs. However, this system should be used sparingly, and primarily when the interface requires that there be more than five tabs. A good example of this would be the SAMM Repair Details Dialog which you can see mock ups of on the Emprise Corporation Wiki.

CSS Note: The Normal state for Tertiary Tabs should have a transition: background-color 0.3s ease-in; on it. The Hover state should have a transition: background-color 0.125s ease-out; on it. The Focus state should have a transition: border 0.125s ease-out; on it. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Example	This State Trumps:	Fonts
Normal		None	Body Copy
Hover		Normal, Focus	Body Copy
Focus		Normal	Body Copy
Active		Normal, Hover, Focus	Body Copy
Disabled		All	Body Copy
Tab In Error		The red text color should trump all other states' text colors while not interfering with the other stylistic elements.	Body Copy

Examples

Specifications

The Toggle Status Indicator is a similar concept to Radio Buttons, whereas only one option can be selected at a time and selecting one option will automatically deselect any other options. As was mentioned earlier, the Yes/No status toggle is the primary use for this UI element. That being said, there may be times where this element may be used for switching between other functional concepts, similar to the Yes/No paradigm.

Other colors for the different options may also be used depending on the use case. When this situation arises the Emprise Corporation Visual Communication Department should be consulted on how to proceed.

Initial / Default State

The initial or default state for the Toggle Status Indicators is to have neither option selected and will appear as follows:

Selected States

The following represents the various states of the Toggle Status Indicator while one or the other of the options is selected. Many of these styles also apply to the default state.

Toggle Status Indicator Styles

Name	Examples	This State Trumps	Fonts
Normal		None	Dark Blue Regular Text
Hover		Normal, Focus	Dark Blue Regular Text
Focus		Normal	Dark Blue Regular Text
Active		Normal, Hover, Focus	Dark Blue Regular Text
Disabled		Normal, Hover, Focus, Active	Dark Blue Regular Text
Selected Red		All	White Body Copy
Selected Green		All	White Body Copy
Invalid		Normal	Dark Blue Regular Text

Examples

Specifications

The most commonly used Tooltip in SAMM will be the Dark Blue color. The Red Tooltip will be used in most cases for important alerts, such as field validation, and will come with a negative connotation. The other colors will be used sparingly as they are meant to address edge-case scenarios where neither the standard dark blue or alert red will work.

Business Rule: Any ambiguous user interaction that does not make itself immediately apparent what the user needs to be doing should have a tooltip. This means things like buttons with icons only, no text. For example, the minimize and maximize buttons in the panel headers or the “Suggestions” button in the main navigation bar. Also all truncated textual content should have a tooltip that displays the full text.

Business Rule: When a user hovers over an element that has a Tooltip attached to it, there should be a 1000ms (1 sec.) delay before the Tooltip appears. Furthermore, if the user continues to hover over this element the Tooltip should remain visible for 10000ms (10 sec.) before fading out to transparent.

Business Rule: The Tooltip should align so that its left-most edge is flush with the left-most edge of the cursor and be 4px below it whenever possible. If for some reason the Tooltip can not be aligned in this position than it should be pushed to align the right-most edge of the Tooltip with the right-most edge of the cursor. If neither one of these postiions is available than the same model can be used to align the Tooltip above the cursor.

Tooltip Styles

Name	Examples	Fonts
Dark Blue Tooltip		White Body Copy
Blue Tooltip		White Body Copy
Grey Tooltip		Dark Blue Regular Text
Red Tooltip		White Body Copy

Examples

Specifications

Trees in SAMM are one of those occasions that the even 2 pixel spacing rule will need to be broken in order to accommodate the design. Where as most of the elements in the trees will still adhere to the even spacing rule, some elements, such as the expand and collapse icons, will need to be oddly sized and spaced to appear correct with this design.

CSS Note: The Normal state for the nodes in Trees should have a transition: all 0.3s ease-in; on it. All other states should have a transition: all 0.125s ease-out; on them. This creates a faster transition into each state while having a smooth subtle transition back to the Normal state.

Name	Examples	This State Trumps:	Fonts
Parent Node Normal		None	Dark Blue Regular Text
Parent Node Hover		Normal, Focus	Dark Blue Regular Text
Parent Node Focus		Normal	Dark Blue Regular Text
Parent Node Active/Selected		Normal, Hover, Focus	Dark Blue Regular Text
Parent Node Disabled		All	Dark Blue Regular Text

Tree Placement And Spacing

The most common occurrence of the Tree in SAMM will be in the Navigation Panel, therefore we will use that as a reference for Tree placement and spacing within other elements. These specs may need to be altered depending on where the Tree is being used in the application. When this is the case, the Emprise Corporation Visual Communication Department should be consulted for any new specs.

Tree Branch Placement and Spacing

Each node in the Tree is connected to the nodes above and below it by a "branch". In this case it is a dotted line that helps the viewer keep track of the hierarchy in the Tree when there is a large amount of data being presented. For the Leaf nodes there is also a horizantal dotted line infront of the leaf icon that connects each leaf node to the vertical line.

The dotted lines should be 1px dotted #ced0d2.

Standard Styles

Business Rule: When determining spacing for text elements the baseline of the text should be used to measure spacing below text and the font ascenders should be used to determine spacing above the text.

Examples

Specifications

In SAMM, Wells are most often used as an enclosure for Secondary Tabs, as depicted by the example above. For styles relating to how the Well interacts with Secondary Tabs, see the Tabs section of this documentation.

Static Wells

CSS Note: Spacing within and around Wells with titles should attempt to ignore the title whenever possible. If this is not possible contact the Emprise Corporation Visual Communication Department for guidance on how to proceed.

Scrollable Wells

Examples

Specifications

The following specifications for the Accordion Cards are for the generic UI elements. There may be some situations in the applicaiton where these styles differ from these definitions. In those case please contact the Emprise Corporation Visual Communication Department for guidance on how to proceed.

Collapsed

Note: The height of the card in the collapsed state is 55px and is determined by the height of the expand icon plus the 20px of padding top and bottom. The summary text in the right-hand side of the card should be centered vertically in the height of the card. This was done as a manditory effort to conserve space in the application and also because the summary text will not always be present.

Expanded

Note: The content within the Content Area of each Accordion Card is variable and should support a dynamic height. Also note that there may or may not be additional content in the Header section depending on the usage of the Accordion Cards. When this is the case please contact the Emprise Corporation Visual Communication Department for guidance on how to proceed.

Examples

Main Interface

Specifications