(Implemented) Survey123Connect choices: duplicate names & different label

[HélèneTOUYERAS]

Good morning,

Recent versions of Survey123 Connect do not allow anymore to have duplicate names in a choice list - duplicates were allowed in previous versions of Survey123Connect. Could it please be reinstated?

My use cases are in forestry management, where Survey123 is used to identify, locate & describe trees.

Just as most other types of wildlife species, tree species hav:

• a single scientific (latin) name in our database,
• potentially several vernacular names (because vernacular names differ from a region to another, or from a foresters' generation to another).

I attach an example mini-survey illustrating the case, with the following parameters:

The result of that mini survey is illustrated below: two entries for the Oak are missing, only the first label from the choices list appears in Survey123 :

I did interact with the "allow_choice_duplicates" parameter in the seetings tab, with no effect (per ref. here:  https://github.com/XLSForm/xlsform.github.io/blob/master/_sections/home-english.md).

Many thanks in advance!

With kind regards,

Hélène.

[DougBrowning]

I have seen it as a setting on the Settings page now in the new template.  Did you try that?

hope that helps

[HélèneTouyéras]

Thanks for your message, @DougBrowning! Yes, I have:

I did interact with the "allow_choice_duplicates" parameter in the settings tab, with no effect.

=> Setting the value according to the XLSForms recommended syntax does not change the behavior of the form (syntax ref: https://github.com/XLSForm/xlsform.github.io/blob/master/_sections/home-english.md)

I hope this functionnality will soon be implemented ;  the recent version(s) of Survey123Connect have resulted a big regression on the form's behavior on this topic.

[DougBrowning]

Opps sorry I missed that.  I think domains will get you on this.

Is there a reason to not just have the label be Oak (English, Common, or European) or something like that?  Autocomplete will find any of the three words no problem.  Seems saver to me.

Just an idea

[HélèneTouyéras]

Hi @DougBrowning ,

Many thanks for your reply & question!

Yes there is a reason why we do not use concatenated aliases: we are using pre-existing domains, furnished by the client. Complying with their codes and aliases is a stringent contract requirement.

Extending labels to have one single code = comma-separated aliases is our current workaround, but it is high maintenance as our client's domain is a moving target (2-3 updates per year), and a relatively long list (102 tree species).

This is why the copy/paste any new version of the client's domain into Survey123 XLS form was a great relief (one step does it all), and an insurance to comply quickly & simply with the requested data model, as used to use the jr:choice-name() function later in the Survey123 form.

This quick & easy workflow is not supported anymore when we concatenate domain aliases into a comma-serataed list. In addition to editing the client's domain, we also have to add an extra maintenance loop, to catch the client's original alias, rather than the comma-separated list.

With kind regards,

Hélène.

[JamesTedrick]

Hi @HélèneTouyéras ,

This would be much better raising with Esri Support as a BUG than as an Idea in the Esri Community.  This was noted late in our development of the 3.12 release, but the only cases we've previously seen that this affected involved cascading selects that needed to retain a value in different cascades; that issue was solved by providing more comprehensive evaluation capability in cascading selects.  The strict requirement of your user to show choice list as is a new requirement.  That being said, are they truly a 'domain' in the geodatabase sense?  I would think it would have the same issue that Survey123 does, in that given that there are multiple labels for a given value, it would only show the first label in the list.

[HélèneTouyéras]

Hi @JamesTedrick ,

Many thanks for your reply!

You are right: these are choice lists, and not true database domains. Underlying this request is ergonomy:

• for the Survey123 field worker, who can find any tree easily, no matter how they are used to calling it. And as Survey123 used to support duplicate entries in choice lists, they are now well used to finding everything they need. 

• for Survey123Connect designers, as we can copy/paste the revised tree species lists when the client refreshes it, and demands compliance to their new list.

XLSForms seem to have some parameter to authorize duplicate names in choice lists ; and the required parameter already appears in Survey123 (ref: https://github.com/XLSForm/xlsform.github.io/blob/master/_sections/home-english.md).

... many thanks for considering its implementation in Survey123 !! 🙂 

With kind regards,

Hélène.