User:Paul Clark/Design Study

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
m (Fixed a link)
m (Current State: Update)
Line 41: Line 41:
 
This section should be updated around once a week. More detailed development happens on my [[Paul Clark's Whiteboard|Whiteboard]]
 
This section should be updated around once a week. More detailed development happens on my [[Paul Clark's Whiteboard|Whiteboard]]
  
I haven't got all that much yet ([[User:Paul Clark|Jimmy]] 08:49, 26 July 2010 (UTC)). I am going to work on some user stories quickly so I can find out what functionality I need to implement. I believe I just need to stop thinking quite so high level.
+
Implemented a basic Person oriented CLI program. Only data storage at the moment is using Java serialisation, so of course data wont persist very long during development. Lots of logic currently lives in a CLI class, this probably needs to be pushed out somewhere soon. Also possibly need to implement a more Network oriented interface. Currently tasks can only be assigned to the creator and are also stored in a Network of which the creator is a member.
  
 
So, what I have so far is this: People will have tasks assigned to them (the items on the ToDo list). The people will be in a 'network' so that if say someone makes a task 'Wash the dishes' worth 40 points, and allows anyone to claim the task (so that they can complete it and get the points), but doesn't assign it to anyone initially, the task can be available to anyone within the network (i.e. all flatmates). I have had a couple of ideas of how to structure it (see my [[Paul Clark's Whiteboard|whiteboard]], but I will just implement it the simplest way I can and see what tensions evolve between the different relationships.
 
So, what I have so far is this: People will have tasks assigned to them (the items on the ToDo list). The people will be in a 'network' so that if say someone makes a task 'Wash the dishes' worth 40 points, and allows anyone to claim the task (so that they can complete it and get the points), but doesn't assign it to anyone initially, the task can be available to anyone within the network (i.e. all flatmates). I have had a couple of ideas of how to structure it (see my [[Paul Clark's Whiteboard|whiteboard]], but I will just implement it the simplest way I can and see what tensions evolve between the different relationships.

Revision as of 03:58, 26 September 2010

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.


(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

Current State

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

Implemented a basic Person oriented CLI program. Only data storage at the moment is using Java serialisation, so of course data wont persist very long during development. Lots of logic currently lives in a CLI class, this probably needs to be pushed out somewhere soon. Also possibly need to implement a more Network oriented interface. Currently tasks can only be assigned to the creator and are also stored in a Network of which the creator is a member.

So, what I have so far is this: People will have tasks assigned to them (the items on the ToDo list). The people will be in a 'network' so that if say someone makes a task 'Wash the dishes' worth 40 points, and allows anyone to claim the task (so that they can complete it and get the points), but doesn't assign it to anyone initially, the task can be available to anyone within the network (i.e. all flatmates). I have had a couple of ideas of how to structure it (see my whiteboard, but I will just implement it the simplest way I can and see what tensions evolve between the different relationships.

The current state of my design
The current state of my design

User Stories

External Links

Personal tools