Embed Size (px)
Citation preview
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
