Barbara Ball

Dmytro Kantala


CSCI 672

Spring 2001

Dr Manaris



Project 2 Final Phase



HTA Diagram








The above picture represents our prototype for the WIMP user interface.  We chose to use a composite metaphor principally combining a film editing/VCR metaphor with the standard Microsoft file or document metaphor.  We likened the log file to that of piece of film, which could be rewound, fast-forwarded, played, stopped, paused and edited at any position.  We chose the ubiquitous “VCR” panel controls because these are representative of working with video film to both individuals with no experience in film work, as well as individuals who have extensive experience in such an industry. 


Although the film editing metaphor worked very well for viewing and working with a log file, we felt that as a stored entity it would be better to consider it a file rather than, for example, a piece of film.  We opted to use the metaphors that have become so standard in computer software when storing any chunk of data: the file.  Likewise, we use the standard floppy disk icon on the “Save” button, the opened file folder for “Open”, the new document for “Create New File”, and the printer for the “Print” icon. These already established metaphors require no interpretation on the part of any user who has used the widespread Microsoft Windows products. 


We purposely divided the controls into separate categories on the interface so the user could see the associations between each group of metaphors and follow the conceptual model therein.  No group has more than seven controls in one area, following the seven +/- two rule.  The center of the interface is the “screen box” where the log file is displayed; regardless of whether it is a currently recording log file or one loaded from storage.  As described above, the left control group represents the standard features almost every user will be familiar with.  Below the screen box are the “film editing” buttons, with images that should look like those on most VCRs: a large red dot to start recording, and a stop button with a square black shape.


At the top of the interface, above the screen box, are the tools to copy, cut, and paste when working with a log file.  We positioned these in the same area where users familiar with Microsoft Windows would find them, and used the same metaphors that have become standards for these tasks.  And following another expectation of most users, given the interface the ability to be minimized and closed from the square buttons on the top right hand side of the program.  The minimize feature should be particularly useful to users who would like to view what has been added to the active log file while they are recording.


The addition of the status bar is a user-friendly mechanism to provide feedback to the user when doing such tasks as loading or printing the file.  We believe that this status area will be more efficient than the minute, thin status bar found at the very bottom of the interface in most computer applications.  We expect the user to keep our interface at its smaller size of about three by five inches, not the full monitor size like many applications, limiting the viewing space required of the user.  The status area is also in the center of the application along with the screen box, therefore much more in the line of vision of the user than if it were at the bottom of the interface.


The colors found on the buttons should not distract from the metaphors and follow standard American symbolism; the red of the “Record” button reflecting a danger, don’t interrupt message.


We feel that our use of metaphors for this interface supports the conceptual models that have become firmly established in our society.  The user should have no problem picking up on how all of the controls work and the learning curve should be minimal, even for the persons most inexperienced at computers.


STD Diagram




Final Design Analysis


                We used the feedback from our previous three phases, as well as extensive discussion of our interface to determine the final design of this project.  We did not change our overall concept of the metaphor of this application since this seemed to be popular with all the evaluators.  We did revise the functionality based on input from both the Hierarchical Task Analysis diagram and the State Transition Diagrams.  One alteration was to remove the “Pause” button since its purpose is redundant; the functionality is paralleled by pressing the “Start” and “Stop” buttons.  We also changed the “Close” button to read “Exit” to avoid any confusion with closing a file versus exiting an application. 


We decided to allow the user to be able to edit the loaded log file while in a stopped state whereas before we had only considered allowing edit commands before any recording had started at all.  So now the user can record, stop, edit then return to recording.  We decided the button which allowed the user to change the size of the application to a smaller size was unnecessary since the interface is already only partially the screen size anyway.  We thoroughly analyzed the enabling and disabling logic to provide the user with consistent constraints that would deter the user from doing potentially dangerous actions.  Likewise, we added a warning message that pops up whenever the user chooses an action that would then cause the user to lose unsaved data.  The SaveAs Dialog box gives the user the list of already created files or the option of creating a file with a new name.  The Open Dialog box also provides the user with a list of previously created files so the user does not need to recall the name of the file he or she is searching for. 


            User feedback is provided using the status bar underneath the screen.  This control is used not only to inform the user of what is going on, but also to suggest to the user what to do next.  For example, when the application is first started, the status bar message is “Start Recording or Open File” which implies to the user that he/she has the capability of recording from the initial state, as well as opening a file and recording or editing it. Since only certain buttons are enabled, the user can see what options are available and what are not.  The following diagrams represent the use of these constraints and user feedback.


            This picture shows how the interface appears when it is initially loaded.  As you can see, the user only has options to paste any text from the text buffer, open a file, start recording in an empty file, exit or minimize the application.



