Repeat group UI redesign

[smoyte]

I think we can all agree that repeat groups could be more usable. This has been mentioned elsewhere -- see #168 for example. I made a new issue here because the title of that one understates the need for a rethink IMO.

The new design should perhaps also incorporate the question jumping screen as it seems the problem of jumping into an existing repeat and creating a new repeat are related.

By the same token, it should also consider how you might delete a repeat.

One requirement of a client of ours is the ability to create a set of partially completed repeats when starting to fill out a form and fill them in later. The use case is that they arrive at a house and first ask 'who lives here' and want to record names. Filling out the repeats partially helps prompt them to finish each of them later.

So the design should be flexible enough to meet this need.

We are planning to come up with something here at Sassafras in the next few weeks and share it in this thread. In the meantime, thoughts on the matter are welcome.

[lognaturel]

@shobhitagarwal1612 You had a wireframe related to repeats in your GSoC proposal and I think you mentioned you had come up with some more ideas. Would be great to hear some of them here!

[florianm]

@lognaturel thanks for the heads-up!
As I mentioned over at #464 - repeat groups are hard to understand for first time or occasional users. The best I can come up with are collapsible sections (bootstrap example) with "add another" and "delete this" buttons. This might work better on desktop than on mobile though.

Ultimately I'm dreaming of a progressive / responsive web app that responds to screen factor and / or user selection whether to show the streamlined "data capture" form (on mobile / tablet), or the detailed (desktop / laptop) data curation / QA version of the same form.

[lognaturel]

#868 is really a subset of this. I'd rather try to address it all at once than to add incremental fixes if possible. @hooverlunch any update on a proposal from your end? I like what @florianm and @shobhitagarwal1612 are suggesting. I think they're pretty similar. @shobhitagarwal1612 did you also have a sketch for the screen prior to the one you showed? The one where users could add more repeats or remove them?

[shobhitagarwal1612]

@lognaturel I didn't make a wireframe sketch for that. But I can try making one. I will post the same on this thread. Any ideas or thoughts how it might look?

[lognaturel]

Well, let's see. There are a few different cases:

• No jr:count -- that's probably the most typical case where users are currently prompted about whether or not to add more repeats.
• Static jr:count -- a set number of repeats need to be automatically generated. That shouldn't change.
• Dynamic jr:count based on previous question -- currently the repeats are automatically generated once at the beginning (see Decrease in Repeat_count while filling in #868). One way to replace that would be to show the count at the top and basically collapse this case with the first one.

I'm imagining that when the user swipes to a repeat group, they'd see something like the group label and hint up at the top, probably with a count of existing repeats in there somewhere. If there's a static jr:count then rows for each repeat would be pre-populated with no way to add more or remove existing ones. Otherwise, there'd be a button for adding another one and some way for deleting existing ones. It's still pretty rough in my head but hopefully the idea of these different cases is helpful. Did I forget any?

[smoyte]

Yes I have done a first round of wireframing and am iterating with TCC folks. Should have something to show here soon. My wireframes are focusing primarily on the jump screen with a few tweaks to the main flow.

I can share something here a bit later this week to get the conversation started with the understanding that TCC folks may also be requesting deltas as well.

Is it ok if my wireframes use the new Material Design style as a basis? Is ODK ok with moving toward that style?

[lognaturel]

Cool! Just to make sure we're all on the same page, TCC is The Carter Center which uses ELMO (the backend built by @hooverlunch and his team) for election monitoring.

By "requesting deltas", you mean changes, right?

Re-reading your initial message, do you have some implementation ideas for your partially filled form concept? I think this will require changes to the XForms spec and Javarosa so it might be good to get those conversations started on the relevant repos.

Material Design is the way to go but of course that transition is ongoing so there will be some evolution to exactly what that looks like for Collect. See #912 for the first stab at updating underlying libraries while mostly maintaining the existing look and feel. Would be great to get your comments there.

As you may have seen across some other issues and in #collect-code, the current plan is to try to get the lib update merged into master so that new features can leverage the updated libraries. In parallel, we'll be working in the ui-refresh branch to make the more disruptive changes to look and feel so that they can be released together with a few months of advance warning to users. That will allow organizations to review wireframes, try out alphas and make a training plan if needed. @shobhitagarwal1612 has been iterating on the big picture as part of his Google Summer of Code project and will be leading much of the effort, hopefully with lots of community input!

I think this repeat group change will be pretty significant so it will likely go in the ui-refresh branch. I think it would be great if it could launch along with the other updates to Material Design. I am pretty sure that this will require changes to Javarosa so we will also need to coordinate with a release on that side of things. Anyway, I'm a bit in the weeds here but I do think it's worth thinking about some of these logistics early since there are a lot of moving pieces!

[smoyte]

First off, I am proposing that what we call 'instances' (I think) of a repeat group should be called 'items' in the UI. Currently it seems we are avoiding calling them anything and it leads to awkwardness.

For the partially filled group thing, I was thinking of having a checkbox on the first page of the group (at bottom) reading "This is a placeholder item".

If that box is checked, a special icon and text treatment will show for the group in the jump screen (what I'm now trying to re-cast as a more functional 'form overview' screen), and validation will be paused for that group so that you won't get errors (if you have error checking set to 'on swipe').

I think you shouldn't be allowed to submit a form with any placeholders in it since otherwise the implication would be that you can come back later and fill them out and resubmit, which I think is an ODK (and ELMO) no-no? I need to check with TCC if this will work for them... If it doesn't I'm not sure what I will do...

Thanks for pointing this out and getting it on the table early.

[smoyte]

Ok folks, here is a first draft.

The main idea is to overhaul the jump screen, renaming it the "form overview" screen, and adding the ability to add/remove repeats (what I'm calling "items") from within it.

The concept of a placeholder item has also been introduced (look for the pause icon).

The main form input flow is largely untouched in these designs, save for a few things:

• A new proposed breadcrumb trail at the top of any group screens
• Improved messaging in the "add new repeat item" prompt
• A new proposed toolbar icon for getting to the form overview screen

Note that this is a set of wireframes with Material Design stylings, not high fidelity mockups. They could be spiffed up visually for sure--that was not my focus nor is it my forte. (I am thinking especially of the title/toolbar area. And there are likely other places.)

If anyone wants to add comments to the Moqup, send me your email address and I'll invite you.

Without further ado, the link: https://app.moqups.com/linesarefuzzy/4WPu8QH3er/view

I'm looking forward to hearing your thoughts! As I mentioned earlier, there may be changes from the TCC side also as we discuss these. I'll try to share any such things here as I do them.

[lognaturel]

Great! So I think we should break this up into 3 issues: reworking the UI for repeats, reworking the hierarchy/jump view and partially filling repeats. I think these mockups look good for the hierarchy/jump view but I do also think we should rethink what happens with repeats within a form's flow.

[smoyte]

I'm glad you like them!

As for the "form input" flow/screens (as I have been calling them), I guess it depends on how much you had been planning on overhauling that part of the system. I wasn't thinking about that stuff much, assuming that the existing "prompt at the boundary" approach was OK.

Has there been much talk about reworking the input flow?

One simple idea might be reworking the prompt a little more to include the option to jump back to the form overview screen.

Another thought is user testing. Do we have much data on what pain points people experience with these things? Might we want to try some user testing on these mockups with more or less the existing input flow and see what people say?

[florianm]

+1 for @hooverlunch - love the parent/child transition for groups. Much smoother UX than the "add new ThingAMagigGroup" dialogue. Plus, the breadcrumb really helps to know where you are!

[shobhitagarwal1612]

I have started working on the new form overview screen as proposed by @hooverlunch in the mockups

[lognaturel]

That's great! I think you mentioned on #collect-code that you had started breaking it down into smaller tasks. I encourage you to share that here. Are there any parts that you think need further description and/or that aren't going to be feasible?

@hooverlunch and I are going to do an unconference session tomorrow in which we design a user testing protocol for the mockups to get a little extra information about what works and what may need refining.

[smoyte]

@lognaturel @shobhitagarwal1612 @yanokwa I have updated the mockups.

This is the first page in the flow: https://app.moqups.com/linesarefuzzy/4WPu8QH3er/view/page/a9e9f72cf

@lognaturel @yanokwa Let me know if I covered everything from our call.

[lognaturel]

The big thing that jumps out at me @hooverlunch is that there's currently no way of doing the naming of repeat elements (the ones in Household Members in your example). Perhaps it could be done with a change to the spec but I'm really not sure what that would look like. If you have ideas, the best place to get the conversation started is probably the features category on the forum.

The other big thing that needs to be decided is when groups that are not repeats are collapsed. #1271 collapses all of the named groups and it's interesting to see the implications that has for different forms. For example, the form shared here nests everything in a group. There are also various parts of the form that are separated out into groups that may not need to be in that hierarchy view. To reiterate, options are:

• Collapse all named groups (current behavior of [WIP] Form hierarchy redesign #1271). This would need some broader user input
• Introduce a new appearance that can be applied to groups explicitly when they should be collapsed.
• New idea: have a settings checkbox called something like "collapse named groups in hierarchy view" that is off by default.

We should probably bring this up on the forum as well.

Aside from those two big things, I think #1271 is a good first pass in terms of functionality and now needs to be thoroughly tested and code reviewed. @hooverlunch can you verify that this is the case? A small change I'd make, @shobhitagarwal1612, is changing the filled out folder icon you're using to the outline and outline with repeat icon ones that @hooverlunch has in his mockups.

Icons, add/remove repeats and possibly validation can be added through separate pull requests.

[shobhitagarwal1612]

A small change I'd make, @shobhitagarwal1612, is changing the filled out folder icon you're using to the outline and outline with repeat icon ones that @hooverlunch has in his mockups.

@lognaturel Done

I couldn't find the outline with repeat icon so I have used a repeat icon instead of that. Meanwhile I'll try to create the outline with repeat icon

[smoyte]

@lognaturel I am confused about the repeat instance naming thing. I thought we had determined this was possible via $notation/<output>. I will follow up with you on Slack about this and then we can post a summary here.

As for when to collapse non-repeat groups, I'm easy on this one. TCC doesn't have a big investment one way or the other and we can build ELMO to do whatever is decided. I think it would be nice to have the option though.

@shobhitagarwal1612 Could you perhaps send me a debug build of #1271 on Slack? I don't have a build env setup yet and my regular computer is in the shop today so there is no point in me taking the time to set one up.

[smoyte]

Ok I see now, you can use in the group label like this:

    <group>
      <label><output value="/data/grp74/q51"/></label>
      <repeat nodeset="/data/grp74">
        <group>
          <input ref="/data/grp74/q51">
            <label>First Question</label>
          </input>
        </group>
      </repeat>
    </group>

but then you get this:

so it takes the first group's question value for the whole repeat group name, which is awkward.

This looks right:

But this is also a problem:

[smoyte]

Seems like this should work, but it doesn't:

    <group>
      <label>People</label>
      <repeat nodeset="/data/grp74">
        <group>
          <label>Person: <output value="./q51"/></label>
          <input ref="/data/grp74/q51">
            <label>Person Name</label>
          </input>
        </group>
      </repeat>
    </group>

The inner label is just ignored.

Would not ignoring it constitute "adding it to the spec"?

[smoyte]

@lognaturel Ping?

[lognaturel]

As I understand it, it's by convention that the group a repeat is immediately nested in is used as the name for the repeat and by extension the repeated elements in the hierarchy view. Here is the description in the ODK XForms specification.

I believe what you're suggesting is to add a new convention stating that if there's a group immediately nested in a repeat, the label for that group will be used as the repeated elements name in the hierarchy view. Does that sound right? If so, that does seem like a good option.

[smoyte]

Yes you're correct. I will head over to that repo and see if I can figure out how to suggest a change :)

[smoyte]

@lognaturel getodk/xforms-spec#141

[lognaturel]

Two of the major concrete suggestions from this issue have been addressed:

• there is now a convention for displaying a meaningful label for each repeat (getodk/xforms-spec@16c189b and Repeat titles #1648)
• the hierarchy view now makes it possible to add and remove repeats (Collect: More efficient repeat group navigation roadmap#19, "Repeat group picker" UI for FormHierarchy #2740)

There are still a lot of improvements to be made but let's track that work in more specific issues.