Assignment for 05-830, User Interface Software, Spring, 1997.

Connected Graph Benchmark Description

Brad Myers

Introduction

This is a particular kind of graphical editor, one that allows the user to create a simple form of boxes and arrows diagrams (directed graphs). This editor is not "real" since it lacks a number of important features, but it is important to have a relatively small task in order to be able to complete it in a reasonable amount of time. I think that the specification below can be implemented in around a day or so with most toolkits.

Certainly, this is closer to the kinds of applications that some tools are designed to support, and less appropriate for others. Still, in order to have some basis of comparison, it is necessary to pick a single benchmark task. The specification below seems somewhat long, but actually the editor is very simple. I felt that it was important to specify it to a significant level of detail, to make sure that everyone was implementing an equivalent system.

You can use whatever tools are in your environment, such as a graphics package, toolkit, a UIMS, an interface builder, etc. Please be sure to list in the question section below which tools you use. If you happen to have an existing graphical editor around, but which is not part of a distributed toolkit, please do not use this code, since this would not be a fair test of the toolkit. (That is, if the toolkit contains parts that can be assembled into a graphical editor, it is fine to use those, but if it does not, but you happen to have a graphical editor around similar to the one described here, it is not fair to reuse parts of that editor.)

Please read the entire document carefully before beginning your work. This will help ensure that you cover all the requirements in your implementation.

Description of the editor

This editor will allow the user to create boxes-and-arrows diagrams. The boxes are labeled with a fixed text string, and each box is attached by an line with an arrow to the box that was previously drawn. The layout for the boxes is entirely under the user's control (there is no automatic layout). The boxes can be re-sized and moved by the user, but the text string cannot be changed. The outline of the boxes and the style for the lines can be specified and changed.

Detailed Specification

Presentation

Here is a picture of one implementation of this editor. The current drawing mode is thin-line, and Box 5 is selected. Box 7 was deleted. This editor uses a particular look and feel; your implementation will probably look different.

Figure 1 Image
  1. The application window will contain two sections (sub-windows). One section will contain the palette and menu (described below), and the other section will be the workspace area where the user will create the boxes and lines diagrams.
  2. The "boxes" will actually be rounded rectangles (rectangles whose corners are rounded instead of square), sometimes called "roundtangles." They are not filled (you can see boxes underneath other boxes), but they are drawn with "replace" mode (logical OR, sometimes called "paint" or "copy"). The rest of this document calls them "boxes" even though they are really "roundtangles."
  3. Each box will contain a text label. This label is centered horizontally, just below the top of the box. Therefore, it is inside the box. The label is generated automatically by the system and cannot be changed. The label for the first box is "Box 1" and for the second box "Box 2", etc.
  4. Each box will have a line to the previously created box (unless this is the first box, of course, in which case there is no line, or if the previous box was explicitly deleted using the delete command (see below), then again, there will be no line).
  5. Each line will have an arrowhead pointing towards the newer box.
  6. For simplicity, the lines will always start and end at the center (both in X and Y) of a box. The lines will stay in the center even if the box is moved or re-sized.

Menus

  1. There is a palette (menu) on the screen containing a number of line styles. This palette contains at least 3 thicknesses (e.g., 1, 2, and 4 pixels thick), plus dashed lines of thickness 1 (to make 4 choices). The initial selection is thickness 1. Preferably, the menu should show the pictures of the lines, not text descriptions.
  2. There is one command menu containing the two choices: Delete and Quit.
  3. The menu and palette are operated in a way that is consistent with other applications on the same machine (i.e., use the environment-standard look and feel -- on the Macintosh, these should be Macintosh-style menus). Preferably, the palette will be on the screen at all times, and show the current line mode using some sort of highlighting. The menu (containing delete and quit) can be on the screen or it might be some sort of pop-up or pull down menu -- whatever is appropriate for the system.
  4. The quit menu command causes the application to exit and the window to be removed from the screen.

Operation

Note: This description assumes two buttons on the mouse. If there is one button (or if the "standard" look and feel of the system dictates using only one button), then you might need a menu or palette to determine whether you are in selection mode or drawing mode. I leave this to you to design.

