Thanks to @MatthewMac & @LN for solving this. With Enketo support up and running on central 1.0 I have now had a quick look at the public links feature.
My first impressions are
It is really great! Being able to send specific link to different individuals or groups is very useful for lots of purposes
Particularly good that the submission data on the database includes the name of the link that was used to send the data
So if I make a link for user "Jeff", I can see that Jeff's link sent the data in the CSV SubmitterName field.
That means that if I am doing a cohort study I can send each participant a unique link and they don't need to enter their personal details as I already have them and they'll automatically be added to the form. This is really good for data security and for auditing percentage of participants who have responded.
Some things that would make it even more useful would be
Batch create public links (i.e. for hundreds or thousands of users).
On screen count of number of submissions received from each link
Ability to reallocate a link to a new form.
For instance if I have a longitudinal study, but the form changes each month, the user can use the same link for every time-point but they actually end up at a different form according to settings I provision within central. In principle this could currently be achieved using a different version of the form, which is fine if the study is synchronous (i.e. if the cohort are all at the same stage in the study on any given day), but doesn't work with a rolling or staggered recruitment approach.
Ability to change the URL of links to something unique & memorable and without lots of slashes, hyphens etc (I think this is on the feature list already)
Customisable confirmation/thanks screen. Super useful for adding for instance a link to results website, or more details on project
Option to email results or a notification of submission via a specific link to a prespecified address. i.e. if there's a form that needs to be sent to a key person as soon as it is filled. This can be very useful for people who are running a form that only gets filled occasionally (i.e. a request for user account for ODK central [how meta!]) or which is used in emergency (i.e. like a serious adverse event in a clinical trial)
Thanks for the feedback, @chrissyhroberts. We won't immediately be adding on to public links but most of what you've mentioned are things we would really like to add in the somewhat near-term, resources permitting.
This is a use case we have in mind. Currently you can do it with an external script that uses the API. You can first make a request to get the enketoId for the form you want to build public links for. Then you can do something like iterate through a list of email addresses, make a request to create a public link for each, build the link as described next, and then email the link. The documentation for creating a public link isn't quite complete and I'll fix that shortly. Use the token attribute from the link creation response combined with the enketoId described above to build the link. Its structure is https://{your domain}/-/single/{enketoId}?st={token}. (note: we're not supposed to build Enketo links that way and will hopefully address that soon)
Yes.
This is not something we've discussed but I see the usefulness. I think this would likely be a relatively small extension on the vanity link concept you describe next.
Yes, this is something we'd really like to do. Currently the Enketo frontend uses the URL it is accessed from to figure out how to behave. There may be some alternate options and we're eager to discuss with @martijnr.
Agreed. Currently you can unofficially do this by adding &return_url=https://yourpage to the Enketo URL. Ideally it'd be part of the link configuration. This would likely be related to whatever strategy is used for vanity links.
This is not directly related to public links and could apply to any kind of submission to Central (or possibly any kind of change on Central such as user added, etc). Our current vision for introducing this kind of functionality is with a publisher/subscriber model. That would allow folks to subscribe to get some kind of web request when e.g. a submission is received for a particular form and then act on that web request e.g. by sending an email. It would be great to organize users interested in this general space and see what common desired usage patterns emerge.
Public links are intended for self-report. After making a submission, the user is redirected and the expectation is that they are done. If they're offline at time of attempted submission, Enketo will show an error but will let them retry until they are connected. Are you looking for offline caching for participants self-reporting? Can you please describe your scenario?
In our user interviews, the offline scenarios we heard about were enumerator-mediated. If there are known data collectors submitting more than one record each, we recommend creating web users with the "data collector" role for each. You can then either have those data collectors start by going to Central to see a form list or distribute Enketo links from the "new" button at the top of the submission table for each form. We deliberately haven't yet surfaced the offline link because we want to be thoughtful about where and how we show that configuration. If you really need that functionality now, you can build your own link by adding an x between the - and form identifier in the Enketo link. E.g. if your submission link is https://{domain}/-/{token}, transform it to https://{domain}/-/x/{token}.
I'm thinking of a basic use case for the offline public links.
Let's say that I have a classroom and I split it in to two teams.
I'm going to ask the two teams to map the local area using their own mobile phones (no ODK Collect and internet only in the classroom because the school is up a mountain somewhere)
I create two links, one for team 1 and one for team 2.
The students all scan the QR codes for their public link (caching the Enketo form to their phones) and then I send them off to collect as much data as possible, but the two teams have different methodological approaches and we expect this to manifest in the quality of the maps we get. Each student has instructions to get multiple data points and without mobile internet these then need to cache to their phones.
When they get back, their phones connect to the internet and submit all the forms as a batch. I then run some scripts to show their maps, making one map for each team, based on the link that was used to submit.
So this scenario shows need for
Offline caching of forms via public links
Use of shared public links for a common ODK form by groups of people with different objectives
Need to use Enketo by preference when installing ODK Collect is either not an option (limited internet) or not desirable (one off/ ad hoc data collection) AND when zero config is preferred over user names etc.
Hi @LN
I just tested both the offline caching version of enketo forms (which works nicely)
and
the 'unofficial' redirect by adding URL to end of public link (which didn't work for me)
For instance, I have a simple form here which should redirect to google.com, but I still get the standard central 'thanks' message.
return_url is the name of the query parameter to request such a link. Technically that's really what should be used and will eventually be available from Central at some point (same as building offline links).
Very excited about this. We've had years of people not submitting the data because they clicked a link on the last page (like to our ethics or something) and never pushed submit.
We have a COVID-19 survey about to start in the UK and will be using this to redirect to our project webpage.
See the discussion above. Your public link will look like <domain>/-/single/<enketoid>?st=<centraltoken>. You can manually modify it to <domain>/-/x/<enketoid>?st=<centraltoken>.
Hi @LN , I'm wondering if there's an update to this feature in ODK Central to facilitate redirection to another form after pressing "submit." Beside the returnUrl parameter option is valid, but when you want to link multiple forms in sequence, this nested link becomes too long, and there's a risk of breaking the logic.
There isn't yet, but we haven't forgotten about it.
That's a very interesting use case! What's leading you to separate out the forms rather than combining them in this case? I can think of many reasons but I'm interested in how that goes for you because we are also thinking about this theme of one long form vs. many short forms, especially in the context of Entities. Would you also want to pass information from one form to the next?
The main reason is that I'm using a webhook, and it breaks when submitting a very large form. The second reason is that a very large form requires approximately 30 or 45 minutes to complete, and participants or users generally don't have that time. In addition to the time, there are no options to partially save a form and then continue later, using Enketo (public links). We are working with entities and have managed to link responses between these forms. Another interesting point is that when you use the urlReturn parameter, the second URL must be encoded so that the token can be used within it. This prevents you from nesting multiple forms because the encoding becomes recursive.