User Interface Design Window Navigation Models Window Specifications Prototyping Menu Structures...

User Interface Design

Window Navigation Models

Window Specifications

Prototyping

Menu Structures

User Object Modelling

User Interface Design

The technique of User Interface Design involves the following activities:

Agree style guide; Design Windows in Outline Design Windows Navigation Model Specify Windows in Detail

Window Navigation Models

In a GUI environment, the interface of each on-line Function will be implemented using one or more windows.

Before designing or building these it may be useful to get an overview of the different windows that will support a Function and how those windows interact.

We can use a Window Navigation Model to do this.

Window Navigation Models

m

indicates more than one occurrence can be

open at once

control transfer to a window which is not

updated

control transfer to a window which is then

updated

action name

control transfer to another window which does not remove this

window

action name

control transfer to another window which removes this window

Window Name

window type m - modal

1

2

control transfer dependent on status (1 or 2)

window button/icon

Window Navigation Models

When developing Window Navigation Models we should bear in mind the following points :

Users will often want to quit or suspend a transaction before completing it: we should define exit points that allow the user to do this.

The window navigation model should be checked for consistency against the relevant Function Navigation Model and Task Model (Work Practice Model).

Window Navigation Models

We should try to minimise the amount of navigation that users have to do in order to complete a task. In particular users should not have to switch back and forth across different windows.

Where possible the structure of dialogues should be consistent across different Functions.

Window Navigation Models

Check Available

Slots

1

Add New Item

Amend Item

Existing Item

Amend Delivery

New Time

New Item

new existing

m existing

Window Specification

For every on-line Function we need to define the Windows that will form the interface to that Function

The type of things we have to document include: Data entry fields: names, size, optionality, validation, format and defaults (where this has not been specified elsewhere.

The use of list boxes, their contents, sort order, etc.

The behaviour of the window e.g. is the window modal (i.e. the user has to finish with that window before they can move to any other window).

Window Specification

Tab sequences (the default order in which we move from control to control).

Help: identifying the things that the user will require on line help for.

Window Specification is a useful technique to use within Prototyping to sketch an outline of the window to an appropriate level of detail.

Window Specification

Web Browse and Buy

PlaceOrder

MakePayment

if password is given

if no passwordis given

if type and criteria areentered

if only typeis entered

if type and criteria areentered

if only typeis entered

ZigZag Welcome ZigZag Search

ZigZag Search Results

ZigZag Customer Registration

ZigZag Customer Details Confirmation

ZigZag Payment

ZigZag Thank You

Customer’s Shopping Cart

User defines type of search and optionally enters search criteria

User enters search criteria. There are several versions of this window catering for different types of search (see the chapter on Relational Data Analysis (Chapter 10) for an example.

search

browse

go

search

add

search

checkout

continue

continue

continue

continue

home

Prototyping

Prototyping provides us with one of the most valuable opportunities to demonstrate and validate

our understanding of system requirements by presenting users with a model or example of what

the system will actually look like.

Prototyping Issues

Once a decision to under take prototyping has been made and management procedures set up, the activities involved are quite easy to understand and satisfying to carry out. However before we can proceed there are a number of issues that need addressing.

Specification prototyping can involve a great deal of time and effort, so for each project we should assess its suitability before committing the necessary resources.

Prototyping Issues

Suitable Projects Politically sensitive projects; Projects involving users with little or no experience of computer systems,

or analysts with little experience of the business area; Projects that involve large elements of new functionality, or for which

there is no existing system. Projects where user interface is of critical importance and where interface

requirements are unclear Unsuitable Projects

Projects that merely aim to replace existing systems, with little or no extra functionality (although some of these projects will be particularly concerned with improving the user interface, in which case prototyping will be useful, perhaps essential);

Largely off-line projects Projects where user requirements are precisely and rigidly defined.

Prototyping IssuesRisks of Prototyping

Virtually all of the risks involved with prototyping are associated with its management and presentation:

False User Expectation

Limits of prototyping tool

Uncontrolled systems design

Lack of documentation

Losing sight of the business objectives of the project

Prototyping IssuesBenefits of Prototyping

For suitable projects there are a number of potential benefits that may justify the use of prototyping :

Improved communication

Validation of user requirements

Assessment of system capabilities

Increased user commitment

Improved project moral

Management of Prototyping

PROJECT MANAGEMENT

TEAM LEADER

Prototyping Scope & Objectives Prototyping Report

USER

Define/ Redefine Scope

Develop Prototype

Demonstrate or Operate

Review

Management of PrototypingPreparing for the Prototype Demonstration

Before we demonstrate prototypes to users, we should draw up specific objectivesobjectives and agendasagendas for the session as it is all too easy in the rather informal atmosphere of prototyping to get side-tracked and to waste valuable time on trivial issues.

To help in this task we can draw up a Prototype Demonstration Prototype Demonstration Objective DocumentObjective Document for each pathway

As well as listing specific discussion points for each dialogue, we can use this document to note down general tasks, such as an explanation of procedure, in the form of an agenda for the entire prototyping session.

Prototype Demonstration Objective Document

Pathway No: 001

Function Name: Book Delivery

User Role: Delivery Scheduler

Agenda:1. Discuss prototyping aims and procedures.2. Explain operation of prototyping tool.3. Carry out demonstration.4. Discuss feedback and possible re-remonstration.

Component No.

Discussion Point

5 Check input data items

if Id unknown

6 Check field sizes

6 Check output details are

sufficient

6 What if stated quantity

exceeds expected?

Management of PrototypingDemonstration

We demonstrate each pathway to one or more users belonging to the appropriate User Role. Ideally, demonstrations should be conducted by two analysts from the project team.

User requests made by the users during the demonstration should be recorded (in a Prototype Result LogPrototype Result Log)

The following are a useful grading scale that can be used to record users’ requests

Management of PrototypingDemonstration

N. No change needed. C. Cosmetic change e.g. requests associated with layout and

format, not content. D. Dialogue level, i.e. changes which affect the content of the

dialogue only. P. Pathway changes. These will generally refer to requests

regarding the sequence of the pathway. S. This indicates a possible need to change installation

standards. A. Analysis errors. G. Global change requests which have implications outside

the business area under investigation.

Menu Structures

We represent menus by ‘square-cornered’ boxes

Menu Structures are fairly straightforward

and individual dialogues by round cornered boxes

Delivery Scheduler

Main Menu MEN01

Book Delivery DIAL01

Menu Structures

We construct a Menu Structure for each User Role. The bottom level in a Menu Structure hierarchy will then consist

of the dialogues required to interface with all of the functions identified for the appropriate User Role in the User Role/Function Matrix.

For example, taking the user role ‘Delivery Scheduler’ the required dialogues are:

Menu Structures

Book Delivery Amend Delivery Maintain Schedule Overdue Delivery Query Check Available Slots Delivery Query Allocate Stock Location

Menu Structures

Delivery Scheduler Main Menu

Book Delivery Amend Delivery Maintain Schedule

Overdue Delivery Query

Check Available Slots

Delivery Query Allocate Stock Location

MENU01

DDIIAALL0011 DDIIAALL0022 DDIIAALL0033 DDIIAALL0044 DDIIAALL0055 DDIIAALL0066 DDIIAALL0077

Menu Structures

Alternatively we could group dialogues together under intermediate levels of menus.

As a general guide any groupings of dialogues should aim to support the way in which users carry out activities.

In the absence of firm requirements from users we might consider groupings based on the following:

Menu Structures

Functions of a similar type (e.g. group all updates under one menu, and all enquiries under another);

Functions that access the same data; The grouping of processes on the Required System

DFM.

Menu StructuresDelivery

SchedulerMain Menu

Amend Delivery

Maintain Schedule

Overdue Delivery Query

Delivery Query

Book Delivery Check Available Slots

Allocate StockLocations

EnquiriesMenu

Maintain Delivery

Menu

DeliveryBookings

Menu

MENU01

MENU02

MENU03

MENU04

DIAL03

DIAL01 DIAL05 DIAL02

DIAL04 DIAL06DIAL07

User Object Models

User Object Modelling is a technique that attempts to represent the computerised information system as the user might think of it. In other words it is used to represent the user’s mental model of the information system.

It can be argued that Function Definition leads analysts to take a too system-centredsystem-centred view of their work, concentrating on the way in which update and enquiry processing will be triggered and hence emphasising a view of the system that is based around the Logical Data Model, events and enquiries, rather than the user.

User Object Models

The intention of User Object Modelling is to redress the balance by taking a user-centreduser-centred view of the system or its interface, forcing the analyst to think about the system as the user perceives it.

User Object Models

There are four basic User Object Model (UOM) concepts:

User Objects; User Object Model Attributes; Actions; Associations.

Developing User Object Models

We can build a single User Object Model for the whole application, for each User Role.

Two suggested ways of developing user object models are:

Developing User Object Models

From the Required Task Model. For each task or sub-task ask ‘which objects does the user want to work on’. Another way of looking at this is that many low level tasks will involve actions on objects.

Directly from interviews with the users. In this case the discussion will focus directly on the appearance of the proposed system’s interface.

Developing User Object Models

In the case of arranging a delivery for ZigZag, delivery schedulers perceive that the activity entails the use of a diary, which consists of many time slots. During the activity, a delivery note is created. This delivery note is associated with one or more half hour slots and with one or more purchase orders.

Developing User Object Models

DIARY

Arrange DeliveryAvailable Time SlotsOpen Diary etc.

TIME

SLOT

Start dateStart timeArrange Delivery.Available Time Slots.etc....

DELIVERYNOTE

Delivery date Product code Supplier code etc. Arrange Delivery etc.

PURCHASE

ORDER

P.O. Number P.O.date etc….

Arrange DeliveryConfirm P.O. etc…

object name

attributes

actions