| [463] | 1 | TODO |
|---|
| [443] | 2 | ==== |
|---|
| 3 | |
|---|
| [472] | 4 | * App / General |
|---|
| 5 | - Introduce a page-wide note (rounded corner box at the top e.g.) |
|---|
| 6 | for notifications that the user has to confirm. |
|---|
| 7 | - Prevent pages from moving away if they contain unsaved edits. |
|---|
| 8 | - Make sure no user generated content is directly inserted in the |
|---|
| 9 | DOM tree (i.e. innerHTML or .content assignments) |
|---|
| 10 | |
|---|
| 11 | * Response |
|---|
| 12 | - response url stops working after response is submitted or surveyRun is closed |
|---|
| 13 | - Check if this works on tablets as well. |
|---|
| 14 | - Should we provide degraded options for filling in surveys for |
|---|
| 15 | browsers that do not support JS? This would involve server-side |
|---|
| 16 | rendering, old-school form submission and server-side validation. |
|---|
| 17 | |
|---|
| 18 | * Question |
|---|
| [463] | 19 | - Question is always shown as 'no topic' when no category is added to it. |
|---|
| [472] | 20 | - QuestionWidgetFactory relies on the names in the factory, but |
|---|
| 21 | also on the name set in the widget. This is redundant and can |
|---|
| 22 | cause inconsistencies. Remove the names from the widgets, only |
|---|
| 23 | relying on the factory for the mapping. |
|---|
| 24 | - Question codes are not checked for uniqueness. |
|---|
| 25 | - Are question codes defined on the right level? Maybe they want |
|---|
| 26 | control on a per-input basis. We can also provide an alias system |
|---|
| 27 | for older data. |
|---|
| 28 | - Users cannot see the code of a question easily. In survey view |
|---|
| 29 | the code should be shown as well as the title. |
|---|
| 30 | - When editing a question, the user should see the final codes the |
|---|
| 31 | different inputs get, so they can match them more easily to their |
|---|
| 32 | data. |
|---|
| 33 | - Cannot easily find a question based on a code. This is important |
|---|
| 34 | if a researcher wants to see the question related to one of his |
|---|
| 35 | datasets in SPSS. |
|---|
| [443] | 36 | |
|---|
| [472] | 37 | * Store |
|---|
| 38 | - Data is not validated before being stored in the database, nor |
|---|
| 39 | when it's used afterwards. |
|---|
| 40 | - Data format should be designedso the database is mostly |
|---|
| 41 | additive. It should also allow for adding metadata later |
|---|
| 42 | (e.g. annotating questions with statistical information about the |
|---|
| 43 | outcome). |
|---|
| [443] | 44 | |
|---|
| [472] | 45 | * SurveyRun |
|---|
| 46 | - Cannot export responses as CSV |
|---|
| 47 | - Current response modes are unclear. |
|---|
| [443] | 48 | |
|---|
| [472] | 49 | * Sessions |
|---|
| 50 | - Allow ease of use for real-life sessions |
|---|
| 51 | * allow registration by participants or pre-registration by GOD |
|---|
| 52 | * provide a portal with simple access code so people don't have |
|---|
| 53 | to type complicated URL's. |
|---|
| 54 | * Make it easy to bookmark a session as a home icon on iP* or |
|---|
| 55 | Android. |
|---|
| 56 | * Clearly show a participant name/email in the screen to prevent |
|---|
| 57 | errors because of mixing hardware. Maybe force confirmation |
|---|
| 58 | after period of inactivity? |
|---|
| 59 | * It should be easy for a host to start a survey or game to all |
|---|
| 60 | or a subset of the participants. The UI could lead the |
|---|
| 61 | participants in what they have to do next. |
|---|
| 62 | |
|---|
| 63 | * Rethink build process |
|---|
| 64 | - AMD dependency analysis/checking would be nice |
|---|
