Yeah I was able to reproduce it and here is the issue: https://github.com/getodk/collect/issues/4627
2 Likes
I have tested this beta version and I must say it is pretty exciting, since it offers so much more flexibility, also simply for data managers to keep a track of all the form versions in different projects and servers!
No bugs detected on my side. Whether adding new projects, switching between encrypted / non-encrypted projects or filling out the different forms, everything was super smooth.
I really appreciate the quicker display of filtered lists (I had only one for recording the residence of respondents and I was considering removing the finest administrative level to increase the form performance, but it really works super smoothly now).
I liked the former audio background volume bar, but I agree that this new bar is more informative for the user when recording.
I found the configuration of the project name not that straightforward when you have added several projects from the same server. In this case I think I would prefer to have directly the project name with the server name in gray below the project name by default rather than solely the server name, but if it is planned to manage this directly with ODK Central later on, I think this is really acceptable the way it works now (especially since the tablet from data collectors in the field will never contain as many projects and users may be more incremental in their approach than I was: i.e., add a project and rename it immediately rather than add several projects and try to guess which is which). Deleting a project is very straightforward.
Two (minor) UX comments:
- When you have the project panel open and want to modify the settings of a project which is not the current project, you have to proceed in 2 steps: you first select the project, and the switch also automatically closes the project panel, then you have to click on the project icon to reopen the panel and be able to modify your settings. I think I would generally find it more natural to keep the panel open and close it manually when I am done with all the changes.
- Pure aesthetics: would you consider using the project color also for the
General SettingsandAdmin Settingsbuttons? It may help create a "project identity"
3 Likes
Thanks so much for all the valuable feedback, @Thalie.
That's really helpful, thank you! We test on a variety of devices and simulated lists but it can be hard to tell whether the user impact will be real. It's very helpful to know that these kinds of performance improvements are noticeable on real forms.
We have a Central point release that will go out before the Collect release to include the project name in the configuration QR codes so hopefully that will help.
Thanks for sharing this workflow. We agree there's some roughness around project creation and switching and are exploring some options to improve that.
That's a very interesting idea! There's a risk there because some colors that work well as icon backgrounds might be problematic as buttons but we'll explore what we can do.
It sounds like you are using a custom server that isn't compliant with our specifications. What server is it?
You’ll also want to make sure you follow the breaking-changes tag.
This is really cool. And after seeing it on my phone, the useful linkage between "Projects" on Central and "Projects" in Collect clicked for me - makes it feel like a more connected/cohesive tool set.
+1, that will be helpful! I was noticing that when loading different app users and/or different projects there is no current way to immediately distinguish between them.
Is there a way, from Collect, to know the App User Display Name for the loaded profile?
Are there use-cases in which someone would want a reminder while within a form about which project is loaded? Either by somehow retaining the project icon on those screens? Or allowing to adjust the project color and have it persist in elements when filling a blank form (like with the experimental magenta theme)?
1 Like
Mission accomplished! 
We talked a little bit about this during the last TAB call but I also want to respond here. Currently we don't use the Central API at all and rely entirely on the limited OpenRosa API for communication so no, Collect doesn't currently know the App User Display Name. I agree that this is an issue for folks who use App Users to group different subsets of forms within a project. I am involved in such a project and what I plan to do initially is go through Collect to change the settings QR code project name as captured in this docs issue. I'll make the project names things like "Serosurvey (Lab)" and "Serosurvey (Monitoring)".
Longer term we do want all Collect settings to be editable from Central but this work is not scheduled yet.
We're not sure. From what we hear from users, the form name typically contains enough information and it would be rare to have the same form name in multiple projects. But I can certainly imagine situations in which it'd be possible to lose context. Hopefully once we get an initial release out folks with that kind of need can describe their scenario and we can figure out whether there's a good change to make. This also relates to @Thalie's suggestion above to use the project color more in order to establish a project identity.
We are seeing a non-fatal crash report that makes us thing something is going wrong related to our performance improvement around selects. We have not been able to reproduce. If you see any unexpected behavior when using selects, please let us know.
The latest beta (beta 3) includes several improvements to projects:
- Creating a project immediately switches to that new project
- Project deletion is not allowed when there are unsent submissions (submissions must be sent or explicitly deleted)
- Google Drive projects can be configured from the manual configuration screen
- The project selection dialog is taller if there are more projects
- App shortcuts work across projects. They can be created for the current project and then continue to work even if the project is changed. It would be good to get feedback from anyone who relies on app shortcuts (e.g. @Florian_May )
- The first project created is used as the default if no project is specified using a content provider URI (if you use an external app integration, please try this)
Thanks for all the great suggestions.
There's a change to location access that we have to make for Play Store compliance and in parallel we are combining general and admin settings to address some of the issues around configuring project title, etc. We expect to have one last beta with those changes when we start quality assurance.
4 Likes
That's amazing to hear about persistent app shortcuts! I'll aim to test and review next week.
2 Likes
I really like the latest improvements and I found the interface easier to navigate in general. I had not seen you could create app shortcuts on the Home screen. Just looked at it, but it seems that you are losing the link to media files (images as CSV) in the shortcut when the project has been changed on ODK Collect.
Missing image
Missing CSV
Would you be able to share an approx. timeline for the release of v2021.2?
One of my research partners has just informed me that they are changing the composition of their data collection teams. As a consequence, one of their data collector would have to collect data for two different studies that are currently stored in different projects (1 project encrypted since collecting personally identifiable data / 1 project non-encrypted, both with different online access rights). I am wondering if I should retain the start of this data collection and suggest waiting for v2021.2 (which is obviously technically my preferred option) or must go the less preferred route of reshuffling forms / projects and protection levels.
Thanks so much for the careful look, @Thalie!
Yes, you are absolutely correct. For now, we've address this (here) by showing a dialog with an error asking the user to switch projects. We'll likely do this automatically in the future. We'll have a beta out within the next 24 hours with this behavior.
Monday July 26th currently looks like the likely release date but that could be pushed back if we find any other defects. We're now doing a thorough quality assurance pass. There are some big changes in this release and we want to make sure the transition goes as smoothly as possible!
2 Likes
Thanks a lot, this is already very informative for me to weight my two options / associated risks. I definitely understand the release can always be pushed back and cannot agree more on ensuring high quality delivery. I honestly feel pretty lucky with ODK's roadmap wrt own project needs.
1 Like
We have now published beta 5 which is our release candidate. Since beta 3, the biggest changes are:
-
General and admin settings are now combined
-
Geotrace and geoshape can now collect points when the screen is locked in a way that conforms with Play Store requirements
-
If there's an attempt to configure a project with the same server and credentials as an existing project, the user is prompted for confirmation or to switch to the existing project
-
External app integrations and app shortcuts require manually switching Collect to the correct project. An error is shown otherwise. More details
We're still seeing a log we don't understand related to selects. If you see any unexpected behavior when using selects, please let us know.
2 Likes
We were finally able to track down and fix the (serious) issue with selects and v2021.2.0 went out on July 27th. If you see any issues or have any suggested improvements to new features, please start new support threads!
Thanks to everyone who helped shape the new features, provided translations, participated in the beta and provided such great feedback. This big release has been a true community effort. 
1 Like
Hi @LN,
finally getting around to testing form shortcuts on Collect 2021.2.4 (Beta opted in).
I am using the managed QR code, so I can roll out form updates centrally without having to touch the data capture devices.
As an improvement, I can see that after disabling a form (say, the 4th in alphabetic order) the other shortcuts to forms remain stable.
There are two behaviours that make my user experience harder:
- Shortcuts link to form versions, not to form ids. Updating a form means I have to replace the shortcut to that form version with a new shortcut. This breaks rolling out silent / centrally managed form updates.
- Although I have selected "hide old form versions", the old versions show up in the list of form names when adding a shortcut. Moreover, only form names but not versions (nor date updated) are shown. This means I have to guess the latest version (bottom most list position?) from several identical form names, or talk my regional coordinators through the process. Only resetting the form cache gets rid of these versions.
Suggestions for general behaviour, or only if "hide old versions" is not selected:
- Shortcuts should link to the latest form version. So they should link to the form ID, not the form version.
- The shortcut form selection menu should show only the latest form version.
- The shortcut form selection menu should include version and date updated (only indication of which version is the latest one), much like the Fill Blank Form menu does.
I think you’ve put in a feature request for this and it’s being tracked separately. It’s a fairly sizable change, especially to also maintain backwards compatibility, so no ETA for it. The whole way shortcuts work is based on a specific database id.
This may be relatively straightforward. PRs certainly welcome.