Difference between revisions of "Milestone 10 Pumas"

From crowdresearch
Jump to: navigation, search
(Updated Prototype)
(Updated Prototype)
Line 7: Line 7:
 
== Updated Prototype ==
 
== Updated Prototype ==
  
[[File:Votism2.jpg]]
+
[[File:Votism2.jpg]]<br>
 +
 
 +
I like to start with a top level approach to things, so my immediate question is what is the goal you are trying to achieve. And I believe the goal is to expand workers' involvement past simple task completions. You basically want to give them a voice. This way the requester has a better understanding of the needs of the workers and can receive feedback that would allow the requester to create better tasks. Happy workers = good workers. So your goal with Votism is to give workers a place to suggest changes for the requester. Workers submit a proposal, and a requester will then take the most popular proposals and decide to implement the changes. 
 +
I think this is a good mechanism that should be part of any crowdsourcing project. As a requester, I have often had to iterate the design of the task until I reached a point were, for the worker, the task was easy to understand and easy to accomplish quickly and accurately. This feedback loop your proposing would be awesome. 
 +
I would suggest changing to up/down votes instead of stars. I'm not sure, but I'm thinking up/down votes is a better way to rank ideas. I have some Luis-science hypothesis in my head which may or may not be true. Where I work we have a suggestion forum, ideas are voted up or down. I like how it works. Star system makes me think of foursquare or netflix. 
 +
 
 +
=Possible additions to Votism:= 
 +
* Ideas should have a space for discussion. Comment thread with ability to vote on comments.
 +
* For idea implementation, I'm thinking of an "Agile-style" approach. Ideas which are voted the highest are reviewed by the requester(s) and he/she will determine how important and how easy it is to implement the new idea. Based on those two criteria, every two weeks or so the requester will choose a few of those ideas and implement them to the satisfaction of the workers. And so on until the whole project is completed.
 +
* Perhaps a rating system that shows how well a requester responds to worker's ideas (demands?).
 +
 
 +
=Several issues I can think of:=
 +
* Changing the task mid-way might affect the results depending on what you're trying to do. If a requester is conducting a research experiment, you probably can't change the task halfway because that might skew your results. You'd have to complete a cycle, and implement changes in the next iteration. Perhaps the feedback received from the workers will allow the requester to get better results for her research. 
 +
* Two-week sprints for implementing changes assumes the whole project will last much more than two weeks. Perhaps a sprint could be every couple of days. Or perhaps you just prioritize which idea from the workers you want to implement, you do it, and then you move on to the next.
 +
* There is also some assumption that the worker will repeatedly work on the requesters tasks. Sometimes workers just work on tasks for a couple of days and go on to the next project. I think this happens with Mechanical Turk. The more repeated interaction there is between a worker and a requester, the greater the interest and the benefit in having two-way communication and feedback. Perhaps something that a platform could emphasize is the ability to repeatedly work with the same requester. Maybe even have reputation scores on requesters ("This requester is cool to work with 5/5 would work again").
 +
 
 +
One of the main features of open governance is transparency: If you can have clear, transparent, and easy to use channels of communication between the workers and the requesters, you will have more transparency, which in theory should lead to a better platform.
 +
 
 +
Those are my thoughts for now. I will keep trying to be involved as much as I can. I will at least be a little more present in slack, and you can always feel free to respond here, or reach out via email.
  
 
== Individual User Study Details ==
 
== Individual User Study Details ==

Revision as of 00:39, 6 May 2015

Template for Milestone 10

Summary of what idea this prototype is attempting to test

A summary of what idea this prototype is attempting to test. Also talk about the improvements you made over the last week's proposal/prototype. Interactive prototypes encouraged.

Updated Prototype

Votism2.jpg

I like to start with a top level approach to things, so my immediate question is what is the goal you are trying to achieve. And I believe the goal is to expand workers' involvement past simple task completions. You basically want to give them a voice. This way the requester has a better understanding of the needs of the workers and can receive feedback that would allow the requester to create better tasks. Happy workers = good workers. So your goal with Votism is to give workers a place to suggest changes for the requester. Workers submit a proposal, and a requester will then take the most popular proposals and decide to implement the changes. I think this is a good mechanism that should be part of any crowdsourcing project. As a requester, I have often had to iterate the design of the task until I reached a point were, for the worker, the task was easy to understand and easy to accomplish quickly and accurately. This feedback loop your proposing would be awesome. I would suggest changing to up/down votes instead of stars. I'm not sure, but I'm thinking up/down votes is a better way to rank ideas. I have some Luis-science hypothesis in my head which may or may not be true. Where I work we have a suggestion forum, ideas are voted up or down. I like how it works. Star system makes me think of foursquare or netflix.

Possible additions to Votism:

  • Ideas should have a space for discussion. Comment thread with ability to vote on comments.
  • For idea implementation, I'm thinking of an "Agile-style" approach. Ideas which are voted the highest are reviewed by the requester(s) and he/she will determine how important and how easy it is to implement the new idea. Based on those two criteria, every two weeks or so the requester will choose a few of those ideas and implement them to the satisfaction of the workers. And so on until the whole project is completed.
  • Perhaps a rating system that shows how well a requester responds to worker's ideas (demands?).

Several issues I can think of:

  • Changing the task mid-way might affect the results depending on what you're trying to do. If a requester is conducting a research experiment, you probably can't change the task halfway because that might skew your results. You'd have to complete a cycle, and implement changes in the next iteration. Perhaps the feedback received from the workers will allow the requester to get better results for her research.
  • Two-week sprints for implementing changes assumes the whole project will last much more than two weeks. Perhaps a sprint could be every couple of days. Or perhaps you just prioritize which idea from the workers you want to implement, you do it, and then you move on to the next.
  • There is also some assumption that the worker will repeatedly work on the requesters tasks. Sometimes workers just work on tasks for a couple of days and go on to the next project. I think this happens with Mechanical Turk. The more repeated interaction there is between a worker and a requester, the greater the interest and the benefit in having two-way communication and feedback. Perhaps something that a platform could emphasize is the ability to repeatedly work with the same requester. Maybe even have reputation scores on requesters ("This requester is cool to work with 5/5 would work again").

One of the main features of open governance is transparency: If you can have clear, transparent, and easy to use channels of communication between the workers and the requesters, you will have more transparency, which in theory should lead to a better platform.

Those are my thoughts for now. I will keep trying to be involved as much as I can. I will at least be a little more present in slack, and you can always feel free to respond here, or reach out via email.

Individual User Study Details

Here you should describe in detail the key findings you observed from your user studies. Feedback you got, observations you made about their usage, etc.

User 1

User 2

Summary of your User Study

Here you should summarize the key findings above, in a nice, concise, bullet-point format.

  • Key finding 1
  • Key finding 2

Improvements to Idea based on Prototype Testing

Here you should identify potential improvements you can make to the idea and prototype based on the testing and feedback you got from users.