CHAPTER 9

USER INTERFACE

Contains 3 fundamental parts:

o
Navigation mechanism
Provides the way in which the user gives instructions to the system and

tells it what to do
o
Input mechanism
Defines the way in which the system captures information

o
Output mechanism
Defines the way in which the system provides information to the user

or to other systems

GUI

Graphical user interface

User interface the utilizes colors and graphics (as opposed to text only)
Uses windows, menus, icons, and a mouse

USABILITY

System is easy to use and easy to learn

Why usability?
o
Tasks are completed more efficiently and with more accuracy
o
Mistakes with system are reduced
o
User satisfaction with new system is increased
o
Adoption of system is more likely

HUMAN-COMPUTER INTERACTION (HCI)

Focuses on improving the interactions between users and computers by making

computers more usable and receptive to the user's needs

PRINCIPLES OF USER INTERFACE DESIGN

Principle

Description

Layout

The interface should a series of areas on the screen that are used
consistently for different purposes -- a top area for commands and
navigation, a middle area for information to be input or output, and a
bottom area for status information

Content
awareness

Users should always be aware of where they are in the system and what
information is being displayed

Aesthetics

Interface should be functional and inviting to users through careful use

of white space, colors, and fonts. There is often a trade-off between
including enough white space to make the interface look pleasing and
losing so much space that important information does not fit on the
screen

User
experience

Although ease of use and ease of learning often lead to similar design
decisions, there is sometimes a trade-off between the two. Novice users
or infrequent users of software will prefer ease of learning, whereas
frequent users will prefer ease of use

Consistency

Consistency in interface design enables users to predict what will

happen before they perform a function. It is one of the most important

elements in ease of learning, ease of use, and aesthetics.
Minimize user
effort

The interface should be simple to use. Most designers plan on having no

more than three mouse clicks from the starting menu until users
perform work.

LAYOUT

Refers to organizing areas of the screen or document for different purposes and using
those areas consistently throughout the user interface
Divide the screen into 3 main areas:
o
Top area: provides navigation through the system
o
Middle area: largest area; display of the user's work
o
Bottom area: status information
Information can be presented in multiple areas
Ideally, areas will remain consistent in size, shape, and placement
Minimize user movement from one area to another

CONTENT AWARENESS

Refers to the ability of an interface to make the user aware of the information it
contains with the least amount of effort by the user
Titles
Menus should show where the user is and where the user came from to get there
Forms and reports:
o
All areas should be clear and well defined to reduce the chances that users
become confused about the information in any area
Fields within each area
o
Fields - individual elements of data that are input or output
o
Field labels - identify the fields on the interface
Should be short and specific

Use dates and version numbers to aid system users

AESTHETICS

Refers to designing interfaces that are pleasing to the eye

Use white space as needed
o
High density --> has too much information packed into too small a space with
too little white space
Novice or infrequent users --> prefer low density, less than 50% (less than 50% of the
interface is occupied by information)
Experiences users --> prefer high densities
Design of text is equally important
o
Larger font size for titles, section headings, etc.
o
Smaller font for the report or form content (at least 8 pt; minimum or 10 pt if
older users)
o
Serif - most readable for printed reports, particularly for small letters
o
Sans serif - most readable for computer screens, and are often used for
headings in printed reports
o
Avoid using all caps
Color and patterns
o
Should be used carefully and sparingly
o
Only when they serve a purpose
o
Colors with high contrast should be used (black and white)

USAGE LEVEL/USER EXPERIENCE

User experience refers to design the user interface with the users' level of computer
experience in mind
Systems that will end up being used by many ppl on a daily basis have a majority of
expert users
o
Users should be able to access the commonly employed functions quickly,
with few key strokes or a small number of menu selctions
Some people will be frequent, heavy users of the system
o
Frequent users desire ease of use (quick and easy completion of job tasks)
o
Include ways to perform tasks directly (short-cut keys)
Other people may use the system infrequently
o
Infrequent users desire ease of learning (quick and easy ways to figure out
what to do)
o
Include careful menu designs, tool tips, and extensive help systems
Mobile devices: use standardized gesture interactions to enhance the user's ease of
learning and ease of use

CONSISTENCY

Single most important factor in making a system simple to use

Considers elements within an application and across applications
Elements are the same throughout the application
o
Reduces learning curve
o
Enables users to predict what will happen
Refers to the interface within one computer system, so that all parts of the same
system work in the same way
Pertains to many different levels
o
Navigation controls --> how actions in the system should be performed
o
Terminology --> using the same words for elements on forms and reports
o
Report and form design --> make them similar, but give them some distinctive
elements that enable users to immediately detect difference

MINIMIZE USER EFFORT

Using the fewest possible mouse clicks or keystrokes to move from one part of the
system to another
Three-clicks rule
o
Users should be able to go from the start menu to the information or action
they want in no more than three mouse clicks or three keystrokes
When possible, provide selection tools instead of requiring typing

USER INTERFACE DESIGN PROCESS

1

UNDERSTAND THE USERS

a
b
c

