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; } } }

Optimizing performance of survey

KClarkDev_GIS

So, after many many hours of work and research, I was so excited to finally get my complex survey built in Survey123 Connect ready to publish.

The survey is big. The XLS Form has 187 rows, there are five different .js files with multiple functions in each of them. There are external choice lists with thousands of different species names for the region, which use the "pull data" function to autopopulate their indicator status. There are also many other calculations and dependencies built within the form.

I thought I was already doing what was recommend as "best practice" for large surveys (i.e. using the Page style, using external choice lists, etc) but even with doing all of this, the survey crashes on iOS (apparently related to a bug that is supposed to be fixed in the 3.14 version release of the field app). When opening on Android, it doesn't crash but the survey takes 2.5 minutes to open.

Is there anything else I can be doing to help optimize the performance of my survey that I'm missing? Or was Survey123 just "not built" to handle surveys like this?

Find more posts tagged with

Accepted answers

All comments

MattEdrich

An excellent list Doug - thank you for the reply! Your list contains a good amount of best practices that I have started adopting already, and plenty of other best practices that I haven't even thought to consider (particularly using relevant and/or repeat_count....yikes!). Also, some of the stuff you mentioned I have seen firsthand in the field and wondered about (# of open apps concurrently, for one), but have hesitated to connect the dots as my background is most definitely not in computer science at all.

The community really needs a resource like this...if Ismael and/or James haven't done a Tricks of the Trade about this yet, I really hope they take notice...

dougbrowning

Good topic. Trying to remember if Ismael or James has done one of these.

First do not rule out the device impact, esp if it only has issues sometimes. Many times I have traced these down to old hardware. We had some people going on Amazon and getting the cheapest iPad they could find. Refurbs are fine but with Apple's tricky naming they were buying iPads that were 5-7 years old without knowing it. They had all kinds of issues other users did not have. Pay up for an Air if you can. Phones can be worse with users trying to use iPhone 4 or 5 is just not realistic. These devices are consumer grade and have a 2 year shelf life really. They are way cheaper than any windows tablets we use to have so just plan to upgrade on the regular. Also make sure the tablet is up to date. A factory reset can also do wonders for an older device. If a certain user keeps crashing get them a brand new device. Remove any apps you never use.

Second make sure your 123 is up to date - both on the tablet and Connect. AND if the form is old read up on new features that have came out. If you still have your lists in choices move them out to a CSV for example. Even if you change nothing a republish from a newer version of Connect can help - and also break stuff so always test, test, test.

Number of apps open can be a big one. In field training the tablets that crashed they had like 20 apps open. Also number of apps installed reducing free space a lot. Some tablets use shared memory and low space can cause issues.

Trial and error is for sure a lot of it.

The start of a list off the top of my head

Finding potential problem fields then removing them one by one can narrow it down

Simplify if statements

Reduce temp fields

Do not use repeat_count

Breaking into multiple forms (I have projects that are 10-15 forms since we have 1,700+ questions)

Reducing the size of images and other files in the media folder. Adding a CSV that has 300 columns when you just need 2 for example. Choice images should be run through an online size reducer.

Reduce the use of relevant as it is memory intensive

If using relevant on many fields add them to a group and have just one relevant.

Move big lists out to a stand alone CSV. If you still use external_choice move those also.

Reduce multiple calls to pulldata. I have seen forms have the same pulldata in multiple questions vs have it once and then reference that question. This can be a big one.

Reduce the number of cals. I have users want huge summary pages with a repeat of the data or summary calcs. Make sure you really need them. Or move to a report, use Arcade in a map instead, etc. This one I have seen make huge differences.

Keep the device out of the sun if you can. Heat slows them way down. Rugged cases can get really hot also. We tend to put them in a cooler at lunch.

Overuse of calculationmode=always is prob going be one.

Many calls to the web in pulldata or search

Limit use of JS and number of calls

Well that is a start I am sure others have some.

MattEdrich

