Ways to speed up data entry, esp with drop downs?

[DougBrowning]

Getting some push back from users on data entry speed in Survey123.  Users expected a fast modern app but so far it is slower than our 15 year old Access program.  

The main slowness issue is the speed of using autocomplete drop down lists.  Our last app could look into Form1 and use it as the drop down list in Form2.  We of course cannot do that in 123 so all lists must include the full 1,500 long list.  This means that where in the past a user could tap the drop down, minor scroll, tap item (2 taps) but now they must tap to start typing, type 3 chars to narrow the list enough, then tap the choice (5 taps).  We have this drop down as many as 12 times per repeat, with 50 repeats.  So we just added 1,800 taps to the field workers day on just 1 form!  They then do this form 3 times at each site.  First reports back are that this form is now taking the user 3 times longer than the 15 year old form.

Any tips to speed this all up?

First idea was move common choices to the top of the list.  One issue here is that varies by where they are in the country.

Second idea was to use predictivetext and have android start guessing the choices based on previous.  But predictivetext does not work with drop down lists.  Could survey123 feed choices to android?

Third idea is that the list learns what items are picked most often and sorts on that.  But this is not possible in 123 currently.

I am sure the team wants it to be faster so here is some input.  Overall the field workers feel that 123 is still a bit clunky.  I have to agree.  When it was beta it was ok but now that we are in v3 it is time to take a hard look at the UI.  Consider having a field UI expert look at this.  Things like the buttons being so small (esp the drop down arrow) are important to field works with big dirty hands.  I think us developers can be guilty of only testing in the office without sun, rain, dirt, etc.  I know I have done that.  Taking the forms/tablets outside for some real world testing needs to be made more important in my opinion.  Speed becomes very important when you are out in the hot sun all day.  It is enough of an issue that it could kill adoption for us.  At my last job we ended up creating a custom app where we sent out a crew, they said too slow, we made it faster, still slow, 20 more iterations.  Took a lot of back and forth but it finally got to the point of keeping up with the human.  In the field speed trumps all else.

Thanks for any ideas!

[Anonymous User]

Hi Doug,

We have an open enhancement issue to speed up large choice lists in the app by caching the choice list data to a sqlite db vs loading it in memory. This will greatly improve the speed of the queries against the choice lists and also the responsiveness of the app. Some of this work is currently in progress with early beta builds, however there is no timeline yet to getting this on EAC or in a future release. It is very important to us to get this right and we are continuing to work on it.

Your feedback is very helpful.

Phil.

[DougBrowning]

Thanks Phil that is great but I think you are misunderstanding my ask/issue.  I am not talking about the speed of lookups, I am talking about making the lookups smarter and improving the workflow of data entry.  Like a Google search where it tries to guess what I want based on previous answers.

Our old form is not fancy technology it simply puts the last choice at the top of list for the next repeat.  This way your list eventually gets sorted with the most frequent choices at the top.  I could see how this would be tough across forms but it should be pretty easy within a form, esp across repeats.  We do 50-100 repeats per form.  I think I saw somewhere that Survey will load the choice list once into memory and then use it for each question that hits that list (at least I hope as no reason to have it in memory several times but this could explain my memory issues).  Then as users pick choices the list would put that response at the top of the list for the next question or repeat.

By having this sorted in memory list you could also implement limiting the number of times a choice can be made.  Lots of posts here about people wanting to remove an item from the list once it is picked.

Speed of entry is key for field workers.  In fact almost nothing else matters.  So as I mentioned our number one user complaint on Survey123 is the slow and clunky data entry workflow.  My real work example I gave above is a big issue.  We did the math and since a user must always tap, then type in 3 chars, we add 1,800 taps to each plot.  They do 2-3 a day so low end that is 18,000 more finger taps a week!  

We have looked at ordering the list by most common but most common choices change Plot to Plot, and for sure crew to crew, and throughout the season.  I am sure others have this.  Our species list is 1,700 plants (per state).  Odds are you will hit a plot with a bit of a cluster of the same plant.  So you will be picking this plant from the pick list maybe 1,000 times that day.  Before that just meant tap for drop down, tap for first choice.  Now they must tap, type in the 3 chars (since so many have the first 3 letters the same), then tap your choice.  Do that 1,000 times and you will probably start to think your form is kinda dumb.  Esp since old Access could do it.

I hope that lays out the use case better.  I think this is a very common one.  Anyone care to chime in?  It is also what I meant by really looking at it from a field worker view, out in the hot sun, with 1,800 taps in front of them.

I believe the next evolution for 123 is "smart" forms, or adaptive data entry, or whatever you want to call it.

Hopefully this makes it on the list!  Thanks!