Users likely will have very different goals and intentions when using the system
Plan a user interface that will be satisfying for that particular user group
Use scenario
i
An outline of the steps that the users perform to accomplish some part of
their work
i
Presented in a simple narrative description that is tied to the DFD
ii
Goal: describe the handful of most commonly occurring use scenarios

ORGANIZE THE INTERFACE

a
b

Define the basic components of the interface and how they work together to
provide functionality to users
Use Interface Structure Diagram (ISD)
i
Defines the basic components of the interface and how they work together
to provide functionality to users
i
Shows how all screens, forms, and reports are related
ii
Shows how user moves from one to another
iii
Generally, there is one ISD for each process on the Level 0 DFD

DEFINE STANDARDS
a
b
b

b
b
b
b

DEVELOP PROTOTYPES
a
a

Clarify decisions on all key interface elements to ensure consistency

Tips:
i
Standard interface icons (pictures) representing status or actions
ii
Use interface metaphors when appropriate
Interface Standards
i
The basic design elements that are common across the individual screens,
forms, and reports within the system
i
Ensures that the interfaces are consistent across the system
Interface metaphors
i
Define how the interface will work
i
A concept from the real world that is used as a model for the computer
system
ii
Helps the user understand the system and enables the user to predict what
features the interface might provide
1 Ex: Many Windows systems use the paper form or table as a metaphor
Interface templates
i
Defines the general appearance of all screens in the information systems
and the paper-based forms and reports that are used
Interface objects
i
The fundamental building blocks of the system, such as the entities and
data stores
Interface actions
i
Ex: buy vs. purchase, exit vs. quit (keeping it similar throughout)
Interface icons
i
Best approach is to adopt icons developed by others
ii
Ex: the floppy disk as a "save" icon
A mock-up or simulation of screens, forms, or reports
The most common methods include:
i
Paper sketches (storyboard)
1 Shows hand drawn pictures of what the screens will look like and how
they will flow from one screen to another
i
Wireframe diagrams: showing a box outline where elements will be placed
ii
HTML prototype: a prototype using Web tools
iii
Language prototype: a prototype using the programming language the final
product will be coded in

EVALUATION/TESTING

SOURCE DATA AUTOMATION

Reduced duplicate work and processing time

Decreases cost and probability of error
Can be obtained by using the following technologies
o
Bar code readers/scanners
o
Optical character recognition
o
Magnetic stripe readers
o
Smart cards
o
RFI (Radio Frequency Identification) tags

CHAPTER 10
STRUCTURE CHARTS

Depicts a program at a high level in graphic form

Shows all components of code in hierarchical format
Illustrates the organization and interactions of the different program modules

PROGRAM SPECIFICATIONS

Contains a set of written instructions in more detail

PROGRAM DESIGN

Creating instructions for the programmers at a high level to program the

system; no standard approach
Include program information, events and triggers, inputs and outputs,
pseudocode (coding-type language that could be easily implemented in any
language), and additional notes and comments

TOP-DOWN, MODULAR APPROACH

Begin with the "big picture" and break it apart into modules, gradually adding
detail

THE PHYSICAL PROCESS MODEL

Show the implementation details and explain how the system will work,
including
o
Actual, specific technology
o
Format of information
o
Human interaction with system

THE PHYSICAL DFD

Similarities:
o
Contains the same components as the logical DFD
o
The same rules pertaining to balance and decomposition apply
Differences:
o
Logical DFDs do not contain any indication of how the system will
actually be implemented when the information system is built; they simply
state what the new system will do.
o
Physical DFDs Contains additional details describing how the system
will be built
o
Physical DFDs show implementation decisions

TRANSFORMING THE LOGICAL DATA MODEL

The logical entity relationship diagram (ERD) depicts the "business view" of
data; omits implementation details
Having determined the data storage format, physical data models are created
to show implementation and to explain more about the "how" of the final
system

STEPS TO CREATE THE PHYSICAL DFD

Draw a human-machine boundary

Add implementation references
Add system-related data stores, data flows and processes
o
Ex: backups, exceptions, audit trails, etc.
Update data descriptions and metadata in the CASE repository

STEPS TO CREATE THE PHYSICAL DATABASE DESIGN

Add primary keys (often same as identifiers)

Add intersection tables to replace N:M relationships with two 1:N
Add foreign keys to represent relationships
o
1:1 --> the primary key in (either) one of the tables (but not both)
becomes a foreign key in other table
o
1:N --> the primary key in the "1" table becomes the foreign key in the
"N" table
Add data types for all fields (formerly attributes)

CHAPTER 12
IMPLEMENTATION

The building of all parts of the system: the software itself, documentation,
and new operating procedures
Consists of developing and testing the system's software, documentation,
and new operating procedures

MANAGING THE PROGRAMMING PROCESS

ASSIGNING PROGRAMMING TASKS

o
o

Project manager must assign program modules to the programming

staff
Each programming module should be as separate and distinctive as
possible from the other modules

Assigning Programmers
o
o
o
o

Minimize the number of programmers

Projects requiring a large team should be broken into a series of
independent, smaller parts
Match programming tasks with programmer capabilities
When skills are deficient, apply mentoring and training

