TODO
====

 * App / General
   - Introduce a page-wide note (rounded corner box at the top e.g.)
     for notifications that the user has to confirm.
   - Prevent pages from moving away if they contain unsaved edits.
   - Make sure no user generated content is directly inserted in the
     DOM tree (i.e. innerHTML or .content assignments)

 * Response
   - response url stops working after response is submitted or surveyRun is closed
   - Check if this works on tablets as well.
   - Should we provide degraded options for filling in surveys for
     browsers that do not support JS? This would involve server-side
     rendering, old-school form submission and server-side validation.

 * Question
   - Question is always shown as 'no topic' when no category is added to it.
   - QuestionWidgetFactory relies on the names in the factory, but
     also on the name set in the widget. This is redundant and can
     cause inconsistencies. Remove the names from the widgets, only
     relying on the factory for the mapping.
   - Question codes are not checked for uniqueness.
   - Are question codes defined on the right level? Maybe they want
     control on a per-input basis. We can also provide an alias system
     for older data.
   - Users cannot see the code of a question easily. In survey view
     the code should be shown as well as the title.
   - When editing a question, the user should see the final codes the
     different inputs get, so they can match them more easily to their
     data.
   - Cannot easily find a question based on a code. This is important
     if a researcher wants to see the question related to one of his
     datasets in SPSS.

 * Store
   - Data is not validated before being stored in the database, nor
     when it's used afterwards.
   - Data format should be designedso the database is mostly
     additive. It should also allow for adding metadata later
     (e.g. annotating questions with statistical information about the
     outcome).

 * SurveyRun
   - Cannot export responses as CSV
   - Current response modes are unclear.

 * Sessions
   - Allow ease of use for real-life sessions
     * allow registration by participants or pre-registration by GOD
     * provide a portal with simple access code so people don't have
       to type complicated URL's.
     * Make it easy to bookmark a session as a home icon on iP* or
       Android.
     * Clearly show a participant name/email in the screen to prevent
       errors because of mixing hardware. Maybe force confirmation
       after period of inactivity?
     * It should be easy for a host to start a survey or game to all
       or a subset of the participants. The UI could lead the
       participants in what they have to do next.

 * Rethink build process
   - AMD dependency analysis/checking would be nice