Establishing the Need for Data Collection

Back to Top

Data about how people work at their computers can be helpful in determining the work patterns that can cause workstation overuse injuries. Understanding the causes of these injuries can highlight which solutions are most likely to help people with an existing injury as well as provide a valuable insight towards developing strategies that can be used in injury prevention.

Currently there is little data to assist research in this area; so much of what is traditionally suggested for preventing overuse injuries s is based on speculation, intuition and anecdotal information. DataLogger seeks to collect useful information about how people work at their computers to establish baselines before injuries and to measure the kinds of changes that occur as a result of macro changes in the job environment as well as from changes resulting from overuse injuries. We believe this type of data has both short and long-term benefits.

Here are five specific ways in which clients have reported using Guardian data:

1. Increasing the effectiveness of workstation assessments by giving health professionals (such as Occupational Therapists) access to information about how the employees uses the computer both in terms of behaviour and specific exposure to strain.

2. Dramatically improving the level of insight available to medical professionals (such as GPs) who make recommendations as to work restrictions and job modifications.

3. Increasing the ability of the employer, employee and insurance company to maintain (or prove) levels of exposure and compliance with workers’ compensation-related work restrictions and to provide pre and post injury insight into the actual causes of an injury.

4. Determining work patterns that lead to high incidence of overuse injuries (by using the Health Status Report Viewer) to analyse the “big picture” connections between reported symptoms and recorded exposures/behaviours.

5. Using this understanding of work patterns to focus preventative measures toward healthy individuals who fit the pattern of having a higher risk of future injury.

Looking at a specific example, let’s examine the typical process behind developing a work-restriction for an injured worker. An employee reports that he is having pain in his right arm after a day at work. A workstation assessment, including looking at DataLogger data, shows quickly that he uses the mouse intensely. The health professional recommends that by bringing the mouse closer and using AutoClick the employee reduces his pain.

However, because the employee waited a long time to report the injury, these corrections do not completely resolve the symptoms and the employee visits a doctor bringing printed graphs of his computer usage from DataLogger. At some point in the employee’s care the doctor may wish to prescribe a reduction in computer use. The doctor asks the employee for an evaluation of how much time he spends at the computer in order to prescribe that the employee follow a work restriction.

Historically, there have been several problems with this method:

The employee may be unlikely to be able to provide an accurate evaluation of their typical computer usage

The employee may not to be able to accurately gauge if they are correctly abiding by a prescribed work restriction

‘Time-based’ work restrictions ignore the varying intensity of computer work

The employer or doctor may have no definitive way of knowing if the work restriction is being followed

With Guardian’s DataLogger, the doctor has accurate historical baseline information about the employee’s workload. The duration and intensity of both mouse and keyboard use – today, last week, last year, etc. – are all accessible. This information can assist the doctor in prescribing a meaningful work restriction. Furthermore, the work restriction can be entered into Guardian’s work-restriction feature to ensure that the employee can easily follow the restriction accurately. The DataLogger will also show the employer exactly how well the employee is following their work restriction.

Finally, because DataLogger tracks ‘work intensity’ as well as time, the work restriction feature can actually limit the user based on either time at the computer or by exposure to cumulative strain. Being obsessive, the employee in this example has trouble following the restriction, but the employer knows about this immediately as opposed to discovering it months later when a stabilised injury might have become more serious.

Having DataLogger information about employees is also important in the context of the Health Status Reports feature. This employee’s injury information, as well as information about other employees who have less serious injuries or no symptoms at all, can be viewed as a whole. Health Status Reports allow OH&S staff to track and analyse patterns of employee ‘subjective’ discomfort feedback and DataLogger’s ‘objective’ observations for large numbers of employees. This dramatically enhances the ability to identify high-risk employees.

