1. What is the general goal of the feature?
Currently, XLSForm supports
or_other added after a select type. This adds an "other" option to the select list with label "Other" and also adds a text field with prompt text "Specify other." In Collect, this looks like:
Problems with this:
- The "Other" and "Specify other" labels can't be translated or personalized (Translation for [or_other])
- The "Other" text field is presented on a separate screen by clients like Collect that show one question per screen
- The user-specified answer is stored in a separate field from values selected from the list which can complicate analysis
2. What are some example use cases for this feature?
Sometimes not all choice values are known ahead of time.
3. What can you contribute to making this feature a reality?
Specification and implementation.
From an ODK XForms specification perspective, I think this is best supported by supporting the
"open" value for the
selection attribute on selects, as described in the W3C XForms spec. That way clients will be responsible for how they want to display the question type and for managing translations.
For XLSForm (what users will care about), I have so far thought of two specification options and would like feedback on which is preferred (or other ideas):
- Similar to existing
openoption added after the list name
|select_multiple mylist open||my_choice|
- Adding a selection option to the