nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Is there an advantage of storing shorter names vs longer labels in ArcGIS Survey123?

EricaNova

I'm transferring an old MS Access database to Survey123. I'm currently creating choice lists and configuring the survey before I import in the historic data.

I noticed that in the Access database, most of the fields were associated with lookup tables. For example, "m", "f", and "u" were stored in the database instead of "Male", "Female", and "Unknown". If "Olivia Beatrice Smith" entered the data, she would choose "OBS" from the "data_entered_by" field.

Is there any reason to keep these codes in Survey123? E.g., having short names and longer labels in my choices sheet in Survey123? Will storing shorter codes make my database take up less size or load faster? Or will it just cause me headaches?

Find more posts tagged with

Accepted answers

dougbrowning

1000000% stop using codes! As you said only headaches. I have been at companies where people are not even sure what the code means anymore.

I keep the name and label the same at all times if possible.

This is a relic from the data entry days for quick typing and yes some space savings. But none of that matters really anymore enough to see any difference.

All comments

dougbrowning

1000000% stop using codes! As you said only headaches. I have been at companies where people are not even sure what the code means anymore.

I keep the name and label the same at all times if possible.

This is a relic from the data entry days for quick typing and yes some space savings. But none of that matters really anymore enough to see any difference.

clt_cabq

Thank goodness its not numeric codes! There is no good reason any more not to make your database human readable. I guess the only real value i can see is if the investment of time it will take to convert the codes to something English like is significant and too costly for your project.

ChristopherCounsell

Yes, and no. I understand as @DougBrowning said it's a bit of a legacy thing to save data size, performance, etc.

But you DO need to keep the choice lists clean - no spaces or special characters in the code column. It's a little known requirement of Survey123 that can cause issues for some parts of Survey123 but also when you move it around to other locations e.g. file geodatabase domains.

https://doc.arcgis.com/en/survey123/desktop/create-surveys/quickreferencecreatesurveys.htm#ESRI_SECTION1_8ED1E0D010424885A425D6BEB893216A

So you can't just keep the name and label the same most of the time. But you can keep the choices clean

e.g. "Male" and "Male" are fine. A label of "Olivia Beatrice Smith" should technically be "Olivia_Beatrice_Smith" in the choice name/code.

Users will see the code if they export to CSV from a web app. Other times you can use arcade to pick which one is shown or used in calculations.

dougbrowning

Spaces have been fine in 123 select one for years now. Select multiple no, but one is just fine.

abureaux

Agreed.

I always use "short-descriptive-form" for my choice lists. In my mind, a list item name should be:

Distinctive. It should be identifiable on its own. E.g., For a list of roof types, EPDM vs 0001. One of these is descriptive, and one is meaningless.
Short. I mean this in the context of some list item labels are unnecessarily long for a name. E.g., EPDM vs Ethylene propylene diene monomer rubber. NOTE: I do not mean this in the sense of reducing database size. As others have mentioned, that isn't really a thing any more. HDDs are cheap.
Simple. No special characters or spaces. As Doug pointed out, spaces are okay for select_one, but I prefer 1) the ability to seamlessly swap between select_multiple or select_one, and 2) standardize everything on the list page to simplify data entry.

EricaNova

Wow! Thanks so much everyone, this is super helpful. I really appreciate it and I know your answers will help other people too. I was having trouble finding a Survey123 specific answer to this question (I saw @DougBrowning alluded to it in another question and I was hoping for more detail). Wish I could mark multiple answers as solutions!

ChristopherCounsell

Spaces for select one choice names will generally work but it's not best practice. It's fine 99% of the time. When I worked for Esri Aus tech support, every now and then there was an issue tied to this. Users would get frustrated as Survey123 gave warnings everywhere else but not this column, so they felt caught out.

The documentation places a hard limit on multiple choice for spaces and commas. Survey123 Connect will throw an error if you have this. Documentation otherwise recommends you should not use spaces or special characters. So it's more a warning than an error.

There's a lot of things that are OK, until they're not. For example, the 30 character limit on field length is OK in ArcGIS Online but not when you go to enterprise. There wasn't a warning for it in the XLSForm for a long time.

I wouldn't worry about it too much but it's definitely worth highlighting in a discussion about choice names. May as well adopt best practice now.

EricaNova

Appreciate the thoughts, Christopher! Can you point me to that documentation? I'd like to read it so I can follow best practice now.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.