Difference between revisions of "Summer Milestone 10 lucamatsumoto Macro Work Submission"

From crowdresearch
Jump to: navigation, search
Line 1: Line 1:
 
== Macro Work Submission Page ==
 
== Macro Work Submission Page ==
  
This is the rough design of the page and data model to submit works for macro tasks
+
This is the rough design idea of the page to submit works for macro tasks.
  
=== Page Design ===
+
=== Macro Work v.s. Micro Work ===
 +
What is the difference between macro and micro work? Although they are not fundamentally different, I would imagine,
 +
* Since macro tasks take longer time than micro tasks, the result document may be a lot longer, any may have complex format. It will be in binary format like PDF, or application specific files such as doc, ppt, xls.
 +
* Requesters may or may not know how many files workers will create. For example, if the task is programming in Java, the number of source code and their names may vary.
 +
* Requesters may want to specify file names in some cases.
 +
 
 +
=== Features for Macro Work Submission ===
 +
* Upload binary file(s)
 +
* Use the file names given by workers
 +
* Requester can specify file naming convention
 +
* Google Drive/Drop Box integration
 +
 
 +
=== Page Designs ===
 +
 
 +
Option 1: Add "file upload form" to the prototype page
 +
 
 +
 
 +
Option 2: Create a new page to upload multiple files
  
 
[[File:SubmitWork.png]]
 
[[File:SubmitWork.png]]
  
Assumption
+
=== Open Questions ===
* workers submit files as "work"
+
1. Google Drive/Drop Box Integration
* workers won't access Google Drive or Requester's website directly
+
: I believe the files should be uploaded to Google Drive/Drop Box thru Daemo. If we allow workers uploading files directly to Google Drive/Drop Box, we can't keep track the work submission.
  
So this page gets the file from the worker, then uploads them to the destination servers, like Google Drive.
+
2. How long should we keep the files
If we have template-based macro works, we need a different page for that.
+
: If we store uploaded files in our database, it will eat up the storage space. Should we ask requesters to download the files and remove them from our storage after a while?
 +
 
 +
==== END ====
 +
----
 +
----
 +
==== Need more time to design... ====
 +
 
 +
The followings are just for my memo. I need to think more on these.
  
 
=== URL ===
 
=== URL ===
Line 18: Line 42:
 
  Page URL: /work/
 
  Page URL: /work/
 
  API URL:  /api/work/
 
  API URL:  /api/work/
 
  
 
=== Data Model ===
 
=== Data Model ===
Line 29: Line 52:
 
      
 
      
 
* The file count field is to keep the number of files originally uploaded. This may be useful because the files may be deleted or lost after we upload them to the destination site.
 
* The file count field is to keep the number of files originally uploaded. This may be useful because the files may be deleted or lost after we upload them to the destination site.
* Can a task have many works? or is it one-to-one?
 
  
 
  WorkFiles
 
  WorkFiles
 
     id        AutoField
 
     id        AutoField
 
     work      ForeignKey (id) -> Work
 
     work      ForeignKey (id) -> Work
     link      TextField
+
     link      TextField (or URLField)
   
+
* Should the link be URLField or TextField?
+

Revision as of 21:25, 30 July 2015

Macro Work Submission Page

This is the rough design idea of the page to submit works for macro tasks.

Macro Work v.s. Micro Work

What is the difference between macro and micro work? Although they are not fundamentally different, I would imagine,

  • Since macro tasks take longer time than micro tasks, the result document may be a lot longer, any may have complex format. It will be in binary format like PDF, or application specific files such as doc, ppt, xls.
  • Requesters may or may not know how many files workers will create. For example, if the task is programming in Java, the number of source code and their names may vary.
  • Requesters may want to specify file names in some cases.

Features for Macro Work Submission

  • Upload binary file(s)
  • Use the file names given by workers
  • Requester can specify file naming convention
  • Google Drive/Drop Box integration

Page Designs

Option 1: Add "file upload form" to the prototype page


Option 2: Create a new page to upload multiple files

SubmitWork.png

Open Questions

1. Google Drive/Drop Box Integration

I believe the files should be uploaded to Google Drive/Drop Box thru Daemo. If we allow workers uploading files directly to Google Drive/Drop Box, we can't keep track the work submission.

2. How long should we keep the files

If we store uploaded files in our database, it will eat up the storage space. Should we ask requesters to download the files and remove them from our storage after a while?

END



Need more time to design...

The followings are just for my memo. I need to think more on these.

URL

Page URL: /work/
API URL:  /api/work/

Data Model

Work
    id             AutoField
    task           ForeignKey (id) -> Task
    comment        TextField
    file_count     IntegerField
    
  • The file count field is to keep the number of files originally uploaded. This may be useful because the files may be deleted or lost after we upload them to the destination site.
WorkFiles
    id        AutoField
    work      ForeignKey (id) -> Work
    link      TextField (or URLField)