source: Dev/trunk/docs/TODO.md @ 464

Last change on this file since 464 was 463, checked in by hendrikvanantwerpen, 12 years ago

Working towards Heroku deployment, restructuring for that and to allow coffee builds.

File size: 3.1 KB
RevLine 
[463]1TODO
[443]2====
3
[463]4 * Have a generic page-wide note (rounded corner, close button thingy)
5   for notification (maybe completely replace the toaster?)
6 * Response:
7   - should we show response answers after submission?
8   - idem after the run ended?
9 * Questions
10   - Question is always shown as 'no topic' when no category is added to it.
11   - Fragile: widget creation relies on the names in Factory, but
12     these must match the types returned by the actual widgets. Fix
13     this.
14 * Codes
15   - Details need to be figured out. Now we have a code in one place,
16     we add indices to disambiguate. Should we allow code editing all
17     the way to the lowest detail? And should it be the complete code or
18     just additions?
19   - Check that question codes are unique in the database.
20   - It might be good to show the codes in GUI, so they know at least
21     which element will be called what
22 * Validation
23   - restore our json schema, there's probably several problems, it
24     was disabled because the questions didn't pass anymore.
25   - use it server side (and maybe client side as well?)
[452]26 * Validate documents on the server before saving them.
27 * Implement authentication and later authorization.
[463]28   - Can we hook in request API so stores work correctly?
[443]29 * Export answers for a survey run
[463]30   - Allow to include partial results, or just include submission date.
31   - Include an URL to the dataset/run so it can easily be traced back.
32   - Flatten object structure
33 * Check if it works on tablets. We could consider special tablet UI
34   later.
35 * Sessions
36   - modes: fixed, bulk, registration
37   - off-line session:
38     * provide a portal page where people can select available survey,
39       maybe later see progress.
40     * Allow for a registration round at the beginning (email, nick).
41     * Show name clearly in portal, to prevent mistakes with the
42       tablets.
43     * Allow sessions based on subnet or a session code (A23X5Y).
44     * Easy grouping of participants or selecting a subset for a
45       survey.
46     * On the server (localhost) show the ip(s) that people should
47       connect to.
[443]48
49Checklist
50=========
51
52 * Form validation (use tooltips!)
53 * Input validation & escaping
54   - E.g. texts and labels of ScaleWidget are directly put in innerHTML, I don't think TextBox does any escaping.
55 * Output escaping
56 * Widget life-cycle
57   buildRendering -> widgets in code before set attributes
58   postCreate -> after all inits, but before in DOM
59   startup -> after insertion in DOM?
60 * Review current JSON formats, do they allow for extension or extra meta-data?
61 
62Open issues
63===========
64
65 * Do different inputs in one question get different codes? E.g. in
66   To ease exporting into other programs and easy communication, the codes
67   are important I think. It should be easy to pronounce, and easy to
68   find in the tool (people might get a dataset and not know where it
69   came from).
70 * What if a question is included in a survey multiple times. Use block
71   or allow a pre/post-fix on the code to differentiate it.
72   Should not be too much work, so if an scale with 5 items has 5 codes,
73   you should be able to set a prefix on all of them at once.
Note: See TracBrowser for help on using the repository browser.