| 1 | TODO |
|---|
| 2 | ==== |
|---|
| 3 | |
|---|
| 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 |
|---|
| 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. |
|---|
| 22 | - Would be nicer if only newly dropped questions are in edit mode |
|---|
| 23 | and the ones that exist on load in view mode. |
|---|
| 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?) |
|---|
| 36 | * Editing |
|---|
| 37 | - Warn if leaving a page that has edits. |
|---|
| 38 | * Validate documents on the server before saving them. |
|---|
| 39 | * Implement authentication and later authorization. |
|---|
| 40 | - Can we hook in request API so stores work correctly? |
|---|
| 41 | * Export answers for a survey run |
|---|
| 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. |
|---|
| 60 | |
|---|
| 61 | Checklist |
|---|
| 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 | |
|---|
| 74 | Open 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. |
|---|
