You are on page 1of 32

COMMITTEE T1 CONTRIBUTION T1M1.

5/99-041

STANDARDS PROJECT: G Interface Specification for Use with the Telecommunications


Management Network (TMN)

TITLE:

Design Guidelines and UI Standards for


Web Based Telco Applications
Source: ADC Telecommunications, Inc.
Date: 2/1/1999

Authors:
Khoa Doan
ADC Telecommunications, Inc.
7151 Columbia Gateway
Columbia Md 21046
Email: khoa_doan@adc.com

Contact:
Don Berryman
ADC Telecommunications, Inc.
PO BOX 1101, MS-68
Minneapolis, MN 55440-1101
Email: don_berryman@adc.com
Voice: +1-612-946-2102
Fax: +1-612-946-3590

DISTRIBUTION: T1M1.5

ABSTRACT: This document defines Design Guidelines and UI standards for Web-
based applications in the telecommunication arenas, especially in the network
management.

NOTICE:
This document has been prepared to assist the Standards Committee T1 -
Telecommunications. It is offered to the Committee as a basis for discussion
and is not a binding proposal. The requirements presented in this document
are subject to change in form and numerical value after more study.
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

Table of Content
1. PURPOSES ...........................................................................................................................................3

2. BACKGROUND...................................................................................................................................3
2.1. TELECOM USER PROFILES ..............................................................................................................3
2.2. WEB-BASED PRODUCTS OVERVIEW ...............................................................................................4
2.3. TELECOM MODEL OVERVIEW.........................................................................................................5
3. DESIGN GUIDELINES .......................................................................................................................7
3.1. DESIGN PROCESS ............................................................................................................................8
3.2. DESIGN FRAMEWORK .....................................................................................................................8
3.3. LOOK AND FEEL DESIGN RULES .....................................................................................................9
3.4. LAYOUT DESIGN RULES..................................................................................................................9
3.5. NAVIGATION DESIGN RULES .........................................................................................................10
3.6. TOPOLOGY VIEW’S DESIGN RULES ...............................................................................................10
3.7. TABLE VIEW DESIGN RULES .........................................................................................................11
3.8. GENERIC DESIGN GUIDELINES ......................................................................................................12
3.8.1. Alignment ................................................................................................................................12
3.8.2. Placement ................................................................................................................................12
3.8.3. Grouping .................................................................................................................................12
3.8.4. Capitalization ..........................................................................................................................13
3.8.5. Abbreviation ............................................................................................................................13
3.8.6. Graphics ..................................................................................................................................13
3.8.7. Icons ........................................................................................................................................14
3.8.8. Commands Dialogs .................................................................................................................14
3.8.9. Message Dialogs .....................................................................................................................14
4. UI STANDARDS ................................................................................................................................17
4.1. STANDARD PAGE LAYOUT ............................................................................................................17
4.2. STANDARD JAVA UI CONTROLS (DERIVED FROM SUN STANDARD JAVA LOOK AND FEEL)...........21
4.3. STANDARD COLORS ......................................................................................................................27
4.4. STANDARD FONTS ........................................................................................................................28
4.5. STANDARD ICONS .........................................................................................................................29
4.6. STANDARD SYMBOLS ...................................................................................................................29
5. REFERENCES ...................................................................................................................................31

2
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

1. PURPOSES
This document defines Design Guidelines and UI standards and for UI designers
and UI engineers to follow during the development of Web-based software
products in the telecommunication arena. The purposes of enforcing UI
standards and design guideline rules are:

ƒ To create unique and consistent look and feel

ƒ To enforce consistent layout in every displayed window

ƒ To ensure consistent usage of terminology and abbreviation

ƒ To provide standard library of icons and images

ƒ To define standard representation of typical telecom objects and concepts

ƒ To incorporate user feedback on a continuing basis

ƒ To conform with ANSI Web-based UI standards

ƒ To guide UI designers/developers during the design decision making process

2. BACKGROUND
2.1. Telecom User Profiles
The main user classes are:

- telecom operators or system admin users

- telecom managers

- end users

3
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

Characteristics Network Usage Favorite UI

Telecom Knowledgeable, Responsible for the Form-based


Operators highly-trained, status and health of the
or System narrowly focused network; handle
Admin requests/orders from
Users end users

