Storyline and facet views inter-operation

[theq629]

Split from #151.

we can go ahead with adding Facet constraints in the Storyline view for each selection done in that view.

• @anoopsarkar in Experimental facet code refactoring #151

[theq629]

I was going to start on this, but I realized I'm not sure I understand. Is the idea to add facet constraints from the storyline drop-down box, so that the selections in the storyline drop-down both add constraints to the facet and a line to the storyline view, whereas selections in the facet only add a constraint?

[anoopsarkar]

Yes, and perhaps vice versa as well where a facet constraint can be reflected as a selection in the drop down menu in the storyline view and a line as well. like we do in the comparison view now, we can have an update button in storyline to avoid triggering an update automatically for the storyline view when selecting a constraint in the facet view.

[theq629]

So it should work similarly to the behavior before the storyline dropdown was added, except that there will now be two places to add constraints (and an update button on tge storyline side)?

[anoopsarkar]

Yes, but keep the storyline drop down to avoid having to switch to the facet view.

[theq629]

After planning the implementation, I'm not entirely sure that I think having both constraint adding and an update button in the drop down is a good idea. This means that if the user hasn't clicked update since making constraint changes elsewhere, clicking on a new item in the drop down may have an effect (like leading to empty results) that isn't obvious from the dropdown itself.

Also, in the other views the view settings (the things in the respective bars at the top, basically) never add constraints, just change what the view shows. Constraints are always added from the visualization itself. So I wonder if it would be better to leave the dropdown as it is (or add an update button if that's better) and instead have the constraints that show up when you click an entity line be facet constraints instead of a separate type.

[anoopsarkar]

Yes, let's do an update to reflect facet constraints into the dropdown list and create a facet constraint for entity line selections. What about selection of reference point clusters? Can they be map constraints? That would make things a lot easier to navigate.

[anoopsarkar]

Also, what do you think about the right hand side placement of names that is currently in the Comparison view as a possible change to the Storyline view?

[theq629]

Ok, I'll have it add facet constraints on entity line selections. I think it can be the same for map constraints, but it may be more confusing since storyline clusters are multiple map constraints.

As for the right hand side placement, I'm not sure. It would be easy to do and it is visually cleaner, but personally I can't tell which label is for which line in the comparison view. Are you able to?

[anoopsarkar]

the mouseover on the line or the names provides the linking. once you are used to it it is fairly easy to use. also selection can be done on either line or name.

[theq629]

The update button is running on my live wikipediahistory demo. Note that this is basically two changes:

• The storyline entity menu uses the facet's context query rather than the global query (like pre- Decoupling storyline and facet views #141 behavior)
• Instead of using that query directly, it makes a copy each time the update button is clicked.

[theq629]

And I'll work on switching the names to the style of the comparison view, that makes sense to me now that I understand it.

[theq629]

The changes except for the map constraint generation are all in the storylinesidekey branch. That is

1. There is an update button.
2. The entity line titles are in a side legend like the comparison view.
3. Entity line clicks make facet selections.

I've refactored the facet code a fair bit to make (3) possible without too much mess. See #183. I'll do the same to the map view to add the map constraint generation.

No demo due to the current server setup.

[anoopsarkar]

I tried it locally. I like it. However there is some change blindness when I mouse over the line and the entity is bold faced, I often don't see which name is in bold since I miss the transition. Is it possible to increase the font size of the entity during the mouse over event?

Also the first time I tried the Comparison after I used the Storyline view the rhs list disappeared in the Comparison view but if I do not load up Storyline then it is fine.

The second time I tried the Comparison view first (for top 5 people) and then went to Storyline and made a selection. Then when I come back to Comparison and switch from person to location and things go crazy in the rhs list.

[theq629]

Demo now running at http://lensingwikipedia.cs.sfu.ca:9000.

[anoopsarkar]

I don't see the Update button in the Storyline view.

[anoopsarkar]

I confirmed the above bug about the Storyline view interfering with the Comparison view no the server as well.

[theq629]

Yes, I realized the update button was actually in a separate branch, and that's from before the move to web/, so I'm going to have to do some sort of very manual merge. That part is still running at http://champ.cs.sfu.ca/WikiHistory/latest/whoosh/wikipediahistory/.

The bug with the comparison view legend should be fixed now, but keep an eye out for further problems in case I missed some case -- basically the comparison view had been selecting the element by class globally, so when I used the same class name in storyline it got the wrong element.

I can make the moused-over text in the legend, but unless the line hight is also increased the items will jump around. Another option might be having a box of the appropriate colour that hovers next to the moused-over item.

[anoopsarkar]

About the change blindness, try the box or try something simple that works for you.

[theq629]

I merged the update button into storylinesidekey. It turned out I'd already merged between file locations, so not as bad as I thought.

I made the legend items use background colour to indicate mouse-over. This seems like the most compact way, and I'm finding it's also clearer when I mouse over lines and nodes.

I also restored the visual indications of which entities are selected.

[theq629]

By the way, the manual query mode right now doesn't support adding constraints for entities that don't correspond to a facet. It's easy enough to fix that, but it may also be confusing for the user. Is it time to just get rid of the manual query mode?

[anoopsarkar]

Let's keep in text search as some find it very useful as a starting point to look for things that are not highly frequent.

Re: your comment above: the text search does add a new constraint for non-facet searches, right?

[theq629]

The difference right now is in what happens when you click on an entity line or legend label. If the field of the entity corresponds to a facet, then a selection is made in that facet. If not, currently nothing happens (since there is no facet to ask for a selection). So if you do a manual query for
eg "person:Hannibal, currentcountry:Tunisia", then you can add constraints of the person lines but not on the currentcountry lines.

It's easy enough add something to handle constraints on the other fields (borrowing the facet's selection and constraint handling code). So it's just a question of whether we want to keep manual query mode and then what is clear enough for the UI.