For example, understanding that break behaviour is correlated to incidence of injury allows OH&S staff to target individuals who are skipping breaks (a statistic recorded by DataLogger). Or as our example employee’s data might indicate, individuals who do mouse intensive work are more likely to be at risk for certain injuries in their mousing hand. Therefore, when DataLogger identifies certain employees as having similarly high mouse exposure, they can be selected to receive additional training (e.g., demonstrating Guardian’s AutoClick feature) to help avoid injury. Analogously, Guardian’s KeyControl feature would likely be presented to employees that DataLogger identifies as being keyboard intensive.

How much exposure to strain is too much? Are there hard and fast risk thresholds? Historically, there was no way to even know how much strain employees were being exposed to. Guardian makes that information available, it creates the question of what risks are associated with what levels of strain exposure. Although the research is insufficient to globally define these associations, a company using Health Status Reports will be able to develop a much more meaningful sense of the patterns that indicate risk. Since Guardian is used by various research organisations, we expect that more research will begin to address this critical question with potentially staggeringly beneficial results in predicting and therefore reducing computer-related overuse injuries.

Back to Top

What kinds of data does DataLogger collect?

Back to Top

Work-time statistics recorded daily include:

Date data was recorded.

Start and end times of computer work.

Amount of time the keyboard was in use.

Amount of time the mouse was in use.

Amount of time that the user was using computer.

Amount of time that the user rested.

Break-related statistics recorded daily include:

Number of suggested breaks that were taken.

Number of suggested breaks that were skipped.

Total time spent taking BreakTimer-suggested breaks.

Length of time that the user postponed breaks.

Number of natural rests the user took of at least 15 & 60 seconds and 4 & 16 minutes.

BreakTimer usage compliance.

“Average break length” setting and “average time between breaks” setting.

Stretch feature usage compliance.

Number of stretch suggestions the user was given.

“BreakTimer willpower” setting.

Work Restriction length setting (or a dynamic value if dynamic restrictions are active).

ForgetMeNot-related statistics recorded daily include:

ForgetMeNot usage compliance.

ForgetMeNot interval setting.

Microbreak usage compliance.

Number of microbreaks taken.

“Microbreak length” setting.

Keyboard and mouse-related statistics recorded daily include:

Amount of cumulative strain incurred from using the keyboard.

Amount of cumulative strain incurred from using the mouse.

Total number of keystrokes.

Total number of mouse clicks.

Average keypress force intensity.

Total number of times user switched between keyboard & mouse.

Number of mouse left clicks, middle clicks, and right clicks.

Distance mouse travelled.

Number of mouse double clicks.

Number of manual mouse drag & drops.

Number of KeyControl assisted drag & drops.

AutoClick usage compliance.

Number of AutoClicks.

KeyControl re-mapping feature usage compliance.

Number of KeyControl hotkeys used.

Total number of keyboard errors (i.e. Backspace/Delete usage).

Number of words the user typed.

Number of Health Status Reports filed.

Information recorded as a running average includes:

Average overall keystroke intensity.

Average overall intensity of keyboard use.

Average overall intensity of mouse use.

Information recorded as a running average about the keyboard includes:

How many times each key is used relative to total number of keystrokes.

A measure of keystroke intensity for each key on the keyboard.

How long it takes the user to reach each key.

Finally, information provided in a Health Status Report
(a subjective self-assessment) includes:

Name and identification.

Reason for filing report.

Current pain level.

Normal/typical pain level.

Frequency of symptoms.

Current medical care.

Use of anti-inflammatories, wrist-braces, & painkillers.

Location on body of symptoms (via checkboxes on a front/back image of body).

Additional symptom and general comment information.

Back to Top

A Technical Discussion of the Data Collected

Back to Top

The descriptions below provide information about each DataLogger-collected statistic. Each statistic has a general description of its purpose (in italics) followed by a technical description that gives a precise descriptions of the manner in which the data is being collected.

Work-Time Daily Statistics

Back to Top

The date stored is the date of the system clock in the selected time zone selected in Microsoft Windows on the computer on which the executable Guardian.exe is executing.

Guardian stores all daily data to the user’s disk drive when:

