During October 2019, is it possible to use the search function (appearance) while executing a select_one_external using the KoboCollect or ODK Collect app? Please advise: yes/no : if yes, some references please. Thanks
Hi @MarkS,
Welcome tot he community! Yes, its possible to use the search function in appearance while executing a select_one_from_file question type in KoBoToolbox. However, please be informed that this only works with Enketo at the moment and not with KoBoCollect or ODK Collect.
You could do the same as shown in the image below:
In the survey tab:
In the choices tab:
In the csv file:
Reference xlsform:
select_one_from_file.xlsx (11.8 KB)
fruits.csv (522 Bytes)
For details, you could also go through the support article Select one or many from external file question type.
GOOD DAY!
1 Like
Hi @MarkS,
Kindly please be informed that you should be able to use the select_one_from_file question type on ODKCollect v1.26.2 along with Enketo.
Have a great day!
1 Like
1 Like
What is presented here is a search function proposed by KoBo but not the search() function of the XLSForm standard.
I have spent hours researching how to use external files in select fields and I find this feature rather poorly documented in the help centre. I will very soon propose improvements for this in a dedicated thread (the proposition is written yet, but not well formatted).
In particular, one of the points I will raise is that the article (https://support.kobotoolbox.org/en/articles/592373-question-options) describing the various fields of the “survey” sheet gives a pointer to further information on the “appearance” field:
https://xlsform.org/en/#appearance
But in that page, the search() option is something completely different (by the way, it would be so helpful to have it implemented, as it is utterly convenient in real life situations that are not matched by KoBo’s “fruits.csv” example).
Cheers!
Hi @freedim,
Would love to hear more on this so that we could improve our documentation. Could you kindly please outline so that we could change/add/update where needed.
Have a great day!
Hi @freedim
Thanks so much for your analysis, it is quite helpful. We appreciate your contributions as this allows us to improve our articles. On the clarifications you have indicated; those are definitely two different approaches to using search() as originally intended by XLS forms. We will however test them further and update the articles.
Stephane
Hi @stephanealoo and @Kal_Lam,
I was planning to open a new thread, but if you want it here, here is what I noticed:
- The article found at:
https://support.kobotoolbox.org/en/articles/592373-question-options
speaks about appearance field and gives a link to:
https://xlsform.org/en/#appearance
That latter link explains how to use search(), in a way that does not work in Kobo (Enketo). I have spoken with one of the main developers of Enketo, and he told me that not supporting the search() function was a deliberate choice, because the search() function is actually a wonky hack that was created to workaround some gaps in the XForm standard specifications. Alas, those gaps have not been filled yet and one might regret that Enketo does not offer ways to workaround them (for example, to feed select fields with real-life CSV files in a flexible way).
Anyway, this link should be provided with some warning that Kobo does not implement/support all of what is written there, in particular the search() function.
delivers a couple of pieces of information that do not match the actual behaviour:
-
The name of the list in sheet “choices”, column “list_name”, indeed needs to be the same than the one in the “list_name” column of the CSV file, but the corresponding field name (or “question” name, or “variable”) and file name can be different (which makes sense if we consider that several fields might use the same list of choices); so in the phrase of “Step 2” that reads “In the choices sheet of the XLSForm, type the name of the variable (i.e. fruits) under list_name” the part “type the name of the variable (i.e. fruits)” should be replaced by “choose a name at your convenience”; and in the phrase in “Step 3” that reads “Under the list_name column, type the variable name for each row”, “variable” should be replaced by “the list name you chose in Step 2”.
-
Whatever is written in the “label” column of the “choices” sheet (even a random word or even just nothing) for the considered row, Enketo will display what is in the “label” column of the CSV file; if the CSV file does not have a “label” column (and again, whatever is set in the “label” column of the “choices” sheet), Enketo will display void labels (radio-buttons or checkboxes with no label). See the below attached example.
- This entails a limitation: since only the “label” column from the CSV file is taken into account, no “label::en” or “label::whatever” will be displayed, and therefore no multi-language labels are supported. A possible workaround for a given select question Q1 using external options is to split it in several questions, each dedicated to a language, like Q1_en and Q1_fr, each using different rows of the CSV file by using filtering, with conditions in the “relevant” field making only the appropriate field (either Q1_en or Q1_fr) appear depending on the language. The “relevant” conditionality must rely on the jr:choice-name() of a prior select field, for example Q0 (I don’t think there is any other way to probe a form’s current language). Unfortunately, if the language is switched during the data collection, the question Q0 must be re-answered to refresh the detected language. Then, a Q1 calculate field can be created to consolidate responses from Q1_en and Q1_fr with the coalesce() function. See the attached example:
Demo-fruits-multilanguage.xlsx (17.9 KB) fruits_multilang.csv (252 Bytes)
- This entails a limitation: since only the “label” column from the CSV file is taken into account, no “label::en” or “label::whatever” will be displayed, and therefore no multi-language labels are supported. A possible workaround for a given select question Q1 using external options is to split it in several questions, each dedicated to a language, like Q1_en and Q1_fr, each using different rows of the CSV file by using filtering, with conditions in the “relevant” field making only the appropriate field (either Q1_en or Q1_fr) appear depending on the language. The “relevant” conditionality must rely on the jr:choice-name() of a prior select field, for example Q0 (I don’t think there is any other way to probe a form’s current language). Unfortunately, if the language is switched during the data collection, the question Q0 must be re-answered to refresh the detected language. Then, a Q1 calculate field can be created to consolidate responses from Q1_en and Q1_fr with the coalesce() function. See the attached example:
-
However, the “name” column of the “choices” sheet must not be void, or Enketo will throw an error. But it can be anything (as seen in the above attached example), even a random word that matches no column in the CSV file; anyway, Enketo will use the “name” column of the CSV file. If the file does not have a “name” column, Enketo will throw an error too.
1 Like
Hi @freedim
Thanks so much. I will be working on this during this week and early next week and will definitely update you on the progress… Thank you so much.
Stephane
1 Like
Hi @Kal_Lam
I’m getting an error when trying to publish the project…
The error message: “The same instance id will be generated for different external instance source URIs.”
