Unclutter multiple image fields in a survey (take two)

3423
19
08-08-2018 02:38 AM
DeonLengton
Esri Contributor
9 19 3,423

After some valuable inputs I have reworked this example to cater for the GOTCHA where a user deletes an image in the middle of the sequence of photos - lets hope its fool proof now! It definitely isnt perfect but hopefully it gives someone else out there an idea of what can be done - and with a little extra effort make it completely fool proof...

Do you have the requirement that your field workers might want to take/attach multiple photos to a survey but you dont want to use a repeat to capture them, since you know its harder to access those photos later?  Just adding multiple image fields to your survey leaves your user interface cluttered like this:


Thats pretty ugly right?

One solution to unclutter the interface is to show the second photo field only once a user has already taken a photo. And after the user took the second photo, the third photo field becomes available... etc etc...

That can be achieved easily by setting the relevant field of each photo field with a calculation such as checking the value of the previous photo field:

The trick to get this to work when a user decides to delete a photo in the middle of a sequence of photos already added is to do the relevant calculation only once with the help of the once() function.

Doesn't this look much less cluttered:

After taking the first photo, the second one is opened up:

19 Comments
MichaelKelly
Occasional Contributor III

Hi Deon,

Another option is to use something like

${photo1} != ""

in the relevant column. This removes the need to use pulldata and shortens the relevancy formula.

Of course you can also use repeats to capture as many photos as you like without using any relevancy statements, but the attachments can be a little more difficult to access post process.

Mikie

IsmaelChivite
Esri Notable Contributor

Thanks Deon!

I like Michael's suggestion. ${photo1}!="" is a bit simpler and also quicker to execute, since Survey123 will no longer need to open the image to check the EXIF data.

One gotcha to keep in mind with this technique is that end users cant delete photos once taken. Consider the following scenario:

  • Take photo 1 (photo2 question will now be shown)
  • Take photo 2 (photo3 question will not be shown)
  • Take photo 3
  • Remove photo 2 (photo 3 will be hidden and lost)
BradenBurkholder
Occasional Contributor

Is it safe to use 

string-length(${photo1})>0

or is that asking for trouble down the road?

I recently had a relevant column value of

string-length(${geopoint})>0

break in 3.0 and cause some headaches...

JamesTedrick
Esri Esteemed Contributor

Hi Braden,

Did the recent update of Survey123 address the string-length and geopoint issue?  That sounds like one of the problems that we believe were addressed. 

BradenBurkholder
Occasional Contributor

Any guidance on how to make this work in the Web Form interface? None of the above relevant statements (or use of them in an intermediate calculate field) appears to work in progressively showing more photo fields...

BradenBurkholder
Occasional Contributor

Yes, I believe the update did solve that issue.

I figured I had used it incorrectly and immediately switched some of my current surveys over to using a calculated field based on a pulldata() value instead of the string-length(${geopoint})>0 in the relevant statement.

JamesTedrick
Esri Esteemed Contributor

Hi Braden,

The ${photo} != "" appears to work for me - can you confirm with this sample:

typenamelabelrelevantcalculation
imagei1Image 1
noteImage 1's text${i1}
imagei2Image 2${i1} != ''
BradenBurkholder
Occasional Contributor

Ahhh, well, that works.

My wrinkle is that the photos are inside a repeat... the above syntax doesn't work in a repeat, best I can tell

JamesTedrick
Esri Esteemed Contributor

Hi Braden,

I do see the issue - it work on the first repeat in the web form but not subsequent ones.

DeonLengton
Esri Contributor

Thank you Michael, I have reworked my calculation - 

DeonLengton
Esri Contributor

That was a major GOTCHA indeed - I have reworked the example - now using the once() function to only do the check at the beginning... its not perfect but its less imperfect now! 🙂

BrandonA_CDPH
Occasional Contributor II

Thank you Deon Lengton‌ for this solution.  Looks very promising for a form I have been working on.

DeonLengton
Esri Contributor

Hi Brandon

That's awesome! Very glad that you could get some use out of the idea.

ShelleySchott
Esri Contributor

Thanks Deon Lengton‌ for sharing. It works quite well for repeat dates as well.

KarinaLivingston
Occasional Contributor

Hello everyone,

I've tried all these solutions and I am still receiving an "Error: Initializing form... TypeError: Cannot read property 'length' of undefined. Does anyone have a suggestion? Deon Lengton thanks for sharing. I'm even trying just a simple survey with 2 "image" types. The error does not start appearing until I add the relevant field for the image. I've tried 3 or 4 different syntaxes for these. 

Thanks

JamesTedrick
Esri Esteemed Contributor

Hi Karina,

The error is probably related to another element of the form - could you share the XLS file?

KarinaLivingston
Occasional Contributor

Hi James,

I'm unsure how to attach the whole file but here is a screenshot of my XLS file.

JamesTedrick
Esri Esteemed Contributor

Hi Karina,

I'm not seeing an error when I publish a copy of the Excel file the image shows.  One thing to note is that there is an issue with using your relevant statement to show images - currently it will not work (and should be string-length(${Tree_Trim_Photo_1}) > 0 in order to work when fixed).

KarinaLivingston
Occasional Contributor

Hi James,

Yes, we are only encountering this error when trying to edit a completed survey through the "My Survey's" data page. For now, we are able to accomplish the most necessary tasks but I will change the relevant statement for when it is fixed. Thank you!