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

Last change on this file since 469 was 468, checked in by hendrikvanantwerpen, 12 years ago

Improved authentication

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