TimeScapers and TimeRank retrospective

I don’t like the term post mortem that much. Also, there wasn’t really much more than an interesting prototype and a group of beta testers at the end of our TimeScapers adventure, so I will just call this story a retrospective rather.

TimeRank? TimeScapers? What?

In 2011 and 2012 Gerwin de Haan and Charl Botha (that’s us!) set out to test an idea they had:

Would it be possible to take all of your tasks and your calendars, and then automatically schedule those tasks around one’s appointments according to priorities and deadlines?

In short, we wanted an automatic system that could tell us at any given point in time what the best thing was to take on next.

We had to build a web-based task (todo) system first, which we did in a few months (we had day jobs also!), and then we implemented the computational core that was able to solve this task-based constraint system. TimeRank was what we called both the system as well as the technique for the automatic scheduling of work. You can read the manual for more detail on the whole system. Screenshot1 shows the project/tasks screen and the deeply integrated pomodoro-like WorkUnits, and screenshot2 shows the planner output with automatically scheduled task sub-units in a calendar view. TimeScapers was the name of the company we formed.

Technically, the idea worked. Based on live Google Calendar data, and all of one’s tasks and time estimates (based on WorkUnits / pomodoros), TimeRank was able to generate, at the drop of a hat, a complete 3 month calendar, fitting in all tasks around all calendar appointments and configurable free time, hitting all deadlines and taking into account task and project priorities. If anything changed, you could just hit the “plan” button, and it would present you with a brand new planning!

Pretty cool right?

We ended up with an interesting technology prototype, about 30 beta users, but no real business plan or business mojo. Also, although the beta testers we chatted with also found the idea of an automatic scheduler intriguing, there were no real champions. Furthermore, at that point both of our day careers had taken wildly different and exciting turns, so on June 5, 2013 we decided to put TimeRank and TimeScapers in the freezer.

We still think the idea is interesting. :)

Tweet us (@gerwindehaan or @cpbotha) or email us if you’d like to chat about this or anything else!

Work in different time zones? We got your back.

During the weekend, a new version of TimeRank was rolled out to the server.

Since the previous roll-out on April 23, the following improvements have been made:

  • We are now 100% time zone capable. Even if you have different Google Calendars each in a different time zone, and you fly from one time zone to the next, TimeRank won’t drop the ball. Please make sure that your time zone is configured correctly in the preferences. When you do need to switch time zones, it’s important that your computer knows in which time zone you are (this affects the display of most dates in TimeRank, and in all other software on your system of course) and that you also configure the time zone in the Time Rank preferences (the Planner needs this).
  • We’ve upgraded a number of important internal libraries.
  • The date parser has been further improved. You can now write for example “tue at 5pm”, and it will set that deadline for 17:00 on the first Tuesday.

That’s not a very long list, but the time zone capability was quite an undertaking, and the internal library upgrades also led to significant restructuring. We are very happy with the results however, and can now continue building more features again!

Week 16 TimeRank update

I have just rolled out a new version of the software to our server. The following improvements have been made since the previous release on April 15:

  • The TimeRank planner now takes into account project importance when scheduling tasks. This means that tasks belonging to projects that you’ve sorted high in the list (by dragging and dropping on the Projects & Tasks screen) will now be scheduled as early as possible. More simply put: the planner makes sure you get around to things that are important to you, and not only things that are urgent. We’re still workin on this algorithm, so let us know what you think!
  • The planner screen has been improved: The controls can be hidden, and the calendar fills the maximum width of your browser until you activate the task detail screen by clicking on a scheduled block of time. This can be hidden again, at which point the calendar will fill the width again.
  • Google Calendar authorization handling has been made more robust.
  • On the tasks and planner screens, the task detail view also shows a clickable link to the project to which the task belongs.
  • WorkUnit duration can now be easily edited also on the Projects & Tasks screen.
  • Fixed a bug where editing task or project fields could break if you navigated to another project mid-edit.

Thanks for all your feedback so far. Please keep the suggestions and feedback coming!

First ever TimeRank released!

Dear users,

With great pleasure I hereby announce that we have just made the first release of the TimeScapers system under its official name: TimeRank.

As you might have noticed, we have been hard at work these past weeks on the TimeRank Planner, unique functionality of our software that tries to make educated suggestions on when you could consider doing which of your tasks. The version we have just deployed is still an early one, but does give an impression of what we have in mind.

