Collect: Prompt for server configuration on first launch

Goals:

  • Make it quicker to configure a fleet of devices
  • 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 (@aurdipas here, @noel_cartong here, @amalm here).

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:

As described there, the project name, icon and color would be auto-populated based on the server URL but could be customized if desired.

Thanks to everyone who has pushed in this direction as we discussed projects. I look forward to feedback!

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.

1 Like

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.

Happy to be persuaded otherwise...

1 Like

:joy: Yes, that's right!

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:

Another option would be to include a generic tagline somewhere. We used to have "Data collection made easier".

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!

1 Like

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.

Thanks for the feedback!