Back in November I started out on a round of user research focused on repeat questions. I ended up interviewing 4 form designers around how they use repeats in Collect. You can read a rough guide to the methodology used here.
My write up of the reseach process and the results are here but I'll list the changes we're planning to make to Collect (based on the problems we heard about) here:
Fix "Add new group" dialog closing on app background
Improve the language around repeats in Collect better. On the "Add new group" prompt we could tweak it so that it puts more prominence on the repeat group label by removing the "group" word altogether.
Revise navigation back through repeat instances. This would be really helped with field visits to see Enumerators work with repeats.
Look at adding the ability to add a new repeat instance without navigating to the hierarchy screen (could be within the options menu).
Revise documentation to highlight using multiple form instances instead of repeats where appropriate.
I've also put together a mock up of how these changes to Collect will look here. There's also a first pass at docs changes happening in this PR.
We're planning on these changes being part of the Collect 1.26 update (our release backlog is here). This could change of course. Feedback on this work is much appreciated!
There were of course bigger changes we could look at in an effort to support use cases form designers are having problems there is a larger ongoing effort looking at that. I'll make sure the findings from this research contribute to that.
So I understand ther will be two ways to add repeat groups : this button and the traditionnal way (swipe /arrow button). Am I wrong ?
2020 seems to be very existing on the ODK side
It's interesting that people wanted an icon for adding repeats from within an existing repeat. What is the use case there? Maybe they have filled out the important questions and want to jump ahead rather than swiping through the full repeat?
Was the idea of tapping the hierarchy button once and then the up button once to get to the add button too much? Or did people not know you could do that?
As for simplifying the dialog text, I also love that idea! I think it may have ramifications for the form design process since if you are going to have a nice smooth sentence like 'Add another observation', you have to allow the form designer to specify it somewhere. Currently all we have the group name 'Observations', right?
I suppose you could call the group 'Observation', but that looks weird in the hierarchy view. Or maybe not? I notice that's what the Carter Center folks have been doing. So is the convention just to specify a singular noun as a group name? Can we rely on that or are there lots of people out there who will end up seeing "Add another people" or "Add another household members". Seems like that could be seen as a bug...
For case, were you planning to just downcase the group name? So Observation becomes observation? I am sure that a lot of people have capitalized group names, even if they're singular. The Carter Center's forms are using 'Person'.
@mathieubossaert note that you can already add a group from the hierarchy screen using the plus button in the toolbar. I believe the proposal here is to also add that button to the question view toolbar when inside a repeat group. @seadowg do I have that right?
Yeah! An example would be where enumerators would get a list of people in a household up front and then fill out the rest of the info with individual interviews.
That did come up but there were still some examples with skip logic being used to make it easier for enumerators (skipping to the end of the repeat after key info taken). Generally the impression I got was that navigation within the hierarchy view felt clunky to folks and that getting to that button required extra training.
Yeah I think we'll play with this and definitely make sure to give it some time in beta. I wouldn't imagine we want to change the name (capitalization etc) and it'll still be an arbitrary string. We're basing this on the assumption that people are repeating questions about some kind of entity/thing so it's up to them how they name it!
@seadowg put in a pull request at https://github.com/opendatakit/collect/pull/3602 and I wanted to report back on some discussion that we had there. There were a few things I had not considered when reviewing this thread that came to me in code review.
The current proposal is for the dialog text to read simply Add "<repeat-name>"?. The "new" or "another" has caused confusion among enumerators and @seadowg has realized it doesn't add anything. In the case of repeats named with singular nouns, this will make very comfortable queries such as Add "observation"? or Add "Patient"?. If a form design uses a plural noun, it's not great (e.g. Add "Observations"? but it's no worse than it was before. This is in line with what @mathieubossaert had specifically requested here.
I can confirm that this will work well in Romance languages (e.g. Ajouter « mammifère »?, Agregar "fruta"?). @seadowg is adding a note to translators to make it clear that the goal is for a short sentence that works with any kind of singular noun (feminine/masculine or whatever other forms a language may have).
In the mockups above, @seadowg had used No and Yes for the buttons. We went back to general UX guidelines and found that verbs are generally recommended. Using verbs means that someone doesn't need to fully read the dialog to take action. Understanding what No and Yes refer to requires more thought. So the current proposal is to use Do not add and Add for the button text.
We hope to alert translators of the change in the next couple of days and to have a beta available soon.
