05-830, User Interface Software, Spring, 2000
Homework 1,   Issued: January 19, 1998
Due: Wed, January 26

Homework 1

Create a Benchmark Description

The goal of this homework is for you to develop a benchmark task description.  You will prepare

• A hardcopy description of the benchmark task, to be turned in on January 26
• The hardcopy should include a URL or full /afs/ address of where I can access the benchmark on line, or else turn in a floppy with the benchmark.
• An oral presentation of the benchmark to be presented in class on January 26.

A good benchmark would be representative of one or more user interface styles.  It would have components that represented the most important or most difficult aspects of implementing that style, and would therefore be representative of a "real" application of the same style.  However, a benchmark should be implementable in just a few hundred lines of code in some appropriate tool (e.g., 200 to 1000 lines of code). Note that it does not have to be implementable, or easy to implement, in all toolkits -- one of the goals is to use these benchmarks to differentiate tools.

Your benchmark should be different from previous years.  Some of the benchmarks should test different aspects of the interfaces than previous year's did.  Even if you test the same aspects, try to do it in a different way.

It would be best if the benchmark were written in HTML format, so it will be easy to put it up on the web.

This written description should have the following parts:

• An introduction, which contains:
  • A brief overall description of the benchmark.  E.g. "This is a simple graphical editor".
  • A discussion of the style(s) of interface that this benchmark is representative of.  E.g. "This is representative of direct manipulation interfaces where the user ...".
  • A discussion of popular, well-known user interfaces that this is similar to.  E.g. "This benchmark is representative of the interface found on software such as CorelDraw and PowerPoint."
  • Motivate and discuss why your task is a good benchmark for the chosen style.  That is, why is it representative?  What features of the style have been captured and which have been left out?
• Next, there should be a detailed description of the benchmark to be implemented.  This description should be detailed enough to insure that each implementation using each toolkit is sufficiently similar. However, you should be careful not to include any specifications that would unnecessarily favor or penalize any one environment or toolkit.  For example, you can say "There must be a command to exit the program"  but it would not be appropriate to say "...which must be called 'Quit'" since on Windows the command is called "Exit" instead of "Quit".
• As an example of the level of detail, you can look previous year's benchmarks.
• It would be appropriate to have a picture, which you can draw by hand or with a drawing program, of a "typical" implementation of this interface, if that would be helpful.

The oral presentation should

• Be 5 minutes or less.
• Present the style of interface you are trying to write a benchmark for.
• Briefly describe your specification and why it is an appropriate benchmark for the specified style.
• Use overheads created ahead of time.
• Please turn in a hardcopy of your overheads after your talk.

This homework is worth 5% of your grade in the course -- both the oral and written parts will count towards your grade.  Since you need to present the benchmark in class, there will be substantial late penalties: one full letter grade immediately, and 1 extra letter grade per class late. 

Features That Might Be Included in Benchmarks

• Drawing freehand objects (Paint)
• Setting properties of objects
• Selecting and manipulating objects with the standard selection handles mechanism
• Keeping objects connected (constraints)
• Keeping properties of objects consistent
• Multi-font, multi-line text editing
• Filtering (testing) textual typed values for correctness
  • Keeping the values in the proper range
  • Converting values among types -- Yes/No -> boolean, strings -> numbers
  • General parsing of input.
    • E.g, as answers to Wizards
• User Interfaces for small devices (e.g., PalmPilots)
• Support for Multi-media
  • Video in the interface
  • Sound output
• Real animations
• "Real-time" interaction, as in games
• Multiple-people interactions
• Undo
  • Single level
  • Multiple level
• Coverage of widgets (does it have a full collection of widgets?)
• Support for Gestures, Speech input, etc.
• Support for 3D

(Bold shows items not adequately covered by any previousdes year's benchmarks, in my opinion.)

Back to 05-830 main page