You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been hearing over and over that people are defaulting to using Esri StoryMaps for visualizations. That is OK if they have access to ArcGIS Online. The InfoMapper can provide an open source alternative that can integrate with other InfoMapper visualizations and components. We would need to add support for the fullpage.js library, which still seems like a good option and they have a GPL 3 license for open source. See the Examples and then drill into the Angular wrapper.
See also issue #14, which has some broad background.
See repositories where OWF used fullpage, also deployed on South Platte Basin:
Rather than calling "story map" or "map story", of which there are already competing products, just use "story" for the app configuration file; however, many people don't have funding for that or the technical skills (or both). I recommend referring to as an "InfoMapper story" or just a "story" within a website so that we don't have confusion with any existing product. For example, we could add a Stories main menu to the application similar to how I have added Dashboards, or build in a story in a sub-menu.
Ideally, the input can be in similar formats to what we have already done, for example Markdown for content, map component, chart component. We are trying to use common input formats like Markdown, GeoJSON, CSV, etc. rather than proprietary black box input.
Configuration may require some additional HTML embedded in Markdown, but as long as it is straightforward and we can explain, hopefully it is simple. For example:
How to format colored text to match colors in a map legend or chart.
How to link to other InfoMapper page.
Ideally the visualization component on pages consists of embedded components like the Leaflet map component. This is complicated by the fact that "pages" scroll within the story (rather than stay as a single page application). Previously, Justin did work so that the scrolling was actually more of an auto-page advance rather than having to scroll. Traditional scrolling such as in Esri stories can be irritating because the pages scroll up and the text for a page scrolls down on top (under some configurations).
Ideally input files can be managed similar to the existing InfoMapper, for example, put content pages in separate Markdown files numbered 01-something.md, 02-something.md, etc. Use map configuration similar to what we have been doing (which are now mainly the map configuration and a few supporting configuration files since data now lives on data.openwaterfoundation.org).
Keep in mind whether a story can be displayed in a popup so that it can be a secondary visualization on top of a map, for example for a short story that is better than simple Markdown, but this may be too complicated.
Also, should we consider supporting the following, either embedded in a story (we did that with some of the South Platte work), or as separate tools? Knight Lab. I see that they now have a story tool (they did not have that when we selected fullpage). Some of these tools could be stand-alone, such as image side by side viewer, or could be embedded in a story. I am always in favor or modularity but I recognize there are technical challenges. For example, do stories allow "widgets" to be embedded, where a widget is any visualization component? In this way, a story could be sort of like a dashboard.
At this point, do some homework and then we can discuss.
The text was updated successfully, but these errors were encountered:
The dashboard approach was ultimately decided on for data & visualization layout for each page in the story. Each story configuration file contains JSON with basic story name, chapter name, and similar other properties. Each page object in the file will be a dashboard configuration object so we can take advantage of the dashboard layout. More information can be found at the Adding a Story docs.
I still need to add the ability to change the background color of each page in the story, so I'll refrain from closing this issue for now.
I have been hearing over and over that people are defaulting to using Esri StoryMaps for visualizations. That is OK if they have access to ArcGIS Online. The InfoMapper can provide an open source alternative that can integrate with other InfoMapper visualizations and components. We would need to add support for the
fullpage.js
library, which still seems like a good option and they have a GPL 3 license for open source. See the Examples and then drill into the Angular wrapper.See also issue #14, which has some broad background.
See repositories where OWF used
fullpage
, also deployed on South Platte Basin:owf-learn-arcgis-story-maps
- old but may be usefulswsi-story-sp-entities
swsi-story-sp-hydrology2
swsi-story-ipps
Technical considerations include:
01-something.md
,02-something.md
, etc. Use map configuration similar to what we have been doing (which are now mainly the map configuration and a few supporting configuration files since data now lives ondata.openwaterfoundation.org
).Also, should we consider supporting the following, either embedded in a story (we did that with some of the South Platte work), or as separate tools? Knight Lab. I see that they now have a story tool (they did not have that when we selected fullpage). Some of these tools could be stand-alone, such as image side by side viewer, or could be embedded in a story. I am always in favor or modularity but I recognize there are technical challenges. For example, do stories allow "widgets" to be embedded, where a widget is any visualization component? In this way, a story could be sort of like a dashboard.
At this point, do some homework and then we can discuss.
The text was updated successfully, but these errors were encountered: