BCP 2.0 Platform Guidelines User Experience

User Application Design Guidelines

May 9, 2012

2 Table of contents

Table of contents

Introduction 4

Purpose of this document 4

How to use this document 4

Functional requirements 5

Layout 5 Screen layout 5 Application screen patterns 5 Content screen patterns 7 Margins 10 Fluid layout 10 Controls layout 10 Toolbars 12

Skinning 14 Themes 14 Icons 15 Interaction states 16 Fonts 17 Text 17

Glossary of terms 17

Controls 19 Standard controls 19 Custom components 28

User input 42 Keyboard 42 Mouse 44

Operations 46 Naming and renaming 46 Saving 46 Validating data 47 Undo and Redo 47

User feedback 47 Success 48 Information and status messages 48 Error 48 Progress 48

Data validation 48 Mandatory values and validation patterns 48 Validation feedback 49 Validation 49 Validation cycle 50

Languages 50 Localizing the user application 50 Translation process 50

Table of contents 3

Regional settings 51 Regional settings content 51 Applying regional settings 51

Non-functional requirements 53

Events tracking 53 Event pattern 53 Most common event origins 53

Events browsing 54

Events notification 54

Application auditing 54

Auditing probes 55 Tracking actions 55 Tracking pattern 55 Asynchronous tracking 55

Audit log 55

4 Introduction

Introduction

Purpose of this document

This document contains a set of guidelines about creating applications.

Designers and developers must follow these guidelines in order to ensure that all applications

provide the mandatory set of features, have the same system and installation requirements,

provide the same user experience, documentation.

How to use this document

This document includes several directives, many of which have the form of rules designers and

developers must follow.

Make sure to:

Understand and follow every rule.

Discuss with the project board every choice that could conflict with these rules.

Discuss with the project board improvement proposals for these guidelines.

Applications will undergo several scrub phases, during which the technical specifications will be

compared to the guideline to ensure overall application requirements are met

Note: these guidelines will evolve by including proposals from project managers.


Functional requirements

Layout

Screen layout

Applications must be designed with a target size of 1280x730px (average available space inside

the browser window). If such space is available, no scrolling of the user interface should occur.

Heading is as wide as the whole application and is 75px high. The remaining space is filled by

the application.

Application screen patterns

The following screen patterns are available.

Site

Site pattern treat the application as a web site.

6 Functional requirements

Vertical tabs

Multiple functionalities are available via vertical tabs menu. Vertical tabs menu cannot contain

features that consist of a one-shot action.

This screen patterns complies to the following rules:

1 Only one tab can be selected at the time.

2 The first tab is selected automatically when the view is loaded.

3 Tabs can have sub-features.

4 If a tab with sub-features is selected, the tabs bellow it slide down to accommodate the list

of features, the first feature is selected automatically.

5 If a tab with sub-features is selected, at least one of the sub-features must be selected as

well.

6 Restrict tab names to 2 words if possible. Try to level tab size.

7 Tab and sub features titles must remain on the same row.

Designer

Use this layout to maximize real estate in designer based applications.


This screen pattern complies to the following rules:

1 Palette areas are optional.

2 Palette areas are non-floating.

3 Palette areas are resizable and collapsible.

4 Contents of the main areas can be zoomable and scrollable.

5 Contents of the main area might support multiple tabs to implement several designer panes.

6 Contents of the main area are not restricted to a workspace, they could include forms, lists

and tables but they must be homogeneous.

Content screen patterns

Wizard

Wizard patters is composed by a horizontal accordion. Each step of the accordion displays a

different view. The pattern allows to perform sequential operations like a check list but also offers

free navigation back and forth.


1 Wizards cannot have more than 9 steps

2 The selected step must display a description (text+images) in the heading


3 All wizard content is committed or canceled at once

4 Wizard steps must be numbered sequentially

5 If a wizard is used both in the creation and editing of an element, corresponding features

must be in the same place in both operations

Master - detail

Use pattern to show information in lists and provide further details about the selected item.


1 If multiple features are modified, the Apply or Cancel button commit or revert them all

2 The master list allows actions

Multiple tabs

Use this pattern to split a main area or a palette area in multiple sibling functionalities.


1 Tab features must be sibling or alternative


2 Tabs cannot be nested

3 When the multiple tabs pattern is used with navigation purpose, the number of tabs must be

fixed.

Popup

Use this pattern to set up a small amount of information for the selected item of a view. The

popup must be modal, therefore the underlying information will be hidden.


1 The popup window is modal

2 All settings of the popup are committed as a whole

3 The popup always appears centered on the application window

4 The popup must be square or, if not, it must have a width greater to its height

5 The popup must always leave a band of 200px of underlying application visible on each

side (based o default application layout).

6 Popup should have two possible outcomes: Apply and Cancel. The first confirms changes

made in the popup, the second cancels them. When the user clicks either Apply or Cancel,

the popup closes. One further outcome is permitted form repetitive action: "Apply and next".

7 An optional button to trigger help actions is permitted.

Floating toolbox

A floating toolbox is a kind of non-modal popup used to host additional controls which are less

important than normal controls and should be displayed on demand. The controls usually affect

contents on a workspace, thus the toolbox must remain visible to allow editing.



1 The floating toolbox is allowed only in designer pattern.

2 If the view from which the toolbox was generated gets hidden, so does the toolbox.

3 The toolbox is not modal.

4 The toolbox is displayed by clicking on a button of the toolbar which it extends by adding

controls. Such button must be of toggle type.

5 The toolbox hosts content laid out vertically and is as wide as needed to host a single form

column.

6 The toolbox can be closed using a button on the top right corner.

Margins

With respect of the screen pattern used, controls must leave the following gaps:

Gap between Distance

Label of a control and corresponding control 5px

Subsequent label/control pairs of the same subjects 15px

Subsequent label/control pairs of different subjects 25px

Window or form sides 10px

Between form columns 20px

Step in of subforms (see Subforms) 10px

Fluid layout

With respect of the screen patterns described above, the following rules of fluid layout apply:

1 All elements which have a variable width or height must expand such size as much as

possible give the current application size.

2 Controls are registered on the top left corner of their container

3 All controls except those included in forms must have a variable size by retaining the

margins described above from every available side of their container

4 Every resizable control must have a minimum size under which it cannot be shrunk (see

controls for details on the minimum size)

Controls layout

Forms

Forms groups of controls stacked on top of each other. Depending on the available space, forms

con be layed out in one, two or three columns.


The following rules apply to form layout:

1 All forms controls are 300px wide.

2 Form control may include titles, which must have a different font size or decoration from the

normal control labels.

3 Mandatory controls must have a red * at the left side of their label.

4 The label is always stacked on top of the control and is also 300px wide. It is not allowed to

have label with text wider than 300px.

5 If the form has more than one column, a 20px gap is reserved between columns

6 If the form has more than one column, controls in each column must have similar meaning

(i.e. set the same class of parameters).

7 Forms should not scroll at default application size. If a form contains too much elements to

be fit in a single column, use multiple columns or categorize elements and create multiple

tabs, each with a piece of the form. In the latter case, the keyboard loop must automatically

select the first control of a form if the focus is on the last control of the preceding and the

user presses TAB.

Subforms

Subforms are forms included in other forms whose activation depends on other controls to be

enabled or not. Subforms comply to the same stacking rules as forms, plus the following:

8 Subforms controls are 290px wide

9 Subforms reserve a 10px gap from the left registration point of the parent form

10 There can be one level of subforms at most

11 Subforms must be activated and deactivated as a single object depending on one or more

controls of the parent form

12 Subforms appear immediately below the last control which determines their activation

Operation buttons

Operation buttons such as Apply, Cancel or Next are placed in the bottom left corner of the

window or region they refer to. In doing so, they always leave a 10px gap from the bottom and

the left sides of their container.


Toolbars

Main toolbar

The main toolbar used by all applications has the following regions:

Region name Content

Logo Contains the Doxee logo (Illustrator and SVG files provided) or

the client logo if not using the default theme.

The logo shall have an emboss effect of 2px per side.

Clicking the logo opens the About panel.

Breadcrumb Contains a path leading to the position the user is working on.

The path is generally followed through Portal and Workbench.

For leaf modules like EDOC and ESOURCE, the breadcrumb is

