Latest revision as of 03:21, 25 November 2010

Abstracted Motivation: A Points Oriented ToDo List & Scheduler

File:PaulClark-src-and-jar-2010.zip

Brief

Some people (e.g. this author) are lazy, they don't do the things which would be most beneficial to them at all times[1]. One possible solution to this problem of motivation is to mandate that rationality [2] and behavioral psychology be taught in schools, but even if you know are well versed in those fields, applying the concepts can be hard[3]. So sometimes (in my opinion) it is more efficient to manipulate people to do what is best. Or even to manipulate oneself to do what is probably best. This concept can be expanded to allow systems to be put in place which will ensure that the best option is more likely to be taken in any anticipated situation.

When looking to motivate people to do 'as they should be doing' one place which we can take inspiration from is games. The most successful games are those in which people are compelled to invest lots of time (and to do this, the games must be efficient at motivating people). Some of the aspects which make gaming so compelling may include: 1) Seeing the quantified benefit of a task completed (experience points, stats increases, leveling up), 2) working toward a definable goal (as opposed to a vague goal like 'achieve success'), 3) working toward an achievable goal (just 10,000 more exp points), and a biggie - 4) being able to see all the people you are better than, or the people who were better than you, but now are not.

So this program is all about augmenting RL with some of the things that motivate people to play games so often and with so much commitment. I am aware that this sounds like a rather broad goal, but hopefully the proposed OO nature of the design will make achieving this goal a matter of many small incremental additions beyond the scope of this project. Some people think that doing the work of ranking the relative value of a task and entering it into a PC program before even starting it will not motivate people. I think that once you make ranking tasks a habit – and if the quantified results of your decisions are highly visible – then you can become quite motivated, especially if you start out just ranking trivial tasks until you get some points built up in the system (i.e. make an investment in the virtual world).

So basically this is a ToDo application. One in which the items on your ToDo list having a common value (points) attached to them.

Current Design

Currently the design consists of a rather minimal domain model (Task, Person Network), surrounded by a still evolving framework to build he application around it. The main aspects of the application which have been worked on up to now are the command line interface (CLI) and the scheduling framework. At the moment the scheduling framework needs the most work done to get to a stable state.

• The main feature of the CLI module are the dynamic reflection generated menu generation, using the state pattern to support sub-menus.
• The main feature of the scheduling back end is the set based recurrencey framework based on Martin Fowler's writings.

Reasoning/Rational

Initially I wanted to make a simple ToDo list. So made a Network class, a Person class, and a Task class--trying to keep it simple. For a while I was stuck on these few classes shuffling them around trying to make something pretty. So to try and further my design I just started implementing some logic in a 'CLI' class. The goal was to get a workable ToDo application so that I could find out what was missing. The first thing I found to be missing was persistence. So I implemented Java's 'serialization' interface. Eventually this will have to be changed to a more flexible method of storing interesting fields. The next major thing to add was scheduling capabilities for recurring tasks. The first go at this was way to general. I tried to specify a very flexible syntax for declaring repeating patterns and that ended up having way too many edge cases and some features which were just plain absent (such as specifying an end to a repeating pattern). I decided to re-implement this using the interpreter pattern. More on this later...

Specific Features/Design Decisions

Schedule

Some of Martin Fowler's temporal patterns used to create the scheduling subsystem

For first attempt at implementing a scheduling system I saved a string specifying the base date and time of the event and extra arguments to specify the recurrence rules. I then generated a list of dates from that stored string when the task schedule was requested. The plan was (as always) to implement the functionality before making it a more maintainable OO design. This approach worked (in terms of functionality), the recurrence rule specification language was very flexible but that caused lots of edge cases while parsing it. Also, the parsing function was large and messy. So I figured I could implement the interpreter pattern. While I was looking around for a better way to handle dates in Java I found some patterns specified by Martin Fowler to deal with dates. More specifically, arbitrary precision time points, Ranges (of time), and recurring events for calendars). These look interesting and like they could be used, albeit with a little work, especially his recurring event language. I also found an implementation of the ideas discussed in Fowler's 'Recurring Events for Calendars' PLoS submission. This doesn't extend the functionality discussed in the paper though, so still some work needed. I have started to integrate this implementation into my design ChronicJ and as it stands now everything works, with less functionality than before started using ChronicJ code. I believe this is due to the fact that the project has been effectively dead since early 2004, I plan to modify this project by ripping out the Schedul classes and adding TemporalExpressions to be more inline with runt for Ruby. Runt implements exactly the same ideas introduced in Fowler's paper but has been used a little more recently.

Referring to the picture above, the short story is that an event has a schedule. A schedule can have some sort of recurrence, that is where the TemporalExpresions come in. These are based on a paper by Fowler entitled Recuuring Events for Calendars. The actual clases I am using at the moment were implemented as part of the (now apparently dead) ChronicJ project. These classes are not nearly all the classes required and they are unweiled in many cases, so eventually (ie over summer) they will be made a little more useable.

The way these temporal expressions are used is to create Unions and Intersections composed of AbstractTemporalExpressions. This way one can create a union of 'The first monday' and 'the last tuesday' of the month. Take the difference of that union and a RangeInYear of February to September. So the task would only actually repeat twice a month outside of February and September.

