Best Practices for the Choices Sheet in an XLSForm

[ThomasHamill]

What are your best practices or naming conventions for the choices sheet?

Do you use CamelCase or underscores in the list_name and name columns?

How do you treat hyphens differently in the name column (equivalent to a domain code) versus the label column (equivalent to a domain description)?

Do you always use integers or acronyms/abbreviations in the name column (and if you do, why?) or is your name column entry simply an underscored or CamelCase version of what you put in the label column for that entry?

What do you do in the name column to represent a label entry that combines text and numeric attribute or value range in parenthesis? Do you simply pick one (either the number or the text component) for the name entry and use the entire string in the label entry?

[Katie_Clark]

This is a really interesting question, I too would like to hear what other people have found to work best for them.

Personally, I usually use underscores in the list_name if it needs to be more than one word, which is just a habit based on my departments convention. As for Name vs. Label, it depends on if the list will be used in a select_one or select_multiple question. If it's for a select_one question, I usually make the Name and Label identical, so I don't have to worry about which version will appear in the tabular version of the data. I haven't had any issues with special characters, it seems to accept the same format. If it's for select_multiple, then I use underscores in the name since it won't allow spaces.

Also, maybe it's a holdover from other programming courses I've taken, but I almost always use lowercase letters in my coded values (list_name, name, etc).  

There are also times where the Label needs to be an entire sentence or two based on the form I'm constructing. My approach for the name varies depending on how I need the answer formatted. Sometimes, the Label will be an entire sentence but the Name is only a number. I can then use this number in calculations elsewhere in the form, since it's used as an overall score for that metric. (i.e. If the user selects the option "Less than 10% of the bottom covered by excessive sediment deposition; bars with established vegetation.", assign a score of 5.)

If I don't need to use the value in a calculation and I have many different choices, sometimes I just use acronyms and numbers. (i.e. I have a "Prescribed Burn Checklist" question in my survey, with 12 different values. The Label will usually be pretty long, but the Name will just be something like pb1, pb2, etc.)

Anyway, that's my approach. 🙂  

[DougBrowning]

Great post idea.  I don't have a ton of time but here is a start.  For context I have been in IT for 30 years and in 123 since the beginning in 2015.

Most of this is preference or hopefully convention in your org.  Being consistent across depts will save you so much.  I honestly think that is why Esri has so many bugs - just not consistent at all.  I won't dig up all the bugs but things like 123 and Field Maps use lowercase globalid and Pro, AGOL, etc use upper (like how does that happen).  ArcMap def query it shows Like on the button and then when you click on it is adds LIKE to the display.  If you turn on editor tracking in ArcMap then publish it uses created_user but if you publish then turn it on it gets Creator.  This stuff make programming so much harder.  Esri needs a standards dept bad.

For me I like CamelCase.  Half my org did not even know the term when I started mentioning it!  Main reasons are no special char issues, _ gets lost in Excel and people miss it, _ AGOL will convert then to spaces on load (can drive you nuts).  Name column you are limited to 31 chars on a field name due to 123 using SQL Lite.  So you have to be strategic (another reason no _ it just takes up space and adds nothing).  Never start a name of anything with a number as it is not allowed many places.

Choice lists - never name the list the same as the field name.  I see this in posted forms a lot and it used to cause issues.  I just do FieldNameList.  I try really hard to make the name and label as close as I can.  We can have spaces now so it is easier.  But for sure no special chars in name.  If the labels start getting really big I tend to use a help image or hint instead of super long labels.  Try not to use codes!  Like we have legacy systems that had Live or Dead for plants.  They did a check box with a value of 0 or 1.  15 years later and still people still are like which one is Live again?  So then people say change it to L and D, no just make it Live and Dead!  Its not the 80s or 90s any more no need for all these codes anymore.
Try not to do stuff like this, make it consistent since case matters.   You will chase you tail a lot on these.

For sure never use Globalid in relationships.  Trust me you will get burned  https://community.esri.com/t5/arcgis-collector-questions/related-tables-for-offline-data-collection/...

All I got for now will add as I think of it.

[Survey123Jedi]

I love this thread, and I'd love to sit down and do a brain dump.

Here's a simple change -

I always tell newbies, "this will change your life" change the yes - Yes (below) to both uppercase because sometimes you need to be coded to the name and sometimes to the label, and this tiny step will save your sanity. 

AND I'd share that you should do this anytime you can.

I hope this changes your life too.

~Michelle Survey123 Jedi!

[ThomasHamill]

Yes, thanks!  I do this too!  Definitely another essential—keeping names and labels (domain code and domain description) the same for the single-word entries.