allow for direct links to specific viz pages

[nickreich]

If I'd like to share a link to a specific plot, e.g. a specific set of drop-down and check-box selections, could those be encapsulated within a custom url? Say I want to send someone to the page with a specific set of models and a specific date chosen, I can't do that right now. There are a lot of knobs here (e.g. the axis limits?), so it might get too messy, but a way to specify an outcome, unit, interval, models, and date would be really nice so that the link could then be passed along to others to see and explore what you are looking at.

[matthewcornell]

Maybe something like the "quick query" feature (my term) that we added for forecasts: https://zoltardata.com/forecast/106743?unit=4725&target=3625#search . It's a kind of permalink, I suppose.

[nickreich]

Yeah, exactly.

[matthewcornell]

Question: Would you want to update the browser history with every click so that users can go forward and back? ( https://reichlab.io/flusight-eval/ does this). The possible problem with doing so is that the history could get pretty long - not a memory problem, but more of unnecessary work that would show up in the browser's back/forward dropdown menu. If we did not support history then the URL would still be updated with each click, but forward/back would not be possible.

[elray1]

I think we don't need to update browser history -- the main use case is probably sharing links to specific views, not necessary navigating with a back/forward button in the browser

[matthewcornell]

Regarding url parameter names and encoding, I suggest the following:

• as_of, interval, target_var: straightforward single-value encoding, no quotes
• model: encode each model in its own parameter with not quotes. this will result in duplicate "model" keys if more than one model is specified, but this is a valid use of params. there are two models in the example below
• task_ids: directly encode task ID names as keys, rather than within a "task_ids" object, say. this will work because the app knows names from task_ids passed in the options object. there are two task IDs in the example below - scenario_id and location

---

http://127.0.0.1:8080/dist/?as_of=2022-01-29&model=COVIDhub-baseline&model=COVIDhub-ensemble&interval=95%25&target_var=week_ahead_incident_deaths&scenario_id=1&location=48

-> Firefox parses these seven params as:

[nickreich]

Adding comments about possibly fixing the y-axis as part of this...

• Currently the implementation does not fix the y-axis range which means that a url does not encode all the parameters specific to a users current view.
• My understanding of the current behavior is that the yrange defaults to the min/max of any plotted data. E.g., here is an example where the y-axis range goes negative (to around -500) because there was one aberrant negative observation and goes up to over 1000 because that was the highest observation in the target data. But a more natural view for that particular date range would be something like (0,250).
• How to fix this? We have commented before on Slack that fixing the y-range can be a tricky business as there may be times where you may want the range to adapt as you use the arrows to move from one week to the next.

Draft statement of desired behavior:

• When the visualization loads in a browser for the first time (e.g., not from a specific saved url with a preset query), the current behavior (yrange is set to the limit of any plotted data) is a fine default. When you click forward or backward, the y-range remains the same.
• if a user does anything to change the y-range, e.g. by using the zoom, pan, or selector functions, then the y-range is then re-fixed to the user-specified range, and also stored in the url of the page so that is could be preserved with a copied/shared link. when users click forward/backward, that user-specified y-axis range does not change unless they manually change it.

[nickreich]

The updated functionality looks good to me. I'll note that I tried to manually change one of the dates and it ended up at a place with no data, and a very empty looking window. direct link

Maybe this is a separate issue, but we are maybe introducing the possibility of directly navigating to a place with no data to show, with editable urls?

[matthewcornell]

Good catch, Nick. Looking at the browser console I see the problem:

Uncaught (in promise) initial_as_of not in available_as_ofs: 2022-01-30

What's going on is that the program reads parameters (if present) from the URL and then validates them, same as is done with the initial options that are passed to predtimechart by clients like zoltar or Covid-19-Hub-Vizualization . I'm not sure how the offending as_of got into the URL parameters without manual editing (there may be a bug - Nick, maybe you can clarify how you got that as_of=2022-01-30?), but using the calendar and arrows, the closest valid as_ofs are 2022-01-29 and 2022-02-05.

As a solution, maybe we can have a bailout where, if the offending parameter was loaded from the URL, then all of the URL parameters are dropped. This would put the program into an initial "good" state, assuming the above options values were configured properly by the client.

[matthewcornell]

Following up, we decided to go ahead with the bailout, but it needs to inform the user of its actions and why.