[463] | 1 | TODO |
---|
[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 | |
---|
| 49 | Checklist |
---|
| 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 | |
---|
| 62 | Open 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. |
---|