This picture shows how the interface would appear if the user had opted to start recording a log file. No editing or file operations

are allowed during this time, hence these buttons are disabled.  Only the minimize, close and stop buttons are enabled.  The scroll bar is generated automatically when the data file is greater than the screen size.  This was a feature that we chose over using the fast forward, rewind symbols since its mapping and the conceptual model behind it is more familiar to most users.



Once the user has selected the “Stop” button,  he/she may edit, save, or print the file.  The user also has the option

of continuing to record, opening an already existing file, or creating a new file.



If the user does choose to open a file, create a new file or exit the application without having saved the file previously changed, then the following warning message box will pop up on the screen. The user may cancel the selected action, save the data by choosing “Yes” or continue with the selected action, but not save the data, by choosing “No”.  The top left corner close button performs the same function as “Cancel”.




The picture below of the Open Dialog box shows the use of giving the user the list of existing files.  The SaveAs Dialog box is virtually identical, except that it gives the user the options of saving or canceling.



We feel that we have created an interface that is pleasing to the eye and easily learned. The interface has all of the necessary functionality that a user would desire, without an excess of embellishments.  The selection controls are divided into categories on different parts of the screen for quick recognition.  The mapping of the controls should support the user’s conceptual model with the “Record” and “Stop” buttons below the logging screen box, similar to that of a VCR.  The screen‘s TV-like design should be instantly recognizable to the user.

  Any doubts in the user’s mind about how the application works are clarified by the use of constraints such as disabling and enabling buttons.

  This is additionally reiterated by the status bar messages below the screen box.


                        Modifications would have to be made for some users, such as the blind, people with biomechanical disabilities, or those not fluent in the English language.  This application was explicitly written for an audience familiar, if not fluent, in this language, not disabled visually or mechanically, and we have assumed some background using the Microsoft Windows interface.




Certificate of Authenticity


We certify that this deliverable is entirely our own work.

We did use a version of the Windows Media Player interface.


Phase 1 Comments


We only received comments back from one of the two teams to whom we gave our Phase 1 Task Analysis Chart and they are as follows:


HTA Comments for Dmytro Kantala and Barbara Ball


From: Matt Bucknam

           Valerie Sessions

           Bryan Spahr


·                          There is no need for the boxes that are associated with Plan 2.2, Plan 2.2.1 and Plan 2.2.1.  These will be given by Dr. Manaris.  Also the order is confusing.

·                          It needs a place for performing the actions to be logged

·                          There is no save functionality

·                          The order of Plan 3 is off-it is possible to start after unpausing


The evaluators we did not hear back from were: W. Paul Markiewicz, Johan Chauvet, and Henry (Hongye) Yang


Phase 2 Comments


Evaluators:  Chris Cordes and David Mendelsohn



1)      We don’t know necessarily agree that a VCR’s controls are ubiquitous, since there are many types of VCR controls and many people who can’t program their VCR (Hence, the “flashing clock” syndrome.)


2)      The layout presents a nice design that is pleasing to the eye.


3)      The only major comment we would make is that only 25% of the project follows the VCR metaphor, since 10 out of 13 buttons follow the standard Windows interface.


4)      There is no indication of file (film) navigation via scroll bars or “fast-forward” or “reverse” buttons.  We do assume that the scroll bars are automatic, though.


5)      In the case of logging, what is the difference between “pause” and “stop”?  Unless “start” is disabled completely once logging begins.  Does the user hit “pause” again to restart?



Overall Comments:  The design premise has merit.  The button grouping is very professional.


Phase 2 Comments For Dmytro Kantala and Barbara Ball

From Valerie Sessions, Bryan Spahr, and Matt Bucknam



·        This is a wonderful design. Good use of two different metaphors and I like the way it is split in space between the VCR/CD icons and the file icons.


·        I am not sure if you have thought of this but you may need some way to let the user know that he/she will not be able to edit the text while it is recording. Maybe there could be two looks to the text box – one that looks editable and one that doesn’t.



·        Usually the Cut icon appears to the left of the Copy icon.


·        The large close icon on the left side is confusing with the small close at the top right. Does one close the application and one close just a single log?







Phase 3 Comments

We only received comments back from one of the two teams to whom we gave our Phase 1 Task Analysis Chart and they are as follows:


Evaluators:  Chris Cordes and David Mendelsohn


1)      What is the difference between “Pause” and “Stop”?  Can’t you just hit “Record”, then “Stop”, and then “Record” again?

2)      Why can’t you “Stop” while the system is paused?

3)      What are the “Search” states?  Does “Search” bring up an additional dialog?


Overall Comment:  This system is very clear-cut, following the combination of the VCR/Notepad model.


The evaluators we did not hear back from were: Matt Bucknam, Valerie Sessions, and

Bryan Spahr.