Modern Systems Analysis and Design Joey F. George Jeffrey A

14.1

MSIS 5653

Advanced Systems Development

Dursun Delen, Ph.D.

Department of Management

Oklahoma State University

CHAPTER 14:

Designing Interfaces and Dialogues

Learning Objectives

14.2



Understand the process of designing interfaces and dialogues and the deliverables



Contrast and apply several methods for interacting with a system



List and describe various input devices and discuss usability issues for each in relation to performing different tasks



Discuss the general guidelines for interface design including:









Layout and design

Structuring data entry fields

Providing feedback

System help

D. Delen MSIS 5653

– Advanced Systems Development

Learning Objectives



Discuss the design of human-computer dialogues and the use of dialogue diagramming



Design graphical user interfaces



Understand interface design guidelines unique to the design of Internet based electronic business systems

14.3



Designing Interfaces in SDLC

14.4



Introduction

Interface?

Focus of user interface design is to determine how information is provided to and captured from the users

Dialogues are analogous to a conversation between two people

A good human-computer interface provides a unifying structure for finding, viewing and invoking the different components of a system

14.5



The Process of Designing

Interfaces and Dialogues

User-focused activity

Conducted in parallel to form and report design processes

Employs prototyping methodology

1.

Collect information

2.

Construct prototype

3.

Assess usability

4.

Make refinements

14.6



The Process of Designing

Interfaces and Dialogues

Deliverables



Design Specifications

 Narrative

 Sample Design

 Testing and usability assessment

14.7



Interaction Methods and Devices

Methods of Interacting





Command Language Interaction

 Users enter explicit statements into a system to invoke operations

 Pros / Cons?

Menu Interaction







A human computer interaction method

A list of system options is provided

A specific command is invoked by user selection of a menu option

 Menu complexity varies according to needs of system and capabilities of development environment

14.8



Guidelines for Designing Menus




Menu Interaction (Continued…)

 Menu Design Guidelines

 Wording













Organization

Length

Selection

Highlighting

Two common placement methods

 Pop-up

 Drop-down

Hierarchies can be employed



Sample Menu Designs



Types of Menu Configurations



Pop-Up and Drop-Down Menus



Building Menus with Advanced Tools







Form Interaction

 Allows users to fill in the blanks when working with a system

 Measures of an effective design













Self-explanatory title and field headings

Fields organized into logical groupings

Distinctive boundaries

Default values

Displays appropriate field lengths

Minimizes the need to scroll windows

14.1

4



Example: Form Interaction







Object-Based Interaction

 Symbols are used to represent commands or functions

 Icons





Graphic symbols that look like the processing option they are meant to represent

Use little screen space

 Can be easily understood by users



Natural Language Interaction

 Inputs to and outputs from system are in a conventional speaking language like English

14.16




Hardware Options for System Interaction



List of devices



















Keyboard

Mouse

Joystick

Trackball

Touch Pad

Touch Screen

Light Pen

Graphic Tablet

Voice

 Carpal Tunnel Syndrome ?..

14.17




Hardware Options for System Interaction



Usability assessment research for various devices

14.18



Designing Interfaces

Designing Layouts





Standard formats similar to paper-based forms and reports should be used

Screen navigation on data entry screens should be left-toright, top-to-bottom as on paper forms



14.19



Designing Layouts

Flexibility and consistency are primary design goals







Users should be able to move freely between fields

Data should not be permanently saved until the user explicitly requests this

Each key and command should be assigned to one function

14.20



Structuring Data Entry

Entry

Never require data that are already on-line or that can be computed

Defaults

Format

Always provide default values when appropriate

Units Make clear the type of data units requested for entry

Replacement Use character replacement when appropriate

Captioning Always place a caption adjacent to fields

Provide formatting examples

Justify Automatically justify data entries

Help Provide context-sensitive help when appropriate

14.21



Controlling Data Input

One objective of interface design is to reduce data entry errors

Role of systems analyst is to anticipate user errors and design features into the system’s interfaces to avoid, detect and correct data entry mistakes

Data entry errors





Appending

Truncating





Transcripting

Transposing

14.22



Controlling Data Input – Cont.

Techniques used by system designers to detect errors





Class/Composition (type)

Combinations















Expected Values

Missing Data

