User:Paul Clark/Design Study

From CSSEMediaWiki
Jump to: navigation, search

Contents

Abstracted Motivation: A Points Oriented ToDo List & Scheduler

The project name is still being worked on.

Also, the page as it is now was written hastily and the sentence/paragraph structure isn't written to aid readability, this will be remedied shortly

My Log

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).

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.


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

Current State

This section should be updated around once a week. More detailed development happens on my Whiteboard

Task

  • Q)All tasks must be kept somewhere – even when they are not assigned to anyone – where? A) Maybe users should be part of a network, but a network should be more than a just an aggregate of people. This way if a user creates a task but doesn't assign it to anyone, it would still be a member of the network object and will be found when the group is queried for un-assigned tasks. A) Maybe a network should just be a type of doer, but when executing a task it just puts it into the unclaimed tasks list? But then how does the task get assigned to someone? Maybe the class which gives the task to the network searches through the user list looking for the user who the task was assigned to. But since the user list is stored in the network then the assigning class needs to know that there is a difference between a network and a person, and which doer is a network and not a person. So there is no point using composite at all because the points always need to go to an individual person.
  • Q) More than one person can have a task, what does this mean for the Person.execute() method? – A) When the task is created (and/or later, maybe by a group op) it should be created as a x person task with y points per person (or as a task worth x payouts of y, this would be analogous to a multistage task, harking back to the %done field of traditional PIM apps ). Each person has to execute it or maybe it should be executed x times, no matter who by. The second option is probably more correct because a task shouldn't know who it has been assigned to.
  • The task must have some way of recording who executed it.
  • 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.
  • Maybe a Task object could have a getSchedule method which returns a list of all the dates at which the task occurs over the specified amount of time, or a year by default.
  • Also need a setWorth method set the number of points the task is worth.
  • 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.

User Stories

External Links

Retrieved from "https://oowisdom.csse.canterbury.ac.nz/index.php?title=User:Paul_Clark/Design_Study&oldid=6073"
Personal tools