AppLogger Keyboard and Mouse Event Logger

by: Robert Gorlitsky, Mike Adams, and Jason Youmans

Click here for a Zip file of the application.
Click here to download the executable.

Hierarchical Task Analysis

HTA Diagram
Click to Enlarge

User Interface Design Rational

Main Window Edit Entry Dialog
Main Window - Notice the top-to-bottom and left-to-right flow of operation.
Edit Entry Dialog - To modify a log entry the user clicks on the line she wishes to change and then clicks the "Edit Entry" button to bring up this dialog.
Open/Save Dialog
Open/Save Dialog - This standard Windows Open/Save dialog is activated when the user initiates an "open" or "save as..." operation.

Metaphors Used

The "new" and "open" buttons are metaphors that represent the way files are kept in folders in an office. The "new" button is used to refer to a blank document and the "open" button is used to refer to the action of opening a previously filed document. This is the standard Microsoft Windows "document" metaphor.

The "Record" and "Stop" buttons are metaphors that are used for the functionality of a VCR. The "Record" button is used to refer to the action of recording, and the "Stop" button is used to refer to the action of stopping recording.

The "new entry", "modify entry", and "delete entry" buttons are metaphors for the actions that can be used to change an itemized list. The "new entry" button is used to refer to the action of adding an item, the "delete entry" button is used to refer to the action of removing an item, and the "modify entry" button is used to refer to the action of changing an item in an itemized list.

Design Rationale

The interface is grouped in a top to bottom left to right fashion. The buttons are grouped according to the functions they are involved with. The first group of buttons in the top left corner are group together because they deal with the commands associated with file organization. The "Record" and "Stop" buttons are grouped above the log entry list because they deal with the starting and stopping of the logging of events that are recorded in the list. The buttons below the list are grouped together because they all deal with the modification of the list after the logging has been completed.

The list box interface with the buttons at the bottom for inserting, editing, and deleting log entries is used instead of free form text entry in order to limit the kinds of changes that can be made to the logs as well as to simplify the creation of new log entries and the deletion of existing log entries. This is done not only to encourage the log files to be kept in a more standard format for easier parsing and analyzing, but also to allow the user to work with log entries more as individual entities instead of just text in a box. Treating log entries as entities in the UI allows for future expansion of functionality related to log entries. For example, a change log can be kept that records all log modification operations. Since the file format for the logs is a simple text file with newlines, the user has the ability to modify the logs in any way by using an external text editor if necessary.

State Transition Diagram

STA Diagram
Click to Enlarge

Appendix - Evaluation Comments

Phase 1 - HTA

From: David B. Mendelsohn <> and team

Your stuff looks great...

Although I wouldn't necessarily include "Perform keyboard and mouse
events" in the HTA, since it is actually external to the program!

This causes a little confusion when you do a "stop logging", since you
are now switching context within the Operating Environment instead of
the logging program.

This could be the same for "Exit Logger" which could be considered an
"atomic" event!

Also, does your statement of "According to Requirements" refer back to
his document?  Kind of unclear!
From: Valerie Sessions <>, Matt Bucknam <>, and Bryan Spahr <>

There is no plan 0.  Too much detail as far as implementation (such as
"Click on").  You probably don't need to elaborate beyond 1, 2.1, 2.2.1,
2.2.2, 2.2.3, 3.1, 3.2, 3.3, 4, 5.  There is nothing that represents
opening and closing the application.
From:Johan Chauvet <> and team

1) Missing student names, etc.

2) Decomposition box#'s are not using
the standard numbering method.

3) Some boxes are decomposed into just
one box! (then..)  What are the two descrete/deliberate tasks?

4) "Plan 0" is missing.

5) What's with "Plan 3".. "according to requirements"? (and "Plan 2.1" also).  

6) The underlines are missing for some boxes that are not further decomposed.  

7) Is it plauseable to delete, modify, add only "part of a log ENTRY"?
If yes then I recomend that your "edit log" boxes/tasks stop asserting
the (word) "entry", and instead use "text". Otherwise it would imply
that your application will somehow monitor and enforce users to only
"enter" complete, valid and well formed entries.

8) If the log file name (existing) was decided in "Plan 2.1.2:1-2-3",
then what does your "required" step 2 of "Plan 4" do?

Phase 2 - UI Design

From: Henry (Hongye) Yang <>

The overall concept is great. The metaphors used fit into the tasks.

The problems that I see are from the log-entry editing.

1. "New Entry" button: What's the purpose of this button? Apparently,
when you start recording, the new entry will come in; you can edit the
entries when you stop recording.

2. "Edit Log Entry": Why do you want to change the input information?
Why don't you keep the original records as they are?

3. A "Sort" option may be helpful. For example, to get a sorted list
from the last entry or first entry in the log file; or to sort
according to the input types ...
By the way, is it necessary to have a "EXIT" button to close the
From: Valerie Sessions <>, Matt Bucknam <>, and Bryan Spahr <>

1. I like the two methapors - VCR and file and they work well together.

2. The graphical part of the icons could be larger. The record and
stop are especially small.

3. You may want to add a way to pause the recording.

4. If you have to edit line by line this may get tedious.
I would prefer a way to change as much text as I wanted at one time.

Phase 3 - STA

From: Valerie Sessions <>, Matt Bucknam <>, and Bryan Spahr <>

First off, the diagram is hard to read.  Besides that, it looks
pretty complete.  Except we don't see where you account for