Pictures/Templates (format)

Range

Reasonableness

Size

Values

MSIS 5653


D. Delen

Providing Feedback

14.24

1.

Status Information



Keeps users informed of what is going on with the system



Displaying status information is especially important if the operation takes longer than a second or two

2.

Prompting Cues





Best to keep as specific as possible

Ready for Input: ____ vs. Enter SSN (xxx-xx-xxxx): _____

3.

Error and Warning Messages



Messages should be specific and free of error codes





User should be guided toward a result

Use terms familiar to user



Be consistent in format and placement of messages



Providing Help

Place yourself in user’s place when designing help

Guidelines







Simplicity

 Help messages should be short and to the point

Organization

 Information in help messages should be easily absorbed by users

Demonstrate

 It is useful to explicitly show users how to perform an operation

Context-Sensitive Help



Enables user to get field-specific help

Users should always be returned to where they were when requesting help

14.25



Providing Help

14.26



Designing Dialogues

Dialogue



Sequence in which information is displayed to and obtained from a user

Primary design guideline is consistency in

 sequence of actions,



 keystrokes, and terminology

Three step process

1. Design dialogue sequence

2. Build a prototype

3. Assess usability

14.27



Designing the Dialogue Sequence

Define the sequence

Have a clear understanding of the user, task, technological and environmental characteristics

Dialogue Diagram





A formal method for designing and representing humancomputer dialogues using box and line diagrams

Consists of a box with three sections

14.28



Designing the Dialogue Sequence

PVF

Customer Information

System

14.29



Building Prototypes and

Assessing Usability

Often optional activities

Task is simplified by using graphical design environment

14.30



Designing Interfaces and Dialogues in Graphical Environments

Interface Design Issues

1.

Become an expert user of the GUI environment

 Understand how other applications have been designed

 Understand standards

2.

Gain an understanding of the available resources and how they can be used

 Become familiar with standards for menus and forms

 Standards for menus (see next page >>>)

 Some common properties of windows and forms in a GUI environment:









Modality

Resizable

Movable

Maximize/Minimize

14.31



Standards for Menus



Designing Interfaces and Dialogues in Graphical Environments

Dialogue Design Issues



Goal is to establish the sequence of displays that users will encounter when working with system









Ability of some GUI environments to jump from application to application or screen to screen makes sequencing a challenge

One approach is to make users always resolve requests for information before proceeding

Dialogue diagramming helps analysts better manage the complexity of designing graphical interfaces

Wizard type screens are useful

14.33



Designing Interfaces and Dialogues for

Electronic Commerce Applications

General Guidelines











Design errors











Opening new Browser Window

Breaking the Back Button

Complex URLs

Orphan Pages

Scrolling Navigation Pages

Lack of Navigation Support

Hidden Links

Links that Don’t Provide Enough Information

Buttons that Don’t Provide Click Feedback

14.34



Summary


Design guidelines for interfaces



Layout design





Structuring data entry fields

Providing feedback



Designing help

Designing dialogues

Designing interfaces and dialogues in graphical environments

Designing Interfaces and Dialogues for Web Application

14.35



CHAPTER 15:

Finalizing Design Specifications

Learning Objectives



Discuss the need for system design specifications



Define quality requirements and write quality requirements statements



Read and understand a structure chart



Distinguish between evolutionary and throwaway prototyping



Explain the role of CASE tools in capturing design specifications



Demonstrate how design specifications can be declared for Web-based applications

15.3

7



Finalizing Design Specifications in SDLC

14.3

8



Introduction

There is a need for systems to be developed more quickly today

The lines between analysis and design and design and implementation are blurring



Traditional approaches allowed for a break between design and implementation



Other approaches, such as CASE and prototyping, have caused overlap between the two phases

15.3

9



The Process of

Finalizing Design Specifications

15.4

0

Less costly to correct and detect errors during the design phase

Two sets of guidelines



Writing quality specification statements



The quality of the specifications themselves

Quality requirement statements













Correct

Feasible

Necessary

Prioritized

Unambiguous

Verifiable



The Process of


Quality requirements









Completely described

Do not conflict with other requirements

Easily changed without adversely affecting other requirements

Traceable back to origin

15.4

1



The Process of


Deliverables and Outcome



