search

sfu-natlang / lensingwikipedia

Lensing Wikipedia is an interface to visually browse through human history as represented in Wikipedia. This the source code that runs the website:
http://lensingwikipedia.cs.sfu.ca
Other
11 stars 4 forks source link

Storyline and facet views inter-operation #168

Closed theq629 closed 8 years ago

theq629 commented 9 years ago

Split from #151.

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

  • @anoopsarkar in #151
theq629 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

theq629 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

theq629 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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.

image

theq629 commented 9 years ago

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

anoopsarkar commented 9 years ago

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

anoopsarkar commented 9 years ago

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

theq629 commented 9 years ago

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 commented 9 years ago

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

theq629 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 notifications@github.com 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 https://github.com/sfu-natlang/lensingwikipedia/issues/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 https://github.com/sfu-natlang/lensingwikipedia/issues/168#issuecomment-109502901 .

theq629 commented 9 years ago

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 commented 9 years ago
  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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

anoopsarkar commented 9 years ago

can we merge with master now?

theq629 commented 9 years ago

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 commented 9 years ago

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 commented 8 years ago

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.