read only

Feature buttons Optional. Contains a tabbed menu with sub-features of the

current position. If only one feature is available, no buttons

appear

User name Contains the user name

1 Size 8pt

Other controls Contains the controls common to all applications like language

change, help and quit

Service name Contains the software service name according to the offering

matrix. The text shall comply to the following rules:

1 All caps, size 9pt

2 Top-Right aligned

3 One line


The main toolbar has the following buttons in the general controls drawer (from the right):

Name Icon Allowed in Description

Exit

All Base Module: logout

Workbench: logout

Other modules: close window but retains user

session

My account Base Module

Workbench

Edit own account settings (if clicked from

Workbench opens the corresponding Base

Module screen)

Settings

Base Module

Workbench

Edit application settings (if clicked from

Workbench opens the corresponding Base

Module screen)

User name All Displays the user name

Example


Other toolbars

Toolbars are collection of controls with consistent meaning placed every one close to each other

and generally follow these rules:

1 Toolbars are always on top of the controls or region they refer to, see single controls for

details about the suggested toolbar type for some of them

2 Toolbars are always horizontal.

3 Controls leave a 5px gap between each other.

4 Controls are placed from left to right in order of importance. I logical grouping of controls (an

therefore vicinity) is needed, the necessity can override this directive.

5 Contain at most two lines of controls per icon only toolbar end one line for button toolbar.

6 Use either text buttons or icon buttons, mixed text/icon buttons are not allowed

7 Toolbars of text controls cannot contain more than 5 buttons. If more than 5 features need

to be included, the last button can be replaced by a combo box with the remaining features.

Skinning

This section contains several specifications about skinning controls and applications.

Themes

Applications must support themes. A theme applies the following features to the user application:

Colors and decorations

Icons

Fonts and text properties

In order to fully support themes, applications must follow these rules:

1 Themes are set by name, upon changing theme the application must reflect changes

without restart. Fonts and other assets are included in the package.

2 Themes are bundled in packages that can be deployed without re-deploying the application.

3 Applications must have a default theme called default built-in.

4 User preferences determine the theme in Base Module, other applications will comply to

user preferences. If the named theme is not available, default theme will be used instead.

5 No icon, font, color can be mixed with the application code. Applications must support

setting of all their properties by stylesheet.

6 Every component type that can be skinned must have a class name which matches the

corresponding style information inside the theme.

Default theme

Default theme has the following features.

Category Feature Details

Font Default font Arial (regular, bold)

Text style Labels

Buttons

Etc...

Color scheme Background


Category Feature Details

Row

Etc...

Icons Apply/Confirm

Cancel

Etc...

White labeling

Themes must allow white labeling. Based on client requirements it is possible not to display

Doxee logo in the logo region and put the client logo instead.

Skinning

The following rules apply.

1 The following controls must support skins.

2 Skins are determined by themes and apply size and style to the control.

3 Controls which support states must be skinned for every state.

Note: some controls may not need additional skinning to be themed, in this case only stylesheet

applies.

Icons

Icons specifications

Icons are used through the application to clarify the meaning of buttons and simplify feedback to

the user.

All applications must follow these rules:

1 Icons are raster assets. Vector icons are allowed if they must represent something

zoomable (i.e. icons included in a workspace for a designer).

2 Icons must be square and have one of the allowed sizes. Applications are not allowed to

apply resize on icons, which must be designer for best viewing at their target size.

3 If multiple sizes are needed for an icon, all sizes must be designed in separate assets.

4 For every icon all interaction states must be produced. See interaction states.

Size of icons

Size (px) Used in Example

16x16 Icons in text buttons

32x32 Icons in icon buttons

128x128 Big icon-only buttons


Size (px) Used in Example

Icons repository

Follow these rules when picking an icon:

1 Search the icons repository for an icon which conveys the same meaning you are picking

an icon for

2 Use the icon repository as example of style, size, states that need to be created

The icon repository is available at: Icons.

Interaction states

Controls which fully support mouse interaction have many interaction states. Every icon

designed must have a version for each interaction state, so to change as the parent control

changes.

State name Description Icon Skin (button)

Enabled up Control can take action.

Mouse pointer is out of the control area.

Enabled over Control can take action.

Mouse pointer is above the control.

Enabled down Control can take action.


Mouse button is pressed.

Enabled selected

up

Control can take action.


Control is toggle-type and is currently

selected.

TBD

Enabled selected

over

Control can take action.



selected.

TBD TBD

Icons


State name Description Icon Skin (button)

Disabled up Control cannot take action.


Disabled selected Control cannot take action.


selected.

TBD TBD

Fonts

Fonts can be used for the following reasons:

For text in controls: in this case fonts are dynamic and determined by the theme

For application purposes (i.e a visual designer may use fonts to customize text

appearance). In this case fonts are loaded separately and must not conflict with themes

font.

Applications must follow these rules:

1 Font files are part of the theme package.

2 All fonts are vector based.

3 Fonts used by controls must cover at least the following codepages: Cp1250, Cp1251,

Cp1252, Cp1253, Cp1254, Cp1255, Cp1256, Cp1257, Cp1258.

Text

The following specifications define how to use test inside the user application.

Capitalization

The following capitalization rules apply:

1 The first letter of any label, title or text block must be upper case.

2 The first letter of any word in a label, title must be lower case except for words that are

names of concepts invented for the application.

3 Never use camel case in the user interface.

Formatting

The following formatting rules apply:

1 Rich text is not allowed in labels, titles or text block except those user for in-context help. All

words of a text content have the same style.

2 Themes define font, text size, style and decoration.

3 Labels and text blocks have the same style, size, decoration through all applications.

4 Titles must have a style different from labels and text blocks.

5 Links always have the same text style, size and decoration of normal labels but they must

be underlined and have different color.

6 Text in lists, combo boxes, trees and other controls that allow displaying of text must have

the same style, size, decoration as labels and text blocks.

Glossary of terms

The following glossary contains terms allowed through all applications. The glossary contains the

correct US English term, the correct Italian term and some examples of wrong terms that are not

allowed.

Correct Wrong

US IT US IT

Code Codice ID

Identifier

Number

N.

ID

Identificativo

N.

Name Nome Label

Title

Etichetta

Titolo

Delete Elimina Remove Cancella


Correct Wrong

US IT US IT

Erase Rimuovi

Import Acquisizione Input (used as

acquisition)

Reading

Loading

Input (in chiave

acquisizione)

Lettura

Caricamento

Delivery Consegna Output (used instead

of delivery)

Transfer

Export

Sending

Output (in chiave

invio o consegna)

Trasferimento

Invio

Esportazione (di

eventi o flussi

informativi)

Settings Impostazioni Administration

Configuration

Management

Amministrazione (di

sistema)

Gestione (di sistema)

Configurazione (di

sistema)

Export Esportazione (di

eventi o flussi

informativi)

- -

Apply Applica Save

Confirm

Ok

Salva

Conferma

Ok

Registra

Cancel Annulla Close

Exit

Cancella

Chiudi

Info Info (severità evento

di log)

- -

Warning Avviso (severità

evento di log)

- -

Error Errore (severità

evento di log)

- -

Type of <something> Tipo di <qualcosa> Type (without

clarifying the scope)

Category (without

clarifying the scope)

Tipo (senza altro

termine che specifica

l’ambito)

Categoria (senza altro

termine che specifica

l’ambito)

Invalid Non valido Not valid Invalido

List Elenco Catalogue

Index

Lista

Catalogo

Start date Data avvio Begin date Data inizio

End date Data termine - Data fine

Due date Data scadenza - Data decorrenza

Abort date Data interruzione - Data blocco

Data fine

Shipment Missiva Missive Spedizione

Document Documento - -

This glossary will extend over time. Project teams must follow these rules:

1 Terms that appear as labels of buttons, controls, tabs and are not part of common language

must be discussed with project board for approval.


2 Synonyms of the terms in this glossary must be discussed with project board for approval

before being used in any part of the application.

Controls

Standard controls

Label

Description Control used to indicate the functionality of the control placed immediately

below in a form layout

When to use In forms: for every control except single check boxes and subforms

enabled by check boxes

Limitations Text is non selectable

Behavior -

Button

Description Control which generally enables user action with immediate outcome.

