@martijnr Of course, as I try to write this out I come up with more questions. I believe this change should also mean that compact becomes compact columns-flex, right?
So we'd end up with:
columns-n: horizontal list organized in n columns
columns-flex: horizontal list organized in a number of columns that is dynamically determined by screen width
columns: horizontal list that packs in choices to fit with minimal, fixed padding
All of these wrap to other rows as needed. The difference between columns and columns-flex is pretty subtle. @martijnrcolumns-flex (currently horizontal-compact) is one that only Enketo has so it would be good to get a more precise description.
And the modifier:
compact: don't include radio buttons or checkboxes
In the new world, does compact also modify a vertical list? We don't have that option currently I don't think.
No, it would stay compact. The columns-flex addition would not do anything when combined with compact. This is the weakness in the proposal, but at least it is foolproof. There is no mutual exclusivity between them.
The columns-flex appearance is essentially a less compact version of compact as it doesn't remove radiobuttons and checkboxes. It allows you to create this (particularly useful if there is a mix of long and short labels):
The columns-flex appearance is essentially a less compact version of compact as it doesn't remove radiobuttons and checkboxes.
Ok, I was getting horizontal and horizontal-compact confused, I think. So in the new world, columns-flex is identical to compact except that it includes radio buttons and checkboxes?
And compact is a modifier but it only can modify columns-n? This I'm not feeling very good about.
How does horizontal/columns behave (it only exists in Enketo)? I'm guessing it associates a particular column count with a screen width range. Does it take the element width into account? That is, if I have screen width X, do I always get Y columns even if the width of the image or label would make them overlap? In the case of labels, does it wrap them if they don't fit?
So in the new world, columns-flex is identical to compact except that it includes radio buttons and checkboxes?
Yes. The word is not ideal. I think the ideal would be to call this horizontal, but unfortunately that would be a breaking change for existing forms (due my bad choice in the past).
And compact is a modifier but it only can modify columns-n?
Compact works by itself, by making everything as compact as possible (margins, hiding radiobuttons/checkboxes, displaying horizontally). So it is independent from columns. Only columns-flex has an overlap with compact unfortunately.
How does horizontal/columns behave (it only exists in Enketo)? I'm guessing it associates a particular column count with a screen width range. Does it take the element width into account? That is, if I have screen width X, do I always get Y columns even if the width of the image or label would make them overlap? In the case of labels, does it wrap them if they don't fit?
It does wrap labels, and it has some fixed margins. It will make all columns the same width and the number of columns will be adjusted based on the space available (in real-time, also when switching between portrait and landscape on a phone). I believe the maximum is 3 columns and then it adjusts to 2 and 1 when necessary. A demo can be seen at https://enke.to/::widgets by changing the width of the browser screen to see how it switches between 2 and 3 columns based on available width. I think it can be thrown off by very long label words (so that's a bug).
Taking a step back, the problems I have with the existing appearances (compact, compact-n, horizontal and horizontal-compact) are:
we're missing a way to represent n columns WITH radio buttons/checkboxes
it's not clear what the relationship between compact and horizontal-compact is. One doesn't have radio buttons/checkboxes and the other does. That should be clear from the naming
it's unclear what horizontal does and what its relationship to the others is.
Given how confused I am trying to explain the suggestion and how the proposed appearances do and don't combine, I don't think we've addressed the second two points.
I have a strong preference to only introduce a modifier if it is used consistently. That is, in the proposal above, compact is a modifier but only in one case AND it can also act alone.
The proposal I've seen so far that most meets my criteria is as described here by @Tino_Kreutzer : compact compact-n compact-auto
with modifier show-buttons or markers that can apply to any of them.
It's really easy to understand, there are no compatibility issues and it adds the missing combination.
with modifier show-buttons or markers that can apply to any of them.
And just to add my problem with this proposal is that compact actively hides radiobuttons and checkboxes, and then we have to undo that with show-buttons. So for same question were undoing part of an appearance that we just added.
Ideally compact would not hide radiobuttons and checkboxes at all, and a modifier hide-buttons could hide them when desired, but that would break backwards-compatibility of old forms. Hence we've been struggling with redesigning a more logical appearance design for select questions that doesn't break anything. If we could come up with a synonym for compact that would allow us to do that.
While I agree it doesn't feel very clean/pure when you state it that way, I don't think that has user impact. In other words, I think someone really has to sit down and think about the appearance names to start feeling uneasy. It's really easy to describe why the modifier goes in that direction with something like "the compact-* appearances are particularly useful for images. Arranging text choices horizontally is also useful and can be achieved by adding show-buttons". As an added bonus, show-buttons can be added to vertical lists (or any other type) and the fact that it has no impact makes perfect sense. If we had a modifier to remove buttons, we'd have to either support it for vertical lists (doesn't seem very useful) or feel uneasy about why we don't.
As an added bonus, there are no compatibility issues and so no user surprises. Given the number of forks and otherwise out of date clients floating around, I think that is worth giving some weight to for a relatively minor adjustment like this.
compact and compact-n would continue having the same meaning
horizontal would become compact-auto show-buttons
horizontal-compact would become compact show-buttons
Because there's no overlap between new appearance combinations and the ones that would remain for backwards-compatibility, I think the implementation is straightforward. Old forms would always work with new clients. New forms that use compact-auto show-buttons and compact show-buttons would likely interpret that as compact which is not exactly what is desired but really not bad.
I think it's really about convincing @martijnr that the approach is not terrible! To be clear, I completely agree that if we were starting over we would hopefully do this differently.
she requires a double appearance value of "compact-auto show-buttons" instead of just "columns" or something. To me this seems the most common use case, judging from the (small subset of all) the Enketo forms I get to see. I understand Collect doesn't have this feature yet, but we may see the same with Collect users when it does.
To me it seems that users are more likely to want to keep the radio-buttons and checkboxes. So having to remove them in order to show columns and then bring them back with another appearance, just doesn't seem like a great re-design (I'm diplomatic here!). I cannot escape the feeling that we can do better than that (without breaking backwards-compatibility of course).
I'd find using a double appearance to a) show columns and to b) remove checkboxes/radio-buttons more logical.
I certainly do agree with that. But so far the tradeoffs for what we've explored haven't seemed worth it.
Maybe the proposal we started this thread with can be salvaged by not reusing compact. That is, something like introducing
columns (currently horizontal),
columns-n (like current compact-n but with radio buttons/checkboxes) and
columns-flex (currently horizontal-compact)
no-buttons as a modifier that applies to all (and perhaps vertical lists?)
The "new form on old client" case is not as nice as what we discussed here because those would be shown vertically. But we can mitigate that by waiting to publish user-facing documentation until after upgraded clients have been out in nature for a while, as @martijnr suggested.
I guess that @martijnr you were suggesting to keep using compact to address that somewhat but I think it is much harder to explain and keep straight than three base behaviors with a consistent modifier.
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.
Fuuuuun!
