Mobile App UX Principles

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
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
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
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
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
3. DESIGN GUIDELINES
3.1. Design Process
7
3.2. Design Framework
8
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
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
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
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
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
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
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
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
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
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
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
Illustration of a standard page layout
20
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
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
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
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
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
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
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
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
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
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
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
32

Mobile App UX Principles

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mobile App UX Principles

Uploaded by

Copyright:

Available Formats

COMMITTEE T1 CONTRIBUTION T1M1.

STANDARDS PROJECT: G Interface Specification for Use with the Telecommunications

Design Guidelines and UI Standards for

 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

- telecom operators or system admin users

Characteristics Network Usage Favorite UI

Telecom Knowledgeable, Responsible for the Form-based

Telecom Analytical, broad Manage telecom Fancy stuff with

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

2.2. Web-based Products Overview

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

Paradigm Implementation Look and Feel Navigation Style Interaction

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

Java applets Java Dynamic, On-screen Locked access to

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

Mixed Paradigm Any combination

2.3. Telecom Model Overview

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

 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

 Top level: consists of group objects

 Medium level: consists of network elements, and links

 Detailed level: consists of cards and shelves

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

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.

3.2. Design Framework

3.3. Look and Feel Design Rules

 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

3.4. Layout Design Rules

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

 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

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

3.5. Navigation Design Rules

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

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

A good navigation model must:

 be designed based on the user workflow process

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

3.6. Topology View’s Design Rules

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

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

A type and several specific properties (transmission media, equipment

Operation, administration, or maintenance states and statuses

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

Other miscellaneous services

Top level: consists of group objects

Medium level: consists of network elements, and links

Detailed level: consists of cards and shelves

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

field-based (coax node), or

peripheral (terminal, database).

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

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

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

provide clear visual indicators and sufficient instructions on how to start

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

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

be designed based on the user workflow process

support consistent visual indicators on when and how to perform the

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

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

Use standard graphical symbols to indicate different types of network

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

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

The ability to scroll vertically

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

The ability to hide and show columns individually

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

Command buttons’ text labels must be center-aligned

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

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

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

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

Dialogs commonly include OK and Cancel buttons

A message dialog displays information about a particular situation or

A message dialog typically include a graphical symbol that indicates what

Minimize the use of message dialogs, if possible

Never use the word “Error” in the title

Avoid using unnecessary technical terminology and overly complex

Avoid phrasing that blames the user or implies user error

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

Make the message as specific as possible

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

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

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

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

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

copyright information on the text displayed

acknowledgements of copyrighted information

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