504 modal intro page

[NealHumphrey]

This PR adds a modal that deploys on initial page load. It has welcome text and allows the user to either take a tour, view an example analysis, or just use the tool. If they are loading a saved state, it does not show them the example analysis option and replaces it with a button to view the saved analysis (this just closes the modal, since the saved analysis is being loaded regardless).

If the user closes the modal before the page is ready to use, it opens a page dimmer with a "loading" spinner until the filterViewLoaded event occurs (which is not 100% at the end of the load process but it is close).

The example analysis button is disabled until the page is finished loading, to avoid triggering the state change before the app can handle it.

The 'tour' functionality is not yet implemented.

This replaces the 'loading saved state' dimmer used previously. The dimmer is only shown on map view - when loading a saved specific project in the project-view, no 'loading' page is shown anymore (the page loads quickly enough that I don't think we need it in that context).

[NealHumphrey]

@ostermanj the one thing that would be useful for you to QA (besides an overall test drive) is the way that I implemented the loading of an example. I used the decodeState to do this, so that the proper setState AND UI updates would occur. I did this by triggering the window history, and then telling the router to decode.

My question was whether I'm ok using the (useless) object that I put into the first parameter of the replaceState call. Elsewhere, you put the router.stateObj into this, but becuase the state has not been decoded we don't have a proper state object available to us anywhere. It looks like you're not actually using this state object though - it would just be used if you called popState as described here. It looks like you're always using the URL as the master of truth for the state to decode rather than using that state object. Some testing proved it out.

I will be adding the tour to this next, can merge either before or after this.

[ostermanj]

You're right that router.js passes in router.stateObj but that's not really doing the work. The work is all in the paths. My early attempts in router.js tried using the stateObj and popState but I could not get that method to work on a fresh load of a saved state. So instead it always just parses the url parameters. I had a better handle on it a month ago:

router.js sets the window's history.state but in the end this is not ever read back in. the history.state would only be available on browser back or forward, not on a fresh load of a paramified URL, so I opted to rely only on the encoded URL for forwards, backs, and fresh loads. This might avoid some cross-browser issues, too.

Hopefully that's true :)

You have to pass in an object, so I left it, but I think it could just be {}.

[ostermanj]

Looks really great! There's one weird thing: when I load the page without my developer tools open, the modal extends below my screen (1280x800) and won't scroll.

When I open the tools, the modal will scroll; when I close it again, the modal is fully visible.

The tour is really cool.

One thought: should we provide a "don't show again" option? Would require setting a cookie.

[ostermanj]

Approving. Positioning problem described in comments.

[NealHumphrey]

Thanks @ostermanj. I had a surprising amount of trouble getting the modal to behave as expected - maybe there's some bootstrap/semantic ui conflicts as they both have 'modal' classed objects. I'll mess with the modal to get it viewable.

I figured it's easier to not set the 'don't show again' option because it won't improve performance - they still have to wait the same amount of time for the page to load. I did verify that using both the in-app back and the back button after viewing a project page only display the modal the first time you see the map view and not again (unless you refresh the page)