A WIMP User Interface
College of Charleston
This document describes the result of one student project completed as part of a joint graduate and undergraduate computer science class, Human-Computer Interaction, at the College of Charleston. The purpose of the project was to develop a WIMP (Windows, Icons, Mouse, Pointers) user interface for an application that logs keyboard and mouse events on MS Windows platforms.
Hierarchical Task Analysis (HTA)
Our aim was to describe the application in terms of a hierarchy of operations and plans. For this, an Hierarchical Task Analysis (HTA) was completed. The final version of our HTA is presented in Figure 1, and reflects changes based peer evaluations and further development of the application.
HTA level 0 represents the initial case, and all other subtasks fall under Begin Applications. These basic tasks of the application include creating a new log, opening an existing log, saving a log, closing a log, using a log, and exiting the application. From our original HTA, we moved the saving task to level 1, added a minimizing task, and dropped the print task. The print task was excluded because we were unable to implement printing capabilities. Also added was the task to confirm/cancel a save task. We did not include a task that would allow editing of the log. We felt very strongly about this and since the design rationale for this project was that this application would be used by developers of other software products to log how people used their product, we felt that the user should not be allowed to change anything in the logs. This follows closely with Good Laboratory Practices (GLP) which prohibits the changing of any data.
UI Metaphor Description/Analysis
Our attempt at a user interface conceptual model led us to use a mixed metaphor. The recording (logging) of events led us to question what sort of devices people use to record things. Our team decided to use a small hand-held cassette recorder as the interface metaphor for our project and a windows application with its understood functionality metaphor for the logs created and manipulated. Many people are familiar with these devices or versions of them and this should be of assistance to a new user. We feel that this will assist new user in understanding an unfamiliar or complex subject, thereby lowering the learning curve. Not necessarily all users will be familiar with this device, but most who are using a computer should be familiar enough with other products that use recording icons to be able to understand the recording, pausing, and stopping functions of the application.
The design of the interface metaphor changed constantly during product development as shown in Figures 2-5. Although we had decided on the interface metaphor when phase 2 was to be delivered, we had not actually made the necessary images to portray it visually, so Figure 2 represents the windows portion of the interface as originally designed.
Figure 3 shows the original interface which is very similar to an actual cassette recorder. There were several problems though. Most notable, the buttons on the side of the recorder. It was felt that because the buttons were set at an angle, it would be hard to correctly place recording icons on the buttons and have the angles match. Also, the color choice was a very light gray and did not offer enough contrast with the logging window that was envisioned to reside in the middle of the recorder.
Figure 3 Figure 4
Figure 4 shows a later design iteration incorporating the minimized feature described in our HTA as well as color changes and removal of the side buttons. As the design evolved, some of the buttons changed in shape and placement. Figure 5 shows the final version along with its minimized view and although it doesn't resemble a cassette recorder as much any more, it still maintains the recording icons that are often used in a recording device.
Below are some of the considerations given to many aspects of user interfaces.
Size: The physical size of the application was designed to allow the user to see the actions that were logged without having to scroll left or right thereby decreasing the number of "false" logging actions that might be recorded.
Button Placement: The arrangement of the buttons was designed to make them as unobtrusive as possible while still keeping them functionally accessible. They were place beneath the logging window and ordered from left to right as follows: record, pause, stop. This flow from left to right was intended to provide a subtle mapping of how the instrument should be used. In theory, the user would begin recording by pressing the leftmost button (record) and continue to the right where they could pause logging and then on the far right they could press the stop button to completely stop logging (could not restart the same log). This left to right flow follows the way most western societies read. In the minimized view, the natural progression from record to stop is provided as well, but was made to be top to bottom instead of left to right. This vertical alignment is a holdover from the original design in which the buttons were place on the side of the recorder. In most cassette recorders those buttons would be vertical if the recorder were oriented as our design is. The minimize button was made long and rectangular to differentiate it from the recording controls directly above it and provide a natural break.
Color: The light yellow coloring of the buttons was designed to not only provide contrast to the blue of the recorder, but also as a pleasing compliment to the blue. It's light color also allows for maximum contrast with the recording icons placed on them.
Menus: The menus were grouped on the application bar logically according to the task at hand. All menu options have keyboard accelerators as well. Because of the limited functions required for this application, cascading menus were not needed. Record, pause, and stop are grouped under the log menu because these are the tasks that one would do to the log. After the log has been made, it is ready to become a file and so those associated tasks are found under the File menu. Here is where one would create, open, save or close a log. Exit is provided under File as a convenience for windows users as this is where it is most often found in Windows applications.
Affordances: The buttons used afford pushing. The scroll bar down the side of the logging window affords moving the sliding bar up and down and would also be familiar to Windows users.
Feedback: Feedback is provided by the application by having the logging window directly above the logging action buttons. This lets the user to know that they are logging because the actions appear directly over the buttons that were pushed. Even when the actions go beyond the scope of the logging window, the scroll bar continues to move whenever the user does something which lets them know that their movements are still being recorded. In the minimized view, feedback is accomplished by having the record button becoming grayed out.
We specified the behavior of the user interface by linking together the objects in a temporal structure. Figure 6 shows our updated interaction diagram. By providing an objective model of the state changes as the user interacts with the interface, we were able to use these behaviors to design the application. In our interface, we decided on three (3) pull-down menus as the major tasks for the initial interface: File, Log, and About. We use these menus were used to categorize and break down the subtasks. Under the File menu, we listed the subtasks: New, Open… , Save, Save As… , Close, and Exit. Under About, we described the application and listed the authors. Under the Log menu, we listed the subtasks: Start, Pause, and Stop Log. This was the basic WIMP graphical user interface created from the Hierarchical Task Analysis (HTA). In the Interaction Diagram, we divided the WIMP User Interface into two distinct states: Logging State Full View, and Logging State Minimal View. In the Logging State Full View, after the application has been started, the user had the choice of the following menu selections: File, Log and About. About produces the narrative of the application. Under File menu, the user had the choice of the following actions: New, Open, Save, Save As, Close, and Exit. Under Log menu, the user had the choice of the following actions: Start, Pause and Stop. In the Logging State Minimal View, the user can choose from the following actions: Record, Stop, Pause, and Full View. These explicit specifications of the interface assisted in the development of the physical appearance of the interface by illustrating the user interface instance hierarchy and the identification of the required components.
We believed that the tape recorder was a generic interaction style that could include all the ways that users would communicate or interact with the WIMP User Interface. This low-level design guideline would require no real interpretation before it could be used. Most users would be familiar with the controls of a tape recorder, which would facilitate a lower learning curve. In addition, we chose to use a Microsoft-like GUI on the same premise. During use, the interface should be as unobtrusive as possible while still providing functionality and accessibility. According to our Hierarchical Task Analysis, the user is provided with the options of starting, pausing and stopping logging. These functions can be found in the Log drop-down menu. Using the File menu a user may Open, Save, Save As, Close, Exit or Create a New Log. We choose to place so many actions under one menu because this maintained a consistency between other applications that the user might have previously used or become accustomed to. The menu system is designed as a standard menu. The redundancy of functionality by using keyboard accelerators allows users use their automatic processes (Ex: Ctrl S to save a file).
Certificate of Authenticity:
We certify that this deliverable is entirely our own work.
Phase 1 comments from:
Good job keeping the diagram fairly high level and not going too deep into the specifics of the implementation.
Needs pause functionality.
Needs a place for performing the actions to be logged.
There is no edit functionality.
Phase 1 comments by Dr. Manaris:
Create Log should be changed to Create New Log.
Log is not always visible? And if so, how about “unview” log (orthogonal).
Sunder save Log, Confirm Filename should be changed to Cancel.
What happens at Stop Recording if 1-2-1? New log? Append log?
Phase 2 comments by Dr. Manaris:
Cassette recorder usually has buttons.
Nice idea [tape recorder], but not really implemented, at least graphically.
This is your standard MS Windows metaphor, document, menus, … metaphor.
How do stop and pause differ? If stop = Pause + New, then there is redundancy here … new is available under File. Consider merging Pause and Stop to Stop. If Start is pressed … simply append new entries.
Phase 2 comments by
Since the application's primary purpose is a logging tool, maybe it should start in the mode shown while logging. The editor should be shown if the user requests to view log.
The cassette recorder as a metaphor is unclear as there are no buttons provided for the user to input selections -- maybe it should be considered.
Some of the standard windows keyboard pneumonics are changed such as Close and Exit, which are usually indicated as Alt-C and Alt-X respectively. This deviation from what the user would normally expect could prove confusing.
What functions are provided by the options menu -- your document does not show them.
Using the Editor window to provide status information for the user is confusing. Should consider using the status bar or title bar for that purpose.
Phase 3 comments by Dr. Manaris:
Certificate of Authenticity?
Move or consider disabling New in initial state.
What are the available options in Initial State: New Open, and Exit? Are there more?
In the Initial State, it is not possible to close any applications.
The Initial State does not follow the HTA and it gets in the way.
You didn’t study Notepad very well … it seems.