Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Radio buttons with short responses: allow two columns of responses #426

Closed
dalerhoda opened this issue Feb 19, 2017 · 6 comments
Closed
Assignees

Comments

@dalerhoda
Copy link

When radio button responses are very short (i.e., few characters per response), it would be nice to allow two columns of responses rather than make the user scroll. In our recent date date entry experiment, we made a simple radio button interface for entering dates, and the amount of scrolling would be reduced if the days could be listed in two (or even 3) columns. (With enough left-right space between that it is unlikely to hit one when aiming for the other)

e.g.:

o 1 o 16
o 2 o 17
o 3 o 18
o 4 o 19
o 5 o 20
...

@lognaturel
Copy link
Member

@MartijnR is this finally a reasonable use of appearance?! 😃 I think you have horizontal and horizontal-compact in Enketo, right? Do you have interest on adding community-standard two-column and three-column values or should we just do it for Collect and document it... somewhere?

@MartijnR
Copy link
Contributor

MartijnR commented Feb 20, 2017

@MartijnR is this finally a reasonable use of appearance?!

Yes, totally in my opinion!! Whoohoo! 🎉 🎈

I believe ODK has a compact-n appearance already (or at least a compact-2) because Enketo seems to have adopted this too (looking at the code for n=1 to 10) and it's on this table.

In Enketo appearance=horizontal is more intelligent and determines the number of neatly-lined-up columns based on the available screen width (appearance=horizontal-compact tries to squeeze all options to the minimum size without caring about lining them up in columns).

A good example of an appearance naming mess. Sorry about that. I'm open to streamlining this. E.g. we could make compact-n (with actual "n") the intelligent one and compact-2 (compact-3 etc) the specific ones. And then scrub all references to appearance=horizontal from docs and example forms. I think appearance="horizontal-compact" could be replaced by just "compact".

@lognaturel
Copy link
Member

lognaturel commented Oct 9, 2018

Closing this in favor of spec discussions going on at XLSForm/xlsform.github.io#125 and https://forum.opendatakit.org/t/spec-proposal-harmonize-compact-compact-n-horizontal-horizontal-compact-appearances/15565. Once there's agreement there we can open an issue with the specific action to take.

@dalerhoda
Copy link
Author

Thanks Hélène !

@lognaturel
Copy link
Member

Slow and steady wins the race, right?? (please say yes)

@dalerhoda
Copy link
Author

Looks like progress to me...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants