Stream: questionnaire
Topic: Paging behavior
Jing Tang (Dec 16 2020 at 19:36):
Is there any support in the IG for paging behavior of questionnaires? This is particularly useful when questionnaires are rendered on small devices. I know we have group and there's also the collapsible extension but couldn't find anything more explicit in the IG. Thanks!
Lloyd McKenzie (Dec 16 2020 at 19:49):
There's now a control type for groups called 'page'.
Jing Tang (Dec 16 2020 at 20:28):
Oh great! Thanks Lloyd. Can you share a link?
Lloyd McKenzie (Dec 16 2020 at 21:03):
http://build.fhir.org/codesystem-questionnaire-item-control.html#questionnaire-item-control-page
Jing Tang (Dec 17 2020 at 23:49):
Thanks Lloyd -- :face_palm: no idea how I missed it... I've opened that page so many times...
RP (Dec 23 2020 at 22:23):
but items in subsequent groups are not displayed until the user indicates a desire to move to the 'next' group
I had a question related to this so my understanding then is that once one group is marked as page all of it's siblings are to be treated as pages regardless of being marked as page items?
Or do we expect groups non-marked as paged to be basically pinned content and the behavior of moving to next group should only be for the next item marked as page?
Lloyd McKenzie (Dec 23 2020 at 23:01):
You could have some groups marked as header or footer. Otherwise, I'd expect them to all be pages. What happens otherwise is undefined.
Jose Costa Teixeira (Feb 10 2021 at 08:21):
I don't get it. My first understanding is that when a group is marked as a "page", it is similar to adding a "page break" before and after that group.
Jose Costa Teixeira (Feb 10 2021 at 08:23):
so not all the siblings are marked as pages.
Paul Lynch (Feb 10 2021 at 13:30):
Jing Tang said:
Thanks Lloyd -- :face_palm: no idea how I missed it... I've opened that page so many times...
I think the reason for missing it might be that http://build.fhir.org/ig/HL7/sdc/rendering.html links to http://hl7.org/fhir/R4/valueset-questionnaire-item-control.html (which does not have "page") and not http://build.fhir.org/valueset-questionnaire-item-control.html (which does). @Lloyd McKenzie should that be fixed?
Paul Lynch (Feb 10 2021 at 13:35):
Jose Costa Teixeira said:
I don't get it. My first understanding is that when a group is marked as a "page", it is similar to adding a "page break" before and after that group.
I agree. The current wording ("If there are items at the same level as a 'page' group that are listed before the 'page' group, they will be treated as a separate page. ") implies that (unmarked) siblings before the group marked "page" would be put together on a single page, not that each sibling would have its own separate page.
Jing Tang (Feb 10 2021 at 14:47):
My 2c:
As an implementer, I would be more comfortable if I know that 1) only top level groups can be pages, and 2) if one top level group is a page, all top level groups must be pages (or as lloyd pointed out, except for headers+footers) and everything must be in a group.
I think the thing here is that, you can't make one group a page without making the rest of the questionnaire also pages (whatever's before and after that page obviously become the page before and the page after the page group) so it's a bit odd to me to specify only one page. Again I'd much prefer if the IG publisher (or the standard itself) is strict about it (makes my logic to separate items to pages slightly easier) but it's not the end of the world if not.
Lloyd McKenzie (Feb 10 2021 at 15:06):
I think that's a reasonble constraint to have. We could have two constraints. One that says that child items cannot have a control type of "page" and a second that says that if a questionnaire has any root elements that are pages, all items must be pages, headers or footers. Only challenge with the last one is if we introduce additional control types that would also make sense in that mix, however adding them to the constraint wouldn't be considered a breaking change.
Elliot Silver (Feb 10 2021 at 16:31):
I wonder if child pages make sense? This might allow a tabbed-subpage behavior within a page.
Brian Postlethwaite (Apr 06 2021 at 22:43):
I'll have to go re - read this.
My renderer has a custom extension for this tab style pages that just marks a group as the tab control, and all children are groups for each page (which aren't marked) and it only works at the top level. We did that back in DSTU2 when there was that one top level group item.
Lloyd McKenzie (Apr 07 2021 at 01:02):
My leaning is that if we wanted tabs, we should define that as a distinct code rather than overloading pages? In any event, someone should submit a change request :)
Last updated: Apr 12 2022 at 19:14 UTC
