Summer Milestone 10 lucamatsumoto Macro Work Submission
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, and it may have a complex format. It will be in binary format like PDF, or application specific files such as doc, ppt, xls, mp3 etc.
- 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 codes and their names may vary.
- Requesters may want to specify file name patterns in some cases.
- How do requesters get the files submitted by workers? Download manually from our site, or should we provide a convenient way?
- Features for Macro Work Submission
- Upload binary file(s)
- Use the file names given by workers
- Requester can specify file naming convention
- Requester Google Drive/Drop Box integration to get the files (nice to have?)
- The following are the page design ideas. It doesn't include all the features listed above.
- Option 1: Add "file upload form" to the prototype page
- Option 2: Create a new page to upload multiple files
- Option 3: File Grid
- If requester posts multiple files for the task and wanted to get a result file for each, we can use a grid style UI. The worker can see the progress too.
1. Google Drive/Drop Box Integration (nice to have feature?)
- Requesters may want to receive the work files in their Google Drive/Drop Box folder. If so, the files should not be uploaded to Google Drive/Drop Box directly. It should be done through Daemo. If we allow workers to upload files directly to Google Drive/Drop Box, we can't keep track of 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?
Below is just for my memo. I need to think more on these.
Current TaskWorkResult model is like this.
TaskWorkerResult task_worker = ForeignKey result = TextField template_item = ForeignKey statuses = ((1, 'Created'),(2, 'Accepted'),(3, 'Rejected')) status = IntegerField
It has just one TextField for result. We need a way to associate multiple files to the TaskWorkResult.
Work id AutoField task ForeignKey (id) -> Task comment TextField file_count IntegerField
The file count field above is to keep the number of files originally uploaded. This may be useful because the files may be deleted later or requesters my lose them after moving them to Google Drive/Drop Box.
WorkFiles id AutoField work ForeignKey (id) -> Work link TextField (or URLField)
Page URL: /work/ API URL: /api/work/