Collect: Multiple projects support

If there's one less step to display the QR code that is no problem, as you say it is not done often. If there is an extra step to capture the barcode on each of 20-100 devices that is a bit annoying but I guess it remains faster than typing usernames and URLs.

In my experience the devices are often the property of an NGO and large numbers of data collectors are often hired on a temporary basis and given temporary access to them. Due to cost reasons those devices may be used by different persons for different projects at different times of the year. For that reason it would be great if they can store multiple URLs but the data collectors should often not have the right to change access credentials, download other forms or submit data to them.

Its unlikely that many would choose to do that as its not very interesting but I can see the event where data collectors think that something is not working on the device due to user error and try to "fix" it by swapping around between different sets of access credentials and inadvertently create a real obstacle for themselves as they no longer know which was the correct credentials.

If this functionality can be hidden by an admin password then there is no issue. If this functionality is displayed and easily accessed by default and individual organisations have to choose to hide it, I see no problem with that.

It will be the same if you're willing to keep the "demo" project. That is, where you now do ⋮ -> Configure via QR code, you will do Project button -> Add project. If it's important not to have the demo project, you'd need to do Project button -> Admin settings -> Configure via QR code to replace the demo project's config.

Where we eventually want to go is to make it so that on a first launch of Collect, users see a brief introduction to the app and an immediate opportunity to scan a QR code / enter credentials. We've separated that out from project support described in this thread to reduce risk and to get functionality to users earlier so we can learn from their usage. Our sense from talking to users is that having an extra demo project that never gets accessed is not a big deal. What do you think?

For that kind of scenario, I would not use this first iteration of project support and instead keep the same workflow. Once a device is ready for a new project, I would go to Project button -> Admin settings -> Reset project... to clear everything. Then I would do Project button -> Admin settings -> Configure via QR code to get it ready for the next person.

We'll work towards requiring some kind of credentials to switch into a project to better support multiple people using a device. We're not yet sure whether this would be the existing admin password, server credentials, device biometrics, or something else.

Thanks for taking time to write a detailed reply. I confirm that from the organisations I have known, having an extra demo project would be no big deal at all and thanks also for your explanation about the work flow.

1 Like

Hi everyone, sorry to barge in at this (late) stage.
The activity on this thread tells me that this is a popular feature with many. I for one am a bit apprehensive about how this will affect me.

We have only one server and we don't allow the users to change it. Most of the settings are locked from the admin settings page. I hope there will be an option in the admin settings to disable the profile selection and profile addition completely.

For me it would be more useful to show the currently logged in user, on clicking the round button.

Can you please describe what you see as the danger with having these available? As I noted above, data collectors would only be able to actually add profiles if they have a QR code or server+credentials to configure projects with. It sounds like in your case they would not have this information. They could tap on the Add Profile button but they wouldn't be able to do anything from there. Is it likely that they would somehow get other server configuration information? If so, what would a potential bad outcome be?

Thanks for the reply @LN.
From my experience working with ground level staff over the past 6 years, additional complexities to the app that they don't understand always lead to mistakes and hence delays in the work.