Telecom Analytical, broad Manage telecom Fancy stuff with


Managers interests, decision operators; gather visually appealing and
maker statistics on the useful data
network to make major visualization
decisions and
instructions telecom
operators

End Users Variety of user types Order new services; Web-based


ranged from novice to change/cancel orders;
expert, mostly remote report network
users, prefer Web problems; work with
access telecom operators to
fix network problems;
request accounting info

2.2. Web-based Products Overview


Based on the look and feel and the deployed tools for product development, there
are 4 different types of Web-based products:

i Html form Paradigm: has html look and feel

i Java applet Paradigm: has Java look and feel

i Applications embedded Paradigm: has Windows look and feel

i Mixed Paradigm: has a mixture of look and feel

4
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

Paradigm Implementation Look and Feel Navigation Style Interaction


Technology Style

Html forms Html, CGI, Static, Back, forward CGI interaction


Javascript information- and link (stateless)
oriented navigations

Java applets Java Dynamic, On-screen Locked access to


function-oriented navigation local file systems

Windows Html, Jscript, Dynamic text, WindowS- Windows style


embedded VBscript, Active windows look oriented (popup menu,
Server Pages and feel menu-driven,
(ASP), dhtml dialog
interaction, etc)

Mixed Paradigm Any combination


of the above

2.3. Telecom Model Overview


The telecom network consists of telecom objects and has different levels of
representation. A telecom object holds the following information [6]:

ƒ A name or identifier

ƒ A type and several specific properties (transmission media, equipment


function, equipment capacity, etc.)

ƒ Operation, administration, or maintenance states and statuses

ƒ Alarm-related data (severity, number of alarms, acknowledgment level)

ƒ Other miscellaneous services

In general, there are 3 levels of network representation; each level consists of


different types of telecom objects:

ƒ Top level: consists of group objects

ƒ Medium level: consists of network elements, and links

5
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

ƒ Detailed level: consists of cards and shelves

Groups are used to display a geographic or a functional region by grouping


either network elements (multiplexers, switches, etc.) or links (transport, access,
etc.) [6, 8].

Network Elements are used to display various types of equipment:

ƒ shelf-based (switch, cross connect, router, etc.),

ƒ field-based (coax node), or

ƒ peripheral (terminal, database).

A network element is represented graphically in its place on the network.


However, all physical details of the element are not visible. The graphical
representation is either symbolic (most often, a rectangle displaying at least one
icon indicating the function of the equipment) or pictorial (a simplified vector
drawing of the equipment, similar to an icon) [6, 8].

Links are used to display the transmission elements making up the network
lines. Links feature the same dynamic display as network elements. Each type of
link has its own graphical representation and different link states are represented
graphically by changes in color or internal pattern design. Links can also carry
decorations, in particular to represent alarms [6, 8].

Cards are used to display details (at the level of the physical card) of
modifications that have been made to the states and alarms of the equipment.
The equipment can be graphically broken down into shelves where cards are
stored [6, 8].

Shelves act as intermediate objects between the network element level and the
card level. As such, they do not bear states or alarms [6, 8].

6
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

3. DESIGN GUIDELINES
3.1. Design Process

7
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

3.2. Design Framework

8
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

3.3. Look and Feel Design Rules


Telecom applications, especially network management, are dynamic and highly
interactive. For example, when the state and alarm data of a telecom object are
changed, the object’s representation is also updated automatically and
immediately. In a Web-based environment, this characteristic of the telecom
applications can be supported using Java applets. A html client is static, thus is
not sufficient. An application-embedded client is also not possible because its
server development is tied with the Windows platform. Java applets is the ideal
candidate in developing Web-based telecom applications because it is dynamic,
interactive, and is not tied with any specific platform on the server side.
However, the downloading time of Java applets on the Web often cause users
frustration because it is taking too long. This limitation can be overcome by
replacing a single Java applet with multiple small Java applets displayed in a
html page incrementally. These Java applets and html forms are then
interconnected using Java script; such interface paradigm will have the following
characteristics:

ƒ mixture of html and Java look and feel

ƒ html is used to create the overall layout

ƒ html is used to display static data

ƒ Java is used to display dynamic data

ƒ Java is used to support interactivity

ƒ Java is used to create interactive UI control components

