Think about generalizing plot types TimeChart

[matthewcornell]

This is a higher-level question. When I met with our Thai visitors at UMass re: features, they want to plot additional things, such as a second baseline, and a nowcast that's in addition to Actual, Observed, and History. (They will be adding three issues for them.) Part of that is wanting a kind of baseline that is not a straight line, but still shows as dashes. However, it strikes me that we might want to generalize plotting to be more flexible, rather than continuing to add one-off features. It seems like we have these variables:

• Two kinds of plots: ones with points, and straight lines.
• Two legend positions: top (Actual, Observed, etc.) and bottom (models).
• Two line types: Dots or dashes.

It could be that I'm on the wrong path here, or the features are already there...

[lepisma]

Features are not there right now.

The changes will go in two places I believe:

1. The classes (for baseline, actual line etc) need to take more arguments to modify their appearances. This should be easy.
2. The main constructor should allow more than one of these items. Might need some planning but the code changes will not be a lot.

What do you mean by the legend positions? Do we need to split the current legend? Or do we need to allow repositioning it? In any case, do we need a generic solution for arbitrary repositioning?

[nickreich]

I think by legend positioning, @matthewcornell is talking about whether a particular line/model could be designated as a line that is in the "top" of the legend, or in the "bottom". e.g. if we have some baseline model a user might have an aesthetic preference to include that model in the top of the legend, near the "actual" and "observed".

[matthewcornell]

@nickreich is correct. For example, http://flusightnetwork.io/ shows the three vertical legend sections as I see it:

----
Actual
Observed
History
----
CI
Show
----
FSNetwork-TTW
----

My thought is to allow users to place items in either the top or bottom sections.

[lepisma]

For legend positioning, I was thinking if we could allow full repositioning of any of the rows involved, including CI, Show, Actual etc. But that will make the config option passed really messy since it will have to handle ordering of all kind of items.

So right now (v0.9.8), I added an option to pin a model. This moves the model to the top section (KDE in the image below)

To make this section (of pinned models) look different, I can either shade it or draw a thin separator above it if needed. Let me know if this pinning thing is sufficient.

[lepisma]

To make a model pinned, we need to add another key in the data like below:

      id: 'mod',
      meta: {
        name: 'Name',
        description: 'Model description here',
        url: 'http://github.com'
      },
      pinned: false, // Setting true shows the model in top section of the legend
                     // In case of absence of `pinned` key (or false), the model
                     // goes in the bottom section

The key is optional and defaults to false when not present.

[lepisma]

A better design would probably also allow dynamic pinning (as we have in web browsers).

1. We start with the states as defined by the model's pinned key value (or its absence).
2. When hovering on a model row, we can make the circles on the left work as pin (or unpin) button.

Another implementation might just allow dragging and repositioning.

Although it might not be that useful in our case. Thoughts?

[nickreich]

I like the option as implemented and don't think we need dynamic pinning for this usecase.

[nickreich]

I think we can close this now based on the comment above about the pinnedoption, but @lepisma I'll leave it to you, just because I'm not sure if this is fully implemented yet or not.