To state an old example: sometimes our devices are shared between users. So initially we trained them to go to the server page and change the username and password when they pick up another device. But inevitably they ended up changing the server URL (unintentionally or not, I don't know) which of course led to download and upload issues. So we ended up creating a custom version of the app to separate out the server settings and the credentials, and show only the credential section to the user:

This saved us a lot of headaches over the months.

For the feature set under discussion, I imagine that enumerators will try to add a new profile when they pick up a new device rather than change their credentials in the settings. And they will come back to us with complaints that it doesn't work. Our supervisors are overloaded as it is, and this will become a new pain point.

If you're using ODK Central, I think the concept of App Users should make it easier to manage this. As I understand it, each 'profile' would be a different App User. Each enumerator could have a printed card with the profile QR code. They can deleted their profile (only possible if all submissions are sent), pass off the phone, and the next enumerator can scan their QR code and be ready to go.

4 Likes

I'm using Kobotoolbox, so not sure how this would work.

3 posts were merged into an existing topic: Filter the Project List on main page

Did you know that you can set the URL and that credentials will be requested the first time Collect tries to connect? The credentials can then be entered once and they will be saved. I would set up a QR code with all of your desired admin settings locking everything down including every general setting and setting only a server. Between data collectors, I would delete the project (requires admin access) and then scan that QR code to start with a fresh project. The data collector will then be prompted to enter their credentials when they refresh Fill Blank Form (or go to Get Blank Form if you choose not to use the "match exactly" form update mode). Alternately, you can have a more lax QR code that doesn't lock things down through an admin password but still sets the server and hides server settings. That way data collectors can delete their own project when done. I think the introduction of a first launch screen will help with this because it will allow you to be in a state where all projects are deleted.

This really will depend on your workflow. You could have multiple projects that are each configured for a specific data collector. Note that username will be shown in the project listing. It sounds like your specific data collectors are likely to make mistakes so it's probably not a good option until we introduce a way to require credentials to switch into a profile.

You could have data collectors set up multiple profiles with the SAME credentials and download a different subset of forms into each. For example, if the same individual collects data about X on Monday and Wednesday and about Y on Tuesday and Thursday (e.g. clinic visits vs. home visits), it can be helpful to download the subset of forms about X in a project called X and the subset of forms about Y in a project called Y.

Thanks to everyone who has provided great feedback! In response to some workflow concerns and specific mentions of the "zero projects case", we're proposing to also introduce a "first launch screen" as part of this change. I hope this will address some of the very good issues brought up here.

1 Like

@tomsmyth We've been tracking some of your earlier feedback and have some preliminary ideas to share. We are working in parallel on some concepts to refresh the landing screen and for an entity-based experience so that we can keep these different directions harmonized. That means there will be more iteration but we're interested in any feedback based on our initial thinking.

We are leaning towards using the project name as the landing screen title. This puts users in the context that is most relevant to them. From their perspective, they are in the "Turtle Nesting app".

If the project title matches the URL domain name, the app title would fall back to ODK Collect vx.x.x. The fall back is because on upgrade, project names will be auto-populated from the current server's domain and there will be a long transition time as servers include project names in their configuration QR codes and/or users customize their project names. An app title of turtlesarecool.com is not terrible but odk.mydepartment.mycompany.com is pretty bad and a.generic.hosted.service.com is even worse. This also means that folks who never even look at project name will have an experience consistent with prior versions of Collect.

The username and domain name we are leaning towards not including on the landing screen. I agree it can be useful in an absolutely ideal context like the one below (Tom / turtlesarecool.com). However, it will often be more like gingerbreadcookies7723@gmail.com / odk.mycompany.com which is really not helpful. That information will be available in the project selection modal to those for whom it is useful.

They now look more like the mockup on the left below which better matches the style Google and others use. We may also explore the option on the right.

As a side note, since we've started this conversation, the Google Android apps have been in the process of consolidating all of the app drawer/left "hamburger menu" items into the account menu at the right (which had previously replaced the three dot overflow menu as we're doing). The Play Store app has done this in just the last few days. I like the results and it's making me feel more confidence about our direction.

2 Likes

Looking good to me! I like having project name as title.

I see that the Gmail Android app uses the buttons similar to how you have them. I'll note that the corner radius is smoother and the button is left aligned with the text ("Turtle nesting") in your example. That may seem trivial but I think it helps establish that the buttons relate to the 'Turtle Nesting' entity. So hopefully you can match that.

Thanks for the pointer about the Google app menu changes! I'm curious if they'll do that with the Gmail and Calendar apps. That would be loading a lot onto those buttons!

Anyway thanks for all your care here! This is going to be great!

3 Likes

Oh one more thing... I think there should be a little more vertical space between "Turtle Nesting" and the URL. And the URL should probably be a bit grayer to reduce the visual weight vs. the project title. Small things.

3 Likes

Hi to all,
I have an egocentric question about profiles : we are moving some of our forms from Aggregate to Central but we'll miss time to move all the forms.
Some colleagues will have to fill forms on both server. In a first approach, in order to maintain background routines, we loaded form in central and mention aggregate url in submission_url setting but it seems to rise some problem (sometime it woks fine, sometimes not).
So I would like ti know if profile managment will allow a profile to use an aggregate server ?
I think it concerns only Collect so it would be ok but if I could be sure and not to have 5 or 6 more forms and routines to recreate on Central it would be great.

1 Like

Yes, absolutely. This kind of straddling of multiple servers you describe is a great use of different projects on Collect.

Could you please file a support post describing what you experience when it doesn't work? That sounds surprising and like something we should look into.

Hi @LN,
you always bring good news :slight_smile:
We will open a support post (me or @nathalie_H)

2 Likes

Multiple project support is now in beta! Thanks to everyone who has participated in this big undertaking and especially to @seadowg and @Grzesiek2010 who have made it come to life.

There is still a bit of work to do (see remaining tasks on Github) but the core functionality is ready to try out and provide feedback on.

3 Likes

ODK Collect v2021.2 is now released and includes multiple project support! We hope this will give users many new options for organizing their work. Please upgrade your servers to Central v1.2.2 to get project QR codes that include project name.

1 Like