ƒ Javascript is used to interconnect Java applets and html

The design guidelines and UI standards are defined in this document basing on
such interface paradigm. Following are design rules on the layout, navigation
style, topology views and table views for Web-based telco applications. Some
generic design guidelines are also put forward at the end of this section.

3.4. Layout Design Rules


A layout model defines how the screen is divided into separate and
distinguishing work areas (sections) and how they are arranged. The
enforcement of the layout model will create consistent layout in all of the
screens. Layout consistency in turn facilitates users in their learning process with
the system after using the first screen (since subsequent screens share the same
layout model). Here are some layout design rules:

9
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

ƒ limit the number of interactive areas (i.e. sections) in a single page to 6 or


less

ƒ limit the number of supporting action buttons on a single page to 8 or less

ƒ display only information understandable by novice users on the page

ƒ help users identify visual differences and different functionality between


different interactive areas in a page

ƒ provide clear visual indicators and sufficient instructions on how to start

3.5. Navigation Design Rules


A navigation model consists of rules that dictate how the UI supports user to
navigate throughout the system, in particular:

ƒ how users switch between system modules (e.g. fault management, network
performance, network configuration, network security and network
accounting)

ƒ how users navigate between different pages within a module (page-to-page


navigation)

ƒ how users move between interactive areas within a page (on-page


navigation)

A good navigation model must:

ƒ be designed based on the user workflow process

ƒ support consistent visual indicators on when and how to perform the


navigation

ƒ provide clear visual indicators of what are visual changes to predict, and
what is the next page in the navigation flow

3.6. Topology View’s Design Rules


ƒ There are 3 levels of a topological view: top view, medium view and
physical view.

10
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

ƒ At the top view, only groups (or regions) and links between groups are
displayed.

ƒ At the medium view, network elements and links between network elements
of the selected group are displayed. At this level, a topology view is
basically a graph whose nodes and links are network elements and links
respectively.

ƒ At the physical view, cards and shelves of a network element and


corresponding links are displayed.

ƒ The topology’s background is the geographical map of the network. Users


can turn on and off the background map at their wills.

ƒ Use the tree view of the topology as a navigation aid: users can select a
desired view on the tree view.

ƒ Use the overview image of the topology as an aid to span and zoom in/out
the current view.

ƒ Provide a designated dialog that displays the properties of the selected object
in the topology (e.g. network elements, links, cards or shelves). The property
dialog can be hidden at the user’s will.

ƒ Use standard graphical symbols to indicate different types of network


elements (switches, multiplexers, etc).

ƒ Use different (standard) colors to indicate different status of the network


elements in general.

ƒ Must allow users to edit the topological view, such as [8]:


9 To insert/remove nodes
9 To move/resize nodes
9 To insert/remove links between two nodes
9 To lay the network on several layers and show/hide these layers
independently.
9 To zoom in and out on the display
9 The ability to scroll on the display by using scrollbars and arrow
keys.

3.7. Table View Design Rules


Table based views are spreadsheet like displays that are used to list large
amounts of data. They are very useful in the network management area, for

11
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

instance to display lists of network events. In the field of network management


applications, the table-based views must be presented to the user with the
following capabilities [8]:

ƒ The ability to scroll vertically

ƒ The ability to sort rows following a column attribute, or several column


attributes, in both ascending and descending order

ƒ The ability to hide and show columns individually

ƒ The ability to scroll horizontally, if all columns do not fit on the screen

ƒ The ability to set the color of a row foreground and background individually

ƒ The ability to filter the rows of information using single-column or multi-


column predicates.

3.8. Generic Design Guidelines

3.8.1. Alignment

ƒ In a html form, the Submit and Cancel buttons are positioned right-aligned.

ƒ When the page elements are positioned vertically, align the elements by their
left edges

ƒ If the title is placed above of the applicable area, the text label of the title
must be left aligned

ƒ When a text label is applicable to a text box control, align the height of the
text with the text displayed in the text box

ƒ Command buttons’ text labels must be center-aligned

3.8.2. Placement

ƒ Submit and Cancel buttons are always placed next to each other

ƒ The last button in the Action bar is a Help button (if there is)

3.8.3. Grouping

ƒ If a particular command button applies to only a particular field, group it


