Hi Peter,
Thanks for interest in story maps. As we continue to enhance our templates we are always looking for the best way to integrate multimedia within our apps, especially in ways that can be easily integrated with the GIS workflow. That being said, we pay special attention for how we integrate with every service we showcase in our builder, including our own services.
First and foremost, Story Map apps are designed to be lightweight applications that allow you to tell your story to anyone you wish and should not be dependent on their browser connection or device speed. When we make decisions about integrating FS attachment support, we always want to provide the best user experience the end viewer. Feature services have powerful enterprise database capabilities but using them in certain ways can have detrimental effects on the end user performance.
Both Map Tour and Crowdsource (and soon Shortlist) which are point based stories do allow you use FS attachments. When creating a new Map Tour, you will first encounter a screen that asks “Where are your image or videos?” If you choose the “ArcGIS” option, the app will create a FS in your account to store the point data. As you upload photos in the app, the app will automatically optimize the photos for the web and upload them as attachments to your feature service. It will then grab the URLs to these attachments and store them in field of the FS service so the app doesn’t need request each attachment URL every time the app loads. The map tour also allows you to use an existing FS with attachments if you create a new web map with that layer and share it into the Map Tour app. However, this is not recommended for the reason below. Crowdsource will always use a FS with attachments since that is layer type which allows other users to edit your data. The crowdsource app does not store URLs to the attachments in another field but works with the new query API call mentioned in reason 2 below.
In our new Cascade app (and soon Map Journal and Series), we are also starting to use a new API call which will allow you to upload photos directly to the application item from within the app. These photos can be managed in the app builder or through the REST API and will keep the same sharing properties as the story you are creating.
There are three main reasons that make it difficult for our apps to use FS attachments that have been added outside of a story map builder.
- Many times attachments that are added outside of our app builders will be the original quality photo that may be 4mb or larger. Even on a 3G connection, this may take 10+ seconds to load per image. All of our apps will optimize the photos for the web before uploading them as attachments. Our typical file size for large images are 2-400kb and for thumbnails is about 10kb.
- Typically, in most other apps (Collector, Survey123, etc.) or in a GIS workflow when you upload an attachment, the URL to that attachment is not saved into another field of the FS. In order to load an image attachment in a story, the app would have to make two requests per attachment. In many of our apps that use feature services, we have a thumbnail gallery to let the user explore all the points. In order to keep the thumbnail gallery, our apps would have to may have to make hundreds of additional requests as the app is first loading. This slows down the initial load time of the app (especially on slower connections) which is the most important period to keep a viewer’s attention. A new API has recently become available to ArcGIS Online hosted FS and may be rolled out to Portal and Server FS that allow us to query all the attachments with only a couple requests. As this become more widely available, we plan to integrate it into our app.
- Lastly, most of our apps require specific data structure such as 1 thumbnail and 1 photo per feature. When our apps upload attachments, we use a specific naming convention to determine which attachment corresponds with each part of the point display. Other apps (Collector, Survey123), maintain the original filename and we cannot reliably predict which attachment is which, especially if there are more than 2 attachments on a feature. We are in the planning stages to update our existing apps to make this more flexible in the future.
