Integrate ODK compatible surveys using enketo core into master #830
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Customise the intro steps: - Consent form - Random token login - Answer Kobo survey
Customise RCITI branch
- toggleDarkMode - toggleLowAccuracy - chanegCarbonDataset
Update intro screens
- This screen is quite concerning in term of privacy. - Date range filter doesn't seem to work properly. (e-mission/e-mission-docs#664)
UI updates
This looks better. ;)
Minor UI changes
Shorten trip confirm options with emojis 🙉
Add support for enketo survey. Refactor the code to be easier to read and maintain. Update the code to be compatible with breaking changes from the master branch. Simplify surver launch method. Generalize the survey launch and label resolution process.
… deal with the manual inputs This ensures that we can more easily move the implementation into the individual directives in the next commit. Testing done: - Loaded data from a previous day - Labels were assigned correctly
Two main reasons: - It really doesn't belong there; the rest of the functions there deal with formatting trips and maps, and are in a common service to avoid duplication between the diary and the common tabs. - It causes a circular dependency when we try to call the directive to process the inputs that we read e-mission/e-mission-docs#727 (comment) e-mission/e-mission-docs#727 (comment) e-mission/e-mission-docs#727 (comment)
And use it to map the manual input results into a map indexed by key
We do this as part of the promise response instead of folding it into the `processManualInputs` function because enketo survey answers also returns a promise. So we will have to set the `resultMap` asynchronously, which may run into timing issues e-mission/e-mission-docs#727 (comment) Let's revisit this later once we figure out how the answers should work
Instead, define `MANUAL_KEYS` in each directive and iterate over them. Also, it turned out that this was not working earlier e-mission/e-mission-docs#727 (comment) not because of any timing issues, but because we were reading the wrong key TODO: see if we can combine `extractResult` and `processManualInputs` since the timing was not the issue after all. However, the timing *could* be an issue since it is async, and we don't want to rely on timing effects, so we may also want to leave it unchanged. `
The previous implementation treated the enketo code as another type of survey. However the enketo survey is different than the multi-label UI. We have now separated out the functionality into separate directives, and removed all references to the ConfirmHelper in the diary code The eneketo survey is a single array entry with key "SURVEY", and is stored in the directive. In the diary, deployers can choose between the multi-ui and enketo implementations e-mission/e-mission-docs#727 (comment)
Since: - it is redundant; the phone only has information for one user anyway - it is currently unused e-mission/e-mission-docs#727 (comment)
Since we already match the user input for the trip during populateInputsAndInferences, we don't need to re-pull all the entries and re-match during the survey launch. This is likely to be particularly bad if we collect data over a long period of time. Reading all the user inputs for a year every time we want to launch the survey is quickly going to get old.
Since we already match the user input for the trip during populateInputsAndInferences, we don't need to re-pull all the entries and re-match during the survey launch. This is likely to be particularly bad if we collect data over a long period of time. Reading all the user inputs for a year every time we want to launch the survey is quickly going to get old. This also means that we need to store the entire survey object instead of only the label when we match entries. e-mission/e-mission-docs#727 (comment)
…ion-phone into refactor_enketo
This should allow us to load and store the demographic survey as well
- Restore a sample user profile.json
- Create a new demographic button directive
- the control launches the survey in a popup
- the service reads all surveys and picks the most recent one
- change the control screen to use the new button instead of a one-off launch command
- remove the callback for the one-off launch from the control code
Concretely:
- add a new survey.html which just has the inline function
- once the account is registered, move to the next slide instead of popping up the survey
- add a new `inline` directive which has all the information from the `<ion-content>` in the popup
- have the directive call `initSurvey`
- which involved having `initSurvey` exported from launch
There are still many weirdnesses that need to be fixed, but let's first get this committed
e-mission/e-mission-docs#727 (comment)
If the user "logs out" and goes back to the intro screen, it is re-created. This ensures that we don't have two form fields sitting around right after we have finished the onboarding, and that opening the popup will not add a new form to the wrong form field This fixes e-mission/e-mission-docs#727 (comment) e-mission/e-mission-docs#727 (comment) e-mission/e-mission-docs#727 (comment) e-mission/e-mission-docs#727 (comment) We tried to remove only the form directive but in that case, the form is not re-created if we go back to the intro screen. e-mission/e-mission-docs#727 (comment) Deleting the entire view does work e-mission/e-mission-docs#727 (comment)
To avoid duplication of content. We can theoretically generalize the demographic button as well, but running out of time for additional refactoring now.
The UI is still clunky but the functionality works:
- if no prior response, show the survey
- if prior response:
- by default show a message asking the user whether they want to edit or skip
- if editing, load the survey and let them edit
So people can determine whether they want to edit it or not. Unfortunately, it doesn't work very well since it displays the code versions of the name and value. Concretely: - this means that the names are not very meaningful (e.g. `hh_size` instead of `household size`) - this also means that they will not support i18nA Checking this in anyway for now, but will remove it in the next commit e-mission/e-mission-docs#727 (comment)
In the case that the prior survey response is found, make the text bigger and more centered
At this point, we are basically done with the phone functionality
This makes it easier to search through the documents in MongoDB and to access the fields in javascript. This is consistent with: e-mission/e-mission-docs#727 (comment) and is the last client-side change for this feature
This reverts commit 9ae72b0.
This reverts commit 56621ef.
Data model: e-mission/e-mission-docs#727 (comment) This makes the format more consistent with the other entries stored on the server. - data.ts as a numeric timestamp in seconds - data.fmt_time as a formatted date - data.start_ts/end_ts for trip-oriented objects - data.ts for one time surveys that are not related to a particular trip
We can fill them in with real implementations if/when we turn on inferences for the survey-based labels.
This ensures that it is displayed correctly
|
First, merge into a branch, consistent with e-mission/e-mission-docs#727 (comment) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.