CSCI 672 – Human Computer Interaction


Dr. Manaris







Project #2 – Phase 4







Team Members:

Chris Cordes

Mike Guminsky

David Mendelsohn


June 12, 2001

1.      Certificate of Authenticity


We certify that the work performed on this project is our own, receiving no outside assistance (except when required for peer evaluations).  The following products were used in the completion of this project:


·        Microsoft Office

·        Microsoft Visio

·        Microsoft Paint

·        Microsoft Visual Basic

·        Microsoft Visual Developer Studio


2.      Final HTA

3.      User Interface and Metaphors Analysis/Description


1)      Use of Windows Operating System Common Dialog Library – By using the common dialog box included with Visual Basic, our end product is able to incorporate the standard metaphors defined by the Microsoft Windows interface.  This includes the following metaphors:


a.       Blank Document  – for New (which we use as New Log)

b.      Open Folder – for Open (which we use as Open Log)

c.       Floppy Disk – for Save

d.      Printer – for Print

e.       Scissors – for Cut

f.        2 Documents – for Copy

g.       Document on the Clipboard – for Paste


By incorporating these standard metaphors, the user’s learning curve is substantially reduced if he is familiar with the Microsoft Windows environment.


2)      Unique Metaphors – The only unique metaphors that our product uses are the Start Light (Green Traffic Signal) and the Stop Light (Red Traffic Signal).  In the American context, these symbols exemplify “Start” and “Stop” which are the exact procedures being performed.  Although they are not internationalized, the differentiation between the two should encourage the user’s ability to operate the product successfully.



4.      Phase 2 Screenshots



1)      Splash Screen – The first screen the user sees is the “splash screen”.  This screen notifies the user that the program is loading.  It has some basic information such as the logo, the title, and the author’s names.  When the program has completed loading, the “splash screen” automatically disappears.   This follows the standard Windows development model (meaning that there are certain forms that occur in a majority of Windows based software).






2)      Main Form – This form is the main form of the Event Logger program.  It follows the standard Windows programming style and makes use of the Common Dialog functions (and metaphors, as described above).  The form opens in a “ready to log” state where all the user needs to do is issue the “Start” command, and events will be recorded in the Richtext box (the large white area).  The standard Windows menu command line is used to make use of the user’s previous knowledge of Windows.  This also helpful for items such as Minimize, Maximize, and Close (the line, the box, and the “X”).  Our interface includes a status line that has the date and time, as well as a space for reporting general user information (example:  “Logging started at 9:00AM” or “Logging stopped at 10:00AM”).




3)      Open Log Dialog Box – This form makes use of the standard Windows Open Dialog box.  Thus, if the user is familiar with Windows, opening an existing log will present no problems.



4)      Save As Dialog Box - This form makes use of the standard Windows Save As Dialog box.  Thus, if the user is familiar with Windows, opening an existing log will present no problems.



5)      Print Dialog Box - This form makes use of the standard Windows Save As Dialog box.  Thus, if the user is familiar with Windows, opening an existing log will present no problems.


5.      Final Interaction/State Diagrams

6.      Design Rationale/Changes from Evaluator Input and Implementation Issues


1.      The initial state of our logger application is shown below.  The logger function is enabled and no files are opened.  We decided to disable the stop function in the stopped state.  The start logger button (Green Traffic Light) stands out which helps eliminate confusion on the user’s part. 


2.      The snapshot below contains a log that has been started and stopped.  All possible types of recorded data are shown.  We elected to stay with the output format of the code given to us.  Each log starts with the “BEGIN LOGGING SESSION AT …” message and stops with the END LOGGING SESSION AT: …” message.  This makes very clear to the user each event, their sequence and end points.  The time and type of each event are very clear to the user.  Again, with the logger stopped the only logging option is to start another log sequence (The stop light is disabled). 



3.      This snapshot comes from the <Edit> <Options> menu selection.  The user can enter the mouse distance threshold that the application will use to record a mouse movement event.  The default is “50” (shown below) which we felt provides a good balance between level of performance and records of movement.



