Project 4

DTUI Booksite

Project 4: Building a Structure Help

Team Size: 5
Duration:

Goals:

The goals of this project are to provide you with the experience of designing and building a graphical interface using a interface building environment.

An HCI professional would be required to know how to design for compatibility with such tools and how to use them to build an interface.

Task Selection:

This project provides an opportunity to apply many of the ideas and concepts that we have seen in the course. The concerns for the task selection were:

The "backend" of the application should be fairly straightforward so that the programming wasn't a major hurdle, and so that reasonable time would be available for designing the user interface.

The "start-up cost" to learn any new system or language should be minimized.

The project should provide an opportunity for user and task analysis, evaluation, and iterative design.

Students could be potential users of the type of system developed.

The task should be familiar to students with only minimal explanation.

Task:

The task is to design and build a simple Structured Help system that uses the text found in the UNIX "Man pages". You will use Visual Basic (VB) to implement the system.

A structured help system has help in layers, with more general assistance at higher levels, becoming more specific as the user progresses towards the leaf nodes. Ideally, each level should provide some help (i.e., it isnt just an index to the actual help).

We suggest that a three level help system would be reasonable for this project, with a top level roughly concerned with "topic", a second level providing "summary" information, and the third level giving "details".

The underlying idea is that Man pages have fairly rigid structure, and could, with some appropriate processing and judgement, be converted into a hypertext system -- i.e., following links takes the user to different pieces of help. Previous research has already demonstrated that this can be done. (In fact, they were able to automatically convert the existing Man pages into a hypertext format for use by a customized viewer.)

It is well known that most people find Man pages tough to use. An experiment has shown that hypertext versions allow users to find things more quickly. People also liked using them better than the normal version that uses large blocks of formatted text.

Note that I do not expect you to produce sensitive text such as usually appears in hypertext (in the Web pages for example). Appropriate use of Buttons will do just fine.

Concentrate on a few simple UNIX commands -- three at most. The system need not be "complete" -- a fully working system would include all commands. However, you should clearly indicate by fully implementing help for a couple of commands how all the others might work -- i.e., it must be obvious that it is extensible. If you want to put non-working buttons on the screen to complete the illusion, that will be fine.

You can assume that ``in the future'' all the pieces of help text for display as hypertext nodes will be available in appropriate files. However, you should produce the text files for display, from Man pages, in any way you want. How (and if) you cut them up into smaller pieces is also up to you.

Base your system on (extracts from) the Man pages. You are not supposed to directly interpret the system's (real) man pages in any way. You display text from files. Your files. You decide what is in the files. You decide what their format should be. You decide what information from a man page appears where in your system. Don't put man page help text directly in your program source! It removes the generality of the program.

The design of the screen/window, the use of menus and buttons, and the format for display of text is also up to you. As this is not intended to be a major programming problem, we urge you to keep the methods used (e.g., the widgets) simple. Use what is provided. There will still be plenty of opportunity for individuality. The KISS (Keep It Simple, Stupid!) principle applies.

Methodology:

First become familiar with VB, so that you know what the limitations of the tool are.

Start the design by considering who the users are, and what they will want to do (i.e., analyze the users and the task). Produce a rough design for the interface.

Test this rough design (on paper) by using the user/task combinations you thought of at the start. Evaluate whether the design supports them well. Make changes until you are satisfied. (Note that at this point user involvement would normally be necessary, for confirmation.)

Map that design into VB. Try to build the system incrementally, so that you always have a "working" version, even if it doesn't really do much.

Test this implementation by using the user/task combinations you thought of at the start. Evaluate whether the implementation supports them well. Make changes until you are satisfied. (Note that at this point user involvement would normally be necessary, for confirmation.)

Hand in:

You are to submit:

a listing of any code produced (commented).

screen dumps showing each of the three levels of the help system;

Note: If we cant find a way to make screen dumps, then we

will arrange for everyone to demo their system for evaluation
by either the TA or myself.

a description of your design rationale -- why did you make those design decisions (screen and program)?

a block diagram or flowchart showing the structure of your system.

Use the CS Department's Documentation Format as much as possible for the program-related material handed in.

Information about Visual Basic:

Information about Using Visual Basic is available.

David Brown

Contributors Page

Please send comments and suggestions to the Booksite Director
Last Updated: 12 March 2000