dual constraints on same facet

[anoopsarkar]

If you add a Person constraint in the Facets view, say "Pyrrhus" then the current faceted browsing interface allows the user to switch easily between Pyrrhus and other persons like, e.g. "Antigonus". But it is currently impossible to add a joint constraint: "Pyrrhus" AND "Antigonus".

One way to do this might be to add a mouse-over on the text presented in the left column on entities to add constraints to the faceted browsing process.

[theq629]

Note that this will add more predicates (see my comments for https://github.com/sfu-natlang/lensingwikipedia/issues/26) in the SimpleDB select query and therefore may need a more scalable database to do well.

[theq629]

For the interface, it should also be easy to dynamically add or remove facets at runtime.

[ramtinms]

I have changed the code in the test branch to add ability for two constraints on same facet, In my code I am adding each one as a new constraint to query object but the query result is empty. I am sending something like this in JSON : Current country: Japan Current country: China

but the given result is empty, I am not sure that I am sending the request wrong or there is something in the back end, I am also trying to change gui for showing multiple selection (like checkbox).

[anoopsarkar]

did you use the command line query tool to check this type of query? if so, can you provide the exact query used and the command line invocation.

[ramtinms]

How can I use command line query tool ? Is there any tutorial for that?

[anoopsarkar]

in the backend directory, run 'querybackend' which takes a query file

the backend server URL is: ec2-54-226-84-88.compute-1.amazonaws.com

there are sample query files in the 'examplequeries' directory.

[anoopsarkar]

we should add a checkbox on all list items when one item has been selected already. if you click on the text you switch to a new constraint on the same facet, but if one clicks on another checkbox, the checkbox is marked as selected and a joint constraint as described above is sent to the backend.

[ramtinms]

It is done in ramtin-test branch , I test every buttons and facets , everything works properly now.

[ramtinms]

Dear Anoop , please check , I will send pull request for this and (#4).

[anoopsarkar]

Let's say I select "Italy" in location, and I want to switch to "Rome" as the constraint as I could before. How do I do that?

The proposal I had was to use the idea from Simile for adding multiple constraints in a single facet. e.g. go to:

http://simile-widgets.org/exhibit3/examples/senate/senate.html

Click on one constraint in the "Sponsoring" facet. Notice that a checkbox appears. If you want to add a new constraint in the same facet you have to click on the check box. Clicking anywhere else simply switches the constraint as was done before in our implementation.

[anoopsarkar]

The checkbox strategy does not address the issue of what the counts should look like.

In the current interface, if you select "United Kingdom" the count is 613 and for "London" the count is 623. Note that these counts are independent of each other.

in ramtin_test when I select "United Kingdom" I can search for "London" in that facet and the count is 20 since it is the intersection of the two constraints.

The question is which counts to show in the checkbox strategy as done in Simile?

Another option is to have a global option for each facet to change behaviour between the old version (what is currently in master branch) and the new version (currently in ramtin_test).

What do you guys think?

[theq629]

Is there a live ramtin_test running to try?

[ramtinms]

http://champ.cs.sfu.ca/WikiHistory/latest/test/

Ramtin Mehdizadeh

On Sunday, 20 October 2013 at 18:19, Max Whitney wrote:

Is there a live ramtin_test running to try?

— Reply to this email directly or view it on GitHub (https://github.com/sfu-natlang/lensingwikipedia/issues/46#issuecomment-26688160).

[theq629]

Thanks. It seems like the facet counts have changed even without using making multiple selections in the same facet -- eg if I select person "Duke" and location "Anjou" then most of the context in the facets is lost.

I also notice there are now zero counts in the facet list sometimes, eg in the above case there is a zero count current country "Italy".

[anoopsarkar]

Here is a better way to think about multiple constraints from the same facet.

We include a sliding toggle switch (see: http://www.bootstrap-switch.org/) to select between a facet view (so that the first click on the facet list will be the behaviour we see in the current version where we can switch to another selection as a facet) OR a view that will move the current selection to the top and create a sub-facet view in which the view will be as if the selection happened in another facet, so it will show only those items that can be intersected with the current selected constraint (this could be empty).

So the top bar which currently has "Clear Selection" will shrink and have a neighbouring toggle switch between Facets: On | Off.

The sub-facet view will be identical to the top level facet view. It should also have a "Clear Selection" and Facets on/off toggle.

In effect, this might replace any need for hierarchical facets (see Issue #2) by exploiting the graph structure of overlaps between facets.

[anoopsarkar]

I still like my proposal above. One additional details needed is to flesh out happens to the constraint listing on the upper left of the page.

I imagine the AND constraint (which serves as adding multiple constraints on the same facet type) to have scope issues with other constraints and so we would like to limit this scope interaction. The best way is to limit the scope interaction. For example, consider the Person facet. We choose X from this facet list to get a constraint [Person: X]. Now the typical behaviour is that if we choose Y from the Person facet list then we switch the constraint to [Person: Y] as faceted browsing should do. Now assume that we use a toggle switch (as explained in previous comment) to turn faceted browsing off. Now the Person facet list should only contain X and all other Person entities that are in events with X. Now a selection of Y from the Person list will create a new constraint [Person: X AND Y]. There has to be a nested toggle switch created for this sub-list to enable faceted browsing, for instance choosing Z would switch the constraint to [Person: X AND Z]. A toggle of the innermost switch would enable a new constraint [Person: X AND Y AND Z]. Toggle it back to get the previous constraint [Person: X AND Y]. We can also clear everything at the top level to remove the constraint on Person altogether.

[theq629]

I think the behavior with the toggle enabled sounds good, and like you say is probably a good way to approximate hierarchical facets without the added complexity.

But I'm not sure if I see the need to have the toggle at all; why not just have a separate place to click that adds to the constraint instead of switching it, like in the ramtin_test version but with the addition that the already selected values go at the top of the facet? That's similar to the interface proposal for hierarchical facets in #2, but uses a simple stack instead of the fixed hierarchy.

Keep in mind that the total constraint set is always a conjunction, so internally there is no need to represent the AND constraint but we can have the interface represent it however is convenient.

[theq629]

Or for another way to look at, if I'm understanding correctly the toggle isn't really disabling faceted browsing, but rather fixing the current selection as a new constraint and changing the associated facet to be the values given that constraint (just as if the a selection had been made in another facet). So unless I'm misinterpreting that, it sounds like it it's more of an add/remove button than a toggle between two modes.

[ramtinms]

Here is my idea about this part : https://docs.google.com/document/d/1IAT1y0yVWxwMUugB9NZWDW9kg-64FTsxw84a9J0Ir7E/edit?usp=sharing

[theq629]

@ramtinms I like that if the goal is just to produce constraints, but if we still want to emphasize discoverablily then I'd be concerned that it hides the facets too much.

[anoopsarkar]

Exactly. One view shows alternatives (switches to new constraint) and another view shows only those items that can be added as a new additional constraint (as if the selection happened in another facet list). my initial mockup had a toggle per item in the list but I thought a single global toggle would be cleaner and use less screen real estate. On Feb 21, 2014 12:12 AM, "Max Whitney" notifications@github.com wrote:

Or for another way to look at, if I'm understanding correctly the toggle isn't really disabling faceted browsing, but rather fixing the current selection as a new constraint and changing the associated facet to be the values given that constraint (just as if the a selection had been made in another facet). So unless I'm misinterpreting that, it sounds like it it's more of an add/remove button than a toggle between two modes.

Reply to this email directly or view it on GitHubhttps://github.com/sfu-natlang/lensingwikipedia/issues/46#issuecomment-35707070 .

[anoopsarkar]

I like this the @ramtinms alternative as a design for a responsive version for small screens like mobile phones. We still need the toggle or something like it to show which items are co-occuring versus which are alternatives.

[theq629]

Ok, in that case I like it but I still think it's clearer if it's presented as an add or drill down (like in the #2 proposal) button rather than a toggle.

[anoopsarkar]

Can you mock up what it would look like?

[theq629]

Crude mock up: http://bl.ocks.org/theq629/9203588

The ">>" button would push a new item into the constraints (the selected item in the left version or the item clicked on in the right version). Then the item goes into the list at the top. You can remove any item from the list at the top with the "x" buttons.

[ramtinms]

What is the difference of left version and right version?
Here is our first problem with dual constraints : Right now we have a list on a facet (with all possible choices), So we can change our selected facet and see how it change other facet list.
But if we let user to select two constraint from the same facet, the list should just shows options related to both of selected items.

Lets define two type of constraints selection : 1st. By “>>” (And mode) 2nd : list selection (possible options) My understanding from your mock for solving this problem is: When the user clicks on “>>” in front of each option , we should add it to the top part and update the list with options related to that constraint. But if the user just clicks on the item in the list , it will work like before.

Question is that if the user have selected a constraint from a list and then add another constraint by “>>”. It is possible that the 1st constraint is not available in the updated list. What is better for solving this. ( In ramtin_test version If someone clicks on “>>” button it that constraint is also selected in the list. )

Ramtin Mehdizadeh

On Monday, 24 February 2014 at 23:22, Max Whitney wrote:

Crude mock up: http://bl.ocks.org/theq629/9203588 The ">>" button would push a new item into the constraints (the selected item in the left version or the item clicked on in the right version). Then the item goes into the list at the top. You can remove any item from the list at the top with the "x" buttons.

— Reply to this email directly or view it on GitHub (https://github.com/sfu-natlang/lensingwikipedia/issues/46#issuecomment-35981641).

[anoopsarkar]

I like the left version for various reasons. But here are some comments which I think also address Ramtin's comments:

1. I don't see the need to keep the constraints [decider x] and [declarer x] on top of the facet list. We can continue to keep them in the global list of constraints on the upper left corner. So it would be [Role: decider x] and [Role: declarer x] that get added to the list of constraints as we do currently. All things being equal I would prefer to keep that part of the interface the same as before. So unless there is a compelling reason, we should not switch where the constraints are shown.
2. When we pick a constraint [Role: decider x] we want two different ways to view the Role facet.
   • The usual faceted view in which we can switch to a new constraint that replaces the old Role facet (no change needed here, this is what happens now)
   • A view in which we want to add a new Role constraint in addition to the one already selected. The selection should not allow a choice which leads to empty set of events. So we toggle the Role facet to show only those choices that can be added. Right now it would be done as in your left choice in the mock-up (I assume) but I would argue that it would look better as a toggle button: Facets [on|off]. When Facets are toggled off, we can choose a new Role constraint to add to the left upper corner, e.g. we can add [Role: thing_decided x] which in this example will not change the number of events, but will be a new constraint. Note that selecting multiple roles will be more suited to some facets than others, e.g. it would make more sense in selecting multiple Categories.
3. Let us consider more than 2 constraints selected from a facet. let's say [Category: A] and then we choose [Category: B] and then [Category: C] so the events shown will belong to three wikipedia categories A, B, C. The Category facet shows those additional categories that co-occur with A, B, and C. There are three things to consider:
   • unordered removal of constraints: what happens if we remove [Category: A] for instance? if the Facet toggle is Off then it is easy: we show all events consistent with [Category: B] and [Category: C]. If the Facet toggle is On then it is not so easy: the most reasonable thing I think is that we show all events consistent with [Category: B] which is the constraint added the earliest after we remove [Category: A]. A selection from the Category facet will replace [Category: C] with the new selection.
   • toggling the Facet choice: so we have constraints A, B, C in the Category facet and we toggle Facets from Off to On (note that we must have Facets to Off to select Category C) then just as above we show all events consistent with [Category: A] and [Category: B] and a new selection will replace [Category: C] with the selection from the list in the Category facet.
   • the other facets (apart from Category) will show choices consistent with the events that have Category A, B, and C. choices in other facets work just as before (I think).

[anoopsarkar]

For point number 3 above, we can add a constraint that looks like a hierarchical facet constraint from Flamenco:

• [ Category: A [x] >> B [x] >> C [x] ]
• Removing B as a constraint would give us [ Category: A [x] ] which are the events that have A as the wikipedia category. Notice we do not get [ Category: A [x] >> C [x] ] which should make it easier since we do not have to compute counts for events with A and C categories. I'm not sure this is a significant advantage. @theq629 can comment on this being more familiar with the query system.
• Starting from [ Category: A [x] >> B [x] ] and then toggle Facets to On for the Category list and selecting D from the Category list would give us [Category: A [x] >> D [x] ] which are the events that have both A and D wikipedia categories. notice that B was replaced by D in the constraint.
• If instead you toggle Facets to Off for the Category list and selecting D from the Category list would give us [Category: A [x] >> B [x] >> D [x] ] which are the events that have A, B and D wikipedia categories.

[theq629]

@ramtinms

The two versions are just for where we want to put the ">>" button (and whether it works on the current selection or whatever item is is next to). I find the right version slightly more obvious, but the left cleaner and easier to extend if we for example want to add hierarchical facets to the same interface.

That's right for how I was thinking it would work.

Isn't the first selected constraint always available in the list after another selection? So actually we could skip the selection list above the facet and just show all items in the constraints with the selection colour.

@anoopsarkar

For 1., the only I reason I see to keep the constraints show above the facet is that it fits with the constraints being fully visible on the map and timeline views as well as the current facets. But see above.

Could you also do a mock up of the toggle version?

For the Flamenco-like constraints, why would we need to compute counts if sub-constraints can be removed independently? As long as the sub-constraints are a conjunction then how we present them is just an UI issue. If there isn't any special reason then it seems cleaner to me to not present them hierarchically and allow the user to remove them in any order.

[theq629]

After thinking about it more I think I understand how the toggle version works (although I'd still like to see a mock up if that's possible; you could start from my HTML for my mock up if that's convenient: https://gist.github.com/theq629/9203588).

I still feel like having a model interface would be more confusing (especially if the content of the facet changes depending on the mode, as you note in the first bullet for point 3.) without gaining much. But it's definitely possible I'm just still trying to think in terms of the plan from #2. It might be worth surveying some other lab members to see how easy it is to explain both versions.

[anoopsarkar]

@theq629 did you mean modal rather than model?

[anoopsarkar]

The modal interface I sketch above is essential since we want our interface to do two different things:

1. show alternatives to current selection (what we have now)
2. show additional choices in current facet list that can be added as an AND constraint in addition to the current selection

Since we need the list to do two things, we have two options: show two different lists (I think this is what @ramtinms was suggesting) or show one list with a toggle switch (I think this saves screen real estate and solves the problem above).

I'll try to modify your html to do a mock-up but it will probably take quite a while for me.

[theq629]

Yes, I meant to say modal. Aren't the two views just the same except for what happens when a selection is made, though? (And maybe filtering out items that would lead to no results in 2.)

I can do the html part if you want to send me an image or something instead.

[theq629]

So for the counts: currently the counts for facet f is based on running the query (global constraints \setminus constraint for f), or just the global query if there is no selection producing a constraint for f. From the query the backend collects the counts for each facet item i.

With the non-toggled version or the toggled version with facets on, the count is presumably from (global constraints \setminus last constraint for f), that is we treat the most recent constraint for the facet (the constraint that would be changed by a new selection) just as in the current version, but previous constraints are treated as though they were for a different facet.

With the toggled version with facets on, the constraint is just (global constraints)?

[theq629]

If what I said above is correct then I think I understand the toggled version and can start implementing if that's the one you want (although we may need to discuss again when we get to the removing constraints part).

[anoopsarkar]

I presented the toggle idea to the lab during yesterday's lab meeting and the consensus was to simply replace the current behavior with the new behavior. No toggle required. The only disadvantage is that the user needs an extra click to remove and add a constraint to replicate the current faceted behavior. But the interaction seems more predictable to them. I see their point.

The original idea of faceted browsing was to organize the results of the search in different ways based on the facet selected. It will be interesting to combine that idea (which we have as the behavior now) with some NL summarization of those events on the left pane. This would be a way to retain faceted browsing but make it more relevant to this domain.

So what do we do now? I think we should implement the "toggle: off" behavior. We can have a program option to switch behavior rather than a user toggle.

In this simplified interface perhaps control-click can give us OR instead of AND. These would go into a single constraint, [A OR B x] on the left pane.

Removing constraints out of order on the same column might be an issue, although I cannot see any obvious problems right now.

[theq629]

Ok, in that case let's try the simplified interface with "toggle: off" behavior first and then see if it needs more improvements.

For adding OR constraints, I think that's doable although we'd have to add backend support. However, for the interface what happens if there are more than two constraints?

[anoopsarkar]

For OR. We already can type in location:India OR location:China in the text search window. The constraint added when we do that seems like the right one for when using control click selection on the facet list.

[theq629]

For the backend, it's just that right now we use direct json queries for the facets rather than the text format. We might be able to switch everything to text queries now (with slight performance loss), but at least we need to make sure stemming and so on is disabled for facet queries.

For the interface, I mean what happens if you say select one item, AND add another, and then OR add another?

[anoopsarkar]

Ok. In that case let's just do the AND for now. For OR we will need to use setminus again so we're back to the toggle idea. Let's do AND and decide about OR subsequently.

[theq629]

I've got an initial version in the facetsmulticonstraints branch and live at http://champ.cs.sfu.ca/WikiHistory/latest/whoosh/full/. No grouping in the constraints list yet.

There is a global setting facetDefaultIsConjunctive to switch the multiple selection mode. It is on by default and can be changed in the settings file or on the console.

[anoopsarkar]

Looks great. Should we provide a toggle switch to enable/disable facetDefaultIsConjunctive on the (it would clear all constraints first). We can create a new tab called "Options" for this. This will be mainly as a convenience for us when we give demos rather than for users.

[theq629]

Do you think it should be global, or separate for different facets? (The code already has an internal variable per facet, just no control to switch them individually after building.)

[anoopsarkar]

I see. How about a toggle for each facet. Can that be done easily?

In either case, I think it should be hidden away in an Options tab because I think it is likely to be confusing to first time users.

If this is going to take too long (more than a day) then I think we should just merge what we have now with master and put it on the agenda and move on to other things.

[theq629]

It probably would take more than a day to clean up enough (eg we'd likely want some small visual difference to indicate which mode a facet is in). Shall I do the constraint list grouping before the merge, though?

[anoopsarkar]

Do we need constraint list grouping for simple AND constraints? On Mar 17, 2014 5:44 PM, "Max Whitney" notifications@github.com wrote:

It probably would take more than a day to clean up enough (eg we'd likely want some small visual difference to indicate which mode a facet is in). Shall I do the constraint list grouping before the merge, though?

Reply to this email directly or view it on GitHubhttps://github.com/sfu-natlang/lensingwikipedia/issues/46#issuecomment-37888704 .

[theq629]

Not really, if you think it is ok already then it's not needed.

[theq629]

I've just made the pull request. If you think it's ready then go ahead and merge. In any case it may be better to use the new interface for a while and then raise new issues when we have a better idea of what we need to add.

[anoopsarkar]

I think we can close this issue.