Currently, using Form builder a user cannot add a table layout. We are planning to build this feature for form builder. The details are in https://docs.google.com/document/d/1e3H3JDD20pY4c8QC6c3xTROnjvvN05pjo1gBB-CNroQ/edit# Can you please review and provide your comments. @darius @angshuonline @mksd @apaule
That looks like a great feature to me!
In our case, I see that this could be very useful to record immunizations for instance. See how it currently takes up a lot of space on the screen to only display 3 yes/no questions:
A table format with 3 columns would be of great use in those cases (though I know the MVP only includes 2 columns tables).
In the screenshot above for instance, there is concept set for PCV and members are PCV1, PCV2, PCV3. Do you think with the Table display it be possible to have the 3 members displayed in 3 separate columns but sill have them saved as an Obs group?
Something like being able to add a Table control within an Obs Group section, and add individual set members as Table cells.
I also think the approach (1) that keeps the format saved via the form builder is much better than using Concept sets (approach (2)). In general, I think concepts should not have much to do with the format you choose to display them.
1 Like
I agree with Romain that approach #1 is better.
Basically we should have support in Form Builder for “layout controls” which don’t really support any behavior, but are only containers for other controls. And they can be very flexible because the user can put whatever controls they want inside, or even nest the layout controls.
We shouldn’t be making the obs or obsgroup controls more complex just to support different layouts.
- In a table, the row element is supposed to convey the same concept.
- I think we should think deeper about the implication on the captured datastructure (and subsequent reporting) in the 2 approaches.
For example, take “WEIGHT” as example. I may have a control, to capture pre and post surgery weight.
- Would you create concepts “WEIGHT_BEFORE_SURGERY” and “WEIGHT_AFTER_SURGERY”? if the number of columns increase, would we keep creating such concepts?
- How would you put that in a dashboard - “the last captured weight”?
This can be left to the implementors because based on the approaches given in the document, we can either have same concept for WEIGHT or even have separate concepts based on the requirements.
Thank you all for your valuable inputs. Based on the inputs provided, we will be going ahead with the approach #1.