[November 2019 or later] Describe new horizontal list appearances

[lognaturel]

New spec, as agreed upon after further discussion here and on the forum:

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

This is really three base appearances with no-buttons that can combine with them (in any order) but the table above lists all 6 possibilities so that old appearances can be listed.

As of May 2019, both Collect (1.22) and Enketo (1.77.0) support all of these combinations. Documentation should be updated in November 2019 at the earliest when users will almost all have updated clients.

Various notes from the original discussion

### ODK Forum thread https://forum.opendatakit.org/t/spec-proposal-harmonize-compact-compact-n-horizontal-horizontal-compact-appearances/15565

Tentative action to take

The following changes will be made to clients, maintaining backwards compatibility:
compact-n > compact columns-n
horizontal -> columns
horizontal-compact -> columns-flex

In roughly April 2019, once users have updated their clients, change the documentation in the following way:

• compact-n, horizontal and horizontal-compact should be deprecated.
• columns, columns-n and columns-flex should be introduced.
• compact should be an optional modifier on those.

See forum.

Description

There are currently various appearances to make select options appear horizontally. Here is a test form illustrating these different appearances: https://docs.google.com/spreadsheets/d/1s79M4wsZ1QA5xwJWSEsTGoJCpjtrrdqP0NtpNeEmsPs/edit?usp=sharing

Here is how they currently behave:

appearance	Collect behavior	Enketo behavior
compact	horizontal labels without select markers, packed in to fit horizontal space with minimal padding	same as Collect
compact-n	horizontal labels without select markers arranged in n columns	same as Collect
horizontal	none	like compact-n but the number of columns is dynamically determined by the screen width and select markers are included
horizontal-compact	none	like compact but with select markers
list	label takes up half the screen, half the screen is for options, option labels are above select markers	none
label	like list but labels only	same as Collect
list-nolabel	like list but options only	same as Collect

I'm guessing these were added organically over time and it would be good to formalize them a little bit before they get broader support.

I think compact and compact-n make sense as they exist and are named appropriately.

I think list, label and list-nolabel are a bit odd but not too bad.

I'm not sure about horizontal -- @MartijnR what is its intended purpose in contrast to compact-n?

The behavior of horizontal-compact (horizontal options with minimal padding and select markers) seems useful but the naming doesn't make sense to me in the context of the other appearances. How about compact-markers or something like that?

[MartijnR]

Yes, it's good to re-think this.

I'm not sure about horizontal -- @MartijnR what is its intended purpose in contrast to compact-n?

Horizontal is more intelligent than compact, as it automatically determines the number of columns that fit on the screen (and changes when switching from portrait to landscape). It also shows radiobuttons and checkboxes.

The behavior of horizontal-compact (horizontal options with minimal padding and select markers) seems useful but the naming doesn't make sense to me in the context of the other appearances. How about compact-markers or something like that?

That's funny (or sad). I have concluded recently that horizontal-compact must have been a mistake (the ref-table now shows it as an alias for compact and Enketo validate will show a 'deprecated' warning). But now, you've discovered that compact doesn't show checkboxes, radiobuttons, so it make some sense after all! 🎉 👍 I agree the name is bad.

Too late now, but in hindsight, I think it would have made sense if we had done something like:

1. horizontal : display horizontally (not in columns, overflowing to next line)
2. columns: display in columns (determine columns intelligently)
3. columns-n: display with fixed number of columns
4. compact: do not display radiobuttons, checkboxes.

1-3 would be mutually exclusive and compact could be added to any of them.

Hmm. We should change at least horizontal-compact into something else and maybe horizontal as well (and turn those into aliases). Not sure what. It doesn't seem right to indicate that the radiobutton/checkboxes should be shown (because that's the default).

[lognaturel]

Thanks for the response, @MartijnR and I apologize for missing it! Agreed with your ideal and too bad it's too late to do. 😫

I've modified my initial table to describe horizontal as "like compact-n but the number of columns is dynamically determined by the screen width and select markers are included." Does that accurately represent it?