[theq629]

The easiest way to handle constraints on any field (versus adding specific constraint management code for the manual query mode) would be to keep abstract facets for each field, without having the facet UI attached. The abstract facet would just be the selection interface (#183) with pre-attached constraint handling.

If that was in place then we could also dynamic adding or removing of UI facets if we want that -- ie in the facet tab we could start with the facets as they are now but also have an option to add a new facet on any field.

[anoopsarkar]

I like this idea. It will be possible to add two Person facets and also any
facet that is indexed, right?

On Fri, Jun 5, 2015, 7:13 PM Max Whitney [email protected] wrote:

The easiest way to handle constraints on any field (versus adding specific
constraint management code for the manual query mode) would be to keep
abstract facets for each field, without having the facet UI attached. The
abstract facet would just be the selection interface (#183
#183) with
pre-attached constraint handling.

If that was in place then we could also dynamic adding or removing of UI
facets if we want that -- ie in the facet tab we could start with the
facets as they are now but also have an option to add a new facet on any
field.

—
Reply to this email directly or view it on GitHub
#168 (comment)
.

[theq629]

It would be possible in the facet interface to add two Person facets, but I'm not sure how to handle that in the storyline. Presumably in the menu we just show them as "Person (1)", "Person (2)", but what about a manual query on the person field?

What do you mean about indexed facets?

[anoopsarkar]

1. In storyline we could just have the list of entities shown that are in the union of the two selections. e.g. the same list we get now in the Person list when one does a text search for "person:Alcibades OR person:Hitler".
2. By indexed facets I mean indexed fields that are indexed by whoosh.

[anoopsarkar]

I like the background color, but can we make this consistent across Storyline and Comparison views? I assume they can simply share the same CSS.

[theq629]

For the manual query, the query itself isn't effected by having duplicate facets since it just passes the field names directly to the backend. But what happens when the user clicks on an entity line for person:Alcibades when there are two person facets? Anyway, I suggest we leave duplicate facets for when we actually do the dynamic facet adding interface, since it will take some extra work on top of what we need here.

Yes, it would work for any indexed field.

And I'm pretty sure I can have the comparison view do the same legend style (it's slightly more than CSS but not much).

[theq629]

The matching style for the comparison view legend is up now.

[anoopsarkar]

can we merge with master now?

[theq629]

Wait a bit, the changes for #183 are mixed in with this one, and some time soon I am really going to get back to finishing that up.

[anoopsarkar]

ok. please let me know. I would like some of these branches closed up before we slow down development on this project (I am hoping we can ramp up again with future funding).

[theq629]

Ok, I have pushed the changes to the storylinesidekeyclean branch. I believe it is working but please play around with a bit in case there is anything serious I missed.

I've added issue #186 for the abstract facets thing. For here the important part is that you can now click on any entity line, and can select non-facet entities from manual queries.

I was hoping to clean up the code for this view more, but on trying to do that it's too complicated to do without risking introducing bugs or changing behaviour. Given that we are slowing down development for now I think that has to wait.