(1) Guardian detects a new day has begun
(2) a period of time has passed without caching the information to disk
(3) Guardian Reports are requested from Guardian; and
(4) Guardian exits normally.

Start time is the moment Guardian first starts up for the day, or, if Guardian is left running overnight, the moment the user first uses the keyboard or the mouse.
End time is the last time during the day that the user uses the keyboard or mouse.

This time range describes how long a person’s workday is. The “number of hours the user uses the computer” statistic divided by the difference between the end and start time tells the percentage of time a user uses the computer.

“Keyboard use” time is calculated by noting the time when a first keystroke occurs, and noting when 20 seconds have passed without a single keystroke. During this time, Guardian considers the user to be in the “keyboard-active state”.

The length of time the user is in the “keyboard-active state” is added to the “keyboard use time” accumulator.

“Mouse use” time is calculated by noting the time when mouse activity (moves, clicks or wheel-spins) first occurs, and noting when 20 seconds have passed without any mouse activity. During this time, Guardian considers the user to be in the “mouse-active state”.

The length of time the user is in the “mouse-active state” is added to the “mouse use time” accumulator.

This is not a measure of how long a user is working, because it does not measure time at any non-computer task or any computer task that doesn’t involve active use of the keyboard or pointing device.

When the user is in “keyboard-active state”, “mouse-active state”, or both, the user is in “active state”. Time using computer is a measure of how many seconds the user is in “active state”. Note that this statistic cannot accurately reflect extended periods of time where a user is viewing the monitor (e.g., reading text) without using the mouse or keyboard. Note also that the mouse-use time added to the keyboard-use time would not be expected to be equal to the total time using the computer, since frequently the user is engaged in using both the mouse and the keyboard.

For example, if the user spent 20 minutes using only the mouse, followed by 30 minutes using only the keyboard, followed by 5 minutes using both, mouse time would be 20+5 or 25 minutes, keyboard time would be 30+5 or 35 minutes, and total computer usage would be 20+30+5 or 55 minutes.

DataLogger notes the first time each day that a user enters “active state”. After that “start of the day” time, when the user is not in “active-state”, the user is in “idle state”. DataLogger notes the time of transitions from “active state” to “idle state” and the time of transitions from “idle state” to “active state”.

The difference between these two times is added to the “user resting” accumulator, unless the period of rest exceeds a threshold of 6 hours, in which case it is ignored.

Break-Related Daily Statistics

Back to Top

When BreakTimer suggests a break, the user is given the choice of taking the break, skipping the break, or postponing the break. These two statistics report how many times the user took the breaks vs. skipped the breaks.

Although Guardian considers all time without keystrokes or mouse activity over a certain time threshold to be rest, this statistic records only the length of time that the BreakTimer suggests breaks. If this number varies, it indicates that either the user is working more or less, or that they are taking natural breaks more or less.

For example, if a user naturally rested for several minutes every 20 minutes, and as a result, no breaks suggestions from BreakTimer were needed, then this statistic would be zero.

Rather than count ‘how many time’s a break is postponed, this statistic counts ‘how much time’ a break is postponed, making it a more meaningful indicator of the user’s behaviour.

Therefore, if five breaks were taken, and this statistic reported twenty minutes of total postponement time, then on average the user is postponing breaks four minutes (20÷5) per break suggestion.

These statistics tells how often users take breaks on their own without the help of BreakTimer. Four break lengths are recorded: breaks of 15 seconds or more, 60 seconds or more, 4 minutes or more, and 16 minutes or more. For example, a 17-minute break would be counted in all 4 statistics, and a 2-minute break would be counted in the 15 second and 60 second category.

This statistic is a strong indication of a person’s natural pattern of taking rest and thus may be an indicator of risk, especially if there are users who don’t use the BreakTimer.

Used to measure compliance with a requirement to use BreakTimer, this statistic is most relevant when looking at a group of Health Status Reports (e.g. to learn what percentage of some category of users use BreakTimer).

