Collect: More efficient repeat group navigation

[smoyte]

Many form designs include repeat groups that may not be filled out in a linear fashion. For such forms, the ability to easily jump from repeat item to repeat item would be a big usability gain.

Imagine a form for a household with 10 members. The enumerator wishes to first list everyone's name, and then survey the members one by one, often jumping around the list in a non-linear way. Getting the names at the beginning is important because people may come and go.

Currently, doing this via the jump screen is somewhat painful.

Now that we have the ability to dynamically name repeat items things are somewhat better, but still, if you are on a question in one of the repeat items, to go to a different item, you need to tap: Jump > Go Up > Expand Arrow > Desired Item > Desired Question. That's 5 taps for each jump, and each is in a different part of the screen, meaning a lot of finger targeting and moving and cognitive load! If you're doing this a lot, that's a lot!

Suggested Solutions

To remedy this we're suggesting 3 separate changes:

1. Separate screen in jump screen for listing repeat items
2. Change jump screen icon to convey 'up' metaphor and show this icon in jump screen
3. "Add item" and "Delete item" buttons in jump screen for repeat groups

Separate screen in jump screen for listing repeat items

Currently the jump screen with repeat groups looks like this:

Specifically:

1. The repeat group is shown initially as a collapsed list item
2. When expanded, a list item is shown for each repeat item/instance
3. Tapping an item opens a separate screen showing the questions within the item.

So there is a somewhat strange combination of two techniques for browsing a hierarchy: 1) tree view, 2) screen-by-screen drill-down.

I would argue that #2 is the more common approach in mobile UIs. Think of the Android settings screen, the iPod interface, etc. Therefore I'm proposing we change things so that tapping the repeat group opens a new screen to show repeat items instead of expanding.

This approach can be seen in these mockups. (You can ignore the question icons and other fancy stuff for now and just focus on the navigation from top level down into a repeat group item and back up.)

Change jump screen icon to convey 'up' metaphor and show this icon in jump screen

Check out this diagram:

I think this is the implicit mental model of ODK Collect -- the left-right swipe motion moves through a long a linear list of questions (those grouped into a single screen are field-lists or grids). Going to the jump screen is kind of like moving 'up' from the base-level question view. This is reinforced by the label of the button 'Go Up' in the jump screen footer. You can go all the way 'up' to the top level of the jump screen, or all the way 'down' to the question view.

Right now, moving up through the hierarchy is cumbersome because to get from a question to the top level via a repeat group you have to:

1. Tap the jump screen icon (this brings you to the list of questions in the repeat item)
2. Tap 'go up' (this brings you to the screen on which the repeat group appears, contracted)
3. Expand the repeat group (note that we skipped a step here -- the repeat group is revealed before its members)

So you have to tap three different things just to get to the list of items in the repeat.

If, instead, we:

1. Do the above (put the repeat items on a separate screen) AND
2. Change the icon to convey the 'up' metaphor that we implicitly use AND
3. Include this new up icon in the same place in the jump screen header as the question view header...

THEN

Moving up the hierarchy is as simple as repeatedly pressing that icon.

1. One press gets you to the list of questions you're in
2. Second press gets you to the repeat item list
3. Third press gets you to the level where the repeat group lives, etc.

Our mockups convey this idea. e.g.

"Add item" and "Delete item" buttons in jump screen for repeat groups

Cuz why not!? See the mockups for where these would be located.

This would make it much easier to add/remove/manage repeat items.

(In future it would also be nice to prompt the user to enter an answer to a key question (e.g. person name) right when they click the 'add' button, but that's for another day.)

That's it! Thanks all for considering!

PS: Note to Helene, others: I know earlier we had discussed skipping the question list for groups that contain only field-list. That is still a possibility, but I realized it may not be as useful given that for non-trivial forms it's hard to have a field-list only repeat group because conditions and multi-level select-ones don't work in field-lists. So that solution won't work for us I think. I also think it might be a bit confusing and inconsistent. I prefer making it easily to quickly move up the hierarchy instead of just skipping things outright.

[smoyte]

Today in the TSC call the question of the 'Add New Group?' modal came up, and whether we should get rid of it, and how that relates to these changes. After reviewing things I am thinking the following:

First: If we're going to maintain the left-to-right swipe metaphor/technique, I think the modal is a pretty good solution to the problem of how to prompt for adding a new repeat item. I can't think of any way of getting the user up into the jump screen to add a new item that wouldn't be jarring and confusing.

Second: We might want to add an option to automatically insert the first item. It seems in the vast majority of cases you're going to want at least one item, and I think it would be less jarring to the user then because they'd know they are already entering data about e.g. people, so the request to add another person makes sense. The way it is now, the first you hear about "people" is an abrupt and slightly cryptic modal.

For those rare cases where you don't want at least one repeat item, we could perhaps add an item to the question view dropdown for 'Delete present repeat item', which would then just dump you into the next question after the repeat group. (Or folks could use the new trashcan icon, but then they'd have to do a few clicks to get back to the question view in the right place.)

Third: It would be nice to spiff up the text in the repeat. Right now it says e.g. "Add another 'People' group?" Yikes! If we had some way in the XForms spec of specifying the noun or even the full string here, that would make things a lot more usable. So it could instead say "Add another person?" (noun-only version) or something totally custom like "Are there any more people in this household you'd like to interview?". For nested repeats it would be nice to be able to mention the parent item, like "Does Sally have any more pets?" The modal title is currently "Add New Group?" or "Add One More Group?" I think there is a title just by convention, but it's very similar to the body. I think it could be nixed.

If folks agree with this approach I could incorporate it into this proposal or do a separate one. Might be nice to include it since it's relevant.

[lognaturel]

We might want to add an option to automatically insert the first item.

Take a look at XLSForm/pyxform#182 for an explanation of why a first item doesn't show up for forms created with XLSForm (it's because jr:template always gets included) and a possible way of addressing it. We're currently thinking of always including a first instance in addition to the template instance.

[lognaturel]

I think it would be helpful to consider the changes to the repeat dialog separately. Those will require specification amendments and I don't think it needs to block progress on the other UX changes.

There is deep in JavaRosa and early form specifications the concept of a "repeat juncture" - https://forum.opendatakit.org/t/change-static-text-in-groups-prompt/1505/ that allows for more customization. That might be something to look into and perhaps we could use just jr:addCaption for customizing the existing dialog.

[smoyte]

Just noting here that there have been several mentions on the forum in support of having a new screen in the question flow "between" repeat items that could be used to manage same. I am still not convinced of this approach (I still think some kind of sidebar or flyout would be better) but in any case I see it as orthogonal to what has been proposed here. The two could end up being complimentary, and I think what's being proposed in the forum is quite more involved than the changes here.

I suggest we continue with this plan and then discuss next steps when it's done.

[smoyte]

One thing I just realized it would be nice to squeeze in here: right now I think a repeat group doesn't show up in the jump screen if it has no instances. How hard would it be to change that?

[jd-alexander]

One thing I just realized it would be nice to squeeze in here: right now I think a repeat group doesn't show up in the jump screen if it has no instances. How hard would it be to change that?

@smoyth I was wondering about that as well because I have utilized other mobile form solutions where repeat groups without instances still show up with its title and description along with an Add New Item button.
I realized there's a + icon in the UI to add a new item to the repeat group. Would attaching it to that functionality suffice?

[jd-alexander]

@smoyth I was looking at your mockups and I realized a comment about sibling to sibling navigation for the transition effect that takes places from a question row to the form input screen. I am not sure if that transition would work well with questions based on the examples I have seen of it where the transitions primarily take place with elements that are on the same hierarchy such as tabs but in this case I think a parent to sibling transition is being taken place and that animation seems a bit more fitting. Let me know what you think and if you have any examples of the sibling to sibling effect that would demonstrate its fit.

[jd-alexander]

In terms of the new proposed way of navigation based on my analysis of the existing code and what needs to be done this is the first approach that comes to mind.

1. When the FormHierarchyViewActivity loads the hierarchy and a repeat group is clicked, the current group can then be center of focus and the refreshView functionality just does a reload that clears out the HierarchyElement collection binded to the list and adds only the items that are within the group itself.

2. A whole new Hierarchy screen could be launched so that it's extremely clear that navigating to a repeat group goes to a seperate screen. This would utilize some of the ideas from number 1 where the Hierarchy list would simply load items within the group but the collapsed and expanded functionality would be removed.

I think utilizing the (2) second approach is what's best because we are able to utilize Android's navigation stack easily by adding a new activity to the stack.

The only advantage of (1) would be the ability to only change a portion of the screen without having to do a full navigation and the list animations would be smooth.

[smoyte]

@jd-alexander

Regarding empty groups -- I'm not sure I quite understand your comment. The + would appear on the screen for the repeat group. But we can't even get to that screen if there are no instances, since the group doesn't show up at all. If we made it show up, then when you tap on it, it would go to a screen saying e.g. 'There are no items in this group', then you could use the + button to add one.

Like this: https://app.moqups.com/sassafras/4WPu8QH3er/view/page/aa2a74b83

[smoyte]

@jd-alexander Regarding transition animations I trust your judgement here.

[smoyte]

@jd-alexander Regarding the implementation directions, I'm not that familiar with the code but just based on your comments #2 sounds better to me. I would expect that the expand/collapse should go and whatever happens when you go from a repeat instance view to the top-level view should also happen when you now go from repeat instance view to repeat group view. They are all just steps on the hierarchy. Unless I am missing a big piece of knowledge here...

[jd-alexander]

No you aren't missing anything. You are right on the ball!

[shobhitagarwal1612]

Closed in getodk/collect#2740