Thank you for your feedback –– we had over 60 people respond to the survey!
Our goal with this research was to understand the challenges with finalizing forms and what could be improved in the user experience based on your feedback.
What did we learn?
Data collectors often complete the survey in more than one visit.
Supervisors are concerned about data collectors making errors, and the last step in finalizing the form often causes confusion.
There is a desire for more feedback about: when people are offline, when their forms have been successfully sent, and reminders to submit their forms.
People would like a way to return forms to the user to be reworked.
Lots of positive feedback about the entity-centric work that’s in progress.
Respondents also appreciated the tips we provided in the survey:
Did you know that you can configure Collect to always mark forms as finalized and to hide the checkbox for finalization? You can read more in the documentation.
Did you know that you can configure the name of filled forms to use data from inside the form? This is the name that is shown in form lists like in "Edit Saved Form". You can read more in the documentation.
Based on feedback from the @TAB, we are now leaning towards leaving the current default in place (no auto-send). We wanted to make auto-send the default because we believe auto-send is a better experience for most users:
It reduces the number of steps for completing a data collection task
It increases the likelihood that important data will make it to a server in a timely manner
It makes it less likely that data collectors will forget to send (there's still a possibility they will forget to turn on Internet access)
It makes it less likely that a large group of data collectors will all submit at the same time which could cause network congestion
Submissions are typically very small so don't use significant amounts of data
However, we know there are also good reasons to keep auto-send off:
Submissions with media can be big and cost real money to send
There may be reasons to use a specific WiFi connection to send submissions (speed, security)
Note that requiring a review step will no longer be a good reason to keep auto-send off: there will be no possibility to edit filled forms once they are queued for sending. Data collectors will need to use the "Save as draft" option to keep a filled form open for editing.
We are currently leaning towards leaving the default in place and updating documentation to make it clear that auto-sending is preferred. ODK Central already configures auto-send by default so this only affects users of alternative servers.
New design updates
We have implemented the following changes based on your feedback!
Finalizing your form
There is no longer a checkbox to “mark as finalized” on the last screen because it caused a lot of confusion for people. Now, the data collector will see a message to tell them what to expect next, and the buttons will change based on the form settings. For example, if the supervisor has turned on save as draft and auto-send in the settings, the data collector will see “Save as draft” and “Send” buttons. By default, “Save as draft” and “Finalize” are shown.
Form design tipIf it’s really important for your workflow that data collectors first save a draft, you can add a question that prevents premature finalization. For example, you could add a checkbox at the end of the form that says "Has this gone through full review" yes/no with a constraint that yes must be selected. If the data collector selects no, they won't be able to finalize. You can tailor the message to your context. For example: "Give your phone to Zenia so they can review your answers. When they are done, Zenia will type their name below" (text question that has a constraint that it must have value "Zenia").
We have improved the main menu! We have changed the language to make it easier to navigate, added icons, and enhanced the buttons
App feedback: We are creating more actionable feedback messages throughout the finalization flow. These messages will be shown at the bottom of the screen in a black bar to let users know what’s happening based on their action on the last screen.
Exit modal: We know the exit modal is confusing. Users will soon see an improved modal that makes it easier to take action.
Summary view: We are investigating adding a summary screen showing what’s completed and if there is any missing information to be reviewed before sending to reduce errors. We want to do some performance testing before we decide to implement.
Jump to another instance: We were debating giving the user the ability to jump to another instance of the same form when they are done or go back to the main menu to create a smoother workflow, but we need to do more testing.