User Interfaces Spring 1998
Homework #5
Due April 23
Total points: 15
Submit to: xianghui@cs.nyu.edu 
Note: The final due date for this assignment is April 30, the last day of class. This is so I can discuss the solutions then.

 

1. (5 points) The following screens are from the kiosk application located at Penn Station that lets you buy tickets for New Jersey Transit trains. For input, the kiosk provides a numeric keypad, two buttons labelled Go Back and Cancel, and ten other buttons marked with arrows, five along each side of the screen. The meanings of these buttons are displayed on the screen in small rectangles.

    1. Some of the screens are poorly ordered. Suggest a way to reorder them that makes more sense.
    2. Redesign the first few screens to incorporate a fast path for English speakers who do not want special promotions. Assume you have much more room available on each screen than is shown in the drawings.
    3. There is another fast path in the application. What is it?

2.(10 points) You are asked to design the user interface for an "electronic library" for a large corporation, an online repository of information about company documents such as memos, reports and so on.The system will have many thousands of users, all of whom have at least a basic familiarity with computers. Your system will run on standard hardware, e.g. PCs. Here is the functionality of the system:

    1. Users can add a document to the library. (Only a small fraction of users of the system -- perhaps 1000 or so -- will perform this task.) The user enters the title, author, creation date, department and miscellaneous other information about the document, including a brief summary. The user also describes the location of the document, either a URL if the document is on the Web, or a physical location if it is on paper. The user must also enter his or her own employee ID for auditing purposes (i.e. so the system administrators know who entered the document). Of course, the user could supply a different person's ID, but that is not your problem. Most of the time this process will be done by the author herself, usually one document at a time. But sometimes it will be done by other people, and occasionally multiple documents will be entered in one sitting by the same person.
    2. Users can edit information about an existing document (perhaps because of mistakes in the original, or because the document has moved). The user must first obtain the document's record in some way. All fields are editable except the employee ID. The user doing the editing must also enter his or her employee ID. It is expected that usually the editing will be done by the same employee who entered the information originally.
    3. Users can delete a document. The user must identify the document somehow, as with editing, and must supply an employee ID.
    4. Users can search for a document or for several documents. This will be by far the most common use of the system. A user should be able to search by title, author name, or any of the other recorded fields, as well as for matching words in the abstract and (in the case of online documents) the contents. No employee ID is required for this task.

Create an application-level design for this system's user interface. (You don't need to worry about what goes on behind the user interface -- obviously it is a front end to a database, but you need not be concerned with any of the technical or administrative details of that part of the system.) Your design should describe the windows of the system, when they appear and disappear, how users move among them, which are modal and which aren't, and so on. Although you should describe what information is in each window, you don't need to do detailed design such as layout or widget choice. You do need to consider how to handle errors and mistakes: when, if and how validation is done, how undo will work, etc.

Try to design a system that is both easy to use for beginners as well as fast and convenient for more experienced users. Explain your design choices in the terms we discussed in class: closure, risk, freedom, constraint, fast paths, etc. If you feel you need to make other assumptions about the use of the system to complete the design, go right ahead, but make sure you document them. You should not write any code--just text and, if you wish, diagrams. Email your assignment to the TA listed above, or bring it to class.