Thanks for the reply. It seems we are understanding each other now! I appreciate you refining my post - looking back now it does seem poorly written. I see your concern with processing the resulting dataset. For my own purposes, displaying the grid is enough for now, and the "awkward" indexing you described would be sufficient (though I agree, awkward). @Shilan_Amin, @Bramleyl, what are your thoughts?
In my biased opinion (my group wants this ASAP), the perfect is the enemy of the good. What are your thoughts on the time difference for "group appearances" vs "new datatype"?
Hi @Xiphware and @David_Kaftan, thanks for keeping this discussion going! I'd certainly agree about the perfect being the enemy of the good - we'd also like this ASAP, and in fact we're already using a set of repeats for the underlying functionality we want, we'd just like to be able to display the questions in grid format.
Apologies if this is a silly question, but regarding the "awkward" indexing, wouldn't it be possible to reference individual inputs with an indexed-repeat() using position(..) and the name of the column required? That's what we're currently doing in our form, so if the plan is to use repeats and just allow a new display format, it should in theory work the same way? If that will still work, it'd be enough for us...I'm curious about how simpler indexing would actually look - but maybe that's getting ahead of ourselves.
How would adding additional repeat instances (in this case, rows) work - would that be possible to do dynamically with a new row getting added to the display?
Yup, that's exactly how you'd have to do it. You can index specific rows via their numeric position(..), which is all fine; the 'awkwardness' comes from having to reference columns by their arbitrary name/question id.
If the columns of the table are distinct and ostensibly unrelated to each other - for example, name, phone number, address, .. - then there's no issue because you are probably only ever going to reference the columns directly by name in any case.
But what if the columns are inter-related, or in a specific partial order. For example, if the data columns are "Age 0-10", "Age 11-20", "Age 21-30", etc, and say you want to count the number of people under 50. Or your columns are for numeric data entry and you want to find the maximum median value for each row. These problems are easily solved if your dataset is stored in an actual array which you can enumerate via a numeric index, but can be quite awkward, and tedious, to solve if each datum is stored individually in arbitrarily named variables.
Again, I think for the purpose of showing a repeated list of (distinct) questions in a table, that a group/repeat group with a new custom appearance to display the group's question horizontally (without label) is a good workaround (in lieu of perhaps a more general-purpose grid, based on an underlying 1D/2D array datatype). And in line with what folks are already familiar with for a table of selects.
I dont see why this would be any different than what we do today for a regular repeat group. The only twist is how to present the top row, containing the group's question labels (but which is otherwise non-editable). But maybe we can somehow mimic how this is accomplished with select tables today?
If I understand correctly, the proposal is to add a "table" appearance to a repeat (or a repeat <group> parent as I believe that's where pyxform would put it currently).
This would (1) display the questions inside this repeat as a table-row with the labels of the questions as table-column headings and (2) display the optional repeat label as the row label.
It feels quite hacky to have the first repeat refer to vegetables, and the second repeat refer to grains and the third repeat to proteins. The XML submission won't provide any clue as to what each repeat instance represents. Any thoughts on how we could improve this? One idea is to populate an attribute on the repeat instance with the value of the dynamically-generated label (i.e. vegetables, grains or protein), but that would be a pretty significant feature (on data-collection clients as well as data backends).
How would we deal with rows that are too wide to fit a screen (e.g. low-res mobile in portrait mode)?
Why not have it as an appearance on a group in general, regular or repeat. Which basically says, display everything in this group on one line, with the first line being all the control labels, and the second line being all the control the values/entry boxes? This could then be used for a non-repeat, single line grid.
And then handle not duplicating the labels (when it s a repeat group), much the same we done presently with select repeat groups; ie an appearance tag to say hide labels.
I like this idea, no need to constrain our grids to "repeating" questions.
And then handle not duplicating the labels (when it s a repeat group), much the same we done presently with select repeat groups; ie an appearance tag to say hide labels.
why did you cross this out? it seems like a reasonable solution.
which seems to be the prevailing workaround for constructing a select table/grid. Basically, the first 'row' is a faux select/select1 with a "label" appearance, simply in order to display show the column headings. Then you'd put all the real select questions in a repeat group, with a list-nolabel. And you then put the whole contraption in a field-list group so it all gets displayed together. Its a bit of a kludge (IMO) because you're adding an entirely redundant select control into your form simply for the purpose of displaying the column headings. But hey, it gets the job done!
However, on reflection (hence redaction) I dont believe this approach is particularly scalable nor the best approach for displaying the column headings for a generic (group-based) grid. It would basically mean duplicating the entire group and all its controls (!) once at the beginning (using "label" appearances or equivalent) for the column headings, and then again within the subsequent real repeat group (w/ "nolabel").
Since we're proposing having to introduce a new group appearance anyway (ie "table") then I think it might be preferable to simply exploit this; by definition a "table" appearance would imply "field-list" (ie the group/repeat group should be shown on the same page), and when rendering a repeat group having a "table" appearance, only show the enclosed controls' labels if position(..) index = 1. This would relieve the form writer from having to worry about how to display the column headings, which they must presently do with the select table workaround.
[aside: we might even look at whether this more general design could be used to better define a select table: ie a repeat group w/ appearance="table", containing a single select/select1 question, and similarly only display the select's option labels if position(..) index = 1?]
Is there still interest in coming up with a design for proper (ie not merely select/checkbox) matrix of questions? of mixed text and/or numeric types? with row and/or column mutual-exclusivity control? with defaults? ...
I think this would be good to do eventually. We took it off the TSC roadmap because there wasn't much interest when I first posted it. I'm currently focused on closing out things that have been on the roadmap for a while.
I think of this feature as separate from repeats and wouldn't try to build on top of them though I don't have a spec in mind yet. I think it should support mixed text and numeric types. I think it would be ok for clients to either wrap or clip in the case of long rows -- presumably this feature would be most useful for large devices.
I'm sure grid style appearance is very helpful for for enumerators to input and it happens very often with paper form. One of our worker's barrier to move to digital form is they dont feel comfortable and familiar to input data without grid style, they have to answer very similar questions.
I voted and still wait for this feature.
Text and numberic input and @David_Kaftan proposal is all my desire.
I see How do I handle the table in xlsform .The attached table and Table questionnaire (integer and text input) so I 'd like to call @Josiah76 and @Frimpongeben1 to this topic for ther interested in the feature.
Hope this come soon.
Hi, also just sharing my interest in this feature. We are shifting to data collection using ODK & monitors are not very happy about 10 questions for boys, and then the same 10 questions for girls. Having a grid for them to input numbers in a familiar table format would really help.
My ideal UX for grids are click counters of things in 2 by 2 categories.
My concrete example are turtle tracks. While I'm capturing a geotrace in the background, I walk along a beach and tap to add one count to a relevant cell. My columns are turtle species, the rows are types of tracks.
I want to use each cell as a click counter (value plus one) and also be able to correct a misplaced click (value minus one). For this, I need to see the value (an integer number), a large plus button and a smaller minus button.
