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

Development
21

Sounds great, @Grzesiek2010.

22

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
23

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
24

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!

25

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.

26

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?

27

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?

28

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
29

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

30

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.

31

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
32

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
33

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