It sounds like you went through a tremendous learning experience.

How much did my test cost? Well, I “paid” Gavin with a packet of biscuits. And essentially I’ve saved probably 2-3 months of time that could have otherwise been completely wasted. That’s a pretty good ratio

“The more you learn the more you understand how little you know”.

Ain’t that the truth. Hopefully I’ll remember to design from the standpoint of complete ignorance from now on, realising that whatever I think I’m probably wrong.

I’ll be interested to hear your argument as to why paper wireframes should die and how this could apply to my project. I’ll keep an eye on your blog.

Thanks for a great comment and I hope to see you at TechMeetup tomorrow. I might be late, but I’ll try and get there.

Not so many years ago was doing web design in an agency where my process involved doing a quick sketch or two before diving straight into a high-fidelity photoshop comp.

I would always get worried about the point where I’d have to call my art director over to review my progress and endure some level of biting criticism of my design skills.

The problem with the situation was that after a few projects I was producing work with the sole objective of impressing the AD. Using visual techniques he favoured, etc.

Of course the reality was that the AD’s preferences were irrelevant, and the areas where we would focus attention would be of little concern to the eventual users of the interfaces.

Later I developed the knowledge that, as an individual designer, I couldn’t possibly understand how a user would interact with the pie-in-the-sky fancies we were building.

Fortunately I eventually got to the point in the organisation where I had the freedom to do some quick and dirty usability testing of my own. And I mean usability testing in the loosest possible terms… Basically just sitting an account director down in-front of an interface and watching him fail to succeed in completing even simple tasks.

As they say, the more you learn the more you understand how little you know. Many designers would take offence at someone questioning their design decision making, citing their education and experience as qualification enough. But I’ve learned that in order to achieve success it’s design research that should lead decision making – the skill of the designer is facilitating the use of techniques to uncover an understanding of the user. To an extent, letting the users design the interface themselves.

I think you made a great decision to sit someone down in-front of a prototype. How much would you say it cost to run the test? And how would you value what you learned in comparison to the cost?

I think rapid iterative prototyping is going to take off in a big way this year. In the last 3 months I’ve been involved in 5 prototyping projects, and all of them have been a fantastic success. I hope to finish a blog post soon about how I prototype with html/css/js, and how paper wireframes as a design tool have to die.

RE Closing and opening the project file – not sure what you mean here. If you came back to your desk, the moment you moved the mouse it would start tracking again and it would be tracking the document in the window that was active – so yes, if you were scrolling around, it would track that time to that project.

An ethernet enabled kettle sounds awesome. The perfect solution for knowing how long you spent making tea. Why don’t you invent this, then we can co-author a protocol to communicate with Lapsus?

Synaptic Mishap was my flatmate’s suggestion, as that seemed to sum me up.

But it’s true that Microsoft seemed to actually ask some people what they thought this time around. It’s just a shame they couldn’t have made in anything more than “not as bad as Vista”. Although that would have been difficult…

Thanks for your comment and sorry about the delay in approving.

What I want to do with Lapsus is more along the lines of getting the computer to intelligently decide what you were working on. It’s the computer that should do this hard work. Then the user can look at this and approve the data or adjust as necessary. I’ve got a target of 80% accuracy out of the box. That means the user will only have to enter data for 20% of the times. And the data entry will be really, really easy – almost enjoyable! And for that 20%, Lapsus should learn, so that a month after starting using Lapsus, the corrections should be few and far between.

I just can’t get excited about a time tracker that’s based around data entry. Once Lapsus matures I may well build in screenshots of windows, but it’ll be a nice extra, not a core feature.

Anyway, thanks for your comments. It’s useful to know that there are users who’d like a Mac version of TimeSnapper.

So it’s not so much “time tracking” as “time reconstruction” – you review the screenshots and log what you were working on.

It seems like a simple implementation that enables detailed tracking.

I find your comment

“I have trained myself to use an inadequate tool reliably…”

particularly interesting. That’s exactly how I feel about all those people who have trained themselves to use a timer. And I’ve heard many more who tried to exercise that discipline and failed. Understandably, many of them actually feel bad about themselves, and see this discipline as the only way they’ll ever be able to keep track on where their time is going. It can be really hard to remember where a timer is at. And it shouldn’t be this hard to track your time.

This is a failing with technology, not with the people.

I’m really hoping my implementation can remove this pain. Thanks again for your comment.

So anytime you have something that is remotely usable, I’d use it as a supplement until it is functional and stable enough to do more.

As you can tell from my comment I really do want to do my time tracking this way. I have trained myself to use an inadequate tool reliably but could benefit even from having the extra perspective to check against. So don’t hesitate to use me as an alpha subject.

