Assignment for 05-830, User Interface Software, Spring, 1997.
This is a simple direct-manipulation interface for playing card games.
It is representative of tasks for which the user must position and operate on objects that are close analogies to real-world objects. In these tasks, the spatial relationships of objects are significant, and the objects are active. Often some objects have fixed positions in the workspace, and the act of placing other objects into them or onto them triggers some behavior. Objects may also support operations that can be directly invoked by the user. For this benchmark, we will also consider the issue of Z-order &emdash; extending the analogy to the real world by requiring a consistent treatment of overlapping objects as if they were embedded in three-dimensional space.
Aspects of this style occur commonly in direct-manipulation interfaces. In the Macintosh Finder, the user manipulates objects representing files and folders. Moving files into folders triggers an actual file-system operation. In the Windows 95 Explorer, right-clicking on a file produces a menu allowing the user to perform specific operations on that file. In the Windows Solitaire card game, moving cards from one position to another corresponds to a move in the game. Only certain moves are legal, and some moves may trigger events such as a change in the score. Furthermore, the rules of the game require a distinction between cards that are "on top" of other cards and cards that are "underneath". And of course almost all windowing systems manage the Z-order of windows and maintain spatial relationships between them. (Systems with inter-application "drag and drop" also treat windows as "active" objects.)
To keep the benchmark simple, we will not have the concept of "selection" which is present in most direct-manipulation interfaces. Selection and operation will always occur together; if there are multiple targets for the operation, they will be determined implicitly by the relationships of objects to a primary target. For example, if the user clicks on an object and drags it, we move all the objects that are "on top" of the primary target.
However, we will be testing the ability to invoke operations both directly on an object and indirectly by moving one object onto another. This is sometimes called "Semantic Feedback." Of course, we will also be testing the functionality for manipulating positional and Z-order information for objects. (Even interfaces such as the Finder that do not attach meaning to the Z-order still require the ability to manipulate the Z-order, for example to bring objects to the front.) We will also use a non-trivial number of objects, so to some extent we will be testing the scalability of the toolkits, which is quite important for tasks such as file manipulation that may need to deal with hundreds or thousands of objects.
This application will present a window containing 52 objects representing playing cards. The user can move them around the window, "flip" them to show either the front or the back, and move a group of cards into a "shuffle box" object that rearranges them. Cards can also be brought to the front of the Z-order. They are implicitly grouped for movement and flipping based on the way they overlap.
Figure 1
The basic appearance should look similar to Figure 1. The only significant elements are the cards and the shuffle box. There need be no menus or other widgets of any kind, except for the standard items provided by whatever native windowing system is available. It is expected that the native environment will provide a way to terminate the application (for example, by clicking on a "close" box).
The cards appear as simple rectangular images. We provide a set of 52 GIF images that must be used for the front faces of the cards (displayed when the card is not in the "flipped" state), and one GIF image that must be used for all cards that are "flipped". The shuffle box appears as another rectangular image. The word "Shuffle" should appear centered horizontally in the box. The exact colors used for the shuffle box (and the background of the workspace) are not significant as long as the overall appearance is pleasing.
When the application is started, all 52 cards should appear “flipped”in an array, spread horizontally and positioned vertically above the shuffle box, but not overlapping the shuffle box. The cards should be ordered so that the leftmost card is bottom in the Z-order and the rightmost card is top in the Z-order. (The "bottom" of the Z-order is the card furthest from the user’s viewpoint.)
A click on a card followed by drag and release moves the card in the traditional way. It also moves all the cards that are "on top of" the target card. Card A is "on top of" card B if A overlaps B and A is above B in the Z-order, or if there is some card C such that A is on top of C and C is on top of B.
All the cards that move retain their relative Z-orders, but they all move to the top of the Z-order relative to the cards that do not participate in the move. The dragging of the cards should be indicated visually, preferably by displaying the actual card images during the move, but alternatively by dragging just the outlines or some bounding rectangle.
A double-click on a card flips it and all the cards that are on top of it. The "flipped" state of each card is toggled, and also the relative Z-orders of the cards is reversed. In particular the target card will end up at the very top of the Z-order. Note that the first click of the double-click counts as a single click too, so these cards will just have been lifted to the top of the Z-order relative to the others.
The shuffle box cannot be moved and clicks on it have no effect.
When a group of cards is moved so that the mouse is in the shuffle box, and the mouse was not in the shuffle box at the start of the move, the move takes place as normal and then the cards are shuffled. This means that a random permutation is applied to the cards. When card A is mapped to card B, card A moves to the position and Z-order of card B. There should be some animation to indicate each such move.
When a move is in progress and the cards are in a position where releasing the mouse would cause a shuffle, there must be a visual notification of the fact. If the platform has a convention for this, that convention should be followed, otherwise the background of the shuffle box should change color. Of course, the highlighting must be removed when the condition lapses &emdash; if the shuffle takes place or the cards move outside the shuffle box.