Buttons may contain text, an icon or a combination of the two.

When to use Express an action with immediate consequence

Limitations Toolbar buttons can be text-only or icon only

Apply and other confirmation buttons have no icon

Behavior Triggered action must start immediately after pressing the button.

Some buttons may require user confirmation before taking action or

further action before commit, in this case their label ends with an ellipsis

(...)

In toolbar with more than 5 buttons, the "More" menu allows actions which

are performed by just selecting the list item

Toggle button

Description Type of button which features on/off states. It combines the action related

to a button with the volatile activation of a feature related to such action.

When to use Used to enable/disable a functionality of the user application. Also used to

toggle an option which can have two possible state. The state of a toggle

button must not be saved as information. For such features use check

boxes.

Limitations Same as buttons

Toggle buttons do not allow "further action required..." mode.

Behavior Implies the use of the Selected/non-selected states. Click once to put in

selected state, click again to place on non-selected state.


List and grid

Description Contains a list of elements, on element for every row. Simple lists have

only one column and no heading, complex lists as data grids may have

several columns and header for each one. Lists can be editable.

When to use Display a list of features: by selecting a row a feature is selected and

some parts of the user interface may be enabled or revealed. This is

called type 1 list.

Display a list of elements whose number and details may vary depending

on user interaction. In such case, usually allows creation, deletion and

modification, sorting of contents. This is called type 2 list.

Limitations If you need sorting, filtering, searching and multiple selection, use the

Table control instead.

Behavior The following rules apply:

1 Only one item can be selected at the time.

2 Single click selects the item.

3 Double click selects the item and enters the edit mode. If the list has

more than one columns, when the item is in edit mode every cell of the

row displays the corresponding editor. See keyboard shortcuts for

other details.

4 Press Enter to exit the edit mode and commit changes, press Esc to

exit the edit mode and cancel changes. Click any other row to exit the

edit mode and commit changes.

5 Additional buttons and control are allowed in rows but they must

appear on mouse over and stay visible in selected row. Controls are

hidden in edit mode.

6 Items are created by creation link. The link is usually labeled "New

<something>...". Clicking the link adds a new row in its place with

default values and enters edit mode. List expected to host a number of

details so to need scrolling should display one creation link above all

elements and one below them. Only one creation link is displayed

when the list is empty.

7 Items are deleted by delete button visible on selected row and on

highlighted row (below mouse cursor).

8 If sorting is allowed, click and hold the button to drag, release button to

release the element. Drop feedback is displayed as a dark line

between the two rows user is going to drop the element in.

9 Alternate row color is allowed only for type 2 lists which don't allow

editing.

10 Lists allow vertical scrolling one row at the time. Horizontal scrolling,

though allowed, is not recommended.

11 When reloading content, always keep selected element if possible.

12 It is not recommended to use type 2 list control to display data which

may grow a lot. Use the table control instead.


Tree

Description Type of list which allows contents to be displayed hierarchically

When to use Display a list of elements whose number and details may vary depending

on user interaction. In such case my allow drag and drop to adjust

hierarchies with limitations depending on the elements displayed.

Limitations Do not use to display a list features, refer to the vertical tabs screen

pattern instead.

Does not allow editing. Use a form to edit the selected element instead.


1 Always customize the node icons in order to clarify the difference

between node nesting levels.

2 Clearly represent allowed drop destinations by showing a drop target

only if the drop is allowed.

3 Creation occurs via external controls. If element of several types can

be created, use a Combo box to list them.

4 When creating nodes, select them automatically.

5 When creating non-leaf nodes, open them automatically.

6 Deletion occurs via delete button visible on mouse over and fixed on

selected elements.

7 Unless you are displaying recursive data, it is recommended to keep

below 4 levels of nesting.

8 Trees with less than 4 levels of nesting should be opened

automatically when the user loads them.

9 When reloading content, always keep selection and open nodes if

possible.


Check box

Description Control made of a toggle button and a label.

When to use Used to let users express an option between two possible choices.

Largely used in forms, where it can activate and deactivate subforms.

Also used in groups displayed flat or hierarchically to enable or disable a

large quantity of elements.

Limitations Choices with more than two outcomes cannot be expressed by check

boxes or a combination of them.


1 Check boxes do not have a label in forms (line above).

