Boxes for select_multiple in Android 5

dmenne · September 1, 2020, 2:06pm

ODK Collect 1.28.2 beta

Under Android 5, none of the boxes for multiple select show up, and without boxes a selection is not possible. This worked in 1.27.

I tested

columns-1 No boxes, no selection possible
horizontal No boxes, no selection possible
compact-1 No boxes by design, selection possible using frame
label No boxes, no selection possible.

So only compact-1 and other compact-n is usable under Android 5.

@lognaturel

github.com/XLSForm/xlsform.github.io

[November 2019 or later] Describe new horizontal list appearances

opened 07:03PM - 15 Jun 18 UTC

lognaturel

help wanted

New spec, as agreed upon after further discussion here and [on the forum](https:…//forum.opendatakit.org/t/spec-proposal-harmonize-compact-compact-n-horizontal-horizontal-compact-appearances/15565/): | 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. <details> <summary>Various notes from the original discussion</summary> ### ODK Forum thread https://forum.opendatakit.org/t/spec-proposal-harmonize-compact-compact-n-horizontal-horizontal-compact-appearances/15565 ### Tentative action to take <strike>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.</strike> 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? </details>

This page is very old, and there is a length discussion without final result. Would it be possible summarized what the current state is?

Grzesiek2010 · September 1, 2020, 3:09pm

Hi @dmenne
please attach your form.

dmenne · September 1, 2020, 6:10pm

Selection is only possible for the images where a selection is shown. Others do not respond to touch.
Android 5.0 Tablet. Looks ok on Android 8.x. I know that some (e.g. label) do not have boxes per se, but selection should be possible.

select_example.xlsx (14.6 KB)

Grzesiek2010 · September 2, 2020, 10:02am

Ok I see you can select those options but radio buttons/checkboxes are not visible so you can't see it that's something we need to fix. Thanks for reporting.

BTW looking at your form I noticed you use appearances that don't exists like grid-2 or are deprecated like compact. We have been working on improvements in selects and we don't have well documented appearances yet but you can find a helpful table here:

dmenne · September 2, 2020, 3:35pm

Thanks for pointing me to the final spec - I always referred to these and https://github.com/XLSForm/xlsform.github.io/issues/125, but since there was a lengthy discussion including grid and similar, I never was sure what the final solution was. I am aware that the title was changed "[November 2019 or later] ", but the message itself is dated 2018, so my confusion was complete.

Please, update it as some location that is well visible.

LN · September 11, 2020, 4:21am

Thanks for the report -- beta 3 is now out and should fix this issue.

Is it possible for your devices to upgrade to Android 5.1? Android 5.0 has a lot of very particular bugs and is not in broad circulation. We verify changes across a range of Android versions but not on 5.0 because it represents a tiny fraction of the user base. It's great to catch these kinds of issues and fix them but if you have a chance to get off 5.0, I would strongly recommend it.

I don't typically jump on documentation issues because they can be approachable for others. In the XLSForm/pyxform case especially, I always hope someone else will pick issues up because the core ODK team is not its official steward! That said, I agree the update is long overdue and will try to get to it soon.

dmenne · September 11, 2020, 6:32am

I tested it, and it looks fine. Thanks for fixing!

Thanks for pointing me and others to Android 5.1. Too bad I cannot upgrade the tablet we have to test legacy software.

Anyway, it was a minor point for me, but it could be relevant for some of the devices in remote areas.

Grzesiek2010 · September 11, 2020, 10:31am

Of course that was a great finding. Thanks again!

LN · September 11, 2020, 4:33pm

I figured that might be the case, too bad! We've been updating to using more modern Android libraries for the user interface over time and still have a few areas of the app where we have to make changes. Those would be at risk of similar issues. We'll be sure to point these out in betas and to be explicit about which Android versions we have done quality assurance on.