COORDINATING ACTIVITIES

o
o
o

o
o

Weekly (hopefully brief) meetings

Create and follow standards
Organize programmers' work areas
Development area

Testing area

Production area

Implement change control mechanisms

Use program log to monitor program changes

MANAGING THE SCHEDULE

Scope creep --> occurs when new requirements are added to the
project after the system design has been finalized

TESTING PHILOSOPHY

Testing helps ensure that the system performs as outlined in the

specifications
It is unwise to test spontaneously without an overall testing plan
Testing must be done systematically and results documented carefully

CATEGORIES OF TESTING
UNIT TESTING

Tests each module - does it perform its function?

o
o
o

Black box testing --> focuses on whether the unit meets requirements
stated in specification
White-box testing --> looks inside the module at actual code
Five common functions to test during unit testing
Create new item

Change item

Delete item

Display item

Find item

INTEGRATION TESTING

Tests the interaction of modules - do they work together?

SYSTEM TESTING

Tests to assure that the software works well as part of the overall
system, including nonfunctional requirements

ACCEPTANCE TESTING

o
o

Tests to assure that the system serves organizational needs

Alpha Testing
Performed by users to assure they accept the system; frequently

repeats earlier tests

Beta Testing
Uses real data, not test data. Actual users monitor for errors or

needed improvements
User sign-off following Acceptance Testing indicates the system is
ready to be placed into production

DOCUMENTATION

Provides information to make the system easier to use and repair

System documentation
o
Intended to help programmers and analysts understand and maintain
the system after it is installed
User documentation
o
Intended to help users operate the system
o
Types of user documentation:
Reference documents (perform system functions)

Procedures manuals (perform business tasks - includes manual

procedures)
Tutorials (how to use system components)

5 TYPES OF DOCUMENT NAVIGATION

Table of contents
Index
Text search
Agent search
Links between documents

CHAPTER 13

THREE STEPS

Unfreezing
o
Loosening up peoples' habits and norms
Moving
o
Transition from old to new systems
Refreezing
o
Institutionalize and make efficient the way of doing things

CONVERSION STYLES

Direct conversion
o
The new system instantly replaces the old
Parallel conversion
o
For a time, both old and new systems are used
o
The old is abandoned when the new is proven fully capable

CONVERSION LOCATION

Pilot conversion
o
One or more locations are converted to work out bugs before
extending to other locations
Phased conversion
o
Locations are converted in sets
Simultaneous conversion
o
All locations are converted at the same time

CONVERSION MODULES

Whole system conversion

o
All modules converted in one step
Modular conversion
o
When modules are loosely associated, they can be converted one at a
time

KEY FACTORS IN SELECTING A CONVERSION STRATEGY

RISK

o
o

Seriousness of consequences of remaining bugs

To minimize risk:
Parallel conversion style
Pilot conversion location
Conversion modules
Riskiest conversion strategy:
Direct conversion style
Simultaneous conversion location
Conversion of whole system

COST

o
o
o

Parallel requires paying for two systems for some time

Simultaneous requires more staff to support all locations
To minimize cost:
Direct conversion style
Pilot or phased conversion location
Conversion of whole system
Highest cost conversion strategy:
Parallel conversion style
Simultaneous conversion location
Conversion of modules

TIME

o
o

Parallel phased, and modular require more time

To minimize time
Direct conversion style
Simultaneous conversion location
Conversion of whole system
Longest time conversion strategy
Parallel conversion style
Phased conversion location
Conversion of modules

BUSINESS CONTINGENCY PLAN

Keeps small technology glitches in the new system from turning into major
business disasters

Helps the business withstand relatively small problems with the new system
so that major business disruptions are prevented

STEPS IN CHANGE MANAGEMENT

1

REVISE MANAGEMENT POLICIES

a
b

No computer system will be successfully adopted unless management

policies support its adoption
Management tools for support adoption

ASSESS COSTS AND BENEFITS MODELS OF POTENTIAL ADOPTERS

MOTIVATE ADOPTION

Informational
i
Aims to convince adopters that change is necessary, through clear
and convincing evidence
b Political
i
Uses organizational power to motivate change
b Potential adopters generally are
i
20-30% ready adopters
ii
20% resistant adopters
iii
40-60% reluctant adopters
iv
Strategies should focus on supporting and encouraging ready
adopters and helping them win over the reluctant adopters
2

ENABLE PEOPLE TO ADOPT (TRAINING)

a
b
c

Dont assume users will "figure it out"

Focus on helping users accomplish their tasks, not on system features
Match types of training to resources and learners
i
Classroom, one-on-one, computer-based (CBT)

POST-IMPLEMENTATION

Provide support
o
Assistance in using the system
Provide maintenance
o
Repair or fix discovered bugs or errors
o
Add minor enhancements to provide added value
Assess the project
o
Analyze what was done well
o
Discover what activities need improvement in the future

LEVEL 1 SUPPORT

Broad knowledge

LEVEL 2 SUPPORT

Specialists in the application system

Unresolved issues are passed to level 2 support