My phenomenally bright and talented friend Nathan Peretic, of Full Stop Interactive, recently got caught up in a fit of uncharacteristic zeal and described Stone Hill Time Card as “a flawless time tracker.”
The contrarian in me bristles at such all-or-nothing language, but I swear that’s not why I’m writing this post documenting the flaws I see in Time Card—or at least, the ways in which the software seems not to be designed for me.
I’m writing this because I started to leave a second comment on Nate’s post, then started to compose an email to the developers, then decided to write the whole thing up here instead.
I want to admit quickly that TimeEdition, which I will continue to use, does crash too often, for example (though I haven’t lost any data), and has interface oddities like a mostly invisible, wholly undocumented AM/PM selector that can take days, nay weeks to decipher. I’m no fanboy, or whatever “fanboy” is in German, the native language in TimeEdition’s place of birth.
But I digress. As I mentioned in my comment on Nate’s post about Time Card, there’s a lot to like, and Nate covers that topic so well I won’t rehearse it here. In the comment, I go on to point out what I’d thought was “the one dealbreaker for me”: the lack of ability to specify separate projects for the same client.
Nate describes Time Code’s primary point of interaction—the “What are you working on?” field—as employing a magic ‘task for project’ syntax, though the help file suggests it’s actually intended as “task for client.” Either way, the lack of ability to specify both project and client for a given task—and to have that specification backed up by a data structure (just as the stuff that comes after the word “for” currently is”)—seems like an oversight.
It could be that, as a freelancer who works largely with agencies, I have a greater need than many to specify different clients as well as different projects. Still, I’m not the only one, and it seems to me that anyone who gets repeat business—either working on staff at an agency or freelancing with “direct” clients—would have the same problem I do.
As I acknowledge in my comment on Nate’s post, there are obvious ways around this problem, like creating and using your own syntax (e.g. “task for project—client,” “project: task for client”), but again, without the data structured behind the scenes, I can’t see using Time Card.
Here’s another issue: When I leave whatever coffee shop or ’40s-themed cocktail lounge I’m working in, I’m often in some kind of hurry, and sometimes I forget to stop my timer. Likewise, at home, I sometimes take a long phone call or have to change my work plans when I’ve just stepped away from my computer for a few minutes, and then I don’t typically go back to my machine to stop the timer. So I regularly have to edit entries after the fact.
In TimeEdition, editing an entry means editing start and end times—easy, since that’s pretty much how most humans keep track of their days. In SHTC, editing an entry means editing start time and duration (in minutes), which seems a needlessly complicated way to go. I’m not into having to figure out how many minutes have elapsed between the time I stopped working and the time I stopped my timer—some number of hours, typically—or how long I worked for based on. That’s the whole reason I use a time tracker to begin with: so I don’t have to do that math. Not that it’s running derivations or anything, but it’s some amount of hassle that I want to avoid.
As an aside, I can’t figure out the use case for the start-time/duration model. Somebody who just needs to fit their schedule to their budget or something? Seems a little shady to me, though it’s common enough in agency environments. And again, I’m probably missing the real purpose of this particular design.