TimeClock notes

Some longer notes from an Associate Professor in HCI. Emphasis is mine.

Last update: Wednesday, 02-Apr-2014 22:09:42 EDT

Here is a set of random notes for the TimeClock system. These are based on quick observations by a faculty member that teaches CS 5714 Usability Engineering here at VT. BTW, this particular course was one of the first of its kind in Academia in the US and has been taught in recent years by 5 or 6 different current faculty in our department. From the professors that have taught this course in its history, there are 4 book authors (in the area of HCI) with at least 6 books. But more importantly, there are at least 3 books in the area of Usability Engineering that have come from professors in this course. We have a fair amount of collective knowledge in this area.

The worse problems in the use of TimeClock were pointed out by C., S., and others. The match from this system to the use for undergraduate research and UTAs is awful. Neither one of these tasks are done on an "hourly" basis and worse, the "managers" don't care or know when the work is performed. If the UTAs grade the exams/assignments, we are happy. If the undergrad researcher prepares the poster and does the work, we are good to go. When it is done is irrelevant, so our "verification of hours" is really a "blindly press a button, please."

But there are other problems too, here are some:

1. Mental Models - people use systems by having preconceived ideas (mental models) of how systems work and applying those ideas to new systems they encounter. TimeClock breaks many basic mental models of how computer applications work. Here are a few:

   1. the website, http://timeclock.vt.edu only works for employees that are using the site to keep track of their hours. Managers and others have to go to http://timeclock.vt.edu/menu/. People expect that all websites be navigable from their root (timeclock.vt.edu) down to subparts of it (/menu). This website does not work that way. Particular users must go directly to a subpart of the website to be able to use it.

   2. "edit hours" vs "approval manager" are the only two options I need to use to approve the hours of the undergraduate that I supervise. I am not sure what the difference is between the two, but when I login every two weeks to "approve my student's hours", "edit hours" is not the option I think off. "Approval manager" is a bit closer but still not clear. And the fact that these two are under a menu labelled "Employee," makes this very confusing. The information architecture of this site is a great example of what NOT to do. BTW, the right choice is "edit hours."

   3. Most programs with a "File" menu have new, open, save, close, quit, inside. This program, TimeClock, does not have "documents". I cannot create a document and save it. Instead, the file menu has an "Import" command which when selected does nothing (why isn't it disabled?) and an "Export" with about 7 subcommands, most of which I have no clue what they are.

2. Fixed layouts in today's large displays are a waste of screen real estate. TimeClock has a fixed screen size that makes my large monitor be a waste of space. It requires extra navigations (scrolling) when I have plenty of space to see long lists in my monitors. The crazy thing is that it takes extra programming to build something of a fixed size. It is harder to do than to just let an app use the whole browser space.

3. Applications like TimeClock that are used infrequently often have an interface style that is more driven by a dialogue (Q&A) rather than a point and click menu system. The style of TimeClock is typical of day-to-day productivity applications where users spend hours in it and thus memorize many of the menu locations. Applications of infrequent use, however, cannot rely on rote memorization (or procedural knowledge) for identifying where things are. I literally use one menu item every time I have to approve hours for my one student. One menu item. Remembering how to get to that menu item is hard (infrequent use) and I often spend longer time finding the right command than doing the task itself. The interface style should provide a more guided approach (Q&A) similar to that used in tax preparation software.

4. From a distributed memory and distributed cognition point of view, this system is basically playing "guess my number" with me. It has menus, upon menus. Labels that are cryptic and meaningless (at least for me, a faculty with one undergraduate doing research). Instead of helping me reach my goal (approve the hours for my student), the system sits patiently waiting for me to do something... what I don't know.

Other problems:

• terminology is system centric and vague... "employee" for example, refers both to me (I am an employee) and to my student that I am paying for undergrad research...
• navigation for a web application is broken (the back button is disabled)
• error messages are cryptic... "You are not recognized as an employee" Really? Last I checked I was getting paid and under contract by the university.
• double click in web apps is infrequent (if you don't count banner, that is, another gem from a usability perspective)

Finally, twice now we (CS) have proposed to the university that they should create an office of User Experience. We currently have a security office that checks systems for security, advices the university on policy issues, and assesses products that we are considering for purchase. Now consider the same office but instead of Security, Usability. We have suggested that the university create an office that would: a) evaluate products before they are purchased so that we make sure that we are easy to use; b) evaluate existing systems and suggest improvements; and c) help design easy to use systems that are being built internally. The first time the proposal was ignored, no response. The second time, we heard indirectly that there is no business case for usability. Measure all the hours we are wasting in using this software and now in complaining and the cost of using this far outweights its benefits.