Spec proposal: harmonize compact, compact-n, horizontal, horizontal-compact appearances

Thanks @LN!

That's a nice twist. I'm in favor of this proposal. :+1:

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.

1 Like

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.

1 Like

So is "compact" in ODK ecosystem only used for images?

Agreed. Anything that reduces ODK's naughtiness is a 'Good Thing'... :slight_smile:

1 Like

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.

1 Like

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.

@LN your approach seems fine to me. I can start looking into the code if you want.

1 Like

Sounds great, @Grzesiek2010.

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:

  1. 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
  2. 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

I'm really sorry about this confusion.

1 Like

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-flex here 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).

< snip obsolete grid >

2 Likes

Yes, this looks good to me, and indeed Enketo has not implemented this yet. Will try to get a wiggle on now that this is forthcoming in Collect.

Thanks!

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?

no-buttons does combine in the way you describe.

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.

1 Like

I'm OK with columns-pack! @martijnr?

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... :frowning: 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... :slight_smile:

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. :+1:

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.

2 Likes

Here is the final spec:

new appearance behavior old appearance
columns horizontal labels with buttons arranged in a number of columns determined by the screen width horizontal
columns no-buttons horizontal labels without buttons arranged in a number of columns determined by the screen width
columns-pack horizontal labels with buttons, packed in to fit horizontal space with minimal padding horizontal-compact
columns-pack no-buttons horizontal labels without buttons, packed in to fit horizontal space with minimal padding compact
columns-n horizontal labels with buttons arranged in n columns where n is an integer between 1 and 10 inclusive
columns-n no-buttons horizontal labels without buttons arranged in n columns where n is an integer between 1 and 10 inclusive compact-n
3 Likes

I've modified the original XLSForm documentation issue to note we want to make the documentation change in ~Nov 2019: https://github.com/XLSForm/xlsform.github.io/issues/125