OOFILE | Downloads | Purchasing | Press | Services | Company Information | Soapbox | References | F.A.Q. | HOME

GUI Events (Cases)

This document uses Jacobson's Use Cases to describe sequences of actions in a typical GUI database application. Other gui docs (eg: gui.txt, pplant.txt) will describe how generic and platform-specific classes work to implement these use cases.

USE CASES

1) Opening an existing database

This applies where the user has a "document" model of their databases and are able to open one of several.

1.1 The user chooses Open from the File menu. A list of database files is shown in a platform-standard Open dialog.

1.2 When they choose a file and press Open, the database opens.

1.3 An initial list of records is shown.

Alternatives:
1.2 The user Cancels the open, leaving them in the same state as before.

1.3 The application may not present an initial list of records, but requires the user to perform a search or explicitly command All Records before displaying the list.

1.3 The state of the initial list may be remembered between Opens or may default to All Records. State of list could include sort order and subset of records shown.

2) Creating a new database

2.1 The user chooses New from the File menu. They are presented with the platform standard Save As dialog - the new database must be named before creation.

2.2 On entering a name and pressing OK, the new database is created and opens with no records.

Alternatives:
same as for 1) Opening an existing database

3) Adding a record

3.1 The user presses a button or chooses a menu item.

3.2 A form appears on which they enter data and

3.3 accept by pressing an OK button.

3.4 The record is saved and,

3.5 they return to the original context

3.6 the new record is shown either in sorted order or at the bottom of an unsorted list

Alternatives:
3.3 The user decides not to save their new record and presses Cancel. This always returns them to their original context.

3.5 The application or user preferences may specify that a new blank form appears, on OKing an entry, and continues to do so until the last blank form is Cancelled

3.6 new records may appear at the top

3.6 new records may be displayed in some different colour or style

4) Editing an existing record

4.1 The user selects a record on a list and double-clicks, presses a button or chooses a menu item.

4.2 A form appears with the current record contents, allow editing and they

4.3 accept by pressing an OK button.

Alternatives:
4.2 Some applications may implement separate commands Modify vs Open to allow displaying a record in a form in read/write vs read/only mode.

4.2 Some applications may allow toggling of the read/write status within a form - the user can start in read/only and then decide they want to change items.

4.3 The user decides not to save their changes and presses Cancel. This always returns them to their original context.

Notes:
Read/write status on a form implies at least one field can be edited. It doesn't imply that all fields are editable at any time or by any user. Restrictions may be based on:
- user security privileges
- state of data - some items may be "sealed off" due to processing

5) Movement while editing

5.1 While in the record editing form, the user presses a movement button (eg: Next Record) or chooses a menu command.

5.2 Their changes are saved and

5.3 the contents of the form change to as the next record in order is loaded.

Alternatives:
5.2 The application or user preferences may not allow automatic saving - the user is prompted "Do you want to save changes" before moving to the next record. They can answer:
Yes - saves & moves
No - discards & moves
Cancel - doesn't move, staying on the changed record.

Notes:
If they are at the end of a collection, the appropriate buttons are disabled (eg: Next and Last vs First and Prev).


 

Feature index

(c) Copyright A.D. Software 1994-2000 (All Rights Reserved).
Last Updated: 9th September 2001