with that field

12
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

ƒ Use bordered pane (in Java applets) or frame/table views (in html forms) to
group related fields together

ƒ The order of fields in a group is determined by the following criteria:


frequency then importance.

3.8.4. Capitalization

ƒ Use conventional book title capitalization: capitalize the first letter in each
word unless it is an article, or preposition not occurring at the beginning or
end of the name

ƒ Examples of usage: Insert Object, Paste Link, Save As, Go To, Always on
Top, By Name, etc

3.8.5. Abbreviation

1. Simple truncation: Use the first, second, third and so on letters of each
command. This rule requires that each command be distinguishable by the
leading string of characters

2. Vowel drop with simple truncation: Eliminate vowels and use some of what
remain with the above rule. If the first letter is a vowel, it may or may not
retained. H, Y, and W are not considered as vowels for this purpose

3. First and final letter: Since the first and final letters are highly visibles, use
them. E.g. use ST for SORT

4. First letter of each word in a phrase:

5. Standard abbreviation from other context: Use familiar abbreviations such


as QTY for QUANTITY, PRT for PRINT, BAK for BACKUP

6. Phonics: Focus attention on the sound. E.g. use XQT for execute

3.8.6. Graphics [4]

ƒ Each image should have alternate text for viewers that cannot see graphics,
or for users who choose not to load them. This is done by using the
ALT=''...'' option in the <IMG ...> tag.

ƒ Do not overlook monochrome monitors. It is possible that some people have


them, either on your network or in your general audience (which may be the
same thing). If you expect that a significant portion of your audience to have
monochrome monitors, you should test your page on such a monitor.

13
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

ƒ Some people can only view pictures in 16 colors-something to keep in mind,


but not necessarily to worry about.

ƒ Try to restrict the width of your pictures to about 450-480 pixels, since this
is usually within the default viewing width of a graphical browser.
ƒ For graphics larger than 10 kilobytes in size, optimization must be
employed:
9 Determine proper graphics format: JPEG or GIF
9 For JPEGs, use appropriate compressions level. LOWSRC the image.
9 For GIFs, reduce the color set and employ interlacing.
3.8.7. Icons [4]
ƒ Put colored or 3-D borders around hot icons to help distinguish them from
labels.
ƒ Where possible, depict familiar, concrete referents (physical objects), or
widely used industry conventions, since they are easier to recognize and
remember than abstract symbols.
ƒ Use a specific icon consistently throughout all Web pages, e.g., use the same
size, shape, and label at the same location to perform the same function.
ƒ Consider using a 3-D border on hot icons in image maps to help users
recognize that they are clickable.
ƒ Use short, descriptive textual labels next to the icons to indicate their
functions.
ƒ Simplify complex objects or shapes by removing extraneous detail, and
depict only the object's essential attributes.
ƒ Avoid being too cute or clever in choosing icons (e.g., avoid using a table to
stand for links to "table of contents", a typewriter to stand for "previous", or
a pair of glasses to stand for "search"); cute and clever icon may be
appealing initially, but they can become quite tedious and annoying over
time.

3.8.8. Commands Dialogs

ƒ Dialogs commonly include OK and Cancel buttons

ƒ Use OK button to apply values in the dialog and close the window

ƒ If the user chooses Cancel button, the changes are ignored, canceling the
operation the user choose

3.8.9. Message Dialogs

ƒ A message dialog displays information about a particular situation or


condition

14
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

ƒ A message dialog typically include a graphical symbol that indicates what


kind of message is being presented

ƒ Minimize the use of message dialogs, if possible

There are several types of message dialogs:

x Information: provides information about the results of a command. Offer no


user choice; the user acknowledges the message dialog by clicking the OK
button

x Warning: alerts the user to a condition or situation that requires the user’s
decision and input before proceeding, such as impending action with
potentially destructive, irreversible consequences. The message can be in the
form of a question – e.g. “Save changes to MyReport?”

x Critical: informs the user of a serious problem that requires intervention or


correction before work can continue

x Status: provides information or status without requiring direct user


interaction to dismiss them. For example, a message dialog that provides a
visual representation of the progress of a particular process that
automatically disappears when the process is complete

A message dialog consists of the title bar, the message body and a set of
command buttons. Following are the design rules for the message dialog:

Title Bar

ƒ Use the title bar of a message dialog to appropriately identify the context in
which the message is displayed – usually the name of the object

ƒ If the message results from a non-document object, then use the application
name

ƒ Do not use descriptive text for message dialog’s title such as “Warning” or
“Caution”

ƒ Never use the word “Error” in the title

Message Body

ƒ State the problem, its probable cause (if possible), and what the user can do
about it – no matter how obvious the solution may seem to be.

ƒ Avoid using unnecessary technical terminology and overly complex


sentences

15
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

ƒ Avoid phrasing that blames the user or implies user error

ƒ Avoid replying on default system-supplied messages, and supply your own


specific messages wherever possible

ƒ Make the message as specific as possible

ƒ Be brief but complete. Provide only as much background information as


necessary. A good rule of thumb is to limit the message to two or three lines.
If further explanation is necessary, provide this through a command button
(e.g. “More”) that expands the message dialog vertically to display further
information. This is called “Two-tier message dialog”.

Command Buttons

ƒ If a message dialog requires no choices to be made but only


acknowledgement, use an OK button, and optionally, a Help button

ƒ If the message dialog requires the user to make a choice, include a command
button for each option

ƒ The clearest way to present the user the choices is to state the message in the
form of a question and provide a button for each response

ƒ When possible, phrase the question to permit Yes or No answers,


represented by Yes or No command buttons

ƒ You can include command buttons in a message dialog that correct the
action that caused the message dialog to be displayed

ƒ Some situation may require offering the user, not only a choice between
performing or not performing an action, but an opportunity to cancel the
process altogether. In such situation, use a Cancel button

ƒ When using Cancel as a command in a message dialog, remember that to


users: Cancel implies restoring the state of the process or task that started the
message dialog. If you use Cancel to interrupt a process and the state cannot
be restored, use Stop instead

16
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

4. UI STANDARDS
4.1. Standard Page Layout
Standard Header

Each page should also have a standard header that will contain information about
where the user is in the web of pages. It consists of the GIF image, followed by
header information in a header tag (<Hn>). In addition, the title of the page
(located between the <TITLE> and </TITLE> tags) is given as a comment.

Standard Footer

Every page should have the following information presented at the bottom of
each page:

ƒ the author/maintainer's email (using a mailto: in the anchor tag), as well as a


person to contact about server problems and for general questions. Also,
stating this information allows an assignment of credit to the person, who
has created the content and/or design of the page.

ƒ a date indicating when the page was most recently modified to allow the user
to determine whether a page is current or not

ƒ the URL of the current page if you feel that users might want to print a page
or will need to know where they are.

In addition to the above required information, the following information should


be provided, as necessary:

ƒ copyright information on the text displayed

ƒ acknowledgements of copyrighted information

ƒ a disclaimer

Standard Navigation Bar

There are 2 navigation bars: the top navigation bar is immediately below the
header, and the bottom navigation is just above the footer. Both are similar in
terms of functionality: providing links to different areas in the body. The top

17
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

navigation bar is normally an image map, and the bottom navigation bar is
basically html text links.

Standard Action Bar

The action bar is located between the bottom navigation bar and the page body.
It consists of a number of action buttons for operating interactive areas’
functionality, or for submitting user input in the interactive areas to the Web
server.

Standard Body

Between the two navigation bars is the page body. The page body consists of a
number of interactive areas. Each interactive area can be a html form or a Java
applet. Following are some guidelines design on defining user input in the html
forms; Standard Java UI controls for the Java applets is defined in the next
section.

HTML Forms [4]

Radio Buttons

ƒ Use radio buttons when you want users to select only one item from a list of
items. The user selects an item by clicking on the button next to the label or
text describing the items.

ƒ Use relatively short lists of options (4-5 choices), and do not require users to
scroll to see all available options.

Pop-Up and Pull-Down Menus

ƒ In addition to radio buttons, you can also have users select one item from a
list using pop-up or pull-down menus. In each case, a menu appears and the
user drags and clicks the mouse to highlight his/her selection and then
releases the mouse button to make a selection.

Check Boxes

ƒ Check boxes enable users to select more than one item from a list of items.
The user selects items by clicking on the boxes next to the label or text
describing the items. Check boxes can be aligned either vertically or
horizontally, depending on how much text is required to describe the desired
items.

