Index: Dev/trunk/docs/TODO.md
===================================================================
--- Dev/trunk/docs/TODO.md	(revision 463)
+++ Dev/trunk/docs/TODO.md	(revision 463)
@@ -0,0 +1,73 @@
+TODO
+====
+
+ * 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.
+ * 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?)
+ * 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.
Index: Dev/trunk/docs/TODO.txt
===================================================================
--- Dev/trunk/docs/TODO.txt	(revision 452)
+++ 	(revision )
@@ -1,48 +1,0 @@
-Todo
-====
-
- * Check that question codes are unique.
- * Validate documents on the server before saving them.
- * Implement authentication and later authorization.
- * Question is always shown as 'no topic' when no category is added to it.
- * Check that answers are saved correctly.
-   Answers to multi-item questions (like scales) are stored in an object
-   now with index as keys. This is not symmetrical with the fact that the
-   configuration is an array.
- * Export answers for a survey run
- * Revive json schema checks for our data.
-   Questions don't pass the schema at the moment.
- * Fragile: widget creation relies on the names in Factory, but these
-   must match the types returned by the actual widgets. Fix this.
- * Write a spec for the codes.
- * Don't allow Save in Question unless all question items are done editing.
- * Use node as a server, adopt the layout described in
-   http://dojotoolkit.org/documentation/tutorials/1.8/node/
-   This will require quite a lot of moving and creating a rest interface
-   -> can be just a proxy to CouchDB in he beginning.
-
-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.
