The ProcrasDoCoder Ring is

• a conversation starter for my startup, ProcrasDonate
• gives the team a warm fuzzy feeling while we’re working
• a fun introduction to microcontrollers

The ring, or possibly a pin next to one’s name tag or attached to one’s hat, consists of a bright BlinkM RGB LED with long wires to an arduino unit hidden in one’s pocket or belt loop. The LED lights up colorfully and brilliantly for a few seconds whenever a user of ProcrasDonate donates to a charity, makes a pledge, downloads our software or participates in some user test.

Currently, the code to do all this has been written, but the hardware housing is still in prototype phase. I’ll update the following videos and pictures soon; hopefully with a real use case in the wild.

This video shows a simple demo of the WiShield and BlinkM.

How it works

The ProcrasDoCoderRing is a simple mashup that stands on the shoulders of 4 giants:

Arduino + WiShield + BlinkM + ProcrasDonate web server

In case it’s not clear: much of the WiShield and BlinkM code is copied from relevant examples.

• Arduino – Arduino starter pack from AdaFruit, snap.
• WiShield – from AsyncLabs

  Nice library. Needed to hack a few config lines in the C code for WEP 5 byte passcode (see section below), but otherwise comes with good documentation.

• BlinkM – RGB LED kit from ThingM

  Comes with a nice arduino library that abstracts fading the LED to a specific RGB or HSB.

• ProcrasDonate web server - python Django website

There are two different ways this could work:

1. The arduino registers itself with the ProcrasDonate site, which then pushes information to the arduino using HTTP web requests to the WiShield webpage server.
2. Instead, the arduino regularly pings a small Django app running on ProcrasDonate. The app has a single webpage, which returns the donation counts, etc.

To view the code and more detailed documentation, see the ProcrasDoCoder github repository.

Proudly ProcrasDonating,

Lucy.

Check out the test app —> give feedback

Today I broke from solidifying and bug-fixing the ProcrasDonate Firefox extension in order to test donations as a time management incentive.

I created a small app that uses RescueTime’s API to retrieve a user’s RescueTime time tracking data.

The user authorizes ProcrasDonate to donate to their selected charity at the indicated $/hr rate for all hours spent on activities with a negative RescueTime productivity score.

Keep in mind: this is a barebones minimal test app. Try it out and tell us what you think.

Proudly ProcrasDonating,

Lucy.

This is one of my favorite tricks: setup the Django environment from the Python interpreter.

(master) $ python
>>> from lib.django_from_shell import start_django as sd
>>> sd()
>>> from procrasdonate.models import User
>>> User.objects.count()
22

All we need to do is wrap a few Django calls like so:

def start_django():
    import sys
    #Now the nearest ancestor directory with a 'settings.py' file
    settings_dir = find_file_in_ancestors("settings.py")
    sys.path.append(settings_dir)
    
    from django.core.management import setup_environ
    import settings
    setup_environ(settings)

By being flexible about finding the global settings.py file, we can call start_django from other scripts buried in bin or cron directories:

def find_file_in_ancestors(filename):
    """
    For each parent directory, check if 'filename' exists.  If found, return
    the path; otherwise raise RuntimeError.
    """
    import os
    path = os.path.realpath(os.path.curdir)
    while not filename in os.listdir(path):
        #if filename in os.listdir(path):
        #    return path
        newpath = os.path.split(path)[0]
        if path == newpath:
            raise RuntimeError("No file '%s' found in ancestor directories." % filename)
        path = newpath
    return path

Conclusion

The goal of these tricks is to reduce copy/past/alter drudgery. It’s rewarding to automate the creation of fluff code, even easy fluff that knocked my socks off when I first learned Django.

Of course, it’s hard to stay impressed with myself or Dan for long since I quickly forget that the fluff code even existed. I suppose that’s part of the point. I can forget about creating Admin Models, and new models still show up in the Admin app as I thoughtlessly expected.

Still, even if I’m not impressed, I do notice how often I get to write new, interesting code. That’s why I’m Proudly ProcrasDonating,

Lucy.

We started with automating Admin Model creation, and continued with automating initialization and installation, model mixins, forms and app settings.

This post diverges from automation to point out some useful view utilities.

Render Response

This trick is more like standard Django practice: wrap render_to_response with your own function that uses your own RequestContext.

def render_response(request, template, dictionary=None):
    """
    Return render_to_response with context_instance=RequestContext(request).
    """
    dictionary = dictionary or {}
    return render_to_response(template, dictionary, context_instance=RequestContext(request))

def render_string(request, template, dictionary=None):
    dictionary = dictionary or {}
    return render_to_string(template, dictionary, context_instance=RequestContext(request))

One small thing sometimes forgotten is that when you call render_response from your view, you don’t have to write out the dictionary, which is really just a copy/double-paste of local variable names. Instead, call locals().

some_view.py

def info(request):
    user_count = User.objects.count()
    visitor_count = Visitor.objects.count()
    pledge_count = ...
    donation_count = RecipientPayment.objects.count()

    return render_response(request, 'procrasdocoder/info.html', locals())

Extract Parameters

Another useful convenience function is extract_parameters, which extracts expected and optional parameters from a request’s POST and GET objects, as well as reporting appropriate errors.

Here’s an example use:

def receive_data(request):
    expected_parameters = ["private_key",
                           "prefs"]
    optional_parameters = ["foo",
                           "bar"]
    response = extract_parameters(request, "POST", expected_parameters)
    if not response['success']:
        Log.Error(response['reason'], "communication_error")
        return json_failure(message)

    parameters = response['parameters']
    private_key = parameters['private_key']
    ...

Here is the definition for extract_parameters:

def extract_parameters(request, method_type, expected_parameters, optional_parameters=None):
    ret = {}
    
    if not getattr(request, method_type):
        return {'success': False,
                'reason': "Expected %s parameters" % method_type}
    
    for p in expected_parameters:
        try:
            v = getattr(request, method_type).get(p, None)
            if v == None:
                return {'success': False,
                        'reason': "Missing expected parameter: %s" % p}
            ret[p] = v
        except:
            return {'success': False,
                    'reason': "Something unexpected happened while extracting parameters"}
    
    optional_parameters = optional_parameters or {}
    for p in optional_parameters:
        try:
            v = getattr(request, method_type).get(p, None)
            if v:
                ret[p] = v
        except:
            return {'success': False,
                    'reason': "Something unexpected happened while extracting optional parameters"}
     
    
    return {'success': True,
            'parameters': ret}

This is a marathon super-bowl blogging experience for me, and the English to Code ratio is quickly approaching zero. I’ve left the best for last, though, so check it out: Part 7 – Django from shell.

Proudly ProcrasDonating,

Lucy.

We started with automating Admin Model creation, and continued with automating initialization and installation, model mixins and forms.

This post describes how we automate incorporating new Django apps into our project.

Creating apps is a wonderful way to modularize work. Encapsulation, abstraction, re-use!

To reduce copy/paste/rewrite drudger we’ve automated our project’s settings.py file according to standard Django conventions.

APPS list

First, we need to list what apps are active in the project:

APPS = ('procrasdonate', 'crosstester', 'adwords', 'procrasdocoder')

Pathify utility

Let’s setup some convenience path functions.

path converts a path with unix path separator, /, into a path with the appropriate os-specific path separator.

pathify converts a list of path components into a string path with appropriate path separator.

Finally, PROJECT_PATH holds the projects root absolute path.

import os
def path(p):
    """
    @param p: path with unix path separator
    @return: string with os-specific path separator
    """
    return os.sep.join(p.split("/"))

import re
_space_replace = re.compile("([^\\\])( )")
def pathify(lst):
    """
    @param lst: list of path components
    @return: string with os-specific path separator between components 
    """
    # replaces spaces with raw spaces so that spaces in file names work
    repl = r"\g<1> "
    return os.sep.join([_space_replace.sub(repl, el) for el in lst])

PROJECT_PATH = os.path.dirname(os.path.realpath(__file__))

Middleware

Now we’re into the core of the work, which is to iterate through each app and append the appropriate path or module to the relevant tuple.

MIDDLEWARE_CLASSES = (
    'django.middleware.doc.XViewMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'ext.pagination.middleware.PaginationMiddleware',
    'django.contrib.csrf.middleware.CsrfMiddleware',
    'lib.ssl_middleware.SSLRedirect',
)
for app in APPS:
    if os.path.exists(pathify([PROJECT_PATH, app, 'middleware.py'], file_extension=True)):
        MIDDLEWARE_CLASSES += (
            '%s.middleware.%sMiddleware' % (app, app.capitalize()),
        )

Templates

Add template directories.

Note: Do you see how we also add the template directory of our Firefox extension? This is so that our server can reuse extension templates (OMGSQUEEL).

TEMPLATE_DIRS = (
    #'procrasdonate/ProcrasDonateFFExtn/content/templates',
    pathify([PROJECT_PATH, path('procrasdonate/ProcrasDonateFFExtn/content/templates')]),
)

for app in APPS:
    if os.path.exists(pathify([PROJECT_PATH, app, 'templates'])):
        TEMPLATE_DIRS += (
            pathify([PROJECT_PATH, path('%s/templates' % app)]),
        )

Installed Apps

INSTALLED_APPS = (
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.humanize',
    'ext.pagination',
    'django.contrib.auth',
    'django.contrib.admindocs',
    'django.contrib.admin',
)

for app in APPS:
    INSTALLED_APPS += (
        app,
    )

Context Processors