Note that this statistic does not describe how often breaks actually occurred or how long breaks actually were. It only tells what the user set the BreakTimer to do. Various factors could make the actual values (shown in other DataLogger statistics) higher or lower.

Used to measure compliance with a requirement to use the stretch feature, this statistic is most relevant when looking at a group of Health Status Reports (e.g. to learn what percentage of some category of users use the stretch animations).

While this statistic tells that the stretches were shown, it does not indicate whether the user actually performed the suggested stretches.

Using Health Status Reports, this gives the program administrator an overall indication of how hard the users feel it is to follow a computer-prescribed break regimen.

ForgetMeNot Daily Statistics

Back to Top

Used to measure compliance with a requirement to use the ForgetMeNots feature, this statistic is most relevant when looking at a group of Health Status Reports (e.g., to learn what percentage of some category of users use ForgetMeNots).

While this statistic tells what the user requested, it isn’t the actual frequency at which ForgetMeNots appeared, which can vary due to a number of factors (e.g., placement of longer breaks, user inactivity).

Used to measure compliance with a requirement to use the microbreaks feature, this statistic is most relevant when looking at a group of Health Status Reports (e.g., to learn what percentage of some category of users use microbreaks).

If microbreaks are enabled as part of ForgetMeNots, the ForgetMeNots include short microbreaks. This statistic tells how many microbreaks the user took during the workday as part of those ForgetMeNots.

During microbreaks the user is asked to pause for a period of time (that can be configured). This statistic tells the length of time of microbreaks.

Keyboard and Mouse-related Daily Statistics

Back to Top

What level of strain implies a risk?

Strain from mouse and keyboard is best analysed “relatively”. In other words, the change in a user’s exposure to strain over time, or the level of strain that various users with similar tasks experience has significance.

Future studies may one day correlate absolute values of strain exposure to risk, but at present, Remedy Interactive does not suggest that any particular level is either safe or dangerous. If an organization has 100 employees doing a similar task, there may be a correlation between their strain levels and their injury risk. Therefore, the return on investment for ergonomic interventions will likely be highest for users with the highest strain values. Strain values between mouse and keyboard cannot be compared since the units of strain for mouse and keyboard have been individually normalized to whole numbers.

How accurately is strain being measured?

Guardian likely measures strain more accurately than any other method available, with the impractical exception of full-time monitoring of an EMG device attached to a user. But Guardian’s strain measurements are still only approximations based on the strain measured in wrist muscle groups. Different workstations, as well as different psychological and physical patterns, all affect muscle strain in the wrists, and other parts of the body also experience muscle strains that are less affected by which particular actions are being performed on the keyboard/mouse. Also, although strain is accepted to be a significant factor for INJURY risk, there are other factors such as break taking patterns, time at the computer, postural factors, and individual psychological and physiological differences.

DataLogger collects the number of keystrokes pressed (without regard to which key is being pressed) and the number of mouse clicks clicked (without regard to which mouse button is being clicked). Double and triple mouse clicks are counted as two and three clicks respectively.

See the Keyboard Analysis Tool description below for more detail about this statistic.

DataLogger tabulates how often the user switches between the mouse and keyboard. Each switch from using the keyboard to the mouse or from using the mouse to the keyboard counts as one switch.

This raw data tells how often the user used each type of these mouse clicks. It does not indicate whether these were drag and drops or plain clicks (these are recorded in the mouse strain statistics and in the manual mouse drag & drop statistic).

Mouse distance is the distance the cursor moves on the screen and is a reasonable indication of how much the user physically moves the mouse. This statistic is most relevant when used to compare how a user changes over time or how they compare to another user with a similar pointing device. Because of differences in mouse drivers, mouse settings (e.g. acceleration, speed, sensitivity, etc.), and pointing device hardware, there is no logical way to provide an actual distance in a unit like feet.

This raw data indicates how frequent double clicks are for this user.

