StoryMaps memory requirements

[Josef_Strobl]

I've seen some related issues posted, but would like to get a summary of recommendations and guidelines ...

I am currently transferring ('manually') several classic storymaps to the current framework. These all contain several maps, scenes and other embeds each which are running just fine in the classic template. In ArcGIS StoryMaps I keep running out of memory and crashing (during editing), or simply facing grey rectangles where content should show (same content like classic, mostly map journal template!)

I seems the local memory requirements are significantly higher for ArcGIS StoryMaps, and I have to resort to simply linking and creating buttons to other content items, or including screenshots instead of live maps. This leads to a much less immersive experience than I would aim for.

Is there any set of guidelines regarding all that?

• overall memory requirements?
• number of included maps and scenes?
• are layers per map a critical item?
• should I use local layers instead of Living Atlas content?
• I try to minimize the number of separate maps, therefore multiple embeds with different activated layers. Would it help to use a higher number of simpler maps?
• does it make a difference whether maps are used as singular blocks, or within sidecars?
• are apps more memory efficient than maps?
• ...

Recommendations are much appreciated!

.Josef

[OwenGeo]

Hi @Josef_Strobl -- I'm sorry you are experiencing these issues creating new stories. I'm guessing you may have one or more maps with lots of layers. That is typically what causes issues like the ones you're reporting. This is not an issue specific to ArcGIS StoryMaps and could cause issues in some classic templates as well. Here's some more specific info...

• are layers per map a critical item?

Yes!!! This is the most critical thing to be aware of, and even layers that are not visible in your web map consume memory resources. Always remove any extraneous layers from any web maps you use in a StoryMap (or any ArcGIS app).

We are currently working on adding some information to the documentation/FAQ about this, and that will be available in the next few weeks, but I can summarize... In general, it's a best practice to keep the number of layers at five or fewer in web maps/scenes you use in a story. While this is helpful from a technical perspective, it's also a good practice from a storytelling perspective to keep your story simple for readers. If you are re-using the same map across sidecar slides for map choreography you may need more than five layers in a single map, but in this case it's good to keep the number of layers below 10.

• should I use local layers instead of Living Atlas content?

Could you expand on what you mean by "local" layers vs. Living Atlas layers. All layers that are added to a web map must be published on the web, so I don't see a difference between Living Atlas and other layers.

• are apps more memory efficient than maps?

No. Adding web maps directly to your story is definitely more efficient and better from a storytelling perspective than embedding apps. Embedded apps should be used sparingly and only whenever it's critical that the reader must interact with the app while reading your story. Typically, it's a better experience to link to an app (so an interested reader can open it in a new tab) rather than embed it in a story. That being said, I wouldn't expect any specific performance issues with typical embedded apps unless you added 3 or more different apps in consecutive sidecar slides or one right after the other in inline blocks.

[Josef_Strobl]

Hi @OwenGeo, glad to hear from you again!

Thanks for some helpful pointers, like only using apps if some particular features are needed (like, interactive legend, charts), but that otherwise simple maps would be more efficient.

Actually, when using the exactly same multi-layer maps (5-8 layers, not more) my impression is that map journal handles these better than ArcGIS StoryMaps. But good to know this being a key factor re memory, I would then need to work with a higher number of simpler maps. Harder to manage, but better than facing these grey boxes so frequently.

Creating maps with new vs classic map viewer should not make a difference, right?

With local I meant e.g. sharing a map with a few countries from my own content, vs filtering a corresponding set of countries from the World Countries Living Atlas. Actually, doing this with LA Terrain, or land cover. I had expected directly using Living Atlas content even for local/regional extents would not carry a performance / memory penalty - ?

Do I understand correctly that a sequence of maps would in these respects be preferable over a sidecar including the same set of maps?

Thanks again, Josef

[OwenGeo · Accepted solution]

Another thing to keep in mind is that for storytelling, the best performing map is a screenshot. If you don't need your audience to interact with your map and the map doesn't contain live data, take a screenshot and add that to your story and that will greatly reduce the moving parts in your story.

Here's some more info about your follow-up questions...

my impression is that map journal handles these better than ArcGIS StoryMaps.

It's important to realize that Journal generally only shows one map at a time since it was a section-based template, which is more similar to the sidecar block in ArcGIS StoryMaps. Adding maps inline as separate blocks is more similar to the classic Cascade template. Journal never pre-loaded any content, so readers had to do a lot of waiting for things to load while navigating the story. Pre-loading in ArcGIS StoryMaps is an improvement in the vast majority of cases, but it's true that it may cause issues when there are multiple maps with a lot of layers used close together in a story.

So, how does this pre-loading work...

• For inline blocks (which also includes content in a sidecar's narrative panels, the StoryMap will load what is currently in view as well as content a bit above and a bit below.
• In sidecars, the StoryMap will load the current slide's media panel as well as the one before and after. This means you can have up to three different maps loaded at the same time. If each map has more than 5 layers you are in danger of exceeding the capacity of the browser and the graphics technologies that are at work. If the same map is reused across sequential slides, it is only loaded once.

Again, it's important to know that even layers that are not toggled on in the map need to be counted. Every layer in the map, whether it's visible or not, needs to be initialized and consumes memory resources.

Creating maps with new vs classic map viewer should not make a difference, right?

Correct, no difference in terms of performance. 

With local I meant e.g. sharing a map with a few countries from my own content, vs filtering a corresponding set of countries from the World Countries Living Atlas. Actually, doing this with LA Terrain, or land cover. I had expected directly using Living Atlas content even for local/regional extents would not carry a performance / memory penalty - ?

Anytime you are filtering/rendering a large or detailed dataset there is work to do on the client and/or server. However, while this might cause some/all layers to render slowly, I wouldn't expect it to prevent a map from loading at all. It's usually a good idea to optimize layers in maps used for storytelling (minimize on-the-fly processing), but this may or may not be necessary in all situations. If your maps load quickly, there's no need to change anything.

Could you share links to your maps (and make sure they are shared with Everyone) so we can take a quick look just to make sure there isn't anything else about them that might be causing an issue?

Do I understand correctly that a sequence of maps would in these respects be preferable over a sidecar including the same set of maps?

Neither is preferable, but they work in different ways (see info about pre-loading, above). If you are following the best practices of minimizing the number of layers in each map I would expect that you would be able to decide how to arrange maps in your story based on how you want to tell your story rather than performance issues.

These best practices are very conservative. They are primarily driven by keeping things simple as well as accounting for the worst case of having different maps that appear immediately next to each other in the story. If you have a single map in your story where you truly have a need  to show 12 layers you should be able to use it, as long as it is not immediately preceded/followed by a different map/app with that many layers.