Apple have brought us some brilliant little changes to the interface over the years but these have been only little. We need a new environment to develop for!

A truly 3D environment with new ways of interfacing with the screen such as multi-touch would really allow companies to innovate with their applications in a whole new way.

Thanks for the interesting slide, have bookmarked it on Dzone
http://www.dzone.com/links/how_to_build_desktop_apps_that_help_your_web_app.html

Anyway, thanks for commenting. I’ll follow your project with interest.

http://reboltutorial.com/blog/rebtweeter-firstproject-vision-draft/

1. It’s only used amongst developers – you won’t hear anyone in other industries boasting about failing.
2. It’s become so commonplace it’s started to become a cliché. Even though clichés are true.
3. It applies well to iterative processes, but less so to anything else.
4. It could be argued that learning from failure is overrated.
5. There’s some difficulties in a mantra that sounds like you’re aiming for failure.

I’m not sure it’s ever appropriate to aim for failure – what I was arguing for instead was to expect failure. If I’m not surprised when it happens, it’s much less of a drama. That will mean I focus properly on the fix. That will mean one mistake will be less likely to lead to others.

I think there’s another post in this. Thanks for your comment, Iain.

Thanks for your comments. You make some really good points here. The counter argument that could be made is: “Things will get better and eventually everyone will have cheap, great internet access.”

These kind of arguments seem to assume that somehow the advancement of technology to a certain minimum standard everywhere is inevitable. I’d argue that although things will get better over time (obviously), certain areas of the world will always be in front of or behind the technology curve.

When making bold claims about the future, we need to remember that a massive chunk of the world’s population still doesn’t even have access to a computer.

Of course you have your own agenda – that’s totally expected and understandable. As I’ve said in my earlier comments, I too have my own agenda which I’ve obsessed over for rather a long time now – I’ve had this idea in my head for the last 5 years, all the time thinking “someone else is bound to do this soon”.

You make a very good point about my app not being able to track tasks. It certainly won’t do this in version 1, but in some far flung future version it’s a feature I’m really keen to add, as it would complete the circle with the GTD methodology. It could look at tasks entered by something like Things or iCal and allow you to assign certain key words to certain apps. I could talk at length about my ideas for this, but it’s a long way off and I’m in danger of talking about features which may well never see the light of day, but hopefully you get a sense that I’ve got loads of ambitions about where I take the app after basic functionality.

Thanks for your comments and I certainly will let you know when something’s ready to be Beta tested. Meanwhile, I’d better get back to coding…

Regarding the Spaces idea, this plan appeals to me because I wouldn’t have to change the way I work that much. I already use Spaces to split off different projects. I usually only use about four spaces at a time – one for email, one for procrastination, and two or three for open projects. The first two are always in the same spaces so that’s easy. The others I swap out all the time. At the end of the day, or twice per day, if I could review my “time sheets” in this new app, it wouldn’t be hard to tag each space with the project I have been working on. A project may be in space 4 one day and space 3 on another but it’s not likely to change during the day.

Personally, I’d like something really simple and then use that to augment my “real” time tracking system (Harvest). Harvest records tasks and projects and people, this other app would track total time in front of the computer (including procrastination) and give me a macro view of how I’m spending my time. I don’t think Slife or your app could very easily track “tasks” as well as projects so this couldn’t be a total solution. But if I knew that between noon and 3pm I was sometimes working on a specific feature I could look at the time I spent in that project’s space and see right away exactly how much cumulative time was spent on that feature, then enter that into Harvest.

Obviously, if you don’t like using spaces, my idea wouldn’t be very useful. I hope I don’t sound too discouraging, I totally agree that time tracking should be automatic and shouldn’t require turning timers off and on. I just have my own agenda .

There is a huge need for something like this! Please let me know when the software is ready for testing, I’d love to try it out.

I’ve tried slife which sounds like the only time tracker out there like what you are building. I really wish you the best success for this. I’m just a little pessimistic about the “automatic” nature of this. It seems like it would take a lot of work to teach the software what software/urls/folders are for what project. The speed at which projects come and go would seem to make that process never-ending.

Yes, you’re right, Slife and RescueTime are two of my closest competitors. I can totally understand you being pessimistic about how realistic my goals are. I’m the first to say that this is a very ambitious project, and even I am not 100% certain I can pull it off. However, I am confident I can get a lot closer to a low friction system than anything else I’ve tried.

In terms of the amount of work to keep the system working, I’ll address your 3 items individually – software/URLs/folders as I think you’ve broken them down perfectly.

1. Folders

