Hi @LN,
this feature would be very helpful for users who participate to different studies from different partners with their own Central server.
Yes, exactly that is the goal.
1 Like
This is a great idea and v. useful when sharing the same device between different studies or when considering separate phases of the same study (e.g., pilot vs. deployment)
As ODK Central user roles and encryption are currently managed at the project level, I may also use profiles as a "trick" to manage different encryption / web user access needs within the same study.
For instance, a first profile would be used to collect encrypted personally identifiable information and a second profile to collect (de-identified) research data with a manually entered link to the previous submission.
2 Likes
In the wireframe, the 'Admin Settings / App Configuration' section is gone. From that section: the 'Save legacy .settings file to disk' is noted as being removed in a future version (presumably this would be that future version), and the 'Configure via QR code' is now part of the adding a profile process, but will there still be a way to 'Reset application...'? You note that "If the current profile is the only profile, deletion is not available." How will a user be able to clear all settings? Also, what does 'Reset profile' do?
1 Like
Wow, great ideas! I really appreciate the attention to detail with things like the color being computed from the name to ensure cross-device consistency!
Generally I love the direction! I have one key concern:
I'd like to see some mockups of what this would look like the first time you open the app (the zero case). You've described the one and many cases nicely but I'm not sure what happens when there are no profiles. What is the icon going to be? How will users know what it means if they weren't the ones to choose it? If it's D for Demo, how do they know what it's for?
I appreciate the desire to keep the UI clean and re-purpose the menu icon space with the profile icon, but now the affordance of the well-known menu icon is gone. I think it might be worth exploring having the profile icon, name, and URL shown above the 'iconic buttons' on the home screen. It would look nice, and it would make a lot of sense. "Turtle nesting: Fill blank form, Edit saved form ... ".
The menu could stay as it is with the options being 'General Settings, Admin Settings, Profile Settings, [divider], Change Profile, Add Profile'.
This also has the added benefit of getting rid of these buttons:
Which seem kind of awkward to me.
Thoughts?
1 Like
I love the direction this is headed.
I agree with @tomsmyth that the two settings buttons seems strange at first, but we could do some user testing between the two alternatives. For most new users the presence of "General settings" and "Admin settings" is confusing, and we would do well to find a better solution rather than just moving the buttons (i.e. finding a solution to having a single 'Settings' button for editing the profile).
I've been thinking about this a fair bit and I'm wondering if we should not revisit whether this is a way to manage and display multiple Projects (each containing one or more forms) rather than calling them Profiles. This would match @chrissyhroberts original idea and also what users are used to seeing in Central and KoBo. It may be the same thing technically but ultimately for most users I expect they will use this feature to differentiate between different projects, all of which may be on the same server or even use the same account/password.
2 Likes
I think so. We've tracked analytics on settings being loaded from those files and it's in the single digits for the past 90 days.
The idea is that 'Reset profile' would be exactly the same as 'Reset application' currently is but only apply to the current profile. Is that the functionality you'd want? Ideas for making that clearer are much appreciated.
This would not be a possible state -- there would always be at least one profile. On upgrade, the configured server domain would be used to populate the profile name, icon and color. If your server were https://turtles.myserver.com, your profile would be named turtles.myserver.com. In the upper right hand corner, you'd see a T with a background of whatever color the domain name hashes to.
I agree that immediately after upgrade it might not be clear what it means. But I think it's pretty natural to try tapping it and I believe the profiles dialog would make it clear what's going on. Additionally, anyone who has ever used any Google app would be used to this structure.
Do you mean well-known within Collect or in Android more broadly? My sense is that for apps that use accounts, having an account indicator instead of an overflow menu is very common. See all the Google apps or any social app. I think the important thing is that people know to tap it. The convention that items on the upper right of the app bar are tappable is so strong that I imagine anyone who has used an Android device would know to tap there. For someone who hasn't used an Android device, it's not clear to me that the three vertical dots has any more meaning than a round button-looking-thing.
Good idea, we can also experiment with that, possibly in addition to the icon indicator. Perhaps the profile name goes in the app bar and the version information goes somewhere else.
I agree they look bad as styled but perhaps it's mostly because of the styling? The mockups are meant to be rough even though they ended up looking more "real" than they probably should because I was copying and pasting material components. I think we could match the styling of "Add profile" with an icon at left or use a button style similar to what the Google apps use in that same space. What I like about this layout is that it's very clear that the settings belong to a specific profile. If we maintain the overflow menu, to me it would look like settings are applied across all profiles.
I agree with this, especially since typical workflows for configuring a bunch of devices with admin protection involve QR codes. I think admin settings can now be less accessible. My preference would be to group a change to settings location with a first launch experience update. In my ideal world we can make the addition of profiles minimally invasive and then do a comprehensive overhaul of the UI as a separate step. I think if we tie too many changes together it will be overly risky.
Are you imagining changes to the concept beyond what it's called? We pitched a more generic "profiles" name because people organize forms in all kinds of different ways across the various supported servers which may or may not have project concepts. That said, I'm personally happy with "projects."
Thanks for all the replies @LN. I think I am persuaded on all points.
I'm not sure what this means:
What is a first launch experience update? Are you saying you don't want to change the structure of settings at the same time as adding profiles?
Don't hesitate to come back with more alternatives. I'll try playing around with making the profile/project name more visible soon.
That does sound kind of jargony, oops! I mean updating what users experience when they launch Collect right after installing it. Ideally users would get guided through adding a new profile/project. I think that change will feel like a major improvement to the app and that it would pair nicely with updating how settings are accessed. Mostly, if possible, I'd like to try to keep this profile/project feature fairly focused because it already has a lot of pieces.
Right, I guess that's clearer. 
I think of a project containing one or more forms that someone in the field needs to work on. I think it reflects the reality on the ground better (one person working on one or more projects to collect data for different ends) than "profiles".
"Profiles" implies to me that you could not use the same server/username combination more than once. If that's the case, we should keep profiles and think about how "projects" can be managed and displayed separately.
1 Like
I got some questions on the TAB call about how one user on a Central server would handle being in multiple projects and I wanted to put my response here for the public record.
Right now, they would scan a different app user QR code for each project and that feels very natural to me. In the future, we’ll also be enabling web users with usernames and passwords to collect data in Collect. In that case, they'll be able to enter a user name, password and project ID (likely select from a drop down list of projects you have access to) And we’d also be able to embed that information in a QR Code.
If I switch the profile on Collect what happens to the downloaded forms? Are they hidden or removed or do they persist? What about saved forms?
If I have added multiple profiles on Collect, do they all sync their forms when in WiFi or just the active one? To fetch/send forms from multiple profiles do I need to toggle between them?
Could Central be changed to allow an App User to be given access to forms across different projects? So that a data collector can fill out forms from multiple projects without changing the Central-URL-with-token.
Question: we have several cases where projects share the devices. A typical example of one institution where once a week the interviewer goes to collect data for project A. Another day or days another interviewer could use the same tablet for a project B, maybe there's as well a project C etc etc...
In this scenario Interviewer B by clicking on switch profile could potentially open forms A and C and see saved data or send data. Wouldn't pe possible that on click an app user has to enter a confirmation code or password to access his profile?
Everything will be kept but not visible (for other profiles). We haven't decided on the implementation yet but probably we are going to create the same structure of dirs (forms, instances, layers, metadata) for every new profile so every profile will have its own space on a device.
That's a good question. We have two automated tasks, one responsible for uploading forms and another responsible for downloading updates. We thought that at least the first one should work for all profiles no matter which one is active but it's not set in stone.
Every profile will have its own settings (general and admin) so for every profile you will be able to set admin password like now. I don't know if we are going to implement it immediately but it shouldn't be a problem to protect profiles using that password.
2 Likes
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.
1 Like
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.
Do you end up with two different App Users in Central for "external" and "internal" users?
Yes, one "global" project" with multiple app users. "Gestionnaire Filmed" is the one for external users.
1 Like
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.
1 Like