Creating Boxes

  1. When the user presses in the workspace window with one mouse button (e.g., the right mouse button), a new box begins to be drawn (as described above, if there is only one button, then maybe you have to be in box mode before drawing begins). While the button is depressed, a feedback object ("rubber-band rectangle") shows where the new box will be. When the button is released, a new box is created using the final position and size. If the user types a special keyboard key (for example, ^G, ^C or Command-.) or releases the button outside the workspace window, then the operation is aborted, and no object is created. The new box will use the current line style (from the line style palette) for its outline. (Note: if your look-and-feel does not create objects in this manner, then use your method.) Be sure the user can create as many boxes as wanted: do not use a fixed size static array for the boxes.
  2. There is a minimum width and height for the boxes, which is big enough for the label. This can be some fixed constant size, e.g., 50 by 30 pixels.
  3. The box will have a label string centered at the top.
  4. In addition, the new box will have a line with an arrow to it from the previously created box (unless this is the first box or the previous box was deleted). The initial line style of the line and the arrow will be the same as the new box (as specified by the current value of the line style menu).

Selection

  1. When the user presses with a different button on an object (e.g., the left button -- or if there is only one button, when the mode is "select"), then that object becomes selected. Feedback of the current selection is shown in the standard way for the system for graphic objects (e.g. on the Macintosh by sprouting "handles" which are small squares at the corners and sides).
  2. Either a line or a box can be selected. If handles or reverse video is used as the feedback to show that a line is selected, they should only be along the line, and not around the entire bounding box of the line (e.g., use 2 or 3 handles for a line at the end points and center).
  3. Only one object can be selected at a time, so when the user points to a different object, the previously selected object becomes deselected. Clicking on the background causes there to be no selection (deselects the current object, if any). Various operations can be performed on the selected object.
  4. The line style menu is updated to reflect the line style of the selected object.
  5. If objects overlap, the topmost one (most recently drawn) is selected.

Changing Line Style

  1. If the line style menu is changed while an object is selected, then that object's line style is changed. (Note that this allows a line to have a different line style than a box, even though they were created with the same style).
  2. Also, whether or not there is a selection, pressing on the line style menu changes the default for the next line or box drawn.

Deleting Objects

  1. Selecting the delete command from the menu causes the selected object to be deleted.
  2. If a box is deleted, all the attached lines should also be deleted (it is illegal to have dangling lines). If a line is deleted, the boxes it is attached to are not deleted, however.

Moving and Resizing Objects

  1. If the selection is a box, it can be re-sized or moved in the standard way for the system, for example by pressing on the selection handles. (If the look-and-feel defines that objects that are not selected can be re-sized and moved, then that mechanism should be used instead.)
  2. Lines cannot be moved, only deleted and changed line styles. Therefore, if the user tries to move a line, the system should beep or otherwise signal an error.
  3. While a box is being created, moved, or re-sized, a feedback object shows the new position and/or size. The original object moves when the operation is confirmed (usually, when the mouse button is released).
  4. Like creating a new object, moving and growing an object can be aborted while the operation is in progress, either by releasing the button outside the window or by hitting a special keyboard key (for example, ^G, ^C or Command-.) In this case, the object retains its original size and position (it does not change).
  5. After a box is moved or re-sized, the lines are adjusted to be at the center and the text string is moved to be at the top, center.
  6. Boxes can never shrink below their minimum width and height while being changed size, and the rubber-band feedback should indicate this by refusing to get smaller than this size.

Windows

  1. The outer-most window should respond to the standard window manager commands, such as bring to front, move, resize, iconize, etc.
  2. If the window was covered and becomes uncovered, the picture must be immediately refreshed ("damaged" portions of the window must be repaired).
  3. If the window is resized or moved, the objects should stay at the same relative position and size with respect to the workspace window's top left corner.
  4. Objects are clipped with respect to the workspace window, so that they will not draw on top of the palettes or other windows on the screen.

Features Not Included

The system does not need to handle scrolling of the picture, zooming, scaling, undo, reading or writing (saving or restoring the picture), or printing.