You’d be able to have individual project folders which would be tracked for open documents as I’ve mentioned in my previous comment. You’re right to say that this means every time a project is created, this would have to be added to Lapsus (the name of my time tracker). This would indeed be a hassle. I have a trick up my sleeve for this – as well as project folders, you could add a project container folder. This would be a folder which held all your projects of a certain kind – e.g. Graphic Design projects or Web Design projects. This would then track any project within this folder. This would mean any time a project was created Lapsus would start tracking with no action required.

2. Software

Any non document based app would come under this category. So software like Mail, iTunes, Address Book, iCal, iChat, Daylite etc etc. From a business perspective, I think most of these apps would either be unproductive, or could be categorised under Overheads – Contact and Calendar management being two of the most obvious examples. Lapsus would come with a built in Overheads project which would track these kinds of interactions.

However, there are examples of apps like Mail which could be used in a productive context. To cope with this, I’d use a system of plugins that could be developed by anyone. The plugin would gather some information on which to base the decision of what project to assign the time to. For example, the plugin might ask iChat via Applescript what contact the user is chatting to. Each project would have a group linked to it in Address Book. The contact would be looked up in the Address Book and if that contact belonged to a specific group, it would assign the time chatting to that contact to that project. This is, of course, pretty advanced stuff and might not be in version 1, but it’s totally feasible with the technology. In the example that Zach gave below, there would be a plugin for the Terminal to detect when the user is sshed into a specific IP or URL. This parameter would then act as the key which could be associated with a project.

3. URLs

This would be the most difficult aspect to get right. I don’t expect to fully nail it on version 1, but I’m confident I can make significant improvements over current systems. The software will guess at what project the user is working on, using a complex series of rules behind the scenes. These rules would take into account things like what search terms were entered into Google if doing a search, what links were clicked from which page, what URL the user was looking at and what the last productive project was and a predefined list of URLs that were likely to be productive or unproductive.

The key element that defines success or failure, I think, will be the interface to change any incorrect guesses. My aim is to provide the checking of guesses alongside the reviews of time that the user would want to do anyway. I’ve already put an awful lot of thought into this part of the interface and I’ve not committed any pixels to the screen yet. Once the user corrects incorrect guesses and tells Lapsus “all the guesses you have made are correct”, these URLs will be remembered for next time. And I’m hoping that the project container system will mean certain URLs can be remembered for types of project, which means that when a new project is created, it will inherit all the URLs associated with that kind of a project. So stackoverflow.com, for example, would be associated with Programming Projects. When stackoverflow.com is visited, Lapsus would decide what project within Programming Projects would be most likely for the user to have worked on – this would be a combination of recent projects and time spent in a project. It would automatically choose the most active recent project to assign the time to.

Here’s my dream time tracking app idea. It’s dirt simple. The application would track time spent in each Space on OS X. It would be up to the user to ensure that the projects they’re working on are segregated into individual spaces. The app would not just track the Space number but the apps used within that space and, when possible, the files accessed. But that information would only there so that if the user forgot what he/she was working on in a particular Space, the app list might provide some clues. I’d have be sure to diligently keep my projects separated, but that’s all it would take to track my time.

I’d love to hear what you think of this idea. Perhaps there are technical limitations preventing this sort of thing, but it seems like it might be easier to build than something like Slife.

It’s an interesting idea and I totally agree with your sentiment – this sounds a lot easier to build than what I’m going for. However, my focus with this project is not to make an application that makes my life programming it easy, but that makes the users life easier. There’s far too many applications saying “hey, if you want me to work for you, you need to change the way you use a computer”. I’m obsessed about making a app that lets the user do what they normally do and still providing value. If I didn’t have a problem with users changing their workflows to suit an application, I wouldn’t be making the software at all and I’d be happy using a stopwatch system.

Your Spaces system at first sounds attractive, but on further consideration I see some aspects that would drive me round the twist. First, there’s the simple fact of how you remember what’s in each space. If projects are being churned out every few weeks, this could get pretty confusing pretty fast. You might just get used to remembering one Space was for a project, then it would be gone and a different project would take its place. They say it takes 28 days to make or break a habit. In the computer world it’s less, but it still takes significant time for my brain to remember something like this. There’s a risk you could end up doing a “Spaces crawl” – a bit like the pub crawl but with more dizzying, stomach churning animation and less alcohol.

Then there’s the huge issue of window management. In my opinion, current window management solutions are pathetic. I really hate having a jumble of windows over one another with no snapping, tiling, proper maximise or the ability to set up a saved workspace. And I’m afraid to say I think your system would make it even worse. I think you might spend half your time moving windows from one Space to another. Then there’s the issue of having different documents in the same application in different Spaces. This would be really confusing. For me, anyway.