This statistic is an important indication of how much exposure a user has to straining mouse activity. One can compare this statistic to the number of mouse clicks to see what percentage of mouse activity is drag & drop (or selection actions). People with high ratios should be exposed to using KeyControl to do mouse-button-free drag & drops.

This statistic is an indication of how well the user is taking advantage of KeyControl to reduce strain associated with drag & drop. If the number is low compared to manual drag & drops, users can receive additional training in using the feature.

Used to measure compliance with a suggestion to use the AutoClick feature, this statistic can be especially relevant when looking at a group of Health Status Reports (e.g., to learn what percentage of some category of users use AutoClick).

This is an excellent indication of how much value a user is getting out of AutoClick as this is roughly proportional to the strain reduction that results from using AutoClick. If a user is using AutoClick but this number is not much higher than the manual left mouse clicks, the user probably needs additional training with AutoClick.

Used to measure compliance with a suggestion to use the remapping feature, this statistic can be especially relevant when looking at a group of Health Status Reports (e.g., to learn what percentage of some category of users use keyboard re-mapping).

KeyControl hotkeys can reduce strain associated with the action they are created to replace. Therefore, this statistic is a gross indication of the overall strain reduction the user benefits from by using KeyControl hotkeys.

DataLogger counts unique groupings of the backspace or the delete key on the keyboard. For example, if a user types: “erfonomic” and presses backspace eight times to change the ‘f’ to a ‘g’, DataLogger counts one error. This is because the user made only one error, even though it required several backspace presses to correct it.

DataLogger collects the number of words typed. The number of words a user types gives an indication of the type of work they are doing (e.g. textual entry vs. keystrokes in database fields). A new word is defined as a series of alpha keys followed by a space or the return key. Text writing produces high “words typed” values. Programming and text editing produce lower values. Keyboard shortcut work, tabbing, use of arrow keys, etc., do not contribute to “words typed” values. Speed is determined by dividing total words typed over total keyboard time. As a result, this is not a traditional “typing speed” measurement, because it includes all the time the user spends at the keyboard, even if they are not typing text.

Normally this statistic is only relevant for looking at a user over a period of weeks or months to estimate, for example, how many reports are filed per month or per year.

Back to Top

Overall Work Intensity Statistics

Back to Top

These values are a continuous collection of strain divided by the time over which the strain was accumulated. Although a snapshot of these values is recorded each day, the values are an accumulation over many days. When the values reach a threshold, they are divided in half, thus expiring some of the significance of older data. In this way, Guardian can maintain an understanding of a user’s changing intensity of use of the keyboard and mouse in a way that filters out the noise of short term fluctuations while still giving higher significance to more recent activity. This statistic (along with others) is used by the BreakTimer to help guide the timing of breaks. Specifically, this statistic ensures that breaks occur, on average, in a more evenly spaced manner.

This statistic takes the keyboard analysis tool’s keystroke intensity measurements for individual keys, and computes an average over all keys, to provide a general value for how hard the user is hitting keys. This statistic, however, can only be used as a relative measurement. If a group of users all use the same keyboard, then one can use this value to see who strikes their keys harder than others. If one can observe that a user pounds their keyboard, one can use this statistic to see if attempts to get the user to lighten up (e.g., using ForgetMeNot reminders) are working. See the Keyboard Analysis Tool description for additional details on this statistic.

Back to Top

Keyboard Analysis Tool statistics

Back to Top

This statistic tells, for each key on the keyboard, what percentage of keystrokes this key comprises. For example, a value of 2 for ‘A’ and 8 for the Tab-Key indicates that 2% of all keystrokes are ‘A’, and 8% are the Tab-Key, etc.

Since very few keyboards actually measure the pressure/intensity of a keystroke, this statistic measures the length of time a key is held down. A harder keystroke generally corresponds to a longer period of time during which the switch of each key is actuated. This allows one to see which keys the user is tending to hit harder or softer. This statistic is based on a principle that a harder keystroke will engage the key switch longer than a softer keystroke. Although this is not necessarily true for each individual keystroke, we believe it accurately corresponds to pressure over the course of hundreds or thousands of keystrokes. The reported value is in milliseconds (1/1000th of a second).