Hello @Katie_Clark and @DougBrowning, and sorry to revive a long-dead post...but this is truly the only place I can find on the internet that is a focused discussion on optimization of S123 forms! Each of you have replied to many questions of mine across the forums, and I found it uncanny that the only public discussion of optimization has happened between the two of you. Over the past year and some change, I have become the de facto "survey guy" at my company, and our surveys have gotten pretty darn complex - and they could easily get even more complex given the time and attention.

As one example: I am developing a form right now that, among other data captures, measures the vertical plumbness and twistedness of a telecom tower, and then takes the field observations and applies a fair bit of trigonometry to them in order to produce calculated values that are utilized by both the field team that made the measurements (during the same site visit), as well as the report deliverable for the site visit. Doing it this way (not well tested on my end yet) is a massive timesaver during the office QA/QC deliverable creation process, and it actually gives us quite a unique product within our industry - so it is important to do what we can to keep the functionality as it is.

Some of my forms really have a tough time running well on a smartphone and I can't really figure out why, as the crashing isn't consistent across the submitting device or the amount of surveys submitted from the device, or even apparently the size of the data capture in the field.

All that is to say, where have you both learned what you know about optimizing surveys? I have definitely learned mostly from trial and error, and secondarily from little snippets in the S123 documentation, but I haven't had really any luck at all in finding better resources than that...and I can't even really find ways to establish performance metrics besides observing whether or not a survey crashed.

Just trying to level up my proficiency as a form designer, and you both are well-established authorities on the matter!

Thanks 🙂

dougbrowning

Mm maybe take out some of the less important things like common name then. Not sure they need that out there.

Also are the numbers just for display? Maybe you could have 1 JS function return a string of values vs calling it multiple times. You could also maybe use substr to pull values back apart.

The new calcs engine in 3.14 does seem a lot better so far. Good luck.

KClarkDev_GIS

That's very interesting to hear your feedback! With this particular form, I actually created a python script first to do the calculations on the feature layer, but that would have to be done in post-processing. The field crew said they either wanted things calculated and displayed "on the fly", or it wouldn't be much use to them and they would proceed with purchasing a software service that does something almost identical. I was hoping to be able to save my company a lot of money by just using Survey123 which we already have.

I'm just starting to look into the EAC 3.14 version. On Android, the survey opened in only 10 seconds compared to 2.5 minutes, so that's promising!

dougbrowning

Funny I do a ton of monitoring forms like this. I think the big issue here is you are doing analysis calculations in the form. We stay away from that. Forms are really just to collect data not for analysis. The big issue you will run into is people fixing species codes and such in the web map after the data is collected. When they do none of the calcs refire. Our other issue is we do 3 transects and do 1 form for each to keep the size down. So we have to look across forms later anyways. We also took some calcs out because people are using the numbers before QA. If you fix something in QA then again the calcs do not refire giving bad numbers.

Also we separate the species list out and store. So we have the species code in the form but the common name and all of that is in a lookup table. In that table we store things like is it invasive, annual, type, etc. A plant can vary annual/perennial across states. So we just log what they saw and then can adjust the analysis based on the species list for that state or when things like invasive change over time.

I cannot see your calcs but these seem like you could do them in Arcade for viewing. The other option, which we do, is run a python script to generate all the calcs. We serve this out as a diff feature class so the raw data and calcs are separate.

Prob not what you were hoping for but I do not think this form is going to work very well as is. I work with the BLM monitoring program doing Wetland, Lotic, and Terrestrial so feel free to contact me if you are interested in our methods.

Sorry I was not more help.

KClarkDev_GIS

Hi Doug, thanks for the response! I've attached the XLS form.

Unfortunately, yes as far as I can tell, I need to pass in the entire repeat to do the calculations I need, for multiple repeats. If you have any suggestions for improvements though I'm all ears.

For version 3.14, it is still only available through the EAC, right?

Midwest Region - Automated Wetland Determination Data Form.xlsx

dougbrowning

Are you passing whole repeats into the JS functions? I have a large repeat and it crashes JS every time. There is a lot to pass in. Maybe there is a way to do some of what you want without JS?

3.14 did seem to help with memory so I would try it.

Post the form if you can.

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.