We have periodically heard that the split between general and admin settings is confusing, especially since most data collection campaigns don't set an admin password.
With the addition of multiple project support, we are hearing feedback that the two settings buttons are awkward (e.g. @tomsmythhere). We are also hearing that it's hard to find how to rename projects or configure how they're displayed (e.g. @mathieubossaerthere).
To address all of these points, we propose combining all settings into one screen (full Figma mockup source):
When there is no admin password set, access controls will be applied (meaning some settings may not appear in their submenu), and all protected settings will be accessible. This is the same behavior as today but the protected settings are more visible.
When there is an admin password set, access controls will be applied and protected settings will NOT be accessible. A user who knows the admin password can tap on any of the protected settings elements or the lock in the top right corner to enter that password. Once the password is entered, the lock image changes to unlocked, access control are NOT applied (meaning all settings are accessible), and this remains the case until settings are exited.
For existing Collect installs with an admin password, should the new "Project display" settings category be accessible after upgrade or not? We are leaning towards making it accessible since it is non-destructive and there are cases in which it would be really nice for users to be able to customize their project name even if Collect is otherwise locked down for them. On the other hand, when an admin password is used, that typically means a project needs a high degree of control over Collect. It may be important that every user has the same project name/icon/color to minimize confusion.
Is there any risk to this change we might not have considered?
We currently plan to include this change in v2021.2 because it pairs well with projects. It won't delay the release -- we have to make a location-related change to satisfy changing Play Store terms of service and this work will happen in parallel.
Hi @LN , great proposal to simplify user experience with settings !
As we do not configure admin password for now, I have some difficulties to imagine any risk link to those changes.
I believe this is an existing risk not one created due to the change, but is the server URL always accessible? As it's not in the Protected section. With the token based submission that Central uses, someone could possibly get the URL and start submitting from another device? Would it be better to not allow the user to get to the URL (specifically the token) if an admin password is set?
Yes. And there's currently no difference between Central tokens and passwords -- passwords are also available in cleartext when tapped on. When we started using Central tokens, we thought leaving them available in cleartext was no worse than passwords being available that way.
I agree that this is worth some rethinking. I've been personally shy about it because any changes we make are likely to break existing workflows. In my experience, credentials are often used to represent roles (especially with Central tokens) and it is common practice for data collectors to share credentials in the field. Making credentials inaccessible would mean those procedures have to change.
Since it is an existing issue, I propose we consider it for a future release. This also possibly intersects with a few other themes:
in some contexts, authing individuals rather than roles would be more appropriate
we'd like to use proper token auth rather than Basic or HTTP auth
in some contexts, there's a desire for greater project-level protection on the device and we've talked about things like locking the profile and prompting for a password (maybe the server password, a PIN, etc) to reenter, possibly encrypting the project on disk, etc
If there is an admin password set, what if the server URL was hidden (just like the password field) or obfuscated with *****? For the default project name it could default to something else, e.g. Project . Since setting an admin password is done by few and more experienced users, we can expect them to also give it a proper name before configuring all devices.
This is now included in Collect v2021.2 beta 5 and it looks like the release will be out early next week!
Apologies for the radio silence, @Tino_Kreutzer. We're not going to expand the scope of v2021.2 further just now because we're getting at risk of never shipping! Thank you for the good ideas and we'll revisit soon.
I think we'll be able to get that into v2021.3, thanks. Please also note that it's possible to use access controls to hide the entire Server category. This is something I've sometimes done without even setting an admin password just to reduce the risk of mistakes. Even if users could technically change the access settings back, in my experience they typically don't.
I think we're ok on this front because only the domain is used as the project name. So if your server URL is https://my.cool.server/secretsecret, you'll just see my.cool.server.
Thanks so much to everyone who has participated in this conversation. The new combine settings screen is available starting in ODK Collect v2021.2. We hope settings will now be easier to use.
If you have further suggestions on improving settings, please create additional feature posts. If you run into issues, please post to support.
