Provide more guidance to new users who need to configure their own device
Don't force a "Demo" project for those who don't need/want it
Allow all projects to be deleted. This is specifically to avoid having an extra "Demo" project that users may not want and to provide a smoother workflow in a shared device context where it may make sense to entirely delete projects between user/project changes
This would only be visible to users who launch Collect immediately after installing it or to users who delete all their projects. Existing users would upgrade without seeing this screen. Rough proposed UI (Figma source):
This is something we have known we wanted to do for a long time. We had been planning to combine it with a broader user experience refresh but this refresh keeps on being delayed by (exciting) functional improvements. In the discussion around introducing support for multiple projects, @rameshbhalla81 explicitly asked for this kind of first launch experience here and @tomsmyth brought up the "zero project case" here. There have also been several questions about what to do in a shared device context and concern about users unnecessarily trying to switch between projects (@aurdipashere, @noel_cartonghere, @amalmhere).
As we've discussed what to do about these valid concerns, we think addressing the "zero project case" is an improvement. It makes it possible to tell data collectors that when they return devices, they must have sent all their data and deleted their project. This can be checked at a glance. For the next data collector using a shared device, they can simply pick it up and directly configure it for themselves without having to figure out what to do with an existing project.
The sketch should be taken as rough. In particular, we will figure out exactly what the buttons look like in the context of the existing app theme. We will try to make it look as clean and modern as we can within those constraints. Things to pay particular attention to are:
Are all the most important pieces of information and possible actions easily accessible?
Is the relative scale of elements appropriate?
Are there any workflows that this disrupts or makes worse in some way?
We've chosen to put the "Configure with QR code" path first because we know from analytics that it's popular. QR codes don't necessarily come straight from a sever -- a common pattern we see and hear about is configuring one device as desired and then scanning that device's QR code from other devices. This can be used to replicate all settings including credentials or all settings other than credentials with users entering in their credentials when prompted. We also know that users send QR code images via WhatsApp for import rather than scanning and that they write scripts to generate their own QR codes.
"Manually enter server details" would go to the same screen as shown in the projects mockups:
I'm pretty happy with this. One minor thing is that instead of "Manually enter server details", it should be "Manually enter project details" since it's linking to the "Add project" screen.
Thanks for another amazing bit of software communication @ln. You are a master at this.
One thing that popped up for me is: what if someone is trying ODK Collect for the first time and doesn't know much of anything about it. The two buttons are kind of jargon heavy. This user may not really know what a 'QR code' or a 'server' is, or what server they're talking about. 'project' is better, thanks Yaw, but still kind of inside baseball.
Should we have just one sentence like "How would you like to configure ODK Collect?" or "Where are you sending your data?" or something like that? Right now this kind of reads like an intranet page or some other artifact that assumes a lot of the user.
I was getting tied up in knots trying to come up with language or links that are informative but also are coherent for all of the various kinds of systems ODK Collect connects to. In a more typical context I would put a link to the getting started guide.
Does this really provide more information? Or is the value that it sets a conversational, friendly tone? I don't mind adding it but I don't love that it may wrap weirdly depending on screen width and will add visual clutter.
I've also noticed that a lot of apps across product types assume users know what app they've downloaded and have a barebones landing screen with ways to login:
Generally, I like the way the screen is designed.
From my perspective, if we want to care more about completely new users I would keep it as is and maybe change a bit that last option like Try Collect with the demo server or Try Collect demo version
Then (in the future, not at the same time we implement that screen) if that option is chosen we could add Introduce first-time users to your app and present some most important facts/options about the app.
I like the tagline idea. I think that might cut the intranetiness (new word!) Like the Twitter one. Even the Tiktok page has a sentence of text ("Sign up for TikTok") that is not jargony and gives a call to action.
It also might help to see a fully hi-fidelity mockup with the true button styles, etc. If that's not too much work.
Thank you for all the thought you've put into this!
We're going to aim to build it as soon as possible and share a screenshot then. It should be straightforward to iterate on once we have something in place.
One underlying question is how important version checks by e.g. trainers are. We know it's more and more common for data collectors to use their own devices. We know one thing organizations have done to ensure a consistent data collection experience is to have a trainer "walk the room" to verify versions at a glance. That motivated the original large version text. With a small version at the bottom of the screen, it'd still be possible but the trainers would have to get pretty close. The last mockup is an attempt at maintaining the affordance of easily verifying version (say, at a 6-foot distance) without making the version front-and-center.
I like moving the "try" text at the bottom and adding some way to make it obviously clickable. I think the current implementation is not sufficiently clear. I think some of you may find the text in the last mockup friendlier.
I really like the mockup with the obviously clickable "Try Collect" (also the phrasing "Don't have a server yet?") and the medium-sized version text which seems a good compromise between the other options you discussed and still allows to quickly check the ODK Collect version if needed
Super minor comment: the text "Collect data anywhere" is more pleasing to my eyes when displayed on 2 lines rather than 3 (but it is probably more of a personal opinion, with no impact on the functionality and may also depend on the device screen resolution)
@LN I like Tom's earlier suggestion on adding a prominent link to a "getting started" page. This could just link to the existing getODK documentation. Alternatively, we could consider a cross-platform page à la xlsform.org to have a generic how-to text and link to specific known documentations?
How about a shorter Scan QR code button?
For the Manually enter project details button, what if we have this displayed only after you click the Scan QR code button (with a No barcode? button, as Duo Mobile does?
I expect most people download Collect because they've been asked to do so by someone who has set up a server for them. The person who has installed Collect just needs to get their credentials in. My preference would be to focus on making that really foolproof for them. I think the risk with adding documentation is that it becomes a place for data collectors to get lost and reach a dead end (e.g. now I'm in a browser and I'm not sure how to return to Collect or now I'm in a browser and I'm on Facebook for the next 40mins). We know English literacy is fairly low in this group and I think it would be quite difficult to come up with actionable resources that provide more information than some big, clear buttons.
You're probably thinking more about the small number of people who download Collect because they've heard about it and want to see it in action (but let me know if I'm guessing wrong). Those folks will use the "Try it" button and I think that's where it would be really helpful to provide more guidance on getting their own project set up. I agree this would be nice to do but now we're talking about a whole new workflow. I think we can design that separately and come back to it.
Another thing we have previously thought about is giving project configurators an opportunity to put a link to documentation for their specific project and its worfklow. Many organizations produce these kinds of documents and they currently have to be distributed separately. This might include screenshots from their own forms, etc. This would be something made available once a project is configured.
I'm not opposed to that. I find it helpful to know what the purpose of the QR code is but I can see how it might not add much. The reasoning for the longer language is to steer folks towards looking for a configuration QR code rather than just scanning random codes. I know it sounds incredible but I've been involved in projects where data collectors tried to scan the first code they saw (most recently, 3 out of 17 data collectors scanned the barcode on an alcohol swab pack). We know from analytics that there are a shocking number of codes without configuration settings that get scanned.
I like this a lot but I wonder whether it might be too aggressive for right now. What I like about the two buttons is that it gives people who don't have a configuration QR code clear assurance that there's a path for them. I said previously that we know there's a lot of QR code configuration but it's not yet the majority so we'd be forcing more than half of our users to go through a fallback path if we only present a single button. I also do want to be mindful of the fact that for some workflows, having each data collector enter in just their server, username and password truly is the ideal. That makes me feel like the manual configuration path still is a first class citizen rather than just a fallback.
This first launch experience is now in beta! Please try it out and share any feedback. You should see it if you uninstall Collect before installing the beta or if you go to Admin Settings > Delete project (this will delete blank forms, form submissions and settings).
Yes, that's right!
