Decoupling storyline and facet views

[theq629]

We will remove the coupling of the storyline view with the facet view, instead adding a new dropdown menu at the top of the storyline view which allows the user to select entities to include. Additionally, the storyline with start with an initial view which is the top entry in the dropdown menu.

Original discussion from #111:

@anoopsarkar:

Re: a default view for Storyline. Just like other views have a summary view that is loaded by default, the Storyline can have the most frequent entity in a facet. To make things clearer we can have a drop down menu in the Storyline view that can be used to select the entity (this will also avoid having to switch to the Facet view altogether).

So the top of Storyline would look like this:

{Clear Selection} {Person facet}(see 1) {Augustus [439]}(see 2)

[ Default Storyline view would be Person facet and most frequent Person ]

1: can be used to select other enabled facets (as it is done now) 2: the other elements in this drop down menu would be entities from the selected facet in (1) sorted by frequency. the user can select any of them without switching to the facet view.

One potential issue is that the frequencies and entities will change based on other constraints. But I think that information is readily available already to the Storyline view, isn't it?

@theq629:

Ok, I think that would work. Do the selections made in the main facet still change the storyline selection (and what's shown as selected in the storyline menu)?

@anoopsarkar:

No, I think we can decouple the Facet view from Storyline view entirely using this approach. That would give us more flexibility in the Facet view (as raised in #138)

[theq629]

I've put up the new interface in the mwhitneyrefactoring branch and my running demos. I haven't finished the facet code refactoring yet.

A major question with the current interface is how to handle entities included in the storyline view falling out of the menu as other constraints change. How does it sound if they are always added as zero-count items in the menu (similar to how the facets handle it), and then we add an explicit "no matches" message for the case where there are no events to make a storyline with since all entities don't occur under current constraints?

[anoopsarkar]

Yes, the solution above is consistent with how other views handle zero-counts created due to other selections. Go ahead with it. Does the new interface require facet code refactoring or is that a separate issue?

[theq629]

Ok, I'll work add that zero-count handling within the next few hours. The facet code refactoring doesn't matter for the interface, I'd just like to have them share code for the menu.

[anoopsarkar]

We don't have to wait for facet code refactoring in order to push this change to the Storyline view to master. Once you are done with zero-count handling, merge it and close this issue (and let me know).

[anoopsarkar]

Do we need a new issue for facet code refactoring or is it covered by an already open issue?

[theq629]

I was originally assuming it would be done with this issue, but since it looks like it doesn't need to be I'll start a new issue.

[theq629]

I've added zero-count handling and a no matches message. There is a pull request, if it looks ok.