TEMPLATE_CONTEXT_PROCESSORS = (
    'lib.context.defaults',
    'django.core.context_processors.auth',
    'django.core.context_processors.debug',
    'django.core.context_processors.i18n',
    'django.core.context_processors.media',
    'django.core.context_processors.request',
)

for app in APPS:
    if os.path.exists(pathify([PROJECT_PATH, app, 'context.py'], file_extension=True)):
        TEMPLATE_CONTEXT_PROCESSORS += (
            '%s.context.defaults' % app,
        )

This only works if the app includes a “context.py” file with a function called “defaults” that returns the context dictionary:

context.py

def defaults(request):
    frame = {}
    frame.update(useful_settings())
    frame.update(header_data())
    ...
    return frame

def useful_settings():
    return { 'PDVERSION': settings.PDVERSION }

def header_data():
    return { ... }

Urls

The project’s base URL file is modified to automatically incorporate each app’s URLs.

For example, an app called “magic_cape” would be accessible from the URL “/magic_cape/”, assuming it contained a “urls.py” file inside a “views” directory.

To customize the urls for an app, it’s name is added to the CUSTOM_URLS_APPS tuple.

CUSTOM_URLS_APPS = ('procrasdonate',)

for app in settings.APPS:
    if app not in CUSTOM_URLS_APPS and os.path.exists(pathify([settings.PROJECT_PATH, app, 'views'])):
        urlpatterns += patterns('',
            (r'^%s/' % app, include('%s.views.urls' % app)),
        )

Proudly ProcrasDonating,

Lucy.

We started with automating Admin Model creation. This post describes how we automate the creation of form classes for models.

Automatic Model Form creation

The point of automatic forms is to reduce the effort that goes into writing views. Form classes for models should be created on the fly as we need them, with the same flexibility as if we had defined the form class directly.

Here’s an example that retrieves a form for the public fields of the Recipient model:

from lib.forms import get_form, EDIT_TYPE

@login_required
def edit_public_information(request):
    recipient = request.user.get_profile().recipient
    FormKlass = get_form(Recipient, EDIT_TYPE, includes=('name',
                                                         'category',
                                                         'mission',
                                                         'description',
                                                         'url'))

    if request.POST:
        form = FormKlass(request.POST, instance=recipient)
        if form.is_valid():
            form.save()

The get_form utility function takes the Model class as a required parameter. If that is the only parameter, it will return the default ModelForm for that model.

The includes and excludes fields normally specified in the ModelForm’s inner Meta class can be provided as parameters to get_form().

The forms module also specifies three ModelForm types, NEW_TYPE, EDIT_TYPE and ADMIN_TYPE. Originally, the includes and excludes were defined per type per model in the forms module. This is useful if there are multiple places in the web app where models are edited, and you don’t want to keep remembering which immutable or signal-computed fields to exclude.

Note: If we go back to using the NEW_, EDIT_ and ADMIN_TYPEs we would move their definitions to inside models themselves rather than editing a single dictionary in the forms module. Live, learn and move on.

The forms module is appended below.

Proudly ProcrasDonating,

Lucy.

from django.forms import ModelForm

"""
We want to create three kinds of forms:
1. Admin<Model>Form  admin forms.     these have all fields and are used for both creation and editing
2. New<Model>Form    user new forms.  these exclude hidden or contextually obvious fields (eg state, a review's node)
3. Edit<Model>Form   user edit forms. these exclude hidden fields
"""
# shows all fields
ADMIN_TYPE = 'admin'
# user facing form for creating new instance
NEW_TYPE = 'new'
# user facing form for editing existing instance
EDIT_TYPE = 'edit'

# users should not reference this cache directly.
# instead, use get_form
FORMS = { ADMIN_TYPE: {},
          NEW_TYPE: {},
          EDIT_TYPE: {},
          }

def get_form(model, type=ADMIN_TYPE, excludes=None, includes=None):
    """
    @param excludes: in addition to type-based excludes. for on-the-fly forms. 
    @param includes: for on-the-fly forms. 
    return form class for model and type
    """
    if model in FORMS[type] and not excludes and not includes:
        # don't cache on-the-fly forms
        form = FORMS[type][model]
    else:
        mname = model.__name__
        excludes = excludes or ()
        
        if type == ADMIN_TYPE:
            exec('Admin%sForm = model_form_class(model, excludes, includes)' % mname )
            form = locals()['%sForm' % mname]
                
        elif type == NEW_TYPE:
            if mname in new_forms_excludes:
                excludes += new_forms_excludes[mname]
            exec('New%sForm = model_form_class(model, excludes, includes)' % mname )
            form = locals()['New%sForm' % mname]

        elif type == EDIT_TYPE:
            if mname in edit_forms_excludes:
                excludes += edit_forms_excludes[mname]
            exec('Edit%sForm = model_form_class(model, excludes, includes)' % mname )
            form = locals()['Edit%sForm' % mname]
            
        else:
            raise "Type no good"
        
        if not excludes and not includes:
            # don't cache on-the-fly forms
            FORMS[type][model] = form
    
    return form


def model_form_class(_model, excludes=None, includes=None):
    class klass(ModelForm):
        class Meta:
            model = _model
            if excludes:
                exclude = excludes
            if includes:
                fields = includes
    return klass

new_forms_excludes = {#'OldModel':('url',),
                      #'OldModel2':('old_model','foo','bar'),
                      }

edit_forms_excludes = {
                       #'MyModel':('slug','immutable','calculated_from_post_save'),
                      }

In the last post we covered automating initialization. Continuing with initialization, this post will cover model mixins.

Model mixins mix convenient utilities into model classes.

Specified Mixins

Mixins is a general term for mixing attributes of an abstract class into a non-abstract subclass.

In this case, we want to mix convenience methods into Model Foo. The reason why these methods aren’t defined in Foo is because of clean, modular code. An example will help:

class Tagging(models.Model):
    tag = models.ForeignKey(Tag)
    post = models.ForeignKey(Post)

    @classmethod
    def Initialize(klass):
        model_utils.mixin(TaggingMixin, Post)

There are three models at play in the above example:

• Post – a blog post
• Tag – a tag
• Tagging – links a tag with a post

There is also a normal python class, TaggingMixin, that provides convenience methods for Posts:

class TaggingMixin(object):
    """ mixed into Post """
    
    @property
    def tags(self):
        return Tag.objects.filter(tagging_set__post=self)

In the Tagging model’s Initialization function, mixin mixes TaggingMixin into Post. This allows us to encapsulate all the Tag logic, including the ForeignKeys to Post, inside the Tagging models and the TagMixin class. The Post model remains clean, with only those functions that deal with its direct fields.

This separation becomes a necessity when Models are spread between different apps.

The mixin code is appended to the end of this post.

Standard Mixins

We automatically mixin in the following convenience functions to every Model:

• add
• find
• get
• get_or_none

get_or_none is a nice way to retrieve an object if it exists, such as:

lucy = User.get_or_none(name="Lucy")
if lucy:
    print lucy.favorite_number
else:
    print "Lucy is not in the database"

add is a convenient constructor for creating objects, though it requires adding a Make classmethod to every Model. The advantage is that we not only put constructor logic inside a constructor, but we also abstract that call into add…in case making things becomes more complicated later.

some view function

lucy = User.add("Lucy", 22)

models.py

class User(models.Model):
    name = models.CharField(max_length=222)
    favorite_number = models.IntegerField()

    @classmethod
    def make(klass, name, favnum):
        favnum = int(round(favnum))
        return User(name=name, favorite_number=favnum)

In order to mix these methods into every Model we resort to the __init__.py trick discussed previously:

from models import ALL_MODELS

from lib import model_utils
model_utils.mixin(model_utils.ModelMixin, ALL_MODELS)

Proudly ProcrasDonating,

Lucy

mixin definition

def mixin(mixin, klasses, last=0):
    if not isinstance(klasses, (list, tuple)):
        klasses = (klasses,)
    for klass in klasses:
        if mixin not in klass.__bases__:
            if last:
                klass.__bases__ = klass.__bases__+(mixin,)
            else:
                # sometimes this fails, but if change order seems to work
                try:
                    klass.__bases__ = (mixin,)+klass.__bases__
                except:
                    klass.__bases__ = klass.__bases__+(mixin,)

ModelMixin definition

class ModelMixin(object):
    """
    @summary:
    B{ModelMixin} is a mix-in used to provide common methods, attributes,
    and hooks across all models.
    
    At initialization, ModelMixin is mixed into all models listed in 
    """
    @classmethod
    def find(klass, ids=None, **kwargs):
        """
        @summary:
        Convenience method: B{find} simply passes arguments through to
        klass.objects.filter()
        """
        if isinstance(ids, (int, long)):
            return klass.objects.filter(id=ids, **kwargs)
        elif isinstance(ids, list):
            return klass.objects.filter(id__in=ids, **kwargs)
        else:
            return klass.objects.filter(**kwargs)

    @classmethod
    def get_or_none(klass, **kwargs):
        """
        @summary:
        Convenience method: B{get_or_none} simply passes arguments through to
        klass.objects.filter()
        """
        f = klass.objects.filter(**kwargs)
        if len(f) == 0:
            return None
        else:
            return f[0]
        
    @classmethod
    def get(klass, id=None, **kwargs):
        """
        Convenience method: B{get} simply passes arguments through to 
        klass.objects.get()
        
        @note: Raises exceptions anytime 'get' would.
        """
        if isinstance(id, (int, long)):
            #return klass.objects.get_object_or_404(id=id, **kwargs)
            return get_object_or_404(klass, id=id, **kwargs)
        elif len(kwargs) > 0:
            return klass.objects.get(**kwargs)
        else:
            raise RuntimeError("No id or conditions given to 'get'!")
    
    @classmethod
    def add(klass, *args, **kwargs):
        """
        @summary:
        This is a general method which simply calls 'make' with the same
        arguments and then saves the returned object.
        """
        o = klass.make(*args, **kwargs)
        o.save()
        #if publish:
        #    o.publish()
        return o