ƒ If you align items horizontally, be careful to leave enough space between


items to make it very clear which check box corresponds to which selection.

18
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

Scrolling Menus

ƒ In addition to check boxes, scrolling menus with a list of options can be used
to allow users to select more than one item at a time.

ƒ Do not make the list of selections too long (e.g., less than 10 items).

ƒ Make it easy for users to see the items they have already selected as they
view other items. In short, do not overload users short-term memories as they
scan and select items.

ƒ Use scrolling menu lists sparingly, since not all users will understand the
procedural details of selecting more than one item from the list, i.e.,
coordinating holding down appropriate keys while marking and selecting
items with the pointing device.

Text Fields

ƒ Use informative labels in forms with text fields to indicate what text should
be entered, and where it should be entered.

ƒ Make sure that the size of the field is big enough to accommodate the largest
quantity you expect users to enter; if the field is too small, users will not be
able to view what they type in after they have filled the designated field.

ƒ If a user fills out multiple text fields in a form or set of forms, carry over
overlapping information so users do not have to reenter the same information
again.

ƒ Use and clearly mark "send" and "clear" buttons on the bottoms of forms.

19
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

Illustration of a standard page layout

20
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

4.2. Standard Java UI Controls [9]


Windows

The basic window frame (Internal Frame) defines the Java Look & Feel design
and includes all the standard window functions: resizing from any side or corner;
dragging from the title bar; and minimize, maximize, and close controls.

Note the "flat" resize corners. Notice also the texture in the title bar, which
indicates "dragg ability." Inactive windows use the secondary colors, which are
typically grey . Texture and 3D effects are maintained, as the inactive window
accepts click-through. Shown below: normal; minimize clicked; maximize
clicked; un-maximize button graphic; un-maximize clicked; close clicked.

palettes
Palette windows float above other windows in their own layer.

Menu

Java Look & Feel menus use the mouse down appearance from buttons, along
with primary2 as a highlight color, to show selected menu titles and menu items.

21
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

Shown here are the menu bar; menu titles; menu items (including one which is
selected); check box menu items; and keyboard equivalents.

This drawing shows a disabled menu; a hierarchical menu; an item separator;


and radio button menu items. Pop-up (contextual) menus look like hierarchical
menus (they can have keyboard equivalents).

basic controls
Controls use the "flush 3D" look. Shown here are check boxes and radio buttons
in four states (unselected, selected, unselected and unavailable, and selected and
unavailable); along with command buttons, the first of which ("OK") is the
default.

Below are the appearances on mousedown. Button text and/or graphics do not
shift on mousedown. A radio button in the "on" state gives mousedown feedback
when clicked, as shown in "Radio 2," but remains in the "on" state (the selected
button in the set) on mouse up.

22
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

scroll bars
Scroll bars have a textured "thumb" and recessed channel.

combo boxes
Editable and non-editable combo boxes are visually distinct in the Java Look &
Feel. The non-editable variety looks like a button with an arrow to indicate the
menu functionality.

Editable combo boxes appear as text fields with arrow buttons.

Note the label text in the primary1 color, and the primary3 text highlight color.
Scrolling menus are a requirement.

list box
The list box uses the primary3 color to show selection.

23
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

text fields
Shown here are editable, password, and non-editable text fields.

tabbed pane
This control allows the user to "switch panes." It is typically used in option
dialogs. (Usages such as the SwingSet demo are not encouraged!)

tool bar
The tool bar is essentially identical to the menu bar, except it contains buttons
(and, potentially, other controls such as toggle buttons and combo boxes). It is
shown here with button borders, but without button graphics.

Note the texture at the left edge; this indicates that the tool bar is draggable, or
"dockable" in Swing parlance. (This is the only drag area.)

tree view
The Tree View uses "turners" to show open and closed containers. Separators
can be drawn between top-level items.

24
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

Also, hierarchy lines can be displayed (both separators and hierarchy lines are
off by default).

bordered pane
The bordered pane is a single-pixel line (not 3D) in the secondary2 color, with a
title in the primary1 color.

progress bar
The progress bar uses a subtle inset 3D effect, to differentiate it from "flush" user
items, along with the primary2 color to indicate "fill."