Here’s a summary of all the changes since our previous deployment:

  • The software has  a fancy new name. The company is of course still called TimeScapers.
  • Early beta version of the TimeRank Planner. This also replaces the calendar view.
  • Project and task editing interface has been improved, crushing many bugs in the process.
  • The project detail interface now shows and allows you to add project-related workunits, analogous to those in the task detail view.
  • The Now! screen is now simply called Tasks. It has been visually improved, but is also up for revamping in the coming weeks.
  • The preferences editing interface has been simplified. It still has one known problem: It’s not yet possible to change your email address. Our preferences editing interface expert is looking into this, it has to do with some more fundamental functionality we still have to implement.
  • Many bugs fixed, thanks to feedback from many of you.

We have the following new features planned for the coming months:

  • More intelligence in the Planner, adding the ability to take into account importance and also your preferences.
  • A reporting module, so you can generate all kinds of fancy graphs and analyses of the work that you do. Personal analytics FTW.
  • A mobile app. We’re initially aiming for Android and iPhone, and we’re dreaming about voice recognition for task addition.
  • Many more usability improvements and bug fixes.

Thank you very much for your feedback up to now. We have tried to take care of as many as possible of your suggestions and bug reports. However, there are still some of your suggestions on the product backlog. Please do keep the feedback coming by sending mail to info@timescapers.com.

Yours sincerely,
Charl and Gerwin

Netherlands second-most efficient European country

In a recent post on The Guardian’s Data Blog, the statistics concerning average hours per week worked and productivity per hour (efficiency in other words) are visualized and compared. We are happy to see that The Netherlands, home of TimeScapers, spends less than the average number of hours per week at work (40.9), but in terms of per-hour productivity performs second-best in Europe (36% better than the EU average), bested only by Luxembourg.

Inbox Zero: No hype, just a clever step towards efficiency.

Inbox zero, a term coined by Merlin Mann of 43folders.com, refers to the state where your inbox is completely empty, implying that you’ve in some or other way taken care of all of the emails in there. Due to the increasing volume and real-time nature of email, some have claimed that inbox zero is not practical, that one should not waste one’s time trying to attain or maintain it, and that it is essentially a hype. This opinion is reflected by the fact that many people use their inboxes as complicated todo lists.

inbox - by Nigel Mykura [CC-BY-SA-2.0 (www.creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons

In spite of managing multiple email addresses over two high-volume inboxes, working in an environment where email is considered to be the primary form of communication and by the nature of that work having to have continuous in-depth email contact with numerous persons in parallel, I would like to make the case for attaining and maintaining inbox zero.

In this scenario, you process new emails at regular intervals (this could be once, or a few times per day), reading each email, deleting if it’s not relevant, processing it immediately if that’s possible in a few minutes (do), delegating it if it’s meant for someone else, or extracting actionable tasks from it and putting them in your todo system (defer). My reasons for advocating this are all pragmatic, and boil down to the observation that having no email in your inbox is the best way to deal efficiently with all the work that incoming email represents:

  1. Your mailbox was not designed to take care of deadlines, priorities and ordering. In contrast, most good todo systems are. In a todo system, you have much more flexibility, and are in fact encouraged to make use of this flexibility, in deciding which tasks will get processed when, how urgent they are and how important they are. Even the best mail systems are woefully inadequate in this regard. Even more simply put, emails are not exactly the same as tasks.
  2. With email, the sender of the email obviously determines the subject and content of the email. There are no real rules for this. This is obviously fine for email, but it’s completely silly for tasks. Each email potentially represents a number of different tasks, all of them hidden in the free-form text of the email. In a task system, these emails have been broken down, by you, into a to-the-point description of the actual activities that you need to undertake to address the request of the email sender. It makes a lot more sense that you formulate your planned actions, instead of a group of miscellaneous email senders.
  3. Related to the previous reason: Every morning as you’re scanning through your inbox, you’re wasting time re-scanning the emails from the days before, re-analyzing each email, possibly re-stressing at the contents and re-remembering what it was that you needed to do to in response. If these had been broken down and put into your task system, you would waste no unnecessary time again spending mental energy on them.
  4. It’s somehow less daunting when you open your email to find 10 completely new emails in an otherwise empty inbox, than it is to find those same 10 emails added to the 100 that you already had in there.

It certainly takes time keeping one’s inbox empty, but there are significant overall savings to be made in terms of personal efficiency, especially in terms of the time that can now be spent on the more important things, instead of something that’s been fished from an overfull inbox. In order to maximize this advantage, email processing itself should be performed as quickly as possible. What helps greatly is trying to make the per-email delete, do, delegate, defer decision as quickly as possible.

We would love to hear about your email-handling experiences and strategy in the comments!

Programming: A concise tutorial on django-nose-selenium.

So you’d really like to perform integration testing on your Django site, to exercise the whole stack right from the client-side Javascript through to the database at the backend. There are a million ways to do this, but only a few work. Of the few that work, none have a fully worked out example showing you how to get them up and running. Enter this blog post! In this, I’m going to show you as compactly as possible how to get django-nose-selenium working on your Django 1.3 test setup.

First install the necessary packages. I use virtualenv (you should do), so that means:
pip install django-nose
pip install git+https://github.com/weluse/django-nose-selenium.git
# we’re going to use the cherrypyliveserver
pip install CherryPy
Better yet, add these to your pip requirements file.

In your settings.py file, make the following modifications and additions:
# so that "python manage.py test" invokes django-nose-selenium
TEST_RUNNER = ‘django_nose.NoseTestSuiteRunner’
# should match SELENIUM_URL_ROOT which defaults to
‘default’: {
# TEST_NAME is absolutely CRITICAL for getting django-nose-selenium
# going with sqlite3. The default in-memory breaks everything.
‘TEST_NAME’: os.path.join(project_path, ‘test_sqlite.db’),
# this HAS to go after ‘south’ if you have that in your INSTALLED_APPS

Most importantly here, if you’re using sqlite3, is to specify TEST_NAME. If you don’t do this, Django by default uses an in memory sqlite3 database, and this breaks in infuriatingly mysterious ways, for example yielding “DatabaseError: no such table: django_site” or the same for “django_session”, while you can see that the test framework is creating those tables. After hours of frustration, I stumbled upon this important tidbit in this django-nose-selenium issue report.

Now you can start writing tests! Below is an example, which lives in project/app/tests.py, that loads up the front page, and also tries to log in. You can use the selenium IDE (firefox extension) to generate the Python exercise code you see below. I’m also making use of selenium_fixtures to load in two users into the database (the fixture itself is shown below this example):

from django.utils import unittest
from noseselenium.cases import SeleniumTestCaseMixin
from the_project.the_app.models import User

class TestSelenium(unittest.TestCase, SeleniumTestCaseMixin):
# this fixture adds two users: admin/admin and test/test
# this data stays in the specially created test DB for the whole run!
selenium_fixtures = [‘test_data1.json’]

def test_ok(self):
""" check that the front page has correctly loaded
and that there’s a login link.
sel = self.selenium
self.failUnless(sel.is_text_present("Login to System"))

def test_login(self):
"""Test that the user can actually login."""

sel = self.selenium

sel.type("id=username", "test")
sel.type("id=password", "test")

self.failUnless(sel.is_text_present("Logout (test)"))


I generated the fixture with the django dumpdata command. It exists as project/app/fixtures/test_data1.json and it looks as follows (one of the two users removed for brevity):
"pk": 1,
"model": "auth.user",
"fields": {
"username": "admin",
"first_name": "",
"last_name": "",
"is_active": true,
"is_superuser": true,
"is_staff": true,
"last_login": "2011-08-27 01:02:53",
"groups": [],
"user_permissions": [],
"password": "sha1$0faea$31f62ca99c405cad9cbe0bd469baeb8b3b6b923c",
"email": "admin@admin.com",
"date_joined": "2011-08-27 01:02:37"

Once all of this has been setup, first startup the Selenium RC server as explained here. In short, download from here, and invoke like this:
java -jar selenium-server-standalone-2.5.0.jar

Then, finally, invoke the tests as follows:
python manage.py test –with-selenium –with-cherrypyliveserver –with-selenium-fixtures

–with-selenium specifies that selenium tests should be executed, –with-selenium-fixtures that selenium fixtures should be loaded and cherrypyliveserver that the CherryPy multi-threaded webserver should be used instead of the built-in django one that’s not really multi-threading ready.

Let me know in the comments if this helped, or if I need to add or fix anything.

P.S. I also wasted a few precious hours with django-sane-testing. Fixtures didn’t work, python manage.py test didn’t work in spite of having correct TEST_RUNNER configured, and it also didn’t serve static files. It also complained about django_session not existing, so it could be that specifying TEST_NAME there might help for that bit.

Programming: Fix for cancel button weirdness with jQuery Jeditable onblur=submit

Jeditable is a great jQuery plugin for when you want to do those neat HTML text fields that turn into input boxes when you click on them, almost like the fields in the GMail contact editor. Whilst working on our all-singing and dancing super interactive web-based time-management tool, we ran into a bug with tho onblur=submit mode of Jeditable. In this mode, clicking anywhere outside of the dynamic input box submits the text. However, clicking on the cancel button would cause a full page reload, something that is less than desirable for highly-interactive single-page HTML apps.

We fixed this bug with a smal patch that you can download here. The fix very simply sets an attribute on the form when the user presses the cancel button. In the blur event handler it checks for this variable and does NOT submit if it’s set.

I also posted a comment concerning this on the Jeditable website.

If this by any chance helps you, pipe up in the comments! We’ll be posting more of these little tidbits in the future.

Beating the Meeting Monster

Ideally, we would have a system or a tool that would unify the scheduling of meeting and of tasks, that is, the actual work that needs to be done. As it is, however, task management systems and the calendaring software that is used to schedule meetings are two separate entities and usually don’t support the most minimal coordination. This often means that you just keep on planning meetings as long as your calendar still allows it, at the same time burning the time that you need to get around to your tasks. In other words: Meetings, although they can be useful, are productivity killers.

The Arctic Council observers meeting 02

Until our systems are able to unify task and meeting scheduling, here’s a simple but golden tip to minimise the detrimental effect of meetings on your productivity. Make the deal with yourself, and as many as possible of your colleagues, that you only schedule meetings in the afternoons. This is hard at first, especially because you sometimes do have to (graciously) decline making meeting appointments, even if the only possibility is in the morning. Think about it this way: If you don’t do this, you’re going to have to spend nights and weekends catching up on the actual work, so you are absolutely in your right saying no. This approach has the added advantage of keeping your mornings free for contiguous blocks of concentrated work, when most people are at their intellectual best.

Let us know in the comments what you think!

Why am I not in a pomodoro?

When you combine Getting Things Done (GTD) with the Pomodoro Technique (PT), the result is super hero productivity. PT entails that you work in 25 minute blocks of ultimate focus, referred to as pomodoros, each followed by 5 minutes of ultimate goofing off. After every 4 pomodoros, you get to take a longer break. Pomodoro people tend to use some form of kitchen timer (often in the form of a red tomato), or software such as the Focus Booster, and they tend to be at least three times as productive. :)

How can a technique named after something this red and tasty not be fantastic?

Whatever the case may be, we’re great fans of the technique and as a rule combine it with our GTD implementation. We do sometimes refer to the pomodoros as “work units”, as this is sometimes easier to explain to management. One might think that 25 minutes is quite short, but most people are generally quite amazed by the high level of focus that can be maintained during this period. The 5 minute break is almost like spending time under the shower: Deliberately goofing off and not thinking about the problem at hand often allows solutions and really good ideas to bubble up spontaneously from one’s sub-conscious.

Besides convincing you of the benefits of PT, the main message of this post to those of you already applying PT, is the following: At any time during the (work) day, if you’re not in a pomodoro or in the short break between pomodoros, you should ask yourself this question: Why am I not in a pomodoro?

In other words, one should either have a really good reason for this, or immediately start that new pomodoro. We noticed in ourselves,before we became TimeScapers of course :), and in other practitioners that people sometimes operate OOP (out-of-pomodoro) because they think that the activity doesn’t fit, for example mail processing or some other miscellaneous small action. Our advice is ABP: Always Be Pomodoroing. The risk with working OOP is that it can spiral out of control, breaking the whole PT focus-zone/goofing-off rhythm, and this is a productivity killer. Don’t fool yourself: You can and should always define a pomodoro.

Let us know in the comments what your experience is with this phenomenon, or if you’d just like to chat about PT in general.