4.      We included a help file into our application, which gives the user basic instructions to operate the logger.  We included two notes to help prevent user mistakes but we included code to prevent exiting while logging and a prompt to save a logger session.



5.      We include some error handling code to prevent the user from attempting to exit the application while the logger is active.  Closing the application while logging would have left the logger process in a running state while the application was closed.  This feature prevents the “zombie process” and also reminds the user in the case the user forgot the logger was still active.  The message box should immediately grab the user’s attention.



6.      Below is a catch to remind the user to save any unsaved log data prior to exiting the application.  This prevents lost work due to mental errors.  We felt the message box was the best control for this error checking.



7.      Peer Review Comments on the Phase 1 (HTA)


1)                  Paul Markiewicz


¨      Your box #'s are not numbered correctly; they should be decomposed #s.

¨      All plans are missing except for "5.2". So, it is impossible to determine if the decomposition is viable. The plan should add some control.

¨      Are 2.1.1 and 2.1.2 missing their underlines (or are they going to be further re-described?

¨      All this business about "Click on Command Line" seems to be inconsistent with "Graphic" part of Graphic User Interface..

¨      Conceptually speaking, aren't "modify Text" and "correct text" somewhat over lapped? (When I correct text, I would think that I am modifying it..)

¨      When task "Enter Text" is performed, I would be entering some text. So,  I am now wondering if/when I "Enter Command", will I be keying in a command?

¨      From the context, my guess is that I would be "pressing some kind of OK button".


2)                  Robert Gorlitsky


¨      I don't like the use of the phrase "command line".  I think you mean menu bar.


¨      I like the overall detail of the diagram.  I think you're supposed to put in more of those plans like in the example in the book but I can tell what you mean anyway so it's not that critical.


¨      On 5.2.2 (replace text) it would be more clear if you put (enter text) as the next step after (select text) instead of as a sub task of "select text" since it's not really part of selecting text but rather, it's a part of replacing text.


¨      The difference between 5.1 and 5.2 is a little unclear.  It seems to me that the stuff under correcting text could be just as easily under modifying text and it would simplify the diagram a bit.



3)      John Jones and Markus Beamer


·        Item 2.2.4 – Not really following what this is (“Enter the command”)

·        Items 1.1 – 1.3 – All seem to be implementation details.

·        Item 7.4 – Enter what command?

·        Item 8.1 – If I am on a command line, shouldn’t I “type” exit instead of clicking on it?


8.      Peer Review Comments on the Phase 2 (UI/Metaphors)


1)      Paul Markiewicz


* The project "identified and analyzed the UI metaphors".* It explained each of the toolbar-Icons purpose. (Since the application also contained a Menu-metaphor, I have presumed that there was a one-to-one correspondence between the tool-bar icons and the menu-items.)  * One critical feedback that I was wondering was: what is presented to the user while the application is actively collecting events? Would the textual-event-data be getting spooled onto the screen-window right in from of the users eyes or will that activity be occurring behind the scenes? *IF* the event-data is being written to the screen while the user is "watching", will they be able to interact with it..? Any way, if we knew whether or not the data can be streamed to an active window then we would also know if there needs to be another screen that simply displays that the collection logging is actively processing.... We would need to know more about the capabilities of that "application-magic" code to make that final determination.


2)      Dmytro Kantala and Barbara Ball


The picture of the traffic symbols seemed to be a little confusing (in black and white).  We really do not know which is stop and which is go.


I have no idea about what is the file system.  No picture or explanation.


Overall, the typical notepad design.  Users are already familiar with this so there should not be any trouble adapting.


The phase 3 diagram will probably answer a lot of questions about how this will work.  Just from looking at the interface of phase 2., it is hard to know details like can the user edit a file which is currently in the “record” state, etc.



9.      Peer Review Comments on the Phase 2 (UI/Metaphors)


1)      Dmytro Kantala and Barbara Ball


Generally clean and concise diagram.


There is no mention of enabling or disabling the Paste function.  From this one would assume there is always something in the clipboard to paste.


There is also no mention of enabling or disabling the stoplights when one or the other is active.