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

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

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 Place Order Make Payment

if password is given if no password is given if type and criteria are entered if only type is entered if type and criteria are entered if only type is entered ZigZag WelcomeZigZag 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 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 Issues Risks 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 Issues Benefits 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 & ObjectivesPrototyping Report USER Define/ Redefine Scope Develop Prototype Demonstrate or Operate Review

Management of Prototyping Preparing for the Prototype Demonstration objectivesagendas  Before we demonstrate prototypes to users, we should draw up specific objectives and agendas 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. Prototype Demonstration Objective Document  To help in this task we can draw up a Prototype Demonstration Objective 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 5Check input data items if Id unknown 6Check field sizes 6Check output details are sufficient 6What if stated quantity exceeds expected?

Management of Prototyping Demonstration  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. Prototype Result Log  User requests made by the users during the demonstration should be recorded (in a Prototype Result Log)  The following are a useful grading scale that can be used to record users’ requests 

Management of Prototyping Demonstration  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

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

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 Structures Delivery Scheduler Main Menu Amend Delivery Maintain Schedule Overdue Delivery Query Book Delivery Check Available Slots Allocate Stock Locations Enquiries Menu Maintain Delivery Menu Delivery Bookings Menu MENU01 MENU02 MENU03 MENU04 DIAL03 DIAL01 DIAL05 DIAL02 DIAL04 DIAL06 DIAL07

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. system-centred  It can be argued that Function Definition leads analysts to take a too system-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 user-centred  The intention of User Object Modelling is to redress the balance by taking a user-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 Delivery Available Time Slots Open Diary etc. TIME SLOT Start date Start time Arrange Delivery. Available Time Slots. etc.... DELIVERY NOTE Delivery date Product code Supplier code etc. Arrange Delivery etc. PURCHASE ORDER P.O. Number P.O.date etc…. Arrange Delivery Confirm P.O. etc… object name attributes actions