In summary my initial attempt at scheduling ended up being inelegant, and the replacement is currently incomplete an a little unwieldy. Taking into account the basic ideas of Fowler's paper (rather than the examples provided in it) should enable me to create a much more usable set-based date-recurrence framework, given a little free time.

CLI

The state pattern used to generate an interactive CLI menu

I haven't had to write a GUI yet in my time at Uni (except for web based), and I had no extension of starting in my final year. Writing an interactive CLI app in java poses its own challenges though. After spending some time adding new methods to the CLI class, I got rather sick of modifying the menu which was printed out to the user (and the switch statement) to keep in-line with the new methods. So I implemented a system to dynamically generate a CLI menu base on method annotations and Java's reflection framework. Methods are designated as occuring in the CLI menu by annotating them with a custom annotation:

@Retention(RetentionPolicy.RUNTIME)
  @Target(ElementType.METHOD)
  public @interface CLIMenu {
    public String menuText();
    public String menuID();
    public int weighting() default 50;
  }

The menuText field is that which is printed to the console, the menuID specifies which menu this option should appear on, the weighting can modify the default ordering of the printed out list. There can be multiple sub-menus. Although I am keeping it at just one layer deep at the moment. The menus are formed using Java's reflection framework. All public methods of the CLI class are examined for annotations with a menuID that contains the name of the current menu (eg, menuID='Main Task' will appear in the menus named 'Main' and 'Task'). The examining of the annotations of the methods is done in the Menu class, whenever a menu class is constructed it is passed the name of the menu, and all of the public methods of the creator class (CLI in all cases). Then menu.parseArg() is called repeatedly in the CLI class, and a pointer to the chosen method is returned for invocation.

Some methods necessitate the entry into a sub menu (such as 'View Tasks; from the main menu). Switching to a sub menu is handled by using the State pattern. Each sub-menu presents an option to 'go up one level' (usually in the place of 'exit' on the main menu), this keeps the hierarchy of sub-menus to just one deep at the moment.

This method of generating menus does cause some issues. I would rather be able to group menu items relating to similar tasks together, but at the moment menu items are sorted first by the weighting specified in the annotation, and then by the natural ordering of the text in menuText. Other than that, it is a relatively lightweight and flexible way of describing a interactive CLI.

The other option with regard to the state pattern is to implement it as recommended by the GoF. This could be achieved by moving the methods which are designated for particular methods to the relevant implementation of the 'Menu' interface. But in this particular application, there are methods which are common across multiple menus.

Planned Features (including Future Work)

(Higher Level) There will be multiple views of the same basic scheduler/ToDo system i.e.

Classic (outlook) style view of calender with views of upcoming tasks sorted by priority or chronologically.

Avatar + stats + task lists as above (more in the style of epicWinApp

An XMPP extension so that you can use your points to get social status and give you even more motivation.

(Lower Level) A reg-exp-y based scheduler e.g.

This event occurs at 10/03/2010 0700 hrs + i*7 days (so it repeats at the same time every week). Java's calender class should be able to handle months with weird numbers of days &c.

(Lower Level) Tasks whose points increase or decrease over time e.g.

This task is worth 120 + 50*(%theDeadline%-(today + 1 day)) points. i.e. you get 170 points if you complete the task tomorrow, 120 if you complete it on the deadline, and the points rewarded decreases linearly with time, maybe you would even get less than 120 if you completed it after the deadline. Although when it got down into negative territory it would never get completed, so maybe there would have to be a automatically applied penalty to whomever the task was assigned to after the deadline has passed.

(Lower Level) Tasks can be completed by multiple people.

This task is worth 3 payouts of 60 points.

So it is essentially a multi (3) stage task and each stage can be completed by different people (or the same person could complete all three stages)

This is kind of the same as the x% done in classic scheduling apps. It also makes the execute() method an oversimplification. Or does it? If you want to fully finish a three stage task you can call execute() three times.

Points to keep in mind:

• Different people are motivated by different things (thanks Simon)
• Could sync stats and tasks with other platforms like phones, fb &c. to enhance the social re-enforcement aspect
• When someone procrastinates they can choose to do a task because it seems like the most important thing to do now, when in-fact, the person doesn't actually qualitatively compare one potential task with another[4]. Indeed comparing apples with oranges is rather hard. Forcing someone to assign a worth (exp. points) to a task when it is first proposed means that the person has moved from comparing apples and oranges to comparing exp. points with exp. points, and if a points system manages to encapsulate the value of a task, then it is an unarguable that if one task has more points than another, it is more important.
• Got any more ideas?
• Need user and network profile pages

User Stories

• User:Paul Clark/US-001-Add Task
• User:Paul Clark/US-002-Claim an Open Task
• User:Paul Clark/US-003-Execute Task
• User:Paul Clark/US-004-View Unassigned Tasks
• User:Paul Clark/US-005-Edit Task Schedule

External Links

• Jesse Schell's presentation at the DICE 2010 summit - a very enthusiastic look at everything being worth points
• Jane McGonigal's presentation at TED - She concentrated on games which could harness gamers gaming hours and put them to use solving Big Problems People wired up to solve big problems (like a lack of energy), that sounds familiar
• An iPhone app which is presumably inspired by the same ideas espoused by Jesse Schell and Jane McGonigal
• Another (older) web app which gives points for 'chores'