That's a nice twist. I'm in favor of this proposal.
I realize some people are going to miss compact (though it's not actually going away - just in the documentation in 6 months or so) but I think this is well-designed and something we can defend.
Just to be clear, compact isnt really a 'modifier' to another appearance setting - rather its one of the fundamental appearance types in XForms spec. [so for backwards compatibility we probably shouldn't be mucking about with it...]
Typically, a style sheet would be used to determine the exact appearance of form controls, though a means is provided to suggest an appearance through attribute appearance. The value of the attribute consists of one of the following values:
"full": all choices should be rendered at all times. "compact": a fixed number of choices should be rendered, with scrolling facilities as needed
"minimal": a minimum number of choices should be rendered, with a facility to temporarily render additional choices
My (rough) interpretation is that "full" is all the bells and whistles, all the time. "compact" is a fixed visible # but scrolling set of some (or all) the bells and whistles. And "minimal" is a fixed # non-scrolling set of some (or all) the bells and whistles. Interestingly, the spec example shown omits the checkboxes for 'compact' and only shows the item labels, but does show the checkmarks for "minimal", suggesting the implied 'dimension' they span doesn't necessarily dictate which actual bell's and whistles to show, but rather whether seeing the full list involves scrolling vs a more explicit user action, eg hitting a "More..." button [hence "...with a facility to temporarily render additional choices"]
While there's certainly wiggle room on how to interpret "compact", I really dont think we should consider defining "compact" as being a modifier on some other (custom) appearance value. That strikes me as a clear violation of the intention in the original spec.
Which is to say, "compact" implies scrolling, so some other modifier to it would optionally specify which suite of eye candy to display for each item.
The compact of the ODK world has never had anything to do with the compact from the W3C spec (and it is implemented consistently across ODK ecosystem clients). So if anything, I think that's an additional reason to deprecate the ODK-custom-compact and make clear that ODK XForms appearances are not related to W3C XForms appearances.
It works for text-only choices as well but in practice is most useful with images. That's where the desire to add something that works exactly like the current compact but does retain radio buttons/checkboxes comes in. That would be what the latest proposal would call columns-flex.
Are we ready to say that the latest take has stood the test of time? I continue to feel ok about it.
@Grzesiek2010, since you're likely to take on the implementation change on the Collect side and were looking at this recently, it would be great for you to look over this thread and share what you think.
We're finally about to finalize the implementation of the new appearances in Collect and I'm noticing that I flipped columns and columns-flex between the first post in this thread and the one we ultimately agreed on. Now I'm no longer sure which should be which.
@martijnr, have you made the switch in Enketo? If so, which did you go with? If not, what makes more sense:
columns is the one that works on a grid determined by screen size and columns-flex is the one with choices packed in with minimal padding
columns-flex is the one that works on a grid determined by screen size and columns is the one with choices packed in with minimal padding
Let's not beat this poor dead horse any more. I searched for columns-flex in https://github.com/enketo/enketo-core where I'm pretty sure it would be defined and it's not there which suggests Enketo has not gotten this change yet.
@martijnr is the one who suggested columns and columns-flexhere so let's go with how he described them there which is option 1 above. I have edited my post here to try to minimize confusion (hah).
I find it hard to grok what columns-flex means from the name. The description of the behavior makes me think that columns-pack or columns-compact might be clearer.
Sigh. Given that I got confused, I certainly can't argue that columns-flex is the most intuitive name. I think we should avoid compact as we've discussed previously.
columns-pack would make sense. How do we finalize this decision and when do we decide to call it done, @yanokwa?
I cant remember (I recall I might have asked this WAAAAY back?) but was it ever determined whether you could have multiple appearances? Seems like we want two, or three (vs 4+): one to enable columns, another to define spacing, another for buttons or not?
We could separate out a modifier for the minimal padding variant (flex or pack or ???) but it would only combine with columns. I don't see a good way of separating columns-n in the way that you describe. columns-n is "parameterized" -- it's actually columns-1, columns-23, etc. Having three bases with one modifier seems clearer to me.
To keep things in one place, @Xiphware wrote on the XLSForm issue:
Have to say, compact-n - that is 'parameterized' appearances - dont really right to me... It seems like the number of options should determine the (preferred) number of columns [and isnt this going to pretty much always be the case in practice?]. Otherwise, specifying column-n where n>#options is redundant.
And if n<#options the form writer is basically try to 'fit' a maximum number of columns to a screen size - which they dont know the actual width of - so than any extra arbitrarily wrap. So I therefore dont necessarily see the (minor?) benefit of being able to specify n - instead of simply using the number of options - is worth introducing something dubious like parameterized appearances [do we allow them anywhere else?].
So I'm still more inclined to have separate appearances for column (vs list), button (vs no button), label (vs no label), and maybe flex vs something (which is only meaningful when associated with column) to indicate the horizontal packing of columns. [eg flex = size each column width to fit, max = columns equal to total width, ...]
Wrapping options - which would be default behavior if only columns is specified (where each column is sized to fit) - would handled both a fixed number of options, or variable number if coming from an external choice-list. In both cases, I dont quite see the benefit of statically specifying a fixed number of columns in the form definition when the form writer has no way of knowing the screen width its actually going to be displayed on (yet alone landscape vs portrait)
Anyway, just my $0.02 before we go down the path of further setting-in-stone something a dubious (IMO) as paramterized appearances...
Specifying the number of columns comes from a real user requirement and is in use today so removing the functionality is not an option. It's an appearance that's generally used with media choices to define a grid of visual choices (hence the original compact-n which does not display buttons). Many deployments use exactly one kind of device so form designers can in fact anticipate what data collectors will see.
The original intent of this appearance name review was to make sure there was a clear definition for each appearance in use today, a path to explain the set of horizontal appearances coherently and consistent support across clients. Specifically, it's tough for users of both Collect and Enketo to have a different set of supported appearances that do not quite the same thing. I want to make sure we keep sight of these goals. I think the columns-flex -> columns-pack does help with clarity but I'm not sure that it's worth revisiting the whole scheme again, though.
columns-pack instead of columns-flex seems better to me.
Wrt to columns-n, I think we could specify a maximum. I propose 10 (and that's how the old compact-n was implemented in Enketo - never had a request for more). So in that case we essentially would support the fixed/non-parameterized columns-1,... columns-10. Any larger maximum would be fine with me too.