This statistic measures how long it takes a user to reach each key from whatever previous key they struck. The purpose of this statistic is still being tested, but the hope is that this can be used to help detect hand position on the keyboard as well as detect typing style (hunt & peck vs. touch typing). The reported value is in milliseconds (1/1000ths of a second).

An important note on the accuracy of recorded data:

DataLogger provides a precise tool for measuring computer use. For typical ergonomic purposes, the accuracy far exceeds what would normally be possible for a human evaluator. This information is provided for researchers who wish to understand the precise limitations of computer-collected usage information.

Guardian uses a hook into the Windows event system to count mouse/keyboard activity (also called "input events"). This event system is the same system that notifies each application that it has received input events. For example, when a user presses the 'A' key while in a word processor (e.g., Microsoft Word), the 'A' appears in the document because the event system tells the word processor that the 'A' key was pressed. Therefore, if an application responds to an event, it will be recorded under most circumstances. Even when no application is the target of an input event, the input event still passes through the event system and will normally be recorded.

There are certain circumstances in which the DataLogger would not detect an input event.

DataLogger will not record events:
1. If the computer is not on.
2. If the computer is on, but Guardian is not running (e.g., when the user is booting up, logging in, or if the user exits the Guardian program).
3. If the user is using software that bypasses the normal Windows system for input events. This includes all MS-DOS applications, but very few if any Windows applications. Therefore, it is important to determine if test subjects use any MS-DOS applications.

Back to Top

Privacy and Security Issues

Back to Top

Employees may perceive DataLogger as an invasion of their privacy because it effectively observes employees and records its observations. You and your employees might also have security concerns.

Guardian includes several features designed to assist with the management of employee information in a manner that is consistent with the employer’s privacy and security policy:

1. DataLogger collects data that describes the manner in which a computer was used, but does not offer any information about what specific work was done.

For example, a user playing who inappropriately plays a video game for several hours during the workday would show high strain values and lengthy time-at-work numbers. However Guardians focus is how a user is interacting with the keyboard and mouse NOT what they are doing on the computer.

2. DataLogger stores keystroke frequency information, but stores no information about the order in which keys are pressed.

As a result, this information cannot be used to discover what a user has typed. Computer users should understand that any application they use could potentially record keystrokes and store or transmit this information – however, Guardian does not do this. All detailed keystroke information is stored in the user’s “.kuf” file. This file is always 5,132 bytes, because it doesn’t store what a user types. It only contains: how many times each key on the keyboard is pressed; how many milliseconds each key on the keyboard is held on average; and how many milliseconds pass before the release of the previous key and the down-stroke of next key.

3. Guardian has basic protections to prevent a user from seeing another user’s usage data without a special password.

For additional security, we recommend that organisations have processes and controls (normally Windows file protections) in place so that DataLogger data is restricted to a limited number of employees who have a ‘need to know’, such as OH&S and HR staff. Employers should also clearly communicate to their employees how the data collected will be used.

4. Health Status Reports are one of the primary ways that an employee’s DataLogger data might be revealed to the broader organisation.

Users have the option when filing a health status report to check the “Exclude DataLogger Data” checkbox. If checked, no DataLogger data is sent with the report.

5. When Guardian is uninstalled, Guardian leaves the user’s configuration in the registry.

This information does not contain any usage data. Usage data is not deleted during uninstallation. You can manually delete all data by deleting the user’s “.tid” and “.kuf” file.

6. If an employee does not wish to have DataLogger data collected, a Guardian administrator can completely disable the collection of DataLogger data from the Admin page of the Settings screen.

Back to Top

Options for Accessing DataLogger Data

Back to Top

