I have been trying to categorize downloaded forms in ODK Collect in groups - like folders. I am new to android app development and was wondering if I have taken the right path and would be very happy to receive any piece of advice. The way I am trying to implement this is by populating a menu with buttons depending on form prefix. When such button is clicked it will open the activity which will be populated with forms with the particular prefix. I am looking forward to receiving any feedback or suggestions on implementing this feature or if anybody else has already done anything similar or intents to do.
Thank you in advance and I want to express my gratitude to the team and the whole community working on this wonderful open-source project.
The idea of grouping forms is an interesting one. We added filtering and searching to all form lists a few months back it sounds like you need more than that. What high-level problem are you trying to solve with grouping?
And as far as the approach, do you have the code in a branch somewhere we could look at it?
I think it could be a useful addition to allow forms to have an arbitrary 'category' property, to assist users in locating and selecting from a large number of forms (and versions thereof). The high-level problem being whenever you start dealing with a large number of anything - forms, files, whatever - trying to browse thru them based only on their name starts to get unweildly, and its natural to segment things into meaningful groups, be they categories, folders whatever.
So I also think that having a category/folder structure in ODK for forms - in Collect, or Aggregate for that matter - could be quite useful when you start dealing with lots of forms. Probably a single level hierarchy is sufficient (ie no compelling reason to introduce 'subcategories').
For the last few days I began working on this feature and I beieve I have effectively imlpemented it. The way I do it is:
I add additional column "formGroup" in the database to identify every form. The "formGroup" is chosen based on the string before the first underscore(_) in the name of the form when the form is downloaded.
I built another activity like the "FormChooserList" one but instead of displaying all forms this one makes a query and groups the forms based on their "formGroup" column and displays it.
After having this list loaded, I can set onItemClick to make a query to get all forms with "formGroup" equal to the title of the group.
This is a brief overview of how I implemented the feature. I would be happy to show you my code. However, before I do this I need to make sure everything is working smoothly. Allow me some time to test it. Furthermore, as I am new to Android Development, mind that this implementation might not be the best one even though I find it to be sufficient.
I know I'm reviving a very old topic, but this is the only thread I've found where this has been discussed, as well as it looks like @yavoredipov has made some progress.
My question: Has there been any more progress on this idea? I'm looking for the ability to organize a large number of forms into manageable groups as well, as it would greatly improve my users experience with what I already consider to be a very user friendly application.
I also like @Xiphware 's idea to add a property to the form definition in order to define the grouping on the device.
I'm mostly just looking to see if there is already something started to implement this change or if I should start it myself.
Can you tell us more about your high-level scenario and the problems you're trying to address? For example, how many different data collectors do you have? Do they use their own devices or share communal devices? Do they all have the same role? How many forms do you have? What is the connection between those forms? Do they all need to be available at the same time? Who determines what forms need to be filled when (e.g. the data collectors make the call based on training vs. a project manager communicates with data collectors)? How do you communicate with data collectors (e.g. Whatsapp group vs. in person)?
We've been working on getting better form segmentation at the server level since for a lot of scenarios that's what's needed. We've done this in ODK Central which is the replacement for ODK Aggregate. Everything in Central is organized by projects. Projects group together forms and app users. Typically app users represent a role like "health worker" or "lab technician". App users within a project can be given access to a specific subset of forms. This means that a specific data collector can see only the forms that they need access to from Get Blank Form.
Currently, if the form list changes over time, that requires manual management. In the next Collect release, there will be a setting to ensure that what the server provides as the form list for a specific app user is exactly what Collect shows in Fill Blank Form.
FYI this ability of Central is pretty much exactly what I was envisioning (back in 2018) wrt to my single-level 'category' hierarchy to organize forms.
Perhaps, in the future, as Central (and its projects) becomes more pervasive, we can consider exposing these projects within the Collect app UI as well...
The model Central has gone with so far is that app users exist only within a single project and are restricted to seeing only the forms relevant to them. This is what a lot of large deployments with some kind of centralized project management structure tend to need. Central likely will provide additional organizational options at some point which is why it'd be great to hear more about @gfinch's underlying needs!
I'll try and answer @LN 's request for a high-level view of what I'm doing.
I've got two groups of forms so far:
Production / reporting forms (5 individual forms): these should be available to all users.
Safety forms: 5-10 planning forms for Safety Managers, 5-10 reporting/inspection forms available to all.
For devices, half of them are assigned to specific users ("management" group), half are communal, which are shared between users that would only be using them for the production / reporting forms.
These devices are deployed to remote sites which restricts me to only being able to update / change forms, etc. via over-the-air methods (I am unable to connect and add things via ADB).
After reading your description of ODK Central I have started looking into it as a replacement / upgrade to my Aggregate server. The planned feature for Collect to be able to get it's form list from the server is going to be a great manageability improvement that I am looking forward to. It looks like the "project" containers in Central should also solve some of my questions as well.
One note about "project" users, I would have some users that would belong to more than one project (managers).
I am still going to have some users that will need access to 15 or more forms, which becomes a usability issue if I just give them a long list of forms to pick from.
Hopefully this covers the high-level overview. let me know if you would like more information about what I'm trying to do.
Thanks very much, @gfinch, that's very useful context and I'm glad to hear some of what we have done and are planning will be useful to you.
Are these users who are only collecting data? Only managing forms and data? Both?
Would they need to frequently switch between forms across categories? Another change to Collect that we are contemplating is adding a concept of profiles. This would allow for configuring several different servers or projects and switching between them.