Select to view content in your preferred language

Briefings Preview Enhancements

705
5
07-30-2025 07:55 AM
Status: Under Consideration
Labels (1)
AaronKoelker
Frequent Contributor

In the StoryMap Briefings web builder, the "Preview" mode has options for Full Screen and Desktop. Given there are differences in how a Briefing displays in a web browser, versus in the app online, versus in the app offline—it would be great to have additional Preview options showing what the briefing would look like in these other modes. This would make the authoring process much easier in terms of testing and monitoring how the briefing looks and behaves across all platforms, without the need to constantly republish and to load up the briefing on a separate app/device, and flipping between online and offline. 

As of posting this, some of the differences we've noticed between platforms that this could apply to are:

  • Lack of support for Themes entirely in the app's offline mode, and minor Theme differences between browser and app in online mode (EDIT: Themes are supported offline except for Google fonts—what we saw must have been user-error or a bug)
  • No support yet for the infographic block in the app (both online and offline)
  • Differences in pop-up display/support across all platforms/modes
  • If a map legend is set to be open by default, it works as intended in the browser version and app while online, but not in the app when offline.
  • Differences in the video player's autoplay/control options between browser and app 
  • Differences in text block spacing, which can lead text that looks fine on one platform and but not the other

It can be a lot to keep track of when authoring a Briefing that could potentially be presented on multiple platforms/situations.  

Tags (2)
5 Comments
nmanocha

Hi Aaron,

Thanks for providing the feedback and much appreciated. In future also if you have any other feedback feel free to drop a line here in the Esri community or directly within the app survey from.

 Preview suggestion - It is a great suggestion. We will discuss within the team to how to go about showing the preview option for the tablet app when authoring the briefing within the builder.

Now I will go with the differences you mentioned below

  • Lack of support for Themes entirely in the app's offline mode, and minor Theme differences between browser and app in online mode  - The StoryMaps briefing tablet app supports all the themes both for online and downloaded briefings except for the themes which uses the Google fonts. If you seeing any discrepancy please report it to us. As for the Google fonts that is a known limitation to support them for all platforms at this time. You shouldn't see any differences between the online briefing or the downloaded briefing from theming point of view when viewed with the tablet app.
  • No support yet for the infographic block in the app (both online and offline) - That is correct we are planning to add this in the next update. We are looking for ways on how to minimize the lag between when new features are released on the web app (browser app) and when they get added within the tablet app (native app).
  • Differences in pop-up display/support across all platforms/modes - I am assuming you are talking about the Map popups. If thats the case then yes it is expected as web app uses different API/SDK as opposed to the tablet app. We will be looking into on how to reduce the differences and add more functionalities in the Map popup to show the related records, show popup media in the future.
  • If a map legend is set to be open by default, it works as intended in the browser version and app while online, but not in the app when offline. -  Yes that is expected. Because when online the app is expected for honor the properties set on the Map. The properties you set within the builder is for the online map only. For offline Map (in case of the downloaded briefing) as an author you are supposed to configure the Mobile Map Package (MMPK) or Mobile scene package (in case of 3d map/scene) or a media. MMPK comes with own set of properties when authored within ArcGIS Pro. Those properties may or may not make sense in all scenarios. For e.g if the MMPK doesn't have the locator configured search cannot be initialized but in the online Map the locator is always available using the Esri world geocoding service. So the property of enabling search will work in online but not in offline. But having said that if you have a specific use case please help us understand that and then we can discuss some possible solutions regarding that.
  • Differences in the video player's autoplay/control options between browser and app - As mentioned above native app uses a totally different SDK and hence a different media element as opposed to the web app. We will look into this to see if we can make it functionally similar. 
  • Differences in text block spacing, which can lead text that looks fine on one platform and but not the other  -That is a known issue and we are looking into making improvements on this across all platforms. There will always be some discrepancies when comparing the fonts and line sizes for the native app across all platforms with the web app (browser app). However, we are looking for solutions to make it look as close to web app as possible.

Please let me know if I answered all your questions and if you have any further questions. Please feel free to mention those.

Thank you very much. Appreciate your feedback.

Nakul Manocha

 

 

OwenGeo
Status changed to: Under Consideration
 
AaronKoelker

@nmanocha Thank you, Nakul, for the in-depth response. That all makes sense, and I completely understand the challenge of keeping both looks and functionality in sync across multiple platforms, especially when mobile devices and offline-usage get involved. 

For the offline Theme issue, it started working after I made an update to the theme and republished (I changed the link style from highlighted to a solid underline). Not sure if that was actually related to the issue or just a coincidence. If it happens again, I'll try and capture it. 

nmanocha

@AaronKoelker 

Current approach -

We have been consistently looking to make the native app works the same way for online briefing and downloaded one. For e.g. briefing looks the same when viewed in native app irrespective of it online or downloaded. In other words, we are showing the same content, UI and UX except for the blocks which have offline dependency such as Map or embeds. 

When new blocks or new features are added to the browser web app then we have to implement those in the native app for both online and downloaded briefings. 

Proposed approach -

One approach we can take to limit the lag for the feature support between the web app and native is by keeping native app behave differently for online briefings and offline briefings.

What if for online briefings we always show the embed view of the web app instead of native view. That way you always have the latest and greatest support for any new features and blocks when viewing online. And for downloaded briefing will always show the native viewer like we currently do. The features for the downloaded briefing will be with added with every release of the app within the native viewer but the online viewer will always continue to work as the web app does.  What do you think?

The workflow would be - Sign in the app > Discover your briefings in the gallery page > View briefings in native app. If viewing the online briefing it will open the embed view of the web app (inside the same container). If viewing the downloaded briefing it will open the native viewer. To download the briefing you continue to use the gallery page. 

Advantages of this approach

a) in case of online briefing

1) This way for any new feature or block for e.g. infographics will be available right away for the online briefing.

2) Also the online briefing will look exactly the same as the browser app . So no discrepancies. All themes will be supported

3) Still stay inside the app so the convenience of auto sign-in and discoverability is still there. Plus an option to take your briefings offline (use downloaded ones) and the app will work in no network env. too. 

4) This can be easily opened on the phones too.

5) Will be as responsive as the browser app

6) Zero lag time for online briefing and the features

b) In case of downloaded briefing 

1) Whatever we currently support will continue to work in native viewer

2) For theme issues we will restrict the native viewer to load certain themes only such as featured themes. Basically, all themes which work nicely will be supported and only restricted to those. 

3) Everything will load quickly as it would be local for the downloaded briefing

4) Any currently unsupported block or any new feature will be added for downloaded briefing as we go along with subsequent releases

5) Still be able to side load and edit local briefings for windows

6) At some point we will allow downloaded briefings for phone too

We will have a documentation of what is supported in downloaded ones and what are the limitations?

 

Any suggestions? What do you think? Does this will help you to alleviate some of the issues you talked earlier.

Appreciate any feedback.

Nakul M

 

AaronKoelker

@nmanocha Nakul, 

Thanks again for the detailed response. I think your last point "We will have a documentation of what is supported in downloaded ones and what are the limitations?" would go a long way toward improving the authoring experience, whether it is just a document linked from the web builder or it is somehow incorporated directly into the authoring experience (for example, if you add an infographic block, maybe there's a pop-up or small banner in the builder that notes the limitations or availability in the app.)

Having the web browser version and the online version of the native app be in sync through an embed as you proposed sounds like it could be beneficial as well and help cut down on unwanted surprises when presenting. However I think for our use cases, if we are ever using the native app it would be because we needed the offline mode. For everything else we'd likely use just use the browser version.