How about making the primary name for that appearance (currently horizontal) compact-auto-markers? The compact-auto part seems to be a nice analogy with compact-n. Now compact would just basically mean "horizontal rather than vertical" and markers would be additive. I know you said "it doesn't seem right to indicate that the radiobutton/checkboxes should be shown" and I theoretically agree but in practice I'm not coming up with a great alternative.

Then it would make sense for horizontal-compact to be compact-markers and we could introduce compact-auto to be like compact-auto-markers but without markers (useful for images).

So we'd have:

• compact: horizontal labels without select markers, packed in to fit horizontal space with minimal padding
• compact-markers: horizontal labels with select markers, packed in to fit horizontal space with minimal padding (alias horizontal-compact)
• compact-n: horizontal labels without select markers arranged in n columns
• compact-auto: horizontal labels without select markers arranged in a number of columns determined based on the device width
• compact-auto-markers: horizontal labels with select markers arranged in a number of columns determined based on the device width (alias horizontal)

Naturally, we could also add compact-n-markers to make this "complete".

It would be better to have several appearances that combine but I don't think this is terrible. At least it has some logic to it!

[MartijnR]

Welcome back @lognaturel!

I think this is good pragmatic solution, and I think we need others' input too (@tinok, you were looking at the current mess the other day).

2 things I'm not sure about:

• the word "marker"
• whether "marker" (or its replacement word) should be concatenated or be its own appearance

[tinok]

@MartijnR @lognaturel this is great. My ideal would be:

• Don't use 'marker'--never seen this to mean either 'checkbox' or 'radio button'. My suggestions would be no-button, nobutton, clickable
• Make this appearance as standalone so it can be used in combination with all other appearances (including without another appearance)

This would mean for select or select1 questions have have
compact
compact-n
compact-auto

as well as
no-button (or similar)

(and any combination of these appearances)

Thoughts?

[lognaturel]

Glad to see this moving!

While I agree that introducing an appearance to suppress select markers would be great if we were starting over, we can't change the meaning of compact or compact-n because they've existed for a long time and are all over documentation as being primarily for use with images. In that context, a select marker is definitely undesirable.

That means we need to introduce something that adds the markers to those existing appearances. We could certainly do it as an additive appearance rather than introducing new appearances with suffixes. It feels backwards but perhaps it's still better than the concatenation. Certainly it makes the implementation cleaner.

Agreed that my attempt to be precise with "select markers" is not common. I don't think of those markers as buttons but I could live with buttons or show-buttons if that seems clearer to both of you.

[MartijnR]

Thanks @tinok, @lognaturel.

I was about to say okay to show-buttons as a best-we-can-do compromise, but decided I want to make an attempt to help us figure out if we can do it right, in such a way that we don’t change the meaning of already-used appearances that remain valid but may have to translate old-style (which no longer exists) to a new style. This would actually be very easy to do implementation-wise.

appearance	description
compact	do everything to make things compact; no buttons, small margins, horizontal
grid	show options in a grid where the number of columns is determined based upon space available
grid-n	same but with fixed number of columns

So grid does not hide the radiobuttons/checkboxes but compact does. We miss out on a disorganized "compact" way of showing radiobuttons/checkboxes horizontally, but I doubt users will miss that.

These appearance combinations remain unchanged:

• compact

We'd have to translate these for backwards-compatibility of old forms in new clients:

• compact-n-> compact grid-n
• horizontal -> grid
• horizontal-compact -> compact grid (slightly different but okay)

[lognaturel]

That seems fine to me! Collect has never had horizontal and horizontal-compact so as long as that change in meaning is ok with you @MartijnR, I don't see a problem with it.

[MartijnR]

Great! Is grid the best to use, or should we use columns or something else? I'm just wondering if grid could cause confusion with the Gorgeous Grid Theme.

[lognaturel]

Hmm. Yes, columns does seem better since it's only configurable in the horizontal dimension. Maybe we should all give it another think through and finalize in the next couple of days.

[lognaturel]

Ok, have spent some more time meditating on this and am not coming up with anything I like more than columns.

[MartijnR]

Me too, and reached the same conclusion.

Any body else any opinion on these select & select_one appearance changes? @tinok, @faith-mutua, others?