TODO
====

 * Drop separate development directory for more complicated build process.
   - Generate files in-place (maybe even include in commit, although I hate that.)
     Automatically update gitignore for generated files?
   - Add header to files to make sure they are not edited as source files by accident.
   - A smarter copy might also fix this, maybe we should implement our own copy.
   - Can we do amd dependency checks?
   - We should also lint the generated javascript, because coffee
     doesn't catch accidental globals
 * Have a generic page-wide note (rounded corner, close button thingy)
   for notification (maybe completely replace the toaster?)
 * Response:
   - should we show response answers after submission?
   - idem after the run ended?
 * Questions
   - Question is always shown as 'no topic' when no category is added to it.
   - Fragile: widget creation relies on the names in Factory, but
     these must match the types returned by the actual widgets. Fix
     this.
   - Would be nicer if only newly dropped questions are in edit mode
     and the ones that exist on load in view mode.
 * Codes
   - Details need to be figured out. Now we have a code in one place,
     we add indices to disambiguate. Should we allow code editing all
     the way to the lowest detail? And should it be the complete code or
     just additions?
   - Check that question codes are unique in the database.
   - It might be good to show the codes in GUI, so they know at least
     which element will be called what
 * Validation
   - restore our json schema, there's probably several problems, it
     was disabled because the questions didn't pass anymore.
   - use it server side (and maybe client side as well?)
 * Editing
   - Warn if leaving a page that has edits.
 * Validate documents on the server before saving them.
 * Implement authentication and later authorization.
   - Can we hook in request API so stores work correctly?
 * Export answers for a survey run
   - Allow to include partial results, or just include submission date.
   - Include an URL to the dataset/run so it can easily be traced back.
   - Flatten object structure
 * Check if it works on tablets. We could consider special tablet UI
   later.
 * Sessions
   - modes: fixed, bulk, registration
   - off-line session:
     * provide a portal page where people can select available survey,
       maybe later see progress.
     * Allow for a registration round at the beginning (email, nick).
     * Show name clearly in portal, to prevent mistakes with the
       tablets.
     * Allow sessions based on subnet or a session code (A23X5Y).
     * Easy grouping of participants or selecting a subset for a
       survey.
     * On the server (localhost) show the ip(s) that people should
       connect to.

Checklist
=========

 * Form validation (use tooltips!)
 * Input validation & escaping
   - E.g. texts and labels of ScaleWidget are directly put in innerHTML, I don't think TextBox does any escaping.
 * Output escaping
 * Widget life-cycle
   buildRendering -> widgets in code before set attributes
   postCreate -> after all inits, but before in DOM
   startup -> after insertion in DOM?
 * Review current JSON formats, do they allow for extension or extra meta-data?
 
Open issues
===========

 * Do different inputs in one question get different codes? E.g. in 
   To ease exporting into other programs and easy communication, the codes
   are important I think. It should be easy to pronounce, and easy to
   find in the tool (people might get a dataset and not know where it
   came from).
 * What if a question is included in a survey multiple times. Use block
   or allow a pre/post-fix on the code to differentiate it.
   Should not be too much work, so if an scale with 5 items has 5 codes,
   you should be able to set a prefix on all of them at once.