Home

Welcome to the mkturk wiki!

Original idea & implementation:

Build the simplest possible code to run psychophysics remotely on a tablet. The result was a couple client side files in html/javascript that run a delayed match to sample (DMS in mkturk.html) task and an automator for automatically updating the task parameters (mkturkautomator.js). The server side was left to dropbox (mkturkdropox.js) which not only hosted the webpage but also stored the images and data for the task.

The implemented code is by no means perfect. Now that this proof-of-concept system works, the intent is for anyone to be able to use it as a starting point for quickly implementing their own web-based, touchscreen systems. For additional examples, inquire about MMturk by @shayo, ptap by @mlee3142 both in DiCarlo lab or the implementation by @thouartodd or @yeonankim in Conway lab. The goal of this repository is to give you resources and provide you a working example to get up and running. Of course, we would love feedback on things you do differently or improve upon to relay those contributions back to the community. For our part, our future plans are below.

mkturk v2

Desirables

• Bluetooth capability: (done) integrate bluetooth capability using chrome API. Requires android marshmallow 6.0 or higher.
• Update dropbox functionality: (done) dropbox has released a cleaned up version of its API. mkturk will need to transition to this version. The advantage of using dropbox is in having a stable place to store data that requires little administrative overhead. More on dropbox API v2: http://www.hnwatcher.com/r/2788001/Dropbox-API-v2-Tutorial-Benefits-of-version-2-and-how-to-integrate-it-Android
• Async/Await: (done) syntax sugar on top of generators to make promise code more readable [google] (https://developers.google.com/web/fundamentals/getting-started/primers/async-functions), microsoft
• Drag & Drop Image Loading: (done) Objects are organized by label folders. New folders can be added without having to update code, simply add folder to parameter file. Folders should be organized by objects and images referred to by descriptive label that includes metaparameters and hash.
• Automator improvements: (done) create block modes to select subsets of images based on metaparameters or designated train/test splits.
• USB capability: (done) integrate usb capability using chrome webusb API available in chrome 61+ allowing direct communication with an arduino.
• OffscreenCanvas for image rendering (done)
• Amazon Mechanical Turk Integration see ptap by @mlee3142
• Google Drive Integration (ongoing)
• RFID Sensor (ongoing)
• Smart Scale (ongoing)
• Parameter GUI: (postponed; instead added in situ parameter text editing at beginning of task) gui that allows user to view and set parameters for a given subject that day and for setting up training schedules for the automator. GUI could also display image previews or recent performance stats of subject.
• Database functionality: (postponed) write a script to transfer data from storage location into a database. This step happens offline and may depend on server side hardware that requires within lab administrative effort.

Bucket List

• Liveplot Leaderboard: Extend liveplot to show data for multiple subjects or extended performance history of one subject
• Inclusive Task Structuring: Task is a set of screens with rules between screens. Each screen is a container of precisely specified images (x,y,t). This structure ideally will accommodate DMS, Go-No Go, SR, and N-back tasks.
• Add a functionality for automatically archiving tasks and stimulus images, and enabling one-command recreation of previous task HTMLs for record-keeping / replication / inheritance purposes
• Base code which applies to every mkturk task - does universal things like specifying a base HTML template, logging to Dropbox / some DB, etc.
• Task template code which specifies the rules, temporal structure, and other general aspects of a task. Particulars like the stimulus set to be used, reward amount, etc. are not specified here; this is supposed to be a template that anyone can plug-and-play by using the next item.
• An online interface (like params.txt) used to specify the task template and the parameters of that task (e.g. which image folder / meta to pull stimuli from, stim duration, juice) by the experimenter or by a task automator. Can be used to perform day-to-day (or trial-to-trial) tweaks during data collection.
• A piece of automator code in which a user-specified sequence of task templates / task params can be traversed based on some specified criteria. (e.g. for a training pipeline)