Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Story - add as main viewing type #65

Open
smalers opened this issue Aug 10, 2022 · 1 comment
Open

Story - add as main viewing type #65

smalers opened this issue Aug 10, 2022 · 1 comment
Assignees
Labels
enhancement New feature or request high Priority: next release if possible L Size: more than 3 days

Comments

@smalers
Copy link
Contributor

smalers commented Aug 10, 2022

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:

Technical considerations include:

  1. 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.
  2. 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.
  3. 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:
    1. How to format colored text to match colors in a map legend or chart.
    2. How to link to other InfoMapper page.
  4. 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).
  5. 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).
  6. 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.

@smalers smalers added enhancement New feature or request high Priority: next release if possible L Size: more than 3 days labels Aug 10, 2022
Nightsphere added a commit that referenced this issue Aug 25, 2022
…riad of issues that were holding back a push to the main branch.
Nightsphere added a commit that referenced this issue Aug 25, 2022
…y page. Adding scroll options to a map in the form of a control.
Nightsphere added a commit that referenced this issue Aug 30, 2022
@Nightsphere
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request high Priority: next release if possible L Size: more than 3 days
Projects
None yet
Development

No branches or pull requests

2 participants