25
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

sliders
Sliders uses the "flush 3D" look. Focus is indicated using a colored slider thumb.

A filling slider is provided as an option (shown here without focus).

tool tip
The tool tip is a small floating "tag" that indicates the functions of controls
(typically tool bars) on screen. It uses black text for the label, and the primary1
color for any keyboard equivalent (in a smaller font), on a primary3 colors.

26
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

4.3. Standard Colors [9]

Color Description
black
Used for user text and user items; sparingly in drawing
Page text, Labels
white
Used for highlights in 3D effects, and user text entry areas
Page Background
primary1
RGB 102-102-153 HEX #666699
Active window borders, shadows, and system text
Header or interactive areas’ headers
primary2
RGB 153-153-204 HEX #9999CC
Highlight/selection color; more shadows
primary3
RGB 204-204-255 HEX #CCCCFF
Large colored areas (e.g. active title bar); text selection
secondary1
RGB 102-102-102 HEX #666666
Inactive window borders; "channel" for flush 3D effect
secondary2
RGB 153-153-153 HEX #999999
Secondary shadows; disabled system text.
secondary3
RGB 204-204-204 HEX #CCCCCC
Canvas color; inactive title bar.

Alarm Severity Coding

Severity Color Letter

Critical Red C

Major Red M

Minor Orange M

Warning Yellow W

27
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

4.4. Standard Fonts

Elements Font Name Samples

Header Times New Roman, 18pt bold,


center on page
Header
Body Times New Roman, 11pt Body
regular

Navigation Bar, Action Bar Times New Roman, 12pt bold, Navigation Bar
center

Area Title Times New Roman, 12pt bold, Area Title


right aligned

Area Instructions Times New Roman, 11pt Area Instructions


regular, right aligned

Footer Times New Roman, 10pt Footer


italic, right aligned

28
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

4.5. Standard Icons [6]

Icons Comments
Resource requires initialization before it can be made available
Resource is being initialized
Resource is initialized and test results are being returned.
Resource is terminating.
Service is degraded. This could adversely affect the usage state.
Resource is subject to a fault that prevents it from being used. In most cases, this status
is coupled to an alarm, an outstanding alarm, or a loss of connectivity.
Resource is undergoing test.
Log is full. Log service has been made unavailable.
Service has been made unavailable because of an ongoing time schedule.
Resource requires power but is not powered. Most often, this resource is coupled to an
alarm, an outstanding alarm, or a loss of connectivity.
Resource is reserved for test.
Resource is currently under test.
Resource is currently under repair.

4.6. Standard Symbols [6, 7]

Equipment Class Symbol

Database

Link

Multiplexer

Operations System

Switch

Transport

Other Equipment

Location

29
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

Class Equipment Icon

Transport Add-drop

Transport Cross-connect

Transport Regenerator

Transport Line Terminating Equipment

Link Communication Network

Link Fiber

Link Electrical

Equipment Symbol

Satellite

Earth Station

PBX

Printer

Workstation

Terminal

Telephone

30
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

Acknowledgments:

- NMF GUI Team

- T1M1.5 UI Team

- Java Design Team at Sun Micorsystems

- ILOH JTGO Team, and

- Ameritech GUI Team

For permission to reference their work in this document.

5. References
1. IBM User Centered Design. http://www.software.ibm.com/ucd/index.html

2. Sun Guide to Web Style. http://www.sun.com/styleguide/

3. W3 Style Guide for online hypertext. http://www.w3.org/Provider/Style/All.html

4. Ameritech Web Page User Interface Standards and Design Guidelines.


http://www.ameritech.com:1080/corporate/testtown/library/standard/web_guidelines/index.h
tml

5. Other Web resources on Guidelines and Standards.


http://www.ida.liu.se/~miker/hci/guidelines.html.

6. ILOG JTGO User Manual.

7. T1M1-232: G interface Specification for Use with the Telecommunications Management


Network (TMN).

8. NMF Graphics Information Requirements for Telecommunications Management Objects


(Draft version).

9. Chris Ryan. Java Look and Feel. http://java.sun.com/products/jfc/tsc/plaf_papers/jlf/jlf.html

31
T1M1.5/99-041: Design Guidelines and UI Standards for Web-based Telco Applications 01/26

32