Set of physical design specifications

 Contains detailed specifications for each part of the system

15.4

2



Representing Design Specifications

Traditional Methods







Pre-CASE

Documents written natural language and augmented with graphical models

Specification documents

 Figure 15-2 shows an example



>>>

Several methods for streamlining







Computer-based requirements management tools

Prototyping

Visual development environments

15.4

3



Example Specification Document

…




Structure Charts



Shows how an information system is organized in hierarchical models





Shows how parts of a system are related to one another

Shows breakdown of a system into programs and internal structures of programs written in third and fourth generation languages

15.4

5




15.4

6

Structure Charts



Module

 A self-contained component of a system, defined by a function (sections in COBOL, subroutines in FORTRAN)

 One single coordinating module at the root of structure chart (a.k.a. boss)

 Communicate with each other by passing parameters



Data couple : A diagrammatic representation of the data exchanged between two modules in a structure chart

 Flag : A diagrammatic representation of a message passed between two modules




1

15.47

Special Symbols used in

Structure Charts

1.

Diamond (conditional call of subordinates)

 Only one subordinate will be called

2.

Curved Line (repetitive calls of subordinates)

 Subordinates are called repeatedly until terminating condition is met

3.

Predefined modules

2

3

4.

Embedded module (Hat)

 Subordinate module is important logically but code is contained in superior module



4

Example: Structured Chart




Structure Charts



Pseudocode

 Method used for representing the instructions inside a module





Language similar to computer programming code

Serves for two functions





Helps analyst think in a structured way about the task a module is designed to perform

Acts as a communication tool between analyst and programmer

15.49




Prototyping





Construction of the model of a system

Allows developers and users to

 Test aspects of the overall design

 Check for functionality and usability



Two types

1.

2.

Evolutionary Prototyping

Throwaway Prototyping

15.50



Representing Design

Specifications

Prototyping



Evolutionary Prototyping

 Begin by modeling parts of the target system

 If successful, evolve rest of the system from the prototype

 Prototype becomes actual production system

 Often, difficult parts of the system are prototyped first

 Exception handling must be added to prototype

15.51



Representing Design

Specifications

Prototyping



Throwaway Prototyping





Prototype is not preserved

Developed quickly to demonstrate unclear aspect of system design

 Fast, easy to use development environment aids this approach

15.52



A Prototyping Example with Oracle:

HB Inventory Control System

1.

Transforming and Generating the Database

Entity-Relationship Diagramming Tool





1.


Database Design Transformer Tool





1.


Data Definition Language (DDL) script

Server Model Diagram





2.

Transforming and Generating Software Modules

Functional Hierarchy Diagram





2.


Module Diagram for

Update Inventory Added Function

Application Design Transformer





2.


Generated Form in Design Editor



Radical Methods: eXtreme Programming

Developed by Kent Beck (2000)

It is distinguished by its





Short Cycles

Incremental Planning Approach



Focus on automated tests

Utilizes a two-person programming team

Planning, analysis, design and construction are fused together into one phase

Requirements and specifications are uniquely captured

15.59




Planning game





Players





Business

Development

Story cards

 Description of procedure or system feature

15.60




Planning game

15.61




Iteration Planning Game



Played by programmers



Task Cards

 Several task cards generated for each story card

 Three phases

 Exploration



Story cards converted to task cards







Commitment



Programmers accept responsibility for tasks

Steering



Programmers write code, test it and integrate it

Game takes place during time between intervals of planning game steering phase meetings

15.62



Radical Methods: RAD

Four life-cycle phases









Planning

Design

Construction

Cutover

Iteration between design and construction

15.63



Electronic Commerce Application

Microsoft FrontPage can be used to build throwaway prototypes

Template based HTML for



Rapid development



Consistency in







Look an feel

Functionality

Navigation

15.64



Summary

Types of Design Specifications



Written document augmented by various diagrams







Structure chart

Computer-based requirements management tool

Prototypes

 Throwaway versus Evolutionary

Radical Methods



 eXtreme Programming

RAD

Electronic Commerce Application



Throwaway prototyping

15.65



Modern Systems Analysis and Design Joey F. George Jeffrey A

…

Related documents

Products

Support

Modern Systems Analysis and Design Joey F. George Jeffrey A

…

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib