Is it possible to create collapsible form sections in xslx forms?
Hi @robinmurphy,
Could you please elaborate more about the use case or scenario? I am not sure if XLSForm has collapsible function but wondering if skipping would help?
Thank you for taking the time to get back to us.
Our current use case is to supply a expandable/collapsible sort of ‘cheat sheet’ at the start of an app form whereby the CHW can quickly refer to a section containing a curated list of values, possibly from multiple sources, which could assist in completing appropriate follow up questions.
Does a pre-existing component exist to satisfy this need?
Do we need to create a custom component, and if so, how would we go about doing so?
1 Like
For your “cheat sheet”, would that contain just informational note fields or would there also be questions (with values you want to record)? If it is only notes, then it should be pretty feasible to just use relevant logic and select_one show/hide buttons to create something functional.
Things get more tricky, though, if you have questions you want to show/hide (and you want to record the answer’s to those questions at the end of the form). In this case, the relevant expressions will not work since answers are not recorded at the end of the form for questions that are non-relevant. Our of curiosity, how close is the toggle-able group functionality in this demo Enketo form to what you are looking for? (Groups displayed within a page can be shown/hidden by clicking the triangle next to the group name.) This functionality is not currently supported in the CHT, but we could log it as a feature request…
2 Likes
I think in the “cheat sheet” section of the form will contain informational note fields exclusively.
Then in other sections of the form those values may be used for some relevant and calculation purposes.
That’s a fair point, and we can definitely use that workaround for now.
I was hoping to avoid using a “question” in order to hide the “cheat sheet” block of fields, and have a purpose built component take care of that responsibility.
The link to that toggle-able group component example is exactly what we were looking for!
Please do log that as a feature request.
What would the turnaround time for such a feature be?
I have logged Support collapsible form groups · Issue #8218 · medic/cht-core · GitHub
Turnaround time on something like this usually depends on several factors. If the feature is acceptable to the CHT maintainers (weighing the usefulness with the cost of implementation/maintenance) then the most important other questions for getting it done are:
- Is there a community member willing to upgrade to a new version of the CHT and use this feature?
- Is the code change being made by an external contributor?
- When is there room on the Medic development roadmap to do the work? (involves weighing the priority of the new project against existing planned work)
More details are in the docs.
When we have a partner interested in using a new feature and they are willing to work with us to validate the functionality, we can get them a feature release with the new functionality in a relatively short amount of time. Please feel free to reach out if something like this sounds feasible (for this or any future features).
On a related note, while doing some investigation around this, I did learn about Guidance hints in ODK forms.
These are not currently supported in the CHT, but I have logged Support ODK guidance_hints in forms · Issue #8217 · medic/cht-core · GitHub to add support in the future.
Also, if you go to implement the relevant workaround, one thing to consider is using a no-buttons columns-1 appearance with a select_one question to handle toggling the section display./
That gives you a nice toggle button. (Can even use an image for the button instead of text if you want!)
Thank you for opening both of these feature request, and explaining the intricacies/hurdles of including them in main.
I’ve confirmed with our senior, and we would be willing to work with the CHT team in order to validate functionality.
Would these feature releases also be accompanied by release docs?
I’ve tried implementing a custom collapsible widget like discussed, however I’ve been unable to get it working.
Would you perhaps be able to point out where/how the below fails to deliver the expected result:
| type | name | label::en | relevant | appearance | calculation | default | trigger |
|---|---|---|---|---|---|---|---|
| begin group | collapsible | Reference section | field-list | ||||
| integer | state | NO_LABEL | hidden | if(.=1,0,1) | 0 | ${toggle} | |
| select_one toggle | toggle | no-buttons columns-1 | toggle | ||||
| begin group | content | ${state}=1 | |||||
| note | test | The content should be here | |||||
| end group | content | ||||||
| end group | collapsible |
Unfortunately, the CHT does not currently support the trigger column in xlsxforms. I have logged an issue to track this: Support `trigger` column in Forms · Issue #8336 · medic/cht-core · GitHub
The TLDR is that I believe our version of pyxform needs uplifted.
For your case here, though, I do not think the trigger is required. One option would be to just depend directly on the toggle without needing state:
| type | name | label::en | relevant | appearance | default |
|---|---|---|---|---|---|
| begin group | collapsible | Reference section | field-list | ||
| select_one toggle | toggle | no-buttons columns-1 | toggle | ||
| begin group | content | ${toggle} = ‘toggle’ | |||
| note | test | The content should be here | |||
| end group | content | ||||
| end group | collapsible |
(For this case, on my choices sheet I only have one entry for the toggle list and it is also named toggle)
If you really need the state field for some reason, one workaround (aka hack) would be to update the calculation to be coalesce(if(.=1,0,1), ${toggle}). This should cause state to be re-calculated every time toggle changes (and the value for state will still always remain 0 or 1).
1 Like
Awesome! @michael can maybe help us out with next steps here!
Would these feature releases also be accompanied by release docs?
For a feature release, we will definitely provide whatever documentation/support is needed for deploying and evaluating the new feature!
1 Like
@robinmurphy would you mind sharing some more/concrete details on this? Do you have some example text, content, designs, or mockups? You mentioned showing this at the start of an app form, but then also being able to “quickly refer” to it… will the forms have multiple pages? Would they need to go back to the cheat sheet while they are on page 5 (for example) of the form?
That is quite unfortunate, thank you for opening the issue!
We’ve run into something similar when we tried to ‘warm up’ the geo-location services by using the “background location question” start-geopoint as mentioned here.
Any idea when the pyxform might be uplifted?
As per usual, you’re an absolute boss at these things! Thank you so much for the solution, it works like a charm. Omitting the default ‘toggle’ value leaves the group collapsed on startup 
.
That’s very smart, I’ve included the “hack” in our internal action form template for completeness.
Speaking of the action template, I’ve discussed this with my senior, and we were wondering if CHT would be interested in having such a file that is easily accessible to new adopters.
The plan is to contain most question types and a few of it’s permutations, a common summary screen layout, as well as some niche things like using icons from font-awesome and custom styling.
Internally we also plan on using it to showcase the usage of our extension-libs.
1 Like
Any idea when the pyxform might be uplifted?
No solid dates, but I am really pushing for it to be done in Q3 (of this year) as a part of this initiative!
we were wondering if CHT would be interested in having such a file that is easily accessible to new adopters
Absolutely! The more I learn about these form config, the more I feel that we need a dedicated place to capture this information so it is easier to learn from. I have started a new thread to continue the conversation: CHT Sample Form Library. (Ultimately, though, I think we could start with something simple like a public repo where the community can contribute to one or more sample form configs…)
1 Like
Unfortunately I do not have either of those at the moment, but it is something I hope to get some clarity on with our BA soon - will relay that info asap.
The idea originally comes from a doctor who wanted to ensure he kept a “personal relationship” of sorts with his patients, rather than making them feel like just another number or case.
While CHWs often have relatively close relationships with those they interact with, as in our case, they also do see quite a few people. It would be advantageous to have an area where they can quickly reference some info regarding not only the health status of the patient but also some other details.
A section such as this could also be advantageous for:
- Quick guides on some required procedures to follow or ways of working.
- Getting new CHWs up to speed.
- Temporarily stand in for a colleague.
Most of our app forms will have multiple pages.
It would thus be really useful to denote a group as a ‘sticky’, which makes the ‘cheat sheet’ inside that group available on every page.
Thinking of it now, that might be a useful feature outside of the ‘cheat sheet’ itself.
Gotcha. This will be really helpful to understand what will work best.
While they tend to be used for more generic content, it’s worth considering use cases where the in-app CHT Training Cards might be useful, particularly around your point #2 (getting new CHWs up to speed).