2 Check boxes labels have always a positive meaning (i.e. "enable

auditing" is a good label "disable auditing" is not).

3 When creating elements whose properties are set by check boxes,

always put them in their default state.

4 User interaction with a check box is applied immediately, there cannot

be confirmation request.

5 User can either check or uncheck the option by clicking the square box

or the label itself.

Radio button

Description Control made of a toggle button and a label. Always used in groups.

When to use Let the user select between more than two options. The number of options


bust be fixed. If the number of options is above 5 and selecting an option

will not determine the behavior of the user application (i.e. view change), it

is recommended to use a combo box instead

Limitations Cannot be used for less than 3 options.


1 Radio button groups cannot scroll.

2 The default option is always the topmost one.

3 User action is applied immediately. Confirmation request is not

allowed.

4 Labels must be clearly different from each other. It is recommended to

create labels which are the conclusion of the label for the group in

forms.

Text input

Description Box to gather user input on a single line.

When to use Allow free text input..

Display an information that was edited once but cannot be edited

anymore.

Limitations Limited to a single line of text.


1 Limitations on the number of characters and allowed characters may

apply.

2 Text input may support drop of elements, in this case its text must be

replaced to the text visible in the drag indicator.

Text area

Description Box to gather user input on multiple lines

When to use Allow free text input.

Display an information that was edited once but cannot be edited

anymore.

Limitations -


1 Limitations on the number of characters and allowed characters may

apply.

2 Text area may support drop of elements, in this case its text must be

replaced to the text visible in the drag indicator.

3 Text area allows vertical scrolling. Horizontal scrolling is allowed only if


the text is not wrapped. If the number of characters is limited, the

default size of the text area should be set up to display all text without

scrolling, if possible.

Combo box

Description Button which displays a list-based menu when clicked.

When to use Allow selection between multiple options.

Gather remaining features in a toolbar with more than 5 features and text

buttons.

Limitations Maximum 20 element s in the list.

Multiple selection is not allowed.

Check boxes are not allowed.

In case you need one or more those features, use a type 1 list instead.

Behavior User clicks the button to display the list.

User selects one item in the list. The list closes automatically.

If there is no default value: use a prompt on the combo box like "Select a

<something>".

Scrollbar

Description Vertical or horizontal bar with a sliding handle and buttons on the sides.

When to use When a view or the contents of a control cannot fit in a given space use a

scrollbar to allow users to browse them.

Limitations -


1 The proportion between the handle size and the scrollbar length must

be equal to the one between the total amount of data and the

displayed data.

2 Avoid multiple adjacent scrollbars.

3 Scrollbars appear only if needed.


Slider

Description Vertical or horizontal track with handle.

When to use Allow users to express a choice in a continuous range of values.

Part of the zoom control.

Limitations -


1 When dragging, always display the instant value above the handle.

2 Always display minimum and maximum values.

3 If there is a discrete set of values, always display a hint of the step

size.

Link and link bar

Link

Description Buttons a little smaller and harder to click.

When to use Same as buttons. Preferably used when actions must blend to contents

(like in lists) or to express a secondary option user is unlikely to click in the

common use pattern (like "Cancel"). Also used as URL locations.

Limitations -

Behavior Same as buttons. Toggle is not allowed.


Progress indicators

Description Progress bar or busy cursor that generally indicate ongoing action which

can be either blocking for further actions or asynchronous background

action.

When to use Export the progress of an action.

(When indeterminate) Inform the user that some action is going on but it is

not possible to tell when it will end.

Limitations -

Behavior Progress bar fills as the action completes. Always display percent of

completion (unless if used for sparklines). Progress bars for file upload

and download are mandatory.

Indeterminate progress bar is displayed for asynchronous indeterminate

action.

Busy cursor is displayed for blocking indeterminate action. When the busy

cursor is displayed, user cannot click on any control or perform any action.

Progress bars should not be displayed for operations with average

duration of 500-600ms. Use busy cursor instead.

Splitter

Description Handle between to containers or views used to resize them by shrinking

one and expanding the other.

When to use The size of two adjacent regions might not fit the user needs.

Limitations -

Behavior User clicks and drags the handle to change size. Always set up a


minimum size of every region that can be resized. Minimum size must be

set up to display all relevant controls at least.

Tabs

Description Menu with several features displayed horizontally.

When to use Apply many groups of controls to the same region. Every tab corresponds

to a group of controls.

Some uses might need to add and remove features.

Limitations -


1 Features of the same tab must have the same meaning and objective.

2 If several tabs are used to display lists of elements, place the total

number of elements (or the total number of relevant elements) in the

tab name.

3 Tabs may support icon to indicate the content. It is recommended to

keep tab content homogeneous in order to avoid confusion.

4 If adding tabs is allowed, the final tab is always a "add tab" and is

replaced by actual tab when clicked. Each tab has the delete button

always visible. Also a combo box must be placed in the rightmost

position of the tab bar to allow explicit selection of tabs in case all tabs

cannot be displayed together in the view.

5 One of the tabs must be always selected.

6 The first tab is selected automatically when entering the view.

7 When creating a tab, always select it.

8 Tab titles cannot be edited in place, use forms instead.


Tooltip

Description Little description that appears when hovering the control. Contains

explanation. Might contain rich text information.

When to use Mandatory for every control.

Limitations -


1 The tooltip appears with 1 second delay.

2 The tooltip stays visible until the mouse pointer stays above the

control. It disappears immediately after the pointer leaves the

control.

3 If the mouse pointer moves from a control to another and the

movement takes less than a second, the tooltip appears for the

second control without delay.

4 The tooltip must not contain the label of the control. Add

information on the consequence of control activation.

Custom components

Breadcrumb navigator

Description Link bar which represent the user interface navigation path followed by the

user. Contents are strictly sequential and may represent a navigation

pattern through elements created by the user.

When to use Main toolbar or every time a navigation needs to be accessed or just

represented.

Limitations Only one breadcrumb is allowed other than the one in the main toolbar.

6 steps maximum.

Breadcrumb never scroll, if there is not enough space to fit the entire path.

shrink single steps by showing initial 4 characters + ellipsis + final 4

characters of the step name.


1 For breadcrumb in main toolbar, the first step is the Home icon.

2 Breadcrumbs that allow direct navigation to previous steps display

them as links. Steps user cannot navigate to are displayed as labels.


Wizard control bar

Description Horizontal accordion used for controlling navigation in wizards. Wizards

consists of a sequence of actions but allow going back and forth between

actions freely.

When to use Only in wizard screen pattern.

Limitations 9 steps maximum.


1 User clicks a step to display the corresponding view.

2 Every step has a sequential number and a short label.

3 The selected step keeps the short label but also displays a description

which might include rich text and images, this is considered visual

hinting.

4 When the user click Apply in a wizard pattern validation occurs:

For each wizard steps that contains error, the corresponding

element in the control bar displays a red dot

The first steps that contains error is automatically focused.

Table

Description Complex table which allows searching, filtering, sorting of elements.

When to use Display and brose large quantities of data.

Limitations Use only for the core data type displayed in the view. Use lists and data

grids for the rest.

Inline editing is not allowed.

No more than two tables per view.


The table contains the following regions.

Region Description

Toolbar region Contains a text-only buttons toolbar (left aligned) and the

refresh button (right aligned).

Toolbar is optional, refresh is mandatory.

Selection control region Contains two automatic selection links: All and None. Further

selection links may appear,. depending in the categories for

automatic selection. If multiple selection is not allowed, this

region is empty.

Pagination region Contains pagination display or controls. See pagination.

Headers region Contains column headers. Headers can be clicked for frontend

sorting.

Filters region Contains filters for searching and filtering. If filtering is not

allowed, this region is not visible.

Filters appear only on columns that can easily be filtered.

Data region Contains actual data. If multiple selection is allowed, the first

column contains selection checkboxes.

The following is a list of features provided by the table. Some features might have a different

behavior depending on the type of data that needs to be displayed. Each feature is described in

details.

Pagination

Pagination means displaying a subset of elements (page) instead of the total. The number of

element displayed in each page is not fixed and generally depends on functional requirements

(i.e. The number of results user are expected to evaluate at once to find what they are looking

for). There are two types of pagination:

Single page Only one page can be displayed. Users must be notified of how many

results are being displayed, how many match the query string, how many

are generally available. Users cannot go to other pages and have to tune

the filter in order to display results that are not originally included within

the page.

The following rules apply:

1 Use single page pagination only in combination with filtering.

2 Prefer single page pagination when the total result set can be large

(i.e. event logs, documents, shipments etc.).

Multi page Several pages can be displayed. Users must be notified about which

range of the total is currently being displayed and can move through


pages (although not called "pages").


1 If filtering is allowed, prefer single page.

2 The total number of results in single page pagination should be

between 20 and 50.

3 Design the table to fit the total number of results in a page without

scrolling at default resolution. I.e. if the table is designed to display 20

entries per page, the user should not need to scroll to view all entries

unless she has reduced the size of the application windows below

default.

4 Always provide links to move to next, previous, first, last pages.

Suppress previous and first when displaying the first page, suppress

next and last when displaying the last page.

5 With single page pagination, if the total record count is higher than

2000, display "thousands" (IT: "migliaia") instead of the exact number.

6 Each time data is refreshed by user action or to synchronize frontend

and backend after an error, always return to the first page.

Data display

Data is displayed in columns. The following rules apply:

1 If multiple selection is allowed, the first column contains check boxes for selection.

2 The first content column should contain the attribute which uniquely identifies the type of

element displayed in the table. If more than one column are required to identify, they should

be the leftmost ones, sorted from general to specific (i.e.

Client/Procedure/Service/Process).

3 Columns may contain information or actions. Information is displayed as labels and may

support regional settings (i.e. Dates, Numbers etc.). Actions such as "Settings" follow these

rules:

If one or more actions are possible that affect the same row, they are gathered in the

rightmost column and displayed as links.

If different actions apply to different columns, they are applied to the cell and displayed

as icons.

4 All headers other than the selection check boxes header and the action column must have

a title. The title follows these rules:

If the category of the property displayed in the column is used only once, just put the

name of the category (i.e. when listing jobs, label the column with the user that launched

such jobs "User" rather than "User name". On the other hand, when displaying creation

date and modification date do not use just "Date", use "Created on", "Modified on").

For columns that provide several details about the type of element the table refers to,

just put the property name and do not repeat the element type (i.e. when listing users,

label columns "Name", "Age" rather than "User name", "User age").

When displaying dates and times use the verb of the action those dates refer to (i.e. use

"Created on" instead of "Creation date" or "Create date"). If such verb is not clear, it


means that the user wouldn't understand: clarify the verb or consider removing the

column.

5 All columns which uniquely identify the entity in the row must have clickable contents (links).

Clicking the text opens a zoom-in view of the content. If zoom-in is not provided, do not use

links.

6 If no results can be displayed (for any reason), apply a 75% opacity white overlay to the

data region where there must be an explanation of why there are no data. If creation is

allowed on the view, the explanation should also contain a quick creation link (see

example).

7 Column width must be set proportionally to contain the data. Follow these rules:

Leave as much space as possible for column which contain names and description.

Columns which contain numbers must be right aligned and as wide as the maximum

number they can contain (if possible). Use abbreviation for the header if it takes too

much space.

Columns with icons should be as wide as necessary to fit the icon and not more. You

can user abbreviated header or icon in header to take less space.

Columns which contain dates should fit the entire date and time if needed.

User must be able to change column width, which will not change if the user exits and

enters the view.


Filtering

If filtering is allowed the header row is expanded to fit two columns. The top column contains

actual headers, the bottom column contains the filter.


1 The leftmost column contains the filter toggle button. The filter toggle button is a icon-only

button that is selected when the filter is enabled and deselected otherwise. The filter starts

disabled and users can enable it and disable later.

2 If the user leaves current view and comes back again, the filter must retain its previous

status. Do not reset the filter on view change. Reloading the set also does not break filters.

3 Every header with a content that can be filtered has a filter on top. The following filters are

permitted:

Free text: user is expected to enter text inside a search field an user its controls to apply

filtering. When text appears in the control, also does the clear button.

Date/Time range: user expands the filter and sets up a start date/time and an end

date/time using two separate date/time pickers. User contracts the filter to apply. The

control has a clear link button to clean up the filter.

Numeric range: same as date range but with numeric values. Use numeric steppers if

possible. The control has a clear link button to clean up the filter.

Multiple choice (additive or exclusive): user clicks a combo box to open the list. Use

checkboxes in the list if multiple elements are allowed for the same filter (i.e. Event

levels) and normal combo box if just one is allowed. In the first case, the user selects

one or more elements by clicking the corresponding checkboxes than clicks on the

combo box prompt to close and apply the filter; in the second case the filter is applied by

selecting an element in the list, while clicking the combo box prompt closes the control

without making any changes. If the number of filter elements exceeds the maximum for

a combo box, switch to free text. Additive multiple choice has quick link buttons to

include all or clear selection, exclusive multiple choice has the “—“ option which means

no choice at all (= any).

4 If more than one column filter is applied, the result set consists of the intersection of all

filtered data (AND condition between filters).

5 Each filter is applied when:

a. If filter toggle button is on, every time filter that has been updated lose focus

b. If filter toggle button is off, only when the button gets toggled on


Selection

Tables support multiple selection of rows. The following rules apply:

1 Selection is available only using check boxes in the first column. Selection does not occur

on click.

2 Selected rows have the checkbox selected and are slightly highlighted.

3 If multiple selection is allowed, toolbar actions apply to all visible and selected items.

Creation actions do not follow this rule. If selection was extended to all elements, deleting

applies to all.

4 If selection is allowed, quick selection links must be displayed in the selection control

region. Links follow these rules:

All and None are mandatory and leftmost (in this order).

Further categories are permitted but they must appear as columns or value thereof (i.e.

select all "Errors" means selecting all events with severity "Error" but the column severity

must appear).

If more categories are applied and they refer to columns filtered with multiple choice,

one link for each category of the choice must be implemented (i.e. For the column

severity, implement all severities as quick links).

It is recommended to provide only quick selection for category the user is expected to

click: putting too many quick selection links by no mean makes them quick.

5 When reloading data, rows that were selected before must be kept selected (if they still

appear after reloading).

6 Selection range must be supported: see mouse interactions for details.

7 If in any moment all visible rows of the view are selected, display further selection hinting

which works as follows:

When all contents of the page are selected, display the hint to select all available

contents too. The hint contains the expand selection link

If the user clicks the expand selection link, further actions affect all contents. In this case

the further selection hint changes by allowing the user to clear selection. By clicking the

link, the selection clears entirely.

If a filter is enabled, further selection hint works the same way but affects only entries

matched by the filter.


Manipulating records

If the table is used in a context which allows record manipulation (e.g. delete, move), the

manipulation confirmation must report the number of entries that will be changed. The following

rules apply (examples based on deletion).

Mode Selected entries Confirmation request title (replace “Model” with

generic name of the record element)


Single 1 Do you really want to delete the Model?

Multiple

1 Do you really want to delete the Model?

More than 1, less

then all

Do you really want to delete nnn Models? (nnn is the

number of selected records)

All Do you really want to delete all Models?

Main filter

Description Combination of selection filters that applies general filtering to all

application. Filtering is allowed only for Use scope.

When to use In Use scope, use to keep a general filter on the whole user application.

Limitations Allowed only for the following categories:

Test/Production mode

Clients

Procedures

Services

Processes


1 Toggle button in the main toolbar opens and closes the filter by

displaying and hiding the filter row below headers (when closing, it has

the same effect as Cancel).

2 Test/Production is selected via switch. The control is optional and

appears only if the application supports modes.

3 Clients, Procedures, Services and Processes appear in Type 1 lists

with check boxes. Every time a checkbox is selected, other lists are

automatically filtered to restrict their values to those that can be related

to the selected element (i.e If a client is selected, only its procedures

are displayed). Lists can be further filtered via incremental search field,

one for each.

4 Apply button applies the filter and closes the popup (view content

might change due to filter change).

5 Clear button removes selection on all check boxes and text in text

filters but doesn't change the Test/Production switch.

6 Cancel reverts the filter to the situation it had on last open and closes

the filter.

Date and time picker

Description Combination of date picker and time picker with regional settings support.

Both date picker and time picker are optional so the component can be

used to capture only date or only time.

When to use Capture date and time.


Limitations -


1 The component is localizable, so it is subject to settings as:

12-hour clock

Date pattern

First day of the week

2 The date picker allows date input in the pattern defined by regional

settings and selection through calendar

3 The time picker allows input and automatically adjusts the time in the

hh:mm pattern.

Search field

Description Generic field for free text search, made of a text input and standard search

controls.

When to use Allow free text search.

Limitations -


1 When left empty, the search field contains a hinting about what it will

search (i.e. when searching clients, the filter will prompt "search

clients...").

2 To begin search, user places focus on the search field or presses the

keyboard combination.

3 User types-in some characters to search.

4 User presses Enter or clicks the search button to search.

5 If the controls enables incremental search, the search button is not

clickable and the search occurs automatically.

6 User presses the clear button to clear content, this counts as delete all

+ press Enter.


Dialog

Description Modal popup window with up to three possible outcomes.

When to use Require confirmation (two outcomes).

Require a mandatory decision between multiple possibilities (three

outcomes)

Limitations Dialogs cannot be generated from other popups. Popups need to commit

their status as a whole and generate corresponding errors after commit (if

errors couldn't be anticipated via data validation).


1 Two-Outcome dialogs always have a positive outcome (confirm) and

negative outcome (cancel action). Three-Outcome dialogs have two

positive outcomes (confirm, do something else other than cancel) and

a negative outcome (cancel the action).

2 Dialogs always have a title. The title contains a question which is the

request the user must answer to.

3 Dialogs always have a description which clarifies the action the

application will take in case the user confirms the request. Three-

Outcome dialogs must explain both the positive outcomes.

4 Two-Outcome dialogs always have the leftmost option which indicates

a confirmation and the rightmost that indicates canceling. The label of

the confirmation must be the same verb contained in the question.

5 Three-Outcome dialogs have the confirmation in the leftmost place,

close to it there is the second alternative and then the negative

alternative.

6 Regardless of which outcome is clicked, the dialog will close

immediately.


Zoom

Description Combination of a slider, increase and decrease zoom buttons, optionally

combo box with zoom presets.

When to use Zoom contents is designer pattern.

Limitations -


1 The slider freely sets the zoom value.

2 The default value is in the middle of the slider.

3 The combo box is optional and sets the zoom value among some pre-

defined values. It must contain the default value (usually 100%).

4 The increase and decrease buttons change the zoom by 10% of the

total.

5 Keyboard combinations apply to zoom.

Hover invitation

Description Small popup menu that appears near selected elements in workspace.

Contains a set of common actions that can be performed on the element.

Eliminates the need of right clik.

When to use Selecting controls in designer pattern.

Limitations Maximum 2 lines of 5 controls.

Only icon buttons.



1 When the user selects an item, the hover invitation appears close to

the item with 50% opacity.

2 If the user moves the pointer on the invitation, it goes to 100%

opacity.

3 If the user moves the pointer away from the invitation, it disappears.

4 To make hover invitation reappear, the user must leave the mouse

pointer for 1 second on the element or deselect and select it again.

Status bar

Description Bar on the bottom (30px high) where to display status messages and

track background activities.

When to use Optional: recommended on design pattern to display generic information

about a project ore selected objects and situation where a complex status

of a running system may be displayed.

Limitations Status bar is bottom aligned.

Status bar is as wide as application window.


1 Status bar can contain up to one row of elements. To display a history

of messages, use a combo box.

2 Use separators to distinguish groups of controls in the status bar.

3 Controls in the status must be also available in other views (i.e. if the

status bar is tracking the outcome of a preview, the same controls

must be available in a preview pane).

4 If the status bar tracks notifications, it does not replace the standard

notification feedback.


About panel

Description Displays additional information when the user clicks on product logo.

When to use All applications must implement the about box.

Limitations 600x330 px


1 Clicking the link button opens the URL pointed as effect fo the skin

settings

2 Clicking anywhere else closes the box

The following is a matrix of what to localize and to personalize based on the module


Element Example Localized Depends on

the module

Depends on

the skin

Logo

no no yes

Platform

name

ENTERPRISE

COMMUNICATION

PLATFORM

no no no

Software

service name

Portal & Collaboration no yes no

Software

service main

version

2.0 no yes no

Service pack Service Pack 2 no yes no

Platform

description

Doxee Enterprise

Communications

Platform is a state-of-

the-art customer

communications

solution… (refer to

Portal 2 project for the

actual text)

yes no no

Link button

label

Doxee.com no no yes

Link button

URL

http://www.doxee.com no no yes

Copyright

notice

Copyright © 2012

Doxee Inc. All rights

reserved

no no yes

User input

Keyboard

Other than standard text input, keyboard interaction should provide a valid alternative to mouse

actions by allowing users to move through controls and toggle actions without moving their hand

to the mouse.

Keyboard guidelines


1 Every menu, control or dialog must be directly focusable using access keys or keyboard

loop.

2 Shortcut keys must have a corresponding action in the application menu or toolbar.

3 Do not override system level accessibility features (i.e. do not provide an action for

Ctrl+Winkey+Shift+F8 because it performs accessibility actions on Mac OS).

4 Allow selection of text with the keyboard. Treat characters as elements subject to mouse

selection rules.

5 If possible, allow move and resize with the keyboard.

6 Do not create keyboard action that requires repetitive press of a button (i.e. repeatedly

pressing the Shift button triggers an accessibility action on Windows and some users find it

difficult to trigger this action).


Keyboard loop

Keyboard loop is triggered by pressing the Tab button to move from one control to the other.

Every time the Tab button is pressed, the next control in the loop is selected. The following rules

apply:

1 Tab always select the next control below.

2 Shift+Tab always selects the previous control.

3 In multi column forms, pressing Tab while focused on the last control of a column selects

the first one of the next column. Shift+Tab inverts the process.

4 In multi tab forms, pressing Tab while focusing the last control of a tab switches to the next

tab and selects the top-rightmost control. Shift+Tab inverts the process.

5 In any form, pressing Tab while focusing the last control selects the Apply button.

6 Multiple control like lists or radio button groups have inner keyboard loop which selects all

their content sequentially.

7 If a modal popup is present, keyboard loop cannot get out of the popup.

Shortcut keys

The following is a list of valid shortcut keys. If a feature of this table is available, it must be

triggered also by the corresponding shortcut key. Defining custom shortcut keys is allowed but

they must not conflict with existing shortcuts, even if the corresponding feature is not provided.

Function Shorctut Action

New Ctrl+N Creates new element

Open Ctrl+O Open something (i.e document)

Save, Apply Ctrl+S Applies changes (default save

operation)

Print Ctrl+P Prints selected content (if allowed)

Close Ctrl+W Closes current content, equivalent to

cancel. A confirmation dialog might

appear

Undo Ctrl+Z Cancel last change

Redo Shift+Ctrl+Z / Ctrl+Y Re applies last canceled change

Cut Ctrl+X Copies the selected elements and

removes them

Copy Ctrl+C Copies the selected elements

Paste Ctrl+P Place contents from system

clipboard to workspace (if allowed)

Duplicate Ctrl+D Duplicates selected content

Select all Ctrl+A Selects all content

Invert selection Ctrl+I Select anything that wasn't

previously selected and deselect

everything that is selected

Delete Del / Backspace Deletes selected content

Find Ctrl+F Brings up a find dialog or selects a

search field

Find next Ctrl+G (frontend search only) If multiple

results are fount, loops through

results.

Replace Ctrl+H Brings up a text replace dialog (if

allowed)

Rename F2 / Enter (on design

pattern)

Enters rename mode for selected

element(s)

Zoom in Ctrl+Plus(+) Increments zoom

Zoom out Ctrl+Minus(-) Decrements zoom

Normal size Ctrl+0 Sets zoom to 100%

Reload/Refresh Ctrl+R Triggers the refresh action


Function Shorctut Action

Next cell Tab (in list edit mode) Highlights next cell which is:

The next on the right

The first of the next row if the cell

is the rightmost one

The first of the first row if the cell

is the bottom-rightmost one

Previous cell Shift+Tab (in list edit mode) Contrary of next cell

Next row Enter (in list edit mode) Select the cell in the same column

for the next row (if available)

Previous row Shift+Enter (in list edit mode) Select the cell in the same column

for previous row (if available)

Add row Ctrl+Enter (in list edit mode) Adds a new row below the currently

selected one (or, if not possible

below the last). The newly created

row is selected, in edit mode and

with the cell in the same column

highlighted.

Cancel Esc In dialogs or popups equivalent to

clicking on Cancel

Confirm Enter In dialogs or popups equivalent to

clicking on the confirmation option

Alternate confirm Ctrl+Enter In dialogs or popups equivalent to

clicking on the alternate confirmation

option (if available)

Mouse

Mouse interaction includes:

Moving the mouse pointer around the screen.

Clicking, also while pressing keyboard buttons.

Dragging and dropping: click, hold the mouse button, move the pointer, release the mouse

button.

Right click is not allowed. Use hover invitation instead.

Mouse interactions

The following mouse interactions are allowed. See rightmost column for corresponding keyboard

action:

Interaction Mouse Keyboard

Select item, deselect all

other

Click Space

Add/remove item from

selection

Ctrl+click Ctrl+space

Extend selection Shift+click Shift+space (next item)

Shift+home (up to first)

Shift+end (up to last)

Shift+pageUp (previous page)

Shift+pageDown (next page)

Move focus Click on the item to be

focused

Select all Click on the first item,

shif+click on the last

Ctrl+A

Deselect all Click background (designer

pattern only)

Shift+ctrl+A

Text selection Click: place cursor


Interaction Mouse Keyboard

Double click: select word

Triple click: select line

Quadruple click: select

paragraph

(applies only to advanced text

editors)

Table range selection Shift+Click: selects all rows

form the closest selected row

on the top to the clicked row

Shift+Ctrl+Click: selects all

rows form the closest

selected row on the bottom to

the clicked row.

Mouse guidelines


1 If a window supports scrolling, the mouse wheel (or equivalent control) will scroll the

window if it is under mouse pointer. In this case the window gains focus.

2 Make sure that every action that can be done with the mouse can also be done via

Keyboard. The only exception is when the mouse interaction is vital to the task (designer

pattern only).

3 Do not restrict movement of mouse pointer on the screen. Do not move the mouse pointer

programmatically.

4 Do not require multiple mouse button press to perform an action (chording).

5 Do not bind actions to triple or quadruple click except for text selection in advanced text

editors.

6 Pressing the Esc key cancels every mouse operation in progress (like drag and drop).

7 Every mouse target must be at least 16x16px.

8 When writing documentations, do not refer to particular mouse buttons (i.e. "Click the left

mouse button"). This allows situations in which users operate with alternate pointing

devices or accessibility tools.

Drag and drop

Drag and drop is a direct manipulation technique used to move elements around the screen via

mouse button. It consists of:

Drag initiation: click and hold the action button on the desired element. A drag proxy should

appear to signal that the user is dragging something.

Move the mouse pointer around the screen up to the desired destination.

Release the action button to release the element or press Esc to cancel operation.

Mouse pointer changes to give feedback of valid drop target and action connected to the

drop operation (see mouse pointers)


1 Use drag and drop only if the user can guess the possible effect. Use visual hinting to

highlight drop targets and explain drop action. Good effects are moving an object from a

place to another or link two objects.

2 Always provide visual feedback of the valid targets and of the exact drop position (i.e. drop

feedback in lists rows).

3 Always include a drag indicator to detail the drag operation. Drag indicator should represent

the item being dragged either by text description or visual representation.

4 Allow users to cancel the drag operation either by:

Pressing the Esc button

Dropping the item in its original position

Dropping the item in an invalid position

5 Allow users to undo the drag operation if the undo feature is enabled on the view.

6 When an item is being dragged into a scrollable window, automatically scroll the window

following the mouse movement.


7 If the drop operation requires further detailed action, pop out a non modal dialog near the

drop target to request additional action. The dialog must not apply overlay or block user

input on the view below. If the user clicks outside the dialog, this counts as Cancel and the

dialog disappears.

Mouse pointers

These are valid mouse pointers:

Pointer shape Meaning

Point

Drag and add to drop target (allowed)

Drag to an invalid drop target

Drag and link to drop target (allowed)

Busy cursor

Drag and move horizontally

Drag and move vertically

Hand TBD Hover can be clicked

Operations

This section contains specifications on some typical operations available through the user

application whose behavior must be standardized.

Other sections may refer to this one when defining how to trigger a particular operation but the

actual behavior is described here.

Naming and renaming

The following rules apply to operations such as deciding or changing a name:

1 Every time a name is mandatory a default localized name must be supplied. It is

recommended to use as default name "New <something>", where <something> is the type

of element being created.

2 Applications may forbid renaming, in this case user must be warned by visual hinting that

the name cannot be changed after creation (use control label).

3 If the name is shared among different application, renaming might break relationship.

Applications that inherit the name must be tolerant to these situations. Applications in

charge of the name must warn the user about the consequence of name change.

4 I names cannot be duplicate, applications must make sure they are not. Backend check is

permitted but it must result in a validation error, not application error.

5 If system limitations are applied, notify them to the user as soon as possible by labels and

frontend validation or blocked input.

Saving

Applications might need to save data from the user interface to the backend tier. The following

rules apply to saving:

1 Saving is performed only with buttons labeled "Apply" (or derivates such as "Apply and

next").

2 When users click "Apply" they expect their content to be saved. Application designers can

decide whether to save the content immediately or queue saving operation for later commit.

3 Operations that require backend validation must be saved immediately.

4 Regardless of the commit strategy, the user interface must reflect changes immediately.

5 If user action or mandatory automated actions need synchronize with backend state, all

pending commits must be completed before synch.

6 When users click "Exit" button, all pending commits must be sent to backend.

7 Application which implement designer patterns may handle a large amount of data between

separate "Apply" actions. In such cases, draft autosaving is allowed.


Draft saving and loading


1 Status is saved automatically every minute (different timing might apply due to network

limitations). Every new save overwrites previous draft.

2 If the user saves explicitly, draft is cleared.

3 If the user abruptly leaves the application (crash, exit browser etc.), the next time the same

content is loaded, the application offers to restore last draft instead of last save. If the user

confirms, last save is replaced by last draft permanently, draft is cleared.

4 If the content is used by other parts of the applications (validations, builds etc), only saved

contents is considered. Drafts can be restored only using the editor that generated them.

5 Failure in draft autosave must not be notified to the user.

Validating data

Data validation should occur in the following ways.

Method Description

Frontend validation User input can be entirely checked against information

available on the frontend.

Backend validation User input requires information from the backend to perform a

check. A save operation is requested to trigger validation.

In case of negative outcome, a validation error is returned,

which is not an application error.

Regardless of the validation method, the following rules apply:

1 The view the user was working with stays visible.

2 Validation errors are reported by highlighting the wrong fields in the same way and reporting

a description of the error.

Undo and Redo

User applications must support undo and redo in the following situations:

All cases which implement the designer screen pattern.

If the user needs to input a large quantity of data inside a single control (like text area).

Allow undo of groups of changes (like Microsoft Office Word).

In all cases, the following rules apply:

1 The amount of operations rolled back and forth depends on the detail of the changes

allowed by the application (i.e. text editor would undo the entire word, or letter. Graphic

designer would undo single changes applied to an element).

2 Undo must be available both form shortcut keys and buttons in the toolbar.

3 Undo queue is at least 10 changes long. All applications must have the same undo queue

length which fits the shortest one.

User feedback

Applications must display feedbacks in notable moments of user operation.

The following general rules apply:

1 Feedback must point to the operation it refers to (i.e. if an error occurs while creating a

client, the feedback would be "Error creating client", not "Error modifying client" or "Generic

error").

2 Feedbacks occur only after notable operations which required users to press Apply. If users

make general modifications to the view, they will not receive feedbacks.

3 When creating or deleting elements, success feedback might just be showing or removing

the entity from the view. In this case, display additional messages only when handling

business entities (i.e. users, clients, profiles etc.).

4 Feedback must be true: do not display a success feedback and then an error feedback for

the same operation.


Success

Success feedback confirms that an operation has been completed. Feedback might contain a

link to reach other zones of the application in case users must be pointed to those zones to

follow on with their work.

Information and status messages

Information and status messages notify the user of a particular condition which isn't either a

success or a failure. Restrict status messages to those actually important to the user to avoid

information overload.

Error

Error feedback informs the user that a particular operation has failed. The following rules apply:

1 If the related error is not blocking, make sure the application is in a consistent state before

displaying the error.

2 Make sure the operation has failed entirely when displaying errors. Users do not expect

partial failures and generally don't know what to do in these cases.

3 Test errors: errors are particular conditions that hopefully should not appear during normal

operations. Nevertheless all errors must be tested to check notification compliance.

Progress

Progress feedback informs the user that a particular operation is going on. Depending on the

application, progress might block user action or allow it. User action is generally blocked if it

could break the correct outcome of the operation in progress.

The following rules apply.

1 If the progress is blocking, do not allow any operation.

2 Close all dialogs before displaying a progress.

3 Use progress indicator to display progress.

Data validation

Data validation occurs when the user is requested to enter mandatory data or needs to follow

specific input constraints (i.e. avoid duplicate values, validation patterns). Validation ensures

data is compliant to any constraint and must always occur on the backend.

Additionally, frontend data validation occurs to provide users with as many feedbacks as

possible before attempting to save.

Mandatory values and validation patterns

When determining constraints to user input, the following rules apply:

1 Make as much data as possible non mandatory and unconstrained. Do not force user to

enter identifiers that must be unique unless they are the focus if her activity in the

application (i.e. It is ok to validate the uniqueness of the user name, but not to force users to

enter code or ids that the machine could determine automatically)

2 If constraints are needed, prefer controls that don’t allow free user input by either limiting

the choice to a set of non-editable values or guide the input through visual feedback (such

as the date picker).

3 Always provide sample data for mandatory values. Also make sure that mandatory data can

be changed after creation, provided it is still compliant with validation specs. There are

some exceptions like the user password: it is mandatory but it doesn’t make sense to have

a default users can’t even read.

4 If the creation of some (even complex) application entities is mandatory, either create at

least one of them automatically or display a creation wizard the first time the user enters the

parent entity.

5 When the data naturally falls in a restricted range of values (like with radio buttons),

automatically select the most reasonable one and make sure it is the first of the group. If

selecting one of the entries is not possible (happens with combo boxes some times) make

sure the control prompts a text like Select a <something>…

6 Patterns and mandatory values must be verified immediately after the user has entered

them, without the need of applying.


Validation feedback

The following rules apply to data validation feedback:

1 Controls that contain wrong data are marked with an error icon near their label. When

hovering the error icon the error text is displayed.

2 Forms that contain errors must provide feedback about the presence of errors close to the

button that is used to apply changes (summary validation feedback). Such feedback goes

away only if there are no more errors in the form.

3 If you are applying changes of multiple views with the same operation and validation

occurs, identify views that contain errors by highlighting the control the user should click to

reach them (see wizard pattern for example).

4 Never blame the user for wrong data. See following sample errors.

5 The error text must contain an explanation of how the user should act in order to remove

the error. See the following sample errors.

Error Correct message Wrong message(s)

User name is

missing

Please enter a user name The user name is missing

User name is not

unique

The name you entered is already

in use, please enter a different

one

The user name is duplicate

User already existing

Invalid user name

Number is out of

range

Please enter an integer value

between 0 and 10

Number is either invalid or out

of range

Passwords don’t

match

Please review the passwords to

make sure they match

Passwords don’t match

The following is a sample of validation feedback:

The following is a sample of feedback close to the form apply button

Validation

The following rules apply to validation:


1 If the frontend validation is possible, do it as soon as the data changes (input on text fields,

creation/deletion of data grid rows). Display the feedback upon validation error, remove the

feedback as soon as the error is corrected.

2 If only backend validation is possible (like username uniqueness), validate after changes

are applied without leaving the view. During the validation period all controls must not

react. On error, display the validation feedback. If the user corrects the data remove the

validation feedback.

Validation cycle

Users must understand only one validation cycle, regardless of the validation type. To make sure

of this, follow these rules.

1 Do not disable the Apply button due to validation error, but display the summary validation

feedback

2 Every time the users hits Apply enforce a validation of the whole content (even if nothing

changed!) and update the validation feedback

Languages

User application must support multiple languages. They are deployed in the form of UTF-8

language packs available to the application.

Localizing the user application

Language pack

A language pack is a localization package which contains localization information for the entire

application. A language pack is not valid if one or more of the localization strings are missing or

translated into a different language.

Localized elements


1 All elements must be localized and capable of changing their language at runtime without

the need of restarting the application, reloading the view or some of its data.

2 Controls which allow to select options within a fixed domain must also localize their content

(i.e. selection of a log level must translate available levels in every language).

3 Default names of elements must be localized (i.e. the default name of a document would be

"New document" in US English and "Nuovo documento" in Italian. The default name used

depends on the current localization.

Applying localization


1 Application always start with the system languages, if it not available, the application

switches to default language: US English.

2 As soon as user data is available, application changes its language to user preferred

language, if available.

3 User can change her default language via Base Module.

4 User can change the session language via the language menu in the toolbar.

it is recommended to deploy all application with the same languages.

User input

User input is always performed via UTF-8 text. Allow user to input characters and text regardless

of the regional setting.

Right-to-left languages

Right-to-left languages are not supported at this time.

Translation process

Translation process goes as follows:

1 Project team defines the set of localizations in native language during design.

2 Project teams refines the set of localization strings during development.


3 When the user application text is not supposed to change anymore, native language is sent

to translators.

4 Project team implements translations.

Regional settings

Regional settings change the way the user application displays information and captures input.

There is no relationship between language and regional settings (i.e. it is possible to have a US

English user interface while using Italian dates, numbers and currency).

Regional settings content

Regional settings properties

The following settings are part of a regional setting:

Property Description

Setting Name Unique name of this setting

Description

Date, pattern Pattern to display dates

Date, first day of the week First day of the week

Number, decimal separator Decimal separator for numbers

Number, thousand separator Thousand separator for numbers

Currency, decimal separator Decimal separator for currency

Currency, thousand separator Thousand separator for currency

Currency, default currency Default currency (if more are available) i.e euro, usd

Measurement, system Measurement system: metric or us

Time, 12-hour clock If true, displays and accepts time between in 24-hour

format, if false, displays and accepts time in 12-hour

formats with am/pm

Time zone Dates and times should be displayed according to the

time zone

Default regional setting

The default regional settings is made as follows:

Property Description

Date pattern Month name / day number / full year

(i.e. September / 6 / 2010)

First day of the week Sunday

Number, decimal separator .

Number, thousand separator ,

Currency, decimal separator .

Currency, thousand separator ,

Currency, default currency $ (USD)

Measurement, system US

Time, 12-hour clock False

Time zone GMT+0

Applying regional settings

Controls subject to regional settings


1 Controls that display dates, numbers, measures, currency are subject to regional settings.

2 Regional settings apply both to labels and user input (i.e. If users enter a date, such date

must be displayed and capture according to regional settings).


3 Values captured from user interaction must be saved in a normalized version (i.e. dates will

be saved as standard UTC date-time, measure will be saved in a unit which is more precise

that both centimeters and inches et.)

Applying regional settings to user application


1 Application always start with default regional settings.

2 As soon as user data is available, application changes its regional settings to the open

preferred by the user.

3 User can change his preferred regional settings via Base Module.


Non-functional requirements

Events tracking

Tracking events occur by saving the event status for further review or notifications. All events

must be tracked, regardless of their future use.

Event tracking must not block the operation the event is related to (i.e. if for some reason

tracking the completion event for a job fails, the job must not be affected).

Note: there is no relationship between event tracking and backend application logging.

Event pattern

For every event, the following information must be tracked:

Attribute Description Example

System code Unique code assigned by the system. 123456

Date Date and time 2010-07-27 10:30

Severity Event severity. Information, Warning,

Error are permitted.

Information, Warning, Error

Origin Business entity which generated the

event

License

Category Type of action on the business entity Creation

Event (or action) Event Code BM123

Client Client which is linked to the business

entity (if available)

Sky

Procedure Procedure which is linked to the

business entity, if available

Invoices

Service Service which is linked to the business

entity, if available

Document Composition &

Multichannel Delivery

Service element Service element which is linked to the

business entity, if available

Data Acquisition

Process Process which is linked to the business

entity, if available

Chain

User User whose action untimely caused the

event

Scott Shelby

Message Verbose event message License update successful

Most common event origins

The following most common origins must generate events. Applications may add further origins.

Origin Common categories related

Any business entity (i.e. client,

procedure, user, process etc.)

Create

Modify

Delete

Import

Export

Enable

Disable

Any Process-related entity (i.e. job, run) User start

54 Non-functional requirements

Origin Common categories related

Automatic start

User stop

Success

Failure

Any Interface-related entity Request success

Request error

Response success

Response error

Login and security Login success

Login error

Maximum number of login failures

User disabled

Login server not found

Events browsing

Every application must offer event browsing functionality. Event browsing is provided via

standard table control and must allow the following features:

1 View event list with general information.

2 Filter and search events.

3 Open event details (popup recommended).

4 Copy visible events to clipboard with a format that can be pasted into Microsoft Office

Excel.

5 Export visible events to file in a standard XML-based format.

6 When exporting, automatically delete exported events.

7 Select and delete groups of events.

It is recommended to offer as many event browsing views as users need. For every user goal,

provide a view which is focused on events for that goal (i.e. ifs the user goal is to manage runs,

provide a related event view).

Events notification

Users can set up notifications. Notifications are listed and edited in the Settings view of

applications. Notification feature is mandatory for all applications.

The following rule apply:

1 Notifications are sent via e-mail. Users can insert recipients for every notification they set

up.

2 A notification can match multiple events. To set up a notification users can select:

Which severities should match

Which origin among those available should be monitored

Which categories should match

The notification will be sent if the event falls in one of the possible combinations.

3 The content of the e-mail cannot be configured via user application. It is recommended to

provide localized content and send them in the default language of the platform (in Base

Module).

4 Notifications can be disabled. Disabled notifications will not be matched to events.

5 Sending notification must not block event tracking.

Application auditing

Auditing allows applications to gather usage data about the user interface such as most

commonly used features, common chains of features.

The purpose of auditing is periodically analyze the audit data to determine:


The preferred features in which invest for evolution.

Possible training lacks (if a commodity is seldom used).

Features to suppress because they are often ignored or bypassed by other features.

Most common navigation patterns that can be optimized.

Note: login auditing is performed via login Events.

Auditing probes

Probes record usage data throughout the applications. Every time the user performs a notable

action, a probe must be triggered to record such action.

Tracking actions

In order to determine which actions to track, follow these rules:

Do not track only the click, also track its meaning (i.e. if the user needs to click a button to

trigger a functionality, track the fact the functionality has been triggered via the click)

If the application allows multiple ways to accomplish a goal, track every way separately

If the application performs long operations automatically which require users to wait, track

both begin and end or duration.

Track every validation error.

Track every message displayed to user.

Tracking pattern

For every action, the following details must be recorded.

Attribute Description Example

User name or dn Distinguished name of the user. cn=user1,ou=client1,p=platform1

Date Date and time 2010-07-27 10:30

Application name Unique application name Base Module

View name Unique name of the view that is

currently displayed on screen when

the action occurs

Users list

Action type Action is automatic or user-

triggered

Automatic, Manual

Action name Unique name of the action Click to create user, click to delete

single user, click to delete multiple

users, select single user

Action duration Optional. If the action requires user

wait, duration of the action in

milliseconds

2000

Action details Optional action details

Asynchronous tracking


1 Every time a tracked action occurs, queue track operation. Do not commit automatically.

2 Every 2 minutes, send all queued actions, if any. If there are no actions to commit, do not

connect to the backend in order to allow http session to expire if needed.

3 If the sending operation fails, do not display or track any errors, keep the action queue for

next try.

Audit log

Audit log is stored within the application data source. It is permitted to flush the audit log

periodically, but the last month must be always available.

BCP 2.0 Platform Guidelines User Experience

Documents

Transcript of BCP 2.0 Platform Guidelines User Experience