The most straightforward way to access DataLogger data is with the Guardian companion program, Guardian Reports. This program is automatically launched with the current user’s data when one selects “View Longterm Usage Statistics” from the “DataLogger Usage Statistics” item under Guardian’s Tools menu.

This program allows the user to view the graphs in three sizes (small, medium and large). In addition, the graphs can show the data over ranges of time from as short as one week to as long as one year. Finally, the data can be exported by clicking on the “Export Data” menu item in Guardian Report’s File menu. The data is exported in a comma-separated text format, which can easily be imported into a spreadsheet, database, or other data analysis tool.

Back to Top

Extended DataLogger Tools

Back to Top

The DataLogger system allows a program administrator to collect extensive ergonomic information about a user. This information is beneficial for determining causes of repetitive strain injuries and helping to identify individuals who are at risk of developing injuries. If the administrator’s research needs necessitate the collection of higher resolution data, the extended DataLogger tools may be helpful.
There are two features provided in Guardian that offer extended data collection possibilities.

1. Normally the DataLogger collects information about a user and records that information once per day. The extended DataLogger allows an administrator to record that information at an interval as frequent as once per minute. An administrator can also specify that the data be recorded between two points in time during the day.

2. The keyboard analysis tool of DataLogger collects information about how the keyboard is used, such as how frequently the user strikes each key. The extended DataLogger allows the administrator to specify individual keys for which one can collect a precise count of how frequently the key is struck, at an interval of recording as frequent as once per minute.

Unlike the standard DataLogger, the extended DataLogger does not have as user-friendly an interface. While it is appropriate for use in the research environment, it is not intended for use by typical end-users or in a typical organisation.

Back to Top

Enabling Extended Data Recording

Back to Top

To enable the recording of extended data, one must access the administrative page of the user settings. To do so, while holding of the control key on your keyboard, click the Tools menu of Guardian. Select the first menu item, Administrator’s Access. Enter the administrator password, ‘adminx’. Next, click on the Setup menu and select the Settings item. Click on the Admin tab and click on the “Data/HSR Settings” button. In the screen that is displayed, enter the start time and the end time during which you want the data to be collected.
The time is entered as the number of minutes into the day beginning from 12 midnight.

For example, 1 a.m. would be 60 because 1 a.m. is 60 minutes into the day. Likewise, 8:30 a.m. would be 510 (eight times 60 plus 30)
To record data 24 hours a day, you enter a start time of zero and an end time of 1440 (which is 24 times 60). .

Make sure you press the enable Hi-Res Data Recording checkbox. Data is recorded to the file xxxx-HiResData.txt, in the Data subfolder where Guardian was installed. xxxx refers to the Windows username of the currently logged in user.

If you also wish to collect extended data about how frequently a user is using particular key combinations, you will need to create a KeyWatch.txt file.
This file must be created in the same folder as the program file Guardian.exe.
It must contain a list of key combinations that you wish to monitor, one per line, and no more than 64 total key combinations.

The format for defining a key combination is as follows:

CASW###

C is 1 if the Control key is pressed, or 0 if it is not

A is 1 if the Alt key is pressed, or 0 if it is not

S is 1 if the Shift key is pressed, or 0 if it is not

W is 1 if the Windows key is pressed, or 0 if it is not

### is the 3-digit Windows ASCII keycode

Some common keys and their codes follow:

Key combination use data is recorded to the file xxxx-KeyWatch.txt, in the Data subfolder where Guardian was installed. xxxx refers to the Windows username of the currently logged in user.

Back to Top

Future Research Plans

Guardian DataLogger is a powerful research tool. Many of the statistics measured presently are being measured at the suggestion of current researchers in ergonomics, and there are future plans to collect additional data to meet the needs of other researchers as well as the needs of commercial clients. We will endeavour to provide new statistical features to help further the cause of ergonomic research. To discuss research opportunities with Guardian, or any other aspect of DataLogger statistics, please contact support@ergonomicoffice.com.au.

Back to Top