New XForm appearance: hierarchy-visible groups

I've opened a PR here that adds an optional new XForm appearance for groups. This appearance would allow groups to be designated as "visible" so they show up on the jump screen (FormHierarchyActivity). You can then click on the group to see its children.

Normally groups are invisible to the user, but with this new appearance, they become a selectable item in the jump screen. All children of the group are then hidden from the main screen, and will be shown on the inner screen instead, effectively giving these visible groups the exact same navigation behavior as existing repeatable groups.

Some folks want non-repeat groups on a separate screen so that the grouped questions don't push other important items "below the fold" on the jump screen.

This is opt-in behavior, available like so:

<group appearance="hierarchy-visible">
    ...
</group>

The existing XForm appearance options are here for reference.

If anyone has feedback, please feel free to reply here or to review the PR.

3 Likes

Given all the :heart_eyes: it sounds like there is no push back. @martijnr is this something you'd be OK with? Would you implement it in Enketo?

@cooperka I don't like exposing the hierarchy term in the appearance since that term is really only used in Collect and it's not clear it's a great name (I say as someone who probably chose that name :laughing:). Maybe always-visible?

How would nested groups be handled? (either regular ones or repeat groups). I ask because 'hierarchy' rather implies nested... Or would the form group depth be effectively restricted to 2 (or 3)?

Some alternative names we've considered:

  • hierarchy-visible is Collect-specific jargon, you're right
  • visible is too vague, could be thought to apply to the group items which are in fact not visible
  • always-visible sounds better to me
  • navigable conveys being able to navigate into the group
  • nested conveys hiding the items, but may be unclear

I'll go with always-visible unless there are objections.

They can nest indefinitely. The proposed PR has a couple of screenshots as well as XML you can try.

Current repeatable groups can also nest indefinitely; the UI was recently altered in #2740 to make this nesting look and feel more intuitive.

1 Like

OK. Gotcha, thnx for clarifying.

This new appearance behavior is basically how I've been handling nested groups (in iXForms. see this thread). So, for me at least, it raises the question of should this perhaps be the default behavior (!); that is, by default all sub-groups are identified as such (using the "Group" footer at the bottom of the respective row) and selectable. And instead only introduce an appearance to explicitly not display a group as such, which strikes me as the less common usecase that needs a special appearance.

When nesting groups, it seems like the default behavior should be that they are all navigable (aka visible), unless specified otherwise. Thoughts?

If I understand correctly the 'jump screen' or Table of Contents, shows all questions by default, and this proposal is about making groups visible in that ToC as well. I'd prefer to show groups by default, and use an appearance to optionally hide them in the ToC (this is what you meant as well @Xiphware?). Is this perhaps not considered because it would change existing behavior?

I'd prefer to use the word 'toc' or 'jump' or something in the new appearance to avoid any confusion with how the groups are displayed in the form itself (which is not impacted right?), e.g. hide-toc.

Enketo has so far taken a bit different approach by showing a simple flat list of pages (not questions) as the ToC. The first label on a page is shown as an item in the ToC (could be group label or question label). However, that feature is very new and can be changed to match Collect (once users start requesting this).

Is there an issue around how the existing field-list group appearance ties in with all this (since a field-list is making assertions on how the group should be 'displayed'...) which I'm not quite clear on. @cooperka perhaps you could you clarify?

BTW I use field-list to distinguish between a group that is to be displayed as a new page vs a group to be displayed inline (ie expanded) as a section within its parent page. But I'm guessing this is not what you are proposing, hence my question how they'll fit together. thnx.

There's a long history of groups being used simply to show a "label", or for structural design purposes, or to skip the group until relevant based on other answers. Making this new appearance the default would probably be too big of a change, at least for now. Perhaps in the future we could discuss a new top-level attribute to make it a form-wide default at least.

I think there's no issue, because that field-list controls form-level presentation whereas this new appearance is table-of-contents-level. The appearances are for different types of screens. Let me know if I'm misunderstanding.

That's a good point. One issue is that there doesn't seem to be a clear understanding even among our own users on what the "jump menu" or "jump screen" or "hierarchy view" or "table of contents" is called, and we also don't want it to be app-specific. But as long as we explained it in the docs, I think that type of name would be more clear.

@yanokwa what do you think of calling the appearance toc-visible or show-toc (and explaining what "toc" means in the docs)? That word seems generic enough.

Perhaps just enumerate all valid combinations of appearances - field-list, table-list, show-toc (or whatever) - for groups & repeat groups, and make sure they have a meaningful UI representation, for both relevant=true and relevant=false ?

Ah, I see what you're getting at. It doesn't look like you can set multiple appearances on a single node, so if you have a field-list group, it's not possible to simultaneously designate that group as toc-visible.

To solve this you'd simply need to nest the groups -- an outer toc-visible group and an inner field-list group. Does that help? I haven't tested this specific behavior, so I'll add it to my backlog just in case.

I dont know about group appearances, but you can have multiple space-separated appearances on controls; eg select

That rather seems like a potential candidate for supporting multi appearacnes for groups: ie "field-list toc-visible" ?

As far as I know the XLSForm docs don't say anything about this currently, and I'm hesitant to add a new feature here just for convenience. I would suggest we hold off on this for now.

Yup. I think its more a question for the group (eg @yanokwa, @martijnr, @LN): do we need to consider supporting multiple appearances for groups, now that we're adding additional group appearances, which may or may not be strictly mutually exclusive?

I prefer to do the narrowest thing that moves us forward, so those grounds, multiple appearances on a group doesn't appeal to me.

There seems to be some interest in making this the default behavior and, I haven't thought deeply about it, but it does seem reasonable and consistent.

@cooperka you suggested that making these groups visible in the ToC (or whatever) is a big UX change, but we are already making a change in the ToC and this doesn't seem that drastic. I wanted to explore your concerns and try to minimize them.

  • Used simply to show a "label"
    • It's a pretty tiny label in form entry, no? And that label isn't see at all in the ToC, which is a place where it'd also help. This change makes that label visible at the expense of a click.
  • To skip the group until relevant based on other answers
    • these typically don't have labels and so we can reduce the scope of the change by only showing groups that have labels.
  • For structural design purposes
    • Not sure what this means.

Am I missing use-cases where this change would make life worse for users?

To help measure impact, I took a quick look at our analytics. EditFormHierarchy and FormHierarchy represent 5% and 3.3% of screen views this year. FormEntry takes up 37% of screen views and MainMenu takes up 21%.

I'm happy with this. Show these new groups by default, but only if the group has a label.

In that case, I can remove the hierarchy-visible attribute altogether and update the docs to explain that labeled groups will be shown, and can be hidden by removing their label.

This may be uncommon, but groups might be used by form designers more as a "separator" of sorts to visusally distinguish groups of questions in the XLS document while designing the form. But like above, if we only show labeled groups, this wouldn't be an issue.

I can't personally think of any other cases that would be affected.

Any final concerns before I make these updates?

Just FYI, and it doesn't apply to ODK Collect, but I happen do precisely this: separate groups of questions on the same page into a visually distinct 'section' by putting them within a group. The section may or may not have a heading (ie group label). Which is to say, there may someday be potential legitimate usecases for this (@martijnr Enketo?)...

I think we've reached consensus here. @cooperka, please make the changes and we will proceed with the PR review and testing. In the unlikely case @martijnr has concerns, we can address them before merging.

All good! Thanks for this!

1 Like