So in summary I still think my system can be done. That’s not to say it’s going to be easy. And I’m still skeptical about the feasibility of it all, and I’m building the thing. But I really really want to have a go at building a truly next gen time tracker and now’s the time to do it. One last thing – when I think of the task ahead of me, I do wonder if what I’m aiming for is possible. But then I think of all the information my computer knows about what I’m doing. It knows an awful lot about what I do, and I’m hesitant to say that all this information cannot be tapped to provide an intelligent time tracker. It may well be pretty dumb in version 1, but I know that personally I’d rather have a dumb tracker that at least captures the time I work on my project documents reliably than any stopwatch system on the planet.

Thanks for your suggestions and interest and I’ll let you know when the software is in Beta so you can decide for yourself if it can be successful.

Also, I really don’t care about exporting this data into other apps. I use Harvest but whenever entering time into it I need to tweak it anyways. Imported time would still need to be gone over manually.

Here’s my dream time tracking app idea. It’s dirt simple. The application would track time spent in each Space on OS X. It would be up to the user to ensure that the projects they’re working on are segregated into individual spaces. The app would not just track the Space number but the apps used within that space and, when possible, the files accessed. But that information would only there so that if the user forgot what he/she was working on in a particular Space, the app list might provide some clues. I’d have be sure to diligently keep my projects separated, but that’s all it would take to track my time.

I’d love to hear what you think of this idea. Perhaps there are technical limitations preventing this sort of thing, but it seems like it might be easier to build than something like Slife.

Thanks for your comments. The aim is to evolve into a product that does what you describe. Of course, I’ve got a little bit of expectation management to do here – it wouldn’t be able to do what you describe on version 1 out of the box. Version 1 tracks URLs and document paths and wouldn’t have any other way of knowing what you’re doing, so it wouldn’t track commands you enter from the terminal. However, depending on the uniqueness of the URLs you are visiting in Firefox, it might track these. The app allows you to review your day or week. In this review, you can tell it that the time on page X was for client Y. Then it will remember this for future. This is how it knows what is for what client, but you’ll only have to tell it once.

In the future, I have plans for some pretty advanced automation to inform the first guess – if you had a project in Basecamp with contacts attached, or if the contacts for a project were in your address book, it would try and decipher a company name from the URL or the contents of the page you visited, then look at what project this company was associated with.

But this is all pretty far off – version 1 would concentrate on the basics for GUI users. The system would require a little setting up – you have to tell it where your documents are for project X, but this would be a 3 click process. And for URLs as I’ve said, you would need to check the guesses the software makes on a regular basis, but this would be integrated with looking at your results and you’d only have to tell the app once – it would then remember.

One of the things I have planned for version 1 is a plugin architecture. You would be able to write plugins for any application that is a non-document application (apps like Address Book and, oh, the Terminal). The point of the plugin would be to provide something my app can associate with a project and would provide this using scripting. The details of this are sketchy in my head at the moment, but it might be possible to track the time you spend between certain terminal commands by running a search of the bash history…

The principle behind my app would be to take all the information available and interpret it to get meaningful time data and to do this all in the background. Therefore, on an abstract level, the only barriers to this would be that the information required to make a decision was not available, or the interpretation was just too hard. And what your describing in the terminal sounds like it would be challenging, but possible as the software evolves.

I want to make something that’s far more intelligent than any software I’ve seen. I’m expecting the barriers to achieving this to be substantial, otherwise why isn’t anyone doing it now? But I have some ideas on how to achieve a basic level of intelligence by doing some pretty simple things, and I’m mocking up a really rough prototype now to test my ideas as I keep thinking that what I’m trying to do isn’t possible for some reason I’ve not thought of. If having a basic level of intelligence to track time is as easy as I’m thinking, I’m puzzled why it hasn’t been done long ago. There may well be something I’m missing.

Anyway, enough of my gibber jabber. Thanks for your feedback – it’s nice to hear someone say “If it could do X and Y, then I’d buy it”. It proves that there’s a need. Now the only question is “Is it possible?”. Which I’ll find out shortly. I’ll keep you updated – I should know whether there’s a future for the idea in about a month.

John.

I’m concerned that it would have to be very very smart to be effective. For example, how would it know which client I’m working on when I’ve got X11 up and I’m ssh’ed into a box and I su from one user to another? Does it track that? Or when I’m in firefox and four tabs are for one client while another is for a second client… how does it know? If it solves those problems unobtrusively you’ve got a goldmine on your hands.