It would be helpful to hear more about the scenario you have in mind. What do projects represent in that case? Even if we do allow the same App User to be associated with different projects, we would expect the projects to be configured separately on Collect from different URLs because we think of separate form lists per project as very important to keeping data collectors organized. In the typical cases we've discussed with users, projects are different enough from each other that it makes sense for data collectors to be entirely within the context of one or the other.
Is the current process something like scanning a QR code or enter credentials before heading out into the field and then resetting the device at the end? That might be the process to continue once this first iteration is out. The slight improvement will be that the currently-configured project will be a little more obvious from the landing screen. As @Grzesiek2010 says, we eventually would like to consider access controls but that would not come in this first iteration.
I do not know what @danbjoseph do have in mind but I have a case that matches with its request :
A colleague of mine, Héloïse, , participate to all our field studies and use 2 or 3 of our internal forms (ecological inventories). All our internal forms are organized in the same project "Les formulaires du CEN".
On our Central server we start to provide a form to external users who are lagoons managers. I first created a new project called "Filmed" to house this form. But I finally integrate it in our internal project to allow Héloïse to use it.
It works this way, because I can select which form is available to each user but it makes the project level not relevant.
I imagine project as a place to share forms that are common to a defined group of people, but some exceptions may occurs, like in my example.
Central currently provides Projects and App Users as organizational tools for forms and different teams use them differently. It's useful to keep seeing different examples of how teams use them and what situations are currently awkward to model as we consider further refinements to Central.
In the case you've described, @mathieubossaert, I think you've used the only reasonable setup given what Collect can do. Once the Collect project support described here is introduced, you will have the option of a public project and a private project because Héloïse would be able to configure both on her device. At that point, having separate projects would require having an Héloïse App User in each project. It's indeed possible that in the future there could be a single Héloïse App User that can be configured for both projects. The two projects would most likely still be configured separately from Collect.
Here are some cases in which I'd consider a split into two projects:
The public and private forms are similar and it's important for Héloïse to know which she's filling out.
Héloïse is performing a different role when she fills out private vs. public forms.
The public forms and data are managed by a different person than the private ones. Then it might help everyone focus to have separate projects.
One dataset is distracting. Let's say the public data is unpredictable and sometimes includes exciting finds. People who do data analysis may find themselves spending some time looking at the public form data every time they go to look at how the private data collection is going.
Some of this comes down to personal preference and maybe Héloïse's preference would be different from yours. For example, GMail makes it possible to switch between email accounts in a similar way. I have multiple email accounts and I like to keep them separate and explicitly context switch into one of my accounts. There is also an "All Inboxes" view which combines messages from multiple accounts. I find it distracting and confusing but others find it more comfortable.
This would be really useful to those managing IM systems.
Two considerations come to mind:
I assume that this functionality would continue to be easily locked down to prevent users from switching as if its easy to do they will do it even if there is no need.
I hope that the QR code scan method of transferring credentials between devices would still work with the multiple accounts as thats a real time saver for larger data collection projects
The concept is a great idea and would save time and avoid problems for a lot of people.
Glad to hear this is sounding useful to you, @noel_cartong! We have now started implementation so for those who might have feedback, now's a good time to get your voice heard.
Yes. The current design keeps the current profile's barcode available from Admin settings -> Configure via QR code. Currently it's also available from ⋮ -> Configure via QR code but that would no longer be the case. That means there'll now be one extra navigation step required making it a little less discoverable but our sense is that this is ok because device provisioning happens once per project and is generally guided by someone who knows more about the system. In other words, showing a configuration barcode from a device is not a feature that gets discovered and used by data collectors.
That's something we've discussed but that we have decided not to do because it doesn't seem like a project should have the authority to decide what a data collector does with Collect outside of its bounds. What kind of scenario are you thinking about? Is it perhaps a shared device situation like @aurdipas described above? As I responded, this is not our main focus for the first iteration of multiple project support though I think the new functionality will put us on a path to better supporting that use case. For now we are focusing on data collectors who are affiliated with multiple organizations or involved in multiple projects in the same organization. If that's also the context you're considering, it would be helpful to understand what your concerns are about users switching profiles. E.g. are you thinking they'll switch and not know how to switch back? Switch and forget to do important work?
Note that having multiple projects in Collect requires having multiple servers to authenticate with. A data collector without multiple affiliations generally would not have multiple barcodes or server+credentials to create projects with. The worst case I can imagine is if they add multiple projects with the same credentials by doing something like Add Profile and scanning the same provisioning barcode multiple times. In that case, they could possibly have submissions that they can't see because they're in another identical project. It's hard for me to imagine this being common but it's suggesting to me that we should consider preventing users from creating projects with the same exact server+credentials combination.
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.
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:
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.
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.
@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.
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!
but I have a case that matches with its request :