We started with automating Admin Model creation. Continuing with automation, this post will cover model initialization and installation.

Initialization is the stuff we would normally put in a constructor, such as register pre-save and post-save signals.

Models are meta-classes, so they don’t have normal constructors. Instead, we put all the initialization stuff in a classmethod called Initialize:

class MyModel(models.Model):
    @classmethod
    def Initialize(klass):
        models.signals.pre_save.connect(MyModel.sanitize_user_input, sender=MyModel)

In the app’s __init__.py file, we automatically look for Initialize methods to call.

__init__.py

from models import ALL_MODELS

for model in ALL_MODELS:
    if hasattr(model, 'Initialize'):
        model.Initialize()

We could put signal registration directly in the model’s file, but it’s nicer to encapsulate all this Initialization stuff in a function, and then automate that function’s execution.

For more neat initializations read part 3 of this series, Model mixins.

Installation is stuff we want to do once the model class is synched with the database, such as installing a fixture or initial data.

As with Initialization, we can optionally add a classmethod called install to a model. A post_syncdb function will look for install functions to call when iterating over models.

management.py

from django.dispatch import dispatcher
from django.db.models import signals
 
import models
 
"""
@summary: Install initial data when models are first created.
 
Automatically called by django.
Find out more be searching for "management.py" and "Extra special stuff" in
http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/
document on wiki:
http://bilumi.org/trac/wiki/PostSyncdbInstall
"""
 
def post_syncdb(signal, sender, app, created_models, **kwargs):
    # only run when models we care about are first created
    if signal == signals.post_syncdb and app == models:
        for model in models.ALL_MODELS:
            if hasattr(model, 'install'):
                if kwargs['verbosity'] > 0:
                    print "Installing ", model
                model.install()
 
signals.post_syncdb.connect(post_syncdb)

Proudly ProcrasDonating,

Lucy.

Since the admin app is one of the stars of Django, we’ll start with our admin module, Adminizer.

Automate Admin Model creation

The point of Adminizer is to reduce all that fluff around admin classes. Rather than literally writing admin classes for every one of our models, we automatically create them.

Adminizer.Adminize() takes a model or list of models as input. For each model, Adminizer creates a ModelAdmin class and registers it with the admin app.

What if we want to provide custom admin options? I initially wrote this so that we define a field in our model, called admin_options, that is a dictionary of the desired admin model fields. I’ve since added detection of an inner class called Admin with fields that match the admin model fields. This is more readable than a dictionary, and seems to be where the admin app is headed.

Voila! I frequently add new models to new and existing apps; by automating the AdminModel creation, I get the Admin app literally for free.

Below are the relevant code snippets building out from the models to the Adminizer.

Proudly ProcrasDonating,

Lucy.

data.py

class MyModel(models.Model):
    slug = models.SlugField();
    name = models.CharField(max_length=200)

    admin_options = {'prepopulated_fields': {"slug": ("name",)} }

    #or

    class Admin:
        prepopulated_fields = {"slug": ("name",)}
...

ALL_MODELS = [MyModel, ...]

models.py

from data import ALL_MODELS as DATA_MODELS
from rank import ALL_MODELS as RANK_MODELS
from fps_models import ALL_MODELS as FPS_MODELS
from log import ALL_MODELS as LOG_MODELS
from analytics import ALL_MODELS as ANALYTICS_MODELS

from data import *
from rank import *
from fps_models import *
from log import *
from analytics import *

ALL_MODELS = DATA_MODELS + RANK_MODELS + FPS_MODELS + LOG_MODELS + ANALYTICS_MODELS

__init__.py

from models import ALL_MODELS

from lib.admins import Adminizer
Adminizer.Adminize(ALL_MODELS)

lib/admins.py

from django.contrib import admin
import settings

class Adminizer(object):

    @classmethod
    def _model_admin_class(cls, options):
        """
        @summary: returns an admin.ModelAdmin class with the specified 
        ModelAdmin options set. see:
            http://docs.djangoproject.com/en/dev/ref/contrib/admin/#modeladmin-options
        @param options: dictionary of ModelAdmin options. key should be string 
            that corresponds to option name (eg, 'date_hierarchy'). value should be
            intended value for field.
        @return: sub-class of admin.ModelAdmin
        """
        class klass(admin.ModelAdmin):
            pass
        for field_name, field_value in options.items():
            setattr(klass, field_name, field_value)
        return klass
    
    @classmethod
    def Adminize(cls, klasses):
        """
        """
        if not isinstance(klasses, (list, tuple)):
            klasses = (klasses,)
        for klass in klasses:
            if hasattr(klass, 'admin_options'):
                options = klass.admin_options
            elif hasattr(klass, 'Admin'):
                options = {}
                for k, v in klass.Admin.__dict__.items():
                    if k[:2] != "__":
                        options[k] = v
            else:
                options = {}
            admin_klass = cls._model_admin_class(options)
            admin.site.register(klass, admin_klass)

Incentivize something we can measure.

Let me first say that I love the procrastination-donation duo that we’re starting with. The ProcrasDonate name is dynamite, the explanation is simple—donate to charity for every hour procrastinated—and the user response is energetic.

Nonetheless, it’s fun to think of other applications for the general idea. We’ve received so many ideas that I can’t help wanting to make sense of them all. Here’s what I’ve come up with:

The chart presents two orthogonal dimensions: behavior and incentive. A good behavior is a virtue, a bad behavior is a vice. A positive incentive is a reward, a negative incentive is a punishment.

Ideas are broken down into behaviors and incentives, which are partitioned into each dimension’s end-points. Taking a cross-product of each behavior against each incentive shows us all the applications we could build.

In this simplistic abstraction I’ve evaluated each idea in binary. In truth, the “goodness” or “badness” of each end-point is relative to the individual. So it goes.

Vices (if harmful)

• Online procrastination (facebook, chat, blogs, feeds, games, TV, movies, videos
• Missing a deadline
• Addictions (smoking, drinking, gambling)
• Physical laziness
• Staying up or waking up late
• Sending too much email
• Unhealthy eating
• Being mean
• Greed

Virtues (if empowering)

• Productive
• Meet deadline
• Learning
• Making
• Fighting addiction (not smoking, not drinking, etc)
• Exercising
• Early to bed, early to rise
• Taking pills
• Good grades
• Healthy eating
• Being nice
• Enabling

Punishments

• Lose money
• Lose time (signed up to tutor or be tutored, community service)
• Volunteer for non-profit or open source project
• Shame (publicize results to friends)
• Annoying warnings, alarms
• Prevent behavior (eg, block procrastination sites)

Rewards

• Receive money (savings account, from parents, wager with friends, coupons)
• Gain time (virtues are good in themselves??)
• Accolades
• Enable behavior (desserts after meal)
• Affirmation (support, coaching)
• Specific goal (eg, plan a trip)

ProcrasDonate

Where would you put ProcrasDonate on the chart?

I’d put ProcrasDonate in quadrants II and III. Donations play a dual role of reward—support good causes—and punishment—lose money. This twist piques many people’s interest, especially mine.

Bets

One kind of app that isn’t clear from the above model is how a group of friends might reward and incentivize each other.

Social dynamics draw on shame, affirmation, competition, and resource re-distribution. For example, each week the friends bet money on their own success. The winners receive either money, decision-making power or a random act of kindness as prizes. The losers give up those things.

This strikes me as a particularly fun and effective behavior-changing strategy, if sufficiently coupled with graphs, of course .

The more ideas the merrier, so keep ‘em coming.

Proudly ProcrasDonating,
Lucy.

I like to evaluate extended periods of technical work in terms of throughput, quality and direction.

Throughput means getting a lot done. The more quantifiable, complete results, the better.

Quality means the work is real and not hidden. Quality work doesn’t cause more work later by introducing bugs or making it harder to add features. Ideally, past work enables future work so that our progress is like a boulder rolling down hill picking up speed.

Direction means driving the company towards success. Burning down the wrong mountain is no good.

Looking back on the past three months, which is when we released our new Amazon Payments powered add-on, ProcrasDonate has demonstrated success in all three areas. I’m personally proud to have kept Throughput and Quality in balance. I would also like to highlight the excellent job Clay is doing with Direction, especially in response to users, market research and outreach efforts.

On the technology side, we accomplished our goals to:

• Solidify our core product
• Iterate each week
• Respond to rounds of beta testers

Two goals moving forward are to:

1. Continue responding to user feedback and developing the core product
2. Implement selected ideas based on new market research

Pivotal Tracker Data

The data from Pivotal Tracker, which we use to manage technology tasks, provides its own narrow but fun perspective. Ain’t data great!!?!

Below are our release charts from Pivotal Tracker. Every day is spent working towards a specific release. Each release chart plots the number of work left at the close of each day. Work is defined in abstract story points, which I estimate when stories are created. Sometimes I adjust these amounts when a story is completed. I try to be consistent without worrying about precision.

Red and green lines show “expected” progress. On the first day, they show the total number of points in the story. At the deadline they show all tasks completed.

Blue lines show how many points actually remained at the end of that day. They do not reflect stories that are in progress. To burn down a story the whole completed story must be delivered.

Chores do not have points and thus do not show up on these charts. Chores include backend work, developer scripts and testing. Bugs do not have points, either. A breakdown of story types is shown in the next section.

Finally, each iteration is exactly one week, but the period of each release varies. Our first public release using Amazon payments, release 0.3.0, is 3 weeks long. The rest are approximately 1 week each, although things often worked out into one long release and one short release. We didn’t want to be so concerned about deadlines that we didn’t take risks, but we also wanted to get into the habit of meeting deadlines….so we alternated.

0.3.0 - working

0.3.1 - email

0.3.2 - new homepage

0.3.3 - slim registration

0.3.4 - polish registration

0.3.5 - graphicals

0.3.6 - smooth install

0.3.7 - more info

0.3.8 - community

0.3.9 - ready for strangers

0.4.0 - faster

0.4.1 - communication

0.4.2 - payments

Velocity

Velocity is the number of points the team accomplishes each iteration. Our iterations span one week, and our team, in terms of developer work, consists primarily of me.

The black line shows the “running velocity,” which is the average of the past three weeks. The running velocity is used by Pivotal Tracker to automatically partition our prioritized list of stories into iterations.

It’s nice to work so fast that new stories have to roll in from the backlog. It’s motivating to have dipped the velocity so much around New Year’s that our backlog was temporarily chunked into iterations stretching to the summer!

Velocity each week

Story Type Breakdown

Features have points. They are customer facing value-adds.

Chores and bugs do not have points. Chores include backend work, developer scripts and testing. Bugs are existing features that are broken.

The following chart stacks each of these types on top of each other.

Story type breakdown: BLUE = features, BLACK = chores, RED = bugs, YELLOW LINE = points completed

Retrospective

Let me first mention the New Years Eve dip. I took a couple days off to recharge

The low-point iterations are because of predominantly backend work, such as automatic backups that are restored on a dedicated test machine, and better build scripts, etc.

In the middle is an iteration in which no stories were completed. A very large chore—automatic cross-platform testing—did land in the next iteration, but that only shows up as a single chore.

That large chore was a rabbit hole. The crosstester app I made is totally awesome, but I should have reigned it in to a couple VMs with brief instructions for manual tests. I’ve learned from this and moved on.

What else did I learn?

We became better at meeting deadlines.

Story point estimation and consistency wasn’t as variable as I expected. I don’t remember changing story point estimations all that much, but there are many factors influencing what appears to be a level chart across the weeks (other than the rabbit hole dip).

Investigatory stories are always a little troublesome, since after the investigation they either turn into work or are halted, so you’re never quite sure whether they’re going to be 1 or 3 points….and we don’t start out thinking they’re investigations. Not so many stories are investigations.

I have to remind myself that we became faster at certain implementations. Tasks that gave me pause in November (2 or 3 pointers) are no big deal now (easy 1 pointers). This comes down to familiarity and reusable libraries and scripts.

The first time I had to migrate the extension database I thought it might take all day. I’ve done so many data transformations and database migrations that I’ve ceased putting “updates” and “release prep” on Pivotal Tracker (we never create 0 point stories…just do it!). The first time I wrote tests I also wrote the framework. Some stories get easier over time. Even when additional features are added, or a different kind of test, I can get more done in the same span of time.

Lastly, we averaged completing 7 features (not points), 2 bugs and 1 chore each iteration, with little variation. Keeping bugs and chores low and attacking features mercilessly—the right features, of course—sounds good to me. I was curious about this breakdown and variability when we first started using Pivotal Tracker, so it’s neat to see the results now.

That’s enough navel gazing for now.

I’ve appended the release notes below for anyone interested. Release notes are written for non-technical users, so only features and bugs are covered, and then in pretty general terms. (They show up on the Firefox tab that automatically opens to say “Congratulations! You’ve installed [or updated]…”)

Proudly ProcrasDonating,
Lucy.

Release Notes

0.3.0.html

• ProcrasDonate only tracks the Firefox tab you are currently viewing. It stops tracking as
  soon as you switch to another application or stop using your computer.

0.3.1.html

• Minor usability improvements

0.3.2.html

• New homepage design
• Website classifications added to My Progress page below the gauges
• Proper uninstall added (all data is deleted)
• Add-on build and update process improved. Update download problem (”incorrect hash”) should be fixed.
• Registration process improvements on payments tab

0.3.3.html

• User registration streamlined into just 4 steps
• My Progress page enhancements:
• Classify websites by entering them directly in the Classifications tab
• New Visits tab that shows all of your page visits for the day
• Time tracking halts when computer goes to sleep
  and resumes, if Firefox is the active application, when computer wakes up
• Fixed bug in which flash was not being detected on currently viewed webpage,
  thus the user needed only to be idle for 3 minutes for time tracking to halt.
  With the fix, pages that contain flash halt time tracking once the user
  is idle for 20 minutes. See the development blog post on
  
  How we track website visits for more time tracking details.
• Fixed toolbar icon bug in which times over 24 hours were reported incorrectly.

0.3.4.html

• When upgrades are available,
  users receive upgrade alert once a day when they visit the ProcrasDonate website.

0.3.5.html

• Graphicals!
• Pie chart added to help with choosing donation percentages to multiple charities.
• Trend section added to My Progress. Plots hours per day spent at different websites and overall.
• No visits are recorded while Firefox is in Private Browsing mode. For more information, see
  the FAQ question What is tracked?

.

• If you had trouble with toolbar icons disappearing they should be back, working and shinier than ever.

0.3.6.html

• My Messages tab added.
  Go here to view a helpful welcome message and
  your weekly affirmation reports.
• Top bar inserted above the first ProcrasDonate website visited
  of the day if there are unread messages waiting.
• Hold down My Settings arrows
  for rapid fire incrementing and decrementing.
• Fixed post-install bug requiring additional restart

0.3.7.html

• Play nicely with other Firefox add-ons, or at least don’t pee in the sandbox.
• Enabled announcements from ProcrasDonate and newsletters from charities to be uploaded
  to My Messages, as enabled by your update settings.
• Duplicate messages removed and underlying bug fixed.

0.3.8.html

• Community statistics added to homepage
• Private beta testing preparation: check
• Fixed extension bug in which dollars were being stored as cents. Data stored prior
  to this release will remain unchanged. Only new webpage visits are effected.

0.3.9.html

• Gracefully handle non-http page visits, eg viewing local files
• Fixed bug in My Impact display
• Removed Buy It Like You Mean It! as a pre-selected charity when downloading
  ProcrasDonate with no pre-selected charity selected.

0.4.0.html

• Smoother registration process
• Fixed co-extension bug: 0.4.0 plays nice with everyone, even bullies

0.4.1.html

• Welcome and registration emails sent to users.
• Homepage improvements: added social sharing site links,
  added recent tweets,
  process charity logos without reducing apparent quality,
  enabled video playback when charity logos are clicked,
  popup helper instructions when user clicks download button!
• Registration incentive page clarified thanks to user feedback.

Press Release

Extension pages are web pages that are constructed directly by the extension on a user’s computer. For example, My Progress pages have four tabs:

1. Gauges
2. Sites
3. Visits
4. Trends

If a user without our extension goes to the My Progress page, http://procrasdonate.com/my_progress/ , then a single error page is generated by our server. However, a user with our extension is able to view multiple pages at that same URL simply by clicking items in a submenu.

Below are two screenshots of the My Progress pages. In the first, the “Gauges” tab is shown. In the second, the “Trends” tab is shown. Note that the submenu is the same on all My Progress tabs.

Gauges tab on My Progress page

Trends tab on My Progress page

Below are two screens of other extension pages. The My Impact pages all have a single table with four tabs for displaying different tables. The Registration pages are a series of forms for setting up ProcrasDonate for the first time. Both My Impact and Registration use a submenu to generate content.

Show All tab on My Impact page

Charities tab on Registration page

Submenu Abstraction

You’re probably already smiling with how cool this situation is. Let’s break it down to savor the moment.

1. We have a single submenu concept: a list of submenu pages plus metadata such as tab name and tab content. The data depends on the page set, eg My Progress, My Impact or Registration, but the data structure is the same.
2. Submenus are displayed differently on each page set, but the functionality—click on menu item to change page content—remains the same.

The second abstract in which we display the same kind of data differently can be handled by creating a different html template for each submenu. The template for displaying the My Impact table tables has different HTML than the template for displaying My Progress images and tab names.

The super awesome part is that the structure of the submenu data is the same regardless of the page set. This allows the view to re-use submenu creation and event handling.

Submenu Data Structure

Each time a view is called to render the contents of a tab, it must generate a submenu data structure. This data structure is a list of submenu items. Each item contains the following properties:

• substate (useful as id)
• tab name (user visible)
• list of properties (eg: prev, selected)

Observe that this structure is keenly linked to the display abstraction. Each menu item includes properties relevant to display and user events. However, actual display implementations are left to the templates.

This data structure is generated by the view based on the user’s state and the submenu specifications.

Submenu Specification

The submenu specification is listed as constants in the extension’s settings file.

The specifications include the tab names, substate names, submenu images if desired, content insertion functions (aka views) and process functions if desired (useful on registration forms to detect whether errors need to be resolved before continuing).

The My Progress submenu data structure looks like this:

constants.DEFAULT_PROGRESS_STATE = "gauges";
constants.PROGRESS_STATE_ENUM = [
        "gauges", "classifications", "visits", "trends", /*"stacks", "averages", "ratios"*/
];
constants.PROGRESS_STATE_TAB_NAMES = [
        "Gauges", "Sites", "Visits", "Trends", /*"Stacks", "Averages", "Ratios"*/
];
constants.PROGRESS_STATE_INSERTS = [
        "insert_progress_gauges",
        "insert_progress_classifications",
        "insert_progress_visits",
        "insert_progress_trends",
        /*"insert_progress_stacks",
        "insert_progress_averages",
        "insert_progress_ratios"*/
];

I included the commented out submenu items because they illustrate why this abstraction is so cool. Once the abstraction is written, adding submenu items or even whole submenus and pagesets, becomes easier and more importantly, less tedious. The more real coding instead of infrastructure copy/pasting that I do, the more productive and happier I am, and the less likely the code contains stupid bugs.

Submenu Activation and Processing

All extension views share a common process:

1. Set substate if necessary
2. Generate the submenu
3. Retrieve content data structures
4. Render template and insert into page
5. Activate html
6. Activate submenu html

Activation means adding event handlers to the inserted html. Activating the submenu specifically means adding click events for each submenu item.

When a user clicks a submenu item, the appropriate view needs to be called. If a content processor function is specified, then that needs to be called first to ensure that the user doesn’t leave a page with erroneous inputs.

I don’t want to go into our view system too much, but it should be clear how the submenu framework fits cleanly into the view model. Our main goal is to make writing views actually equal writing the data retrieval, template html and html activation if there is any. All the other bullet items could be automated by the view framework.

(Whether everything is abstracted and squirreled away into a frameworked is one of those engineering decisions based on trade-offs. Even when the scope of the problem is well known so that a framework is an obvious non-constraining, yes-extensibility decision, some costs are so low that it’s better to just got on with the coding and do a little copy and paste. We can’t write programs to write all our programs for us. Not until the singularity, anyway.)

All together

When we put this all together we get an extensible submenu system that reduces the coding of new pages and subpages to the heart of the matter—specifying data and writing the middle of the view (retrieve content data structures)—while leaving the tedious submenu data structure generation and activation to already written helper methods.

Some pseudocode and diagrams would probably make this clearer, but for now I hope this overview is still mildly informative.

For those of you starving for more details, I’ve appended some code snippets to the bottom of this post. You might be particularly interested in the non-trivial closure in the activation function.

Proudly ProcrasDonating,
Lucy.

activate_substate_menu_items: function(request, current_substate, enums, inserts, processors) {
                var self = this;
                _iterate(enums, function(key, substate, index) {
                        if (processors) {
                                request.jQuery("#substate_tab_"+substate+", .substate_tab_"+substate).click(
                                        self._process(current_substate, enums, processors, inserts[index], request)
                                );
                        } else {
                                request.jQuery("#substate_tab_"+substate+", .substate_tab_"+substate).click(
                                        self._proceed(inserts[index], request)
                                );
                        }
                });
        },
        
        _process: function(current_substate, enums, processors, event, request) {
                var self = this;
                return function() {
                        _iterate(enums, function(key, substate, index) {
                                if (substate == current_substate) {
                                        var success = self[processors[index]](request, event);
                                        if (success) {
                                                self[event](request);
                                        }
                                }
                        });
                };
        },
        
        /// necessary because when did direct closure
        /// (function(event) { return event; })(self[event])
        // .click(
        //     (function(event) { return event; })(self[event])
        // )
        /// called functions had incorrect this
        _proceed: function(event, request) {
                var self = this;
                return function() {
                        //self[fnname].apply(self, args);
                        self[event](request);
                };
        },
        
        /*
         * @param: images: may be undefined
         * @return: dictionary of:
         *              menu_items: list of (id, klasses, value) tuples for substate menu
         *          id is "substate_tab_"+enums[index]
         *          value is tab_names[index]
         *          klasses is ["substate_tab", "current_tab"]<---if current tab
         *      next: tuple of next tab or null
         *      prev: tuple of prev tab or null
         */
        make_substate_menu_items: function(current_substate, enums, tab_names, images) {
                var menu_items = [];
                var prev = null;
                var next = null;
                
                var _last = null;
                var _one_past_current = false;
                var _two_past_current = false; // because can't tell the difference bw nulls
                _iterate(tab_names, function(key, value, index) {
                        // figure out menu item
                        var klasses = ["substate_tab"];
                        if (enums[index] == current_substate) {
                                klasses.push("current_tab");
                        } else if (!_one_past_current) {
                                klasses.push("past");
                        } else {
                                klasses.push("future");
                        }
                        
                        var img = "";
                        var bar = "";
                        if (enums[index] == current_substate) {
                                if (images) {
                                        if (images[index].selected) {
                                                img = constants.MEDIA_URL+"img/"+images[index].selected;
                                        } else {
                                                img = constants.MEDIA_URL+"img/"+images[index].past;
                                        }
                                } else {
                                        img = constants.MEDIA_URL+"img/StepCircle"+(index+1)+"Done.png";
                                }
                                bar = constants.MEDIA_URL+"img/Dash.png";
                                
                        } else if (!_one_past_current) {
                                if (images) {
                                        img = constants.MEDIA_URL+"img/"+images[index].past;
                                } else {
                                        img = constants.MEDIA_URL+"img/StepCircle"+(index+1)+"Done.png";
                                }
                                bar = constants.MEDIA_URL+"img/Dash.png";
                                
                        } else {
                                if (images) {
                                        if (images[index].future) {
                                                img = constants.MEDIA_URL+"img/"+images[index].future;
                                        } else {
                                                img = constants.MEDIA_URL+"img/"+images[index].past;
                                        }
                                } else {
                                        img = constants.MEDIA_URL+"img/StepCircle"+(index+1)+".png";
                                }
                                bar = constants.MEDIA_URL+"img/DashGreen.png";
                        }
                                
                        var menu_item = {
                                id: "substate_tab_"+enums[index],
                                klasses: klasses,
                                value: value,
                                img: img,
                                bar: bar
                        }
                        // set next
                        if (_one_past_current && !_two_past_current) {
                                next = menu_item;
                                _two_past_current = true
                        }
                        // set prev
                        if (enums[index] == current_substate) {
                                _one_past_current = true;
                                prev = _last;
                        }
                        // add to menu items
                        if (value != "XXX" && value != "XXXX") {
                                menu_items.push(menu_item);
                        }
                        _last = menu_item;
                });
                return {
                        menu_items: menu_items,
                        next: next,
                        prev: prev
                }
        },

Most of our tests are not concerned with timing, but we do have a few dozen time tracking scenarios. Each scenario re-enacts a user taking particular actions for particular durations. In addition to viewing webpages, we throw in application switches, the computer going to sleep, and other time tracking influences.

We’re particularly interested in how different time tracking triggers interact with each other, especially since some of the notifications can be delayed up to 5 seconds.

An important requirement is that we be able to write a test that plainly lists the actions and durations to take; such as the following:

• Start viewing a web page; say, http://foo.com/bar
• 30 seconds later notify the “user is idle” observer
• 40 seconds later notify the “user is back” observer”
• 10 seconds later start viewing a new web page

We expect to nicely abstract the test framework stuff that checks the actual behavior against the expected behavior (in this case a 30 seconds visit followed by a 10 second visit to web page http://foo.com/bar).

Algorithm Overview

The Javascript tool at our disposal is

, which waits for a given duration before executing a given expression.

Thus, the core of our sequentializer is turning a list of expressions and durations into a setTimeout expression that itself calls setTimeout with an expression that calls setTimeout… The recursive nature of the algorithm is best viewed through pseudocode:

# input items: list of (action, duration) pairs
# [ {action: some function, duration: seconds}, 
#     ...,
#    {action: some function}
#  ]
# goal is to execute items[idx].action, wait items[idx].duration,
# and then execute items[idx+1].action, wait items[idx+1].duration,
# and then execute items[idx+2].action, .... until all actions
# are executed. 
# The duration field, if present, in the last dictionary in items
# is ignored.
#
# input idx: index into items of next pair to execute
sequentialize( items, idx )
        # if there is an action to execute, execute it
        if idx < items.length
                execute( items[idx].action )
        fi

        # if there are more actions to execute, recurse
        if idx + 1 < items.length
                setTimeout( sequentialize(items, idx+1), items[idx].duration )
        fi

Javascript Solution

When we converted this pseudocode to a Javascript sequentializer function, we added a _create_sequentializer helper method to do testing stuff so that each test case need only specify the items data structure.

Here’s the full Javascript:

/**
 * @param items: list of functions to execute.
 *      has the following form:
 * [
 *  {fn, self, args, interval},
 *  {fn, self, args, interval},
 *  ...
 * ]
 */
sequentialize: function(items, idx) {
        var self = this;
        if (idx < items.length) {
                items[idx].fn.apply(items[idx].self, items[idx].args);
                if (items[idx].interval) {
                        setTimeout(function() {
                                self.sequentialize(items, idx+1);
                        }, items[idx].interval);
                } else if (idx+1 < items.length) {
                        // flexible: in case we have actions we don't want to wait on
                        self.sequentialize(items, idx+1);
                }
        }
},

/**
 * Test framework stuff
 */
_create_sequence: function(testrunner, display_results_callback, site, actions) {
        var self = this;
        
        var expected_durations = [];
        var sequence = [];
        
        _iterate(actions, function(key, action, index) {
                if (action.expected_visit) {
                        expected_durations.push(Math.round(action.interval/1000.0));
                }
                sequence.push({
                        fn: action.fn,
                        self: action.self,
                        args: action.args,
                        interval: action.interval
                });
        });
        // append tests to sequence
        sequence.push({
                fn: self.check_visits,
                self: self,
                args: [testrunner, display_results_callback, site, expected_durations],
                interval: 1
        })
        // initiate sequence execution
        self.sequentialize(sequence, 0);
},

// here is the above example test case in code
// it reenacts a user initiating a view of a webpage, going idle,
// coming back, and then ending that page view
self._create_sequence(
        testrunner,
        display_results_callback,
        site,
        [{
                fn: self.time_tracker.start_recording,
                self: self.time_tracker,
                args: [site.url],
                interval: Math.floor(Math.random()*7000)+2000,
                expected_visit: true
        }, {
                fn: self.idle_back_listener.idle,
                self: self.idle_back_listener,
                args: [],
                interval: Math.floor(Math.random()*7000)+2000
        }, {
                fn: self.idle_back_listener.back,
                self: self.idle_back_listener,
                args: [],
                interval: Math.floor(Math.random()*7000)+2000,
                expected_visit: true
        }, {
                fn: self.time_tracker.stop_recording,
                self: self.time_tracker,
                args: [],
                interval: 0
        }]
);

Proudly ProcrasDonating,
Lucy.

What are all the visualizations and analyses we could do for tracking time?

This already has one of my favorite features: enumeration. I’m a natural judger: I perceive more than I observe; I think from my gut and heart. Despite this, or perhaps because of it, I love building out the space before narrowing it down.

Mapping out a space can be especially useful after an initial creative brainstorm. It forces one to consider the corners and holes one didn’t know existed.

Breaking down ideas also makes them more precise. It helps us understand the salient points, even if the direction of our decision is already made.

Below are the 7 types of time tracking information I’ve brainstormed so far.

1. Timeline, chronology, notable events

A timeline or chronology shows events over time. At most basic it is a list, such as the Visits tab on ProcrasDonate’s My Progress page.

started viewing new url
ended by application switching away from Firefox
2 secs
https://ProcrasDonate.com/my_progress/
December 13, 2009, 11:52:20

It could also be an actual timeline, where the spacing of events is based on the time the events occured. The events themselves can be marked using icons of different shape, size and color to indicate different things.

Timelines can be useful for seeing correlations between events. For example, it might be interesting to mark the end of each week with whether one’s goals were met, as well as when one visited the My Progress page, or whether the computer was asleep before midnight. Does ProcrasDonation lessen after payments are made?

2. Ranking, ordered list

Rankings list items according to some metric, such as number of hours spent on websites.

Rankings can show the hotspot websites, unless the sites at the top of the list are already optimized—I can’t use email any less!—and it is the sites somewhere in the middle that take up some amount of unnecessary time—maybe I can watch a TV show instead of a movie.

Rankings can also be useful as bookmarks, especially if more recent behavior is valued higher than behavior deep in the past. Hotspots are hot for a reason.

3. Amplitude, breakdown over time

Amplitude charts are the canonical time tracking visualization. I made these kinds of graphs first for my own life tracking. How much time did I engage in certain activities over a span of time.

This is the simplest was to view a trend over time. It’s like viewing a chronology of quantitatively comparable events.

Amplitude charts are great ways to view a break down of activities. In addition to overlapping line charts or side-by-side bar charts, one can also stack the lines or bars.

The trend tab on the My Progress page is a good start, but I’d love to see my ProcrasDonate curve broken down by the top 5 ProcrasDonate sites I visit. Then I could see what sites contribute to the different humps.

I will say that I’ve already found the trends informative. It’s clear that every other day I watch a couple TV shows. I avoid hackernews and email most days, and then splurge (note that some of the big humps are from not stopping the time tracker when my laptop goes to sleep for the night; this has been fixed!).

4. Ratio, comparison, balance

I initially overlooked ratios, but after Clay introduced us I see that they’re pretty cool.

Ratios show how much you do one thing versus another. For example, maybe you want to be producing 5 times as often as you are chilling.

Having another perspective on one’s time could be more useful than amplitude alone. People who use the Pomodoro method, which uses two timers to segregate productive time from chilling time, would find this especially useful.

I envision a simple, sparkline-esque monitor of one’s ProcrasDonate v TimeWellSpent ratio, perhaps red or green based on whether that day was above or below the ratio goal. Or we could give up the over time view and go with a dynamic pie chart, akin to the progress meters and gauges we have currently.

5. Accumulation, burn down/up, progress

Accumulation shows ones progress towards a particular total. This is my favorite motivational chart, a la the release story burn down. Perhaps more than the other information types listed so far, this one is conducive to understanding the present in relation to the past and future.

When Pivotal Tracker shows my current burn down compared to the linear burn down, I can see whether I’m on track or not right now.

Even better is when Pivotal Tracker estimates when I’ll be done. The first iteration it was quite pessimistic about my abilities. Even though I was below the linear progress line, I felt spurred on because nuts if I was going to sit still with my expected completion date 2 weeks later than the deadline!

With ProcrasDonate it would be neat to actually set the goal line. I think a burn up makes more sense, so instead of a goal line that starts at 0 hours Monday morning and rises to 12 hours Sunday night, what about a fairly flat goal line that rises sharply on the weekend? What about requiring a near flat line during the mornings? or after 10pm?

Maybe that can even influence alerts and preventative actions by ProcrasDonate.

I’d like to return a moment to my battle with Pivotal Tracker’s expected burn down line. That little guy was full of character. It egged me on in the beginning, and seemed to pat me on the back later. Our relationship is more distant now, but were it an actual cartoon character I could relate to and who responded to my behavior, perhaps I would still find it motivational.

Clay is especially looking forward to exploring this kind of user interaction. I have to say I am, too.

6. Average, compressed trend, period

Averages compress trends over time to a canonical view of some period. Averages are a meta chart, since they can average any of the information types mentioned so far.

This is pretty exciting because after a few weeks, and certainly after months and years, the chronological trends start needing aggregation, and even then there is just too much space to look at. Maybe you see a recurring pattern to your productivity and procrastination, but how do you know if you are doing better this week without making a huge change?

Averages gives you a number that you can strive against. For example, a chart might show you the average number of minutes you ProcrasDonated during any hour of the week. You might see the days of the week on the yaxis and the hours of the day on the xaxis. Perhaps you can mark regions of the chart to indicate goals and even preventive measures, as mentioned in the accumulative type above.

Maybe the points in the chart use size or color to indicate their value, or maybe the points are themselves pie charts indicating the ratio of ProcrasDonation to TimeWellSpent. Perhaps their value, instead of hours spent ProcrasDonating, is simply ProcrasDonation or TimeWellSpent, whichever occurs more often during that hour.

The averages charts can also average amplitude trends over time, and then use arrows to show the current derivatives.

Another neat averages chart is to see the day, as specified by “waking up” and “going to sleep”, with the most viewed website shown for each hour.

As a ProcrasDonate developer, I’d be particularly interested in viewing averages where the period is defined by ProcrasDonate releases.

7. Combination, overlays of above types

Finally, we have combinations, which overlay charts on top of each other.

Without fully understanding the information space, it can be easy to start with a graph that seems useful, and then add features that overtime become quite muddled. Feature creep is what happens when you stop iterating on design.

There is a good chance we find something revolutionary in the combination type. Until we build more basic types and iterate them with user feedback, I don’t even feel ready to speculate.

Proudly ProcrasDonating,

Lucy.

Clay said to view this short iteration as a celebration or break, a chance to recharge by doing whatever I wanted.

What I heard was

GRAPHS GRAPHS GRAPHS!

ProcrasDonate Screenshot: hours per day spent on Pivotal Tracker compared to all sites classified as Time Well Spent

I’ve been looking forward to graphs for a while. Graphs are part of a larger vision of actionable visualizations and analysis.

The first step was integrating existing Javascript graph libraries into our extension. As alluded to elsewhere, and based on previous trouble integrating jQuery UI, I expected this to be troublesome.

In fact, the first night I solved non-graph problems instead, such as honoring Firefox’sprivate browsing mode. By Thursday I thought I was going to work on email newsletters or community page aggregations and return to graphs when I had more time.

I admit I was a little afraid. What if I made graphs that people laughed at? “These aren’t useful! Why do ProcrasDonate developers waste their time making these?” I like looking forward to graphs.

ProcrasDonate Screenshot: Hours per day spent at Hacker News and Hulu

Clay told me not to worry, and my unconscious mind must have heard, because that night I got graphs working. I woke up in the early morning and worked on them some more, took a nap, and kept going. Have track to roll on is such a pleasure.

It was already Friday, release day, and we were in good shape. We decided to push through the Registration page’s recipient percent pie chart and the My Progress page’s trend line chart. Screenshots of these are throughout this post.

ProcrasDonate Screenshot: Percent of each donation received by selected charities. The full donation amount is determined by the user's $/hr rate times the number of hours ProcrasDonated, limited by the user's maximum weekly donation amount.

We pushed to release Friday afternoon, but I ended up spending until Saturday morning getting all the user interaction elements up to snuff. Even if meeting deadlines is important, there is a minimum quality, including quality of process and decision making, that is even more important. Deadlines are a single factor in a larger equation.

I should also mention that our Friday deadlines are internal. Releasing for real Friday afternoon is still a good goal to work towards, but I do like the idea of using the weekend as a buffer if necessary, with releases out the door by Sunday night. Buffers as flex time, to be used for loose ends, documentation, blog posts, celebration or getting ahead on the next iteration, are wonderful.

We also like having challenging goals. It pushes us to accomplish more. Varying within the bounds is ok.

For those of you interested in the technical details, they are appended below.

Proudly ProcrasDonating,

Lucy.

Pie Chart Technical Details

The pie charts are created using gRaphael Javascript library.

In order to provide Raphael with the right document, I wrapped the library in a function with a single document parameter:

function init_raphael(document) {
        [Raphael library code]
}

I wrapped the gRaphael files in functions, too, since they rely on Raphael being initialized first.

I then called everything from my extension’s view like so:

init_raphael(request.get_document());
init_graphael();
init_graphael_pie();

// create pie chart
var paper = Raphael("pie_chart", 550, 250);
var pie = paper.g.piechart(125, 125, 100,
    data,
    { legend: legend,
      legendpos: "east",
      colors: colors });

// add cool effects (copied from g.raphael demo)
pie.hover(function () {
    this.sector.stop();
    this.sector.scale(1.1, 1.1, this.cx, this.cy);
    if (this.label) {
        this.label[0].stop();
        this.label[0].scale(1.5);
        this.label[1].attr({"font-weight": 800});
    }
}, function () {
        this.sector.animate({scale: [1, 1, this.cx, this.cy]}, 500, "bounce");
        if (this.label) {
            this.label[0].animate({scale: 1}, 500, "bounce");
            this.label[1].attr({"font-weight": 400});
        }
    });

Trend Chart Technical Details

The trend charts are created using the DyGraph Javascript library.

I used a similar function-wrapping method to provide the right document.

init_dygraph_canvas(request.get_document());
init_dygraph(request.get_document());
g = new DateGraph(
    request.jQuery("#"+div_id).get(0),
        data,
        {showRoller: false,
         //labelsDivWidth: 350,
        labelsDiv: request.jQuery("#legend").get(0),
        labelsSeparateLines: true,
        axisLabelFontSize: 14,
        pixelsPerXLabel: 50,
        pixelsPerYLabel: 50,
        gridLineColor: "#BBBBBB",
        strokeWidth: 4,
        highlightCircleSize: 6,
        colors: [acolor, bcolor],
        /*xAxisLabelWidth: 50,
        yAxisLabelWidth: 50*/
        });                                                                                                                                                                       

request.jQuery("#trend_chart").children().children().each(function() {
    if ($(this).attr("style").match("bottom: 0px")) {
        $(this).css("margin-bottom", "-.5em");                                                                                                                                    
    }
});

By the way, you can click on the graph to zoom in, double click to zoom out and even set the rolling average were I to enable that input book!

A good week in iCalendar

Some people use calendars to organize future meetings. I primarily use my calendar to track my past.

When I mention my meticulous time tracking to friends they react in one of two ways:

1. Neat. I do that, too.
2. How do you track the time you spend tracking your time?

If your reaction was the first one, I salute you. Please leave a comment telling me all about it.

For the rest of you…yes, haha…you make a good point. There are significant benefits to tracking one’s time, but it only works if the tracking itself takes hardly any effort or time.

So easy I don’t even notice

Tracking webpages should take no time. I switch tabs every few seconds. I view hundreds of different webpages a day without even realizing. Tracking my web habits with deep granularity is not something I could manually do. That’s part of what makes ProcrasDonate so good.

On the other hand, updating my MacBook Air’s iCal program a few times a day takes hardly any time. I simply bring iCal into focus and drag-n-drop events.

I track my time with minimal granularity:

• 15 minutes is the smallest increment
• Estimation is ok
• I care only about the overall category of my actions
• I write short notes for fun if at all

Whenever I want to get feedback on my activity habits, I run a python script that reads my iCal data and generates weekly statistics and graphs.

Analysis

I began tracking my time because I wanted to see how well I could balance a full time summer job with a demanding startup. It turns out I’m really bad at doing two serious projects at the same time.

I’d like to think I’m not as bad as the time tracking makes out, but the truth is that one serious project, with time for sports and simple building projects to recoup creative energies, is my stable resting state. Since I didn’t collect data early enough, the work that went into ProcrasDonate’s winning entry is the stuff of legend and lore.

Weekly chart for a good week

My initial interest was simply to track how many hours a week I worked versus wasted time. Culturally, that’s a compelling number. The python script created a webpage with a list of pretty charts, one week after the other, and weekly statistics. The charts were easy to make using google charts, and looking at colorful charts is uplifting. Nonetheless, I primarily look at the weekly totals.

LifeTracking Trend

After a handful of weeks it became clear that what I wanted to see was trends. How am I changing each week? As well as averages. What do my cycles or weeks or days tend to look like? The big questions I wanted to answer were:

• Am I improving each week?
• What can I learn about myself in order to get better?

Results

In my first month after the summer I spent most of my time implementing a library to interact with Amazon Flexible Payments Service (FPS). It was mucky and slow going. I put in 25-35 hours per week on ProcrasDonate. Surfing the web, eating meals, and talking to people are not included.

The next month got better as I saw the big picture for completing our first beta release. My technical skills were also improving, and in general I was ramping up on how to do this work more and more efficiently.

Finally, in November we started using Pivotal Tracker and sending out weekly releases. That brought my weekly totals up to 50-55 hours per week. Looks like my gushing over Pivotal Tracker is justified

Answering the interesting questions

The interesting questions go beyond summing one’s hours per week. They rely on better charts and better analysis. Signal analysis comes to mind.

At first I’d like to focus on better trend charts, perhaps animated to move across weeks. Perhaps stacked lines? Perhaps 24 hr pie charts? Perhaps correlated with Pivotal Tracker or git events?

I’d like to see all my days on top of each other, with the hours of the day and the number of hours spent on the axes. Then I could see when times of the day were prone to time wasting, and how much variance is in my working hou
I’d like to see all my weeks on top of each other, with the days of the week and the hours of the day on each axis. That way I could see when I am most productive, assuming I have a roughly week-long period for my productivity cycles.

Perhaps I can automatically split the trends into cycles and then look for similarities. How much variance is there in cycle length and productivity? Do sports and other projects seem to spur productivity versus take it away? How does sleep fit into all of this?

That this brainstorming heavily ties into ProcrasDonate hasn’t escaped my attention; that working on these charts conflicts with directly working on ProcrasDonate hasn’t escaped, either

Even so, these questions won’t go unanswered for long.

Proudly ProcrasDonating,

Lucy.

Proudly ProcrasDonating is a technology blog, so I can happily overwhelm readers with all the subtleties of time track and if no one is the wiser then I’ll return to coding undeterred, and will try another blog post later, no harm done. If you have feedback, do share

The ProcrasDonate extension tracks the webpage currently being viewed. Let’s say you open Firefox and start reading GMail. Our extension records the start time.

Your friend has emailed you a link to Proudly ProcrasDonating, which opens in a new tab when you click on it. When you go to the new tab, the URL bar changes, which triggers our url bar listener. The listener stops recording the GMail visit, which is in turn saved in the database, and starts recording the Proudly ProcrasDonating visit.

If you switch back to the GMail tab, the visit to Proudly ProcrasDonating is halted and saved, and a visit to GMail is initiated. Same for switching between multiple Firefox windows.

We only record the webpage currently being viewed.

(This might be problematic for people who listen to internet radio or stream tv shows while they work. If you never visit the audio page, then we don’t know about it. I personally wouldn’t count that time as ProcrasDonating if the tabs I were actively viewing are work, but if I wanted to contribute to the audio content providers via TimeWellSpent, I wouldn’t be able to.)

* * *

Tracking the URL bar notifies us whenever the user visits a different webpage. However, we also need to be notified when the user does other things, including:

1. Opens or closes Firefox
2. Switches to another application and back to Firefox
3. Walks away from the computer and comes back
4. Puts his computer to sleep and wakes it up
5. Force quits Firefox (or Firefox quits unexpectedly)

I’m going to explain each of these issues in turn, including the current state of things.

User opens or closes Firefox

This is covered by our InitListener, which is an

on the browser for ‘load’ and ‘unload’ events. Its time tracking is straightforward: stop recording when Firefox closes.

The tricky part is that when Firefox opens we don’t know whether it is in focus or not. The user might have opened Firefox and then switched to a different application before our extension is fully loaded and listening.

Right now we assume Firefox is out of focus; thus, we err on not recording the initial visit rather than record a false visit.

User switches to another application and back to Firefox

This is covered by our FocusBlurListener, which is an

on the browser for ‘focus’ and ‘blur’ events. A focus event occurs when an element, such as form field or the url bar, gains focus. A blur occurs when an element loses focus.

Let’s say the user is typing “procrastinate less” into the google search bar. The search bar has the focus. Halfway through typing, the user decides to click on the ProcrasDonate meter in their toolbar. The search bar blurs and the meter icon gains focus.

Because of “bubbling,” the containing elements also gain and lose focus. Thus, a single mouse click can trigger a dozen focus and blur events.

We care about the last event. If the user is clicking on Firefox elements, then the last event is some element gaining focus. If the user is clicking on a different application, or alt-tabbing to a different application, the last event is a blur event, since no Firefox element is gaining focus from the one that loses it.

Thus, the first time* a focus or blur event occurs, a timeout is set to run in 1 second. Also, every focus and blur event sets a last event type flag to either focus or blur.

After 1 second, the timeout function is called. If the last event type flag is focus, then we know Firefox is the active application and we may need to start recording a visit. Otherwise, we know Firefox is not active, and we should stop recording the visit.

*The timeout function also resets the first time flag.

User walks away from the computer and comes back

This is covered by our IdleBackListener, which registers with Mozilla’s idleServer,

. This is a neat service since the notifications come for the user’s operating system. I suspect this means that pressing volume and lighting controls, in addition to standard keyboard and mouse actions, including scrolling, also triggers non-idle-ness. It might be different per operating system, and it also can add up to a 5-second delay on notifications.

Detecting idleness is pretty tricky. We don’t know whether the user is reading an article or taking a bathroom break, nor whether the user is watching a video or was interrupted and is now talking to a friend.

To make matters worse, we can’t tell what’s happening with flash. Is the movie paused or is it playing? Is it an advertisement or an hour long show?

We try to err on the side of caution. We register two IdleBackListeners, one for flash pages and one for no-flash pages. The no-flash idle timeout occurs after a few minutes. There’s only so long one can read a single screen of text. If nothing happens, we give the user the benefit of the doubt and stop recording the visit. When the user comes back, we start recording again.

If the currently viewed webpage does contain flash then we wait for the 20 minute “idle with flash” timeout to occur. We figured that 20 minutes was the length of a short TV show, and would do for a default guess. If the user is watching a full movie, then maybe he will have to move his mouse within 20 minutes anyway to keep the screensaver from interrupting.

We plan to make idle detection more precise eventually. The backend already supports per-website idle timeout lengths. Time yet for iteration.

User puts his computer to sleep and wakes it up

I hadn’t initially thought about this case. Of course, it didn’t take long to realize that if I closed my laptop with Firefox the active application, I’d return to see a sudden spike in ProcrasDonation visits.

At first it seemed there was no Mozilla listener for the computer going to sleep or waking up. One solution would be to set our own timer to periodically chirp. If it ever chrips and notices that its last chirp was longer ago than expected, then some kind of pause occurred, and the current visit should stop at that last chirp.

Fortunately for my street cred, I was able to google and forum search it up until I found something interesting about Firefox’s download manager: it pauses downloads when a computer goes to sleep, and resumes them when the computer wakes up. A code search immediately turned up this gem here:

mObserverService->AddObserver(this, "sleep_notification", PR_FALSE);
mObserverService->AddObserver(this, "wake_notification", PR_FALSE);

That looks like C code. Futzing around with Javascript soon yielded success, which now lives in our SleepWakeListener:

this.observerService.addObserver(this, "sleep_notification", false);
this.observerService.addObserver(this, "wake_notification", false);

it was almost too easy. I emailed Eric Shepherd, Developer Documentation Lead, to ask why these notifications were not included in the Observer Notification page.

Simple omission apparently. I’ve since added a Computer Sleep, Wake section to the Observer Notification wiki page.

(A side-benefit of having sleep and wake work is that now when I close my laptop to go to bed, a time when I often forget to update my meticulous life-tracking calendar, I can simply read the last few messages in my development logs the next morning.)

User force quits Firefox (or Firefox quits unexpectedly)

There may be times when Firefox’s close notifications are not called, for instance an unexpected power outage, or a memory-leak-induced forced quit.

The chirps don’t sound like a bad idea now, although there might be a notification for when Firefox opens after not closing correctly.

I’m going to have to get back to you on this one since I’m still working on it.

It might also be nice to show the largest visits of the past week and allow submitting them as bugs, which would also subtract them from the time tracking totals.

I hope that cleared some thing up. Questions and suggestions are welcome as usual.

Proudly ProcrasDonating,

Lucy.

Original extension architecture

The above diagram shows our original extension architecture. It’s not a hacked together mess by any means, but not all of the object oriented behaviors went with the right objects. Mix in some dead or duplicated code from learning how to write extensions and soon it’s hard to keep things straight.

Dan wrote this while I mucked around with views and the data model, so don’t think I’m complaining. It worked! Nonetheless, reading through the code sufficiently confused me so that in the diagram I listed each object’s functions, including who called what, and also who used what preferences, which made the diagram so confusing I then added big red arrows to give the big picture.

Super awesome extension architecture

This diagram shows how our refactored extension architecture currently looks. Beautiful isn’t it? It’s not a true apples-to-apples comparison with the original diagram since this one contains much less information. I suppose that is also good news, since it means I’m more intimately acquainted with the code and APIs, and therefore no longer needed to spell everything out.

Nonetheless, the code has been greatly clarified. Part of the reason I can look at each object and know what it does is because each object does exactly what one would expect. The main improvements are:

• Listener objects
• Appropriately placed fields
• Deleted dead, duplicate code

Listener Objects

Our extension has a number of listeners:

• InitListener
• PageLoadListener
• URLBarListener
• UninstallListener
• BlurFocusListener
• SleepWakeListener
• IdleBackListener (x2)

In the past couple weeks I’ve added those last three listeners, plus half of the uninstall one. Even though the extension’s main object, myOverlay, originally contained just three listeners, the jumbling of code made it seem super complicated.

All of the non-view and non-lib code was shared between Overlay and PDDB (ProcrasDonateDataBase). This included install and upgrade code, website tracking listeners and logic, database initialization and page load logic.

myOverlay was itself the listener to various events, although it did instantiate a URLBarListener instance that subclassed, in a sense, from Overlay. Some listeners weren’t able to unregister properly. Some of the new listeners wanted to live in PDDB.

myOverlay and PDDB did too much. Now they delegate to happily packaged listeners.

Each group of listeners that make a listening concept, such as “em-action-requested” and “quit-application-granted”, from which we determine whether to uninstall the extension, is now packaged into a handy class. The constructor takes necessary state, such as access to PDDB and preferences, and automatically registers itself.

Additionally, I abstracted all the time tracking logic, such as start_recording and stop_recording, into a TimeTracking object which is passed into the constructors of the time tracking listeners.

Appropriately placed object fields

There’s nothing more confusing than our database ORM also doing time tracking logic and url dispatch. And why did I put the toolbar manager inside the url bar listener?

The new setup is clear as water. Overlay registers the InitListener. The InitListener loads everything else: all of the state (PDDB, TimeTracker, Schedule, Controller, Prefs, PD_API, ToolbarManager); and all of the listeners. PDDB just initializes state. The Controller’s URL dispatch is called from PageLoadListener, just as you’d expect.

When InitListener’s uninit is called, it unregisters all of its listeners.

Deleted dead, duplicate code

Finally, it helps when there is just one Controller instantiation, rather than an array of controllers and various Controller references, including a PageController, which is already a field of Controller. I guess this wasn’t problematic because even though our code is object oriented, there is very little instance state. Boy would that be a hard bug to track down one day…

While refactoring the code, I was able to remove many of the unnecessary variables and functions that come from iterative learning. In one place we used the “nsIPrefService” directly, whereas in most others we used our abstracted PreferenceManager object. Now we use the PreferenceManager everywhere, and not by asking for the one inside PDDB! Same goes for accessing the ProcrasDonate API. No longer does the view have to access it through

. The view gets its own reference on instantiation, just as PageController does.

Epilogue

I took apart the code yesterday morning. It was a working well oiled machine by yesterday night. According to my meticulous records that meant I spent at most 9 hrs on this story.[1] I spent maybe two days prior informally thinking about the re-factoring I wanted to do (which is meticulously recorded as sleeping and walking with Bear to the park).

It was adding the SleepWakeListener a few days ago that tipped me over into re-factoring. After doubling the number of listeners and having to run the gamut of warning lights and not-quite-working binds, I was ready to make adding features easier and better.

Last night, once I completed putting things back together, I didn’t have any heinous bugs. I wasn’t expecting any, which is an unusual and awesome feeling that I’m chalking up to my excellent understanding of our code and the Mozilla API, rather than some kind of ignorant risk-taking or good fortune. Either way, I closed my laptop, brushed my teeth, and when I came back to admire the beautiful new architecture one last time before bed, ProcrasDonate verified that my last page view had only lasted 5 seconds rather than 5 minutes.

Proudly ProcrasDonating,

Lucy.

ps – We also still pass all of our regression tests. How to test listeners will have to be a different blog post.

pps – I do take meticulous records, which I’m looking forward to blogging about later. [edit: see Life Tracking]

ppps – Wondering what these listeners are? Here’s a simplified explanation

InitListener – Called when a window is loaded or unloaded

PageLoadListener – Called when a page is loaded

URLBarListener – Called when the url bar changes

UninstallListener – Called when the user requests the extension is uninstalled, cancels that request, or closes Firefox, at which point a request uninstall will occur

BlurFocusListener – Called when a window element gains or loses focus (used to track whether Firefox is the active application)

SleepWakeListener – Called when the user’s computer goes to sleep or wakes up

IdleBackListener (x2) – Called when the operating system reports that the user has been idle for a specified period of time (we specify two times, and thus have two listeners)

This fun chart is from Pivotal Tracker. It’s a stacked line chart of the types of stories we’ve completed each iteration since we began using Pivotal Tracker.

The graph provides a colorful analysis of how we allocated our efforts: squashing bugs; bulking up the code; adding functionality.

Seeing past results is powerful. One naturally follows the trend into the future. What breakdown do we want? Is it good or bad to spend time squashing bugs? I can’t help but feel extra motivated in bringing the red line (bugs) down to 0. I wonder if the black line (chores) is cyclic, and if so with what frequency. Can I raise the blue line (features) consistently? Will all these short term metrics trick us into making a bad decision?

It will be fun to find out.

Note that bugs and chores are always 1 “point” on the chart, since we’ve opted not to assigned points to them. Keeps us driving towards features since that’s the only way to burn down each iteration’s point-based allocation of stories. Although we can’t precisely compare story allocation to time spent, these results look like a reasonable proxy.

I don’t have too much more to say on this. Just wanted to share something colorful while we wait for more data to come in.

Proudly ProcrasDonating,

Lucy.