Re: [VuFind-Tech] Facet functionality enhancements

[Demian K. <dem...@vi...>]

Sounds like we have a clear path forward for points 1 & 3, so that's a good place to start doing some work!

Regarding point 2, you are correct that the relationship becomes less explicit, but if we're only showing one level of the tree at a time, I'm not sure if it matters.  That is, if you have faceted down to Audio, you're probably going to filter out all the second-level values that are not applicable anyway.  (I realize that there could be some records where both audio and video facets apply, so there might be handful of DVDs showing up as an additional limit...  but such records are the exception rather than the rule, so CD should be much closer to the top of the facet list).  Although using delimited strings in the facets gives you a bit more control than this, it also puts a lot more responsibility on the PHP code, and this functionality is the sort of thing that should ideally be handled by Solr itself.  If there really is no satisfactory way to achieve this in Solr, I'd certainly be willing to consider the delimited string approach... but in my experience, solutions involving delimited strings tend to be complex and brittle, so I try to stay away from them if native mechanisms can be used instead.

And yes, the UI is definitely the big challenge on VUFIND-177.  As you say, we should keep the scope under control and do this one step at a time.  Perhaps the path forward on complex facet application is to first implement the server-side capabilities (i.e. figure out parameter names to apply NOT and OR facets on the URL, then implement all the necessary changes to the Solr communication) and worry about the UI for actually setting those values later.  I don't think there's going to be a single obvious UI solution, so implementing the back end first allows different VuFind users to experiment with different UI approaches before we actually commit to something official for the trunk.  (And, of course, since the facets are rendered by a recommendation module, we can always create a set of alternate modules for people to choose from).

- Demian

From: Kauler, Leto S (DoE) [mailto:Let...@ed...]
Sent: Wednesday, May 09, 2012 9:18 PM
To: Demian Katz; vuf...@li...
Subject: RE: Facet functionality enhancements

Cheers for the feedback.


1)      I agree that option A is better for long-term.

2)      The only problem with using multiple fields is you lose the relationship between parents and children.  It's ok for dewey I presume because the fields would contain like 6XX, 61X, 612 so the path is inherently available.  Consider this situation where a record contains:
Level 1: Audio;  Level 2: CD
Level 1: Video;  Level 2: DVD
If you select Audio then you would be presented with both CD and DVD from Level 2.  Pivoting may help?  I haven't really experimented with it.

3)      Yes there should be a configuration to trigger the new behaviour.  We would point the "more" link to the browse page/action but the event will be captured by javascript-enabled client to open it in a lightbox.  I'd like the keep the scope under control for now but there is definitely potential to expand on its use later.

I've not spared any brain time re. VUFIND-177.  I think the biggest issue is the UI.
//Leto

From: Demian Katz [mailto:dem...@vi...]
Sent: Wednesday, 9 May 2012 11:35 PM
To: Kauler, Leto S (DoE); vuf...@li...
Subject: RE: Facet functionality enhancements


1.)    Individual facet settings - either approach seems valid to me.  Initially I thought it might make the most sense to use suggestion A, since other modules (like the Summon implementation) could also benefit from the same features...  then I noticed that the Summon module already supports this feature through Summon-specific syntax.  This leads me to two different possibilities: either go with suggestion B, since it's easier to code and we've already set a precedent of using a service-specific syntax, or else try to reconcile the two modules, either by adding support for the suggestion-A syntax in the Summon module or by borrowing the Summon syntax (a comma-separated list of parameters following the facet name) in the Solr module.



Okay, maybe that's not very helpful - I've just added another option rather than helping you make a decision.  I guess for now I lean toward option A, with the intention of fixing the Summon module to match - it's probably better to have consistently designed config files even if it adds a little bit of code complexity.

2.)    I gave a bit of thought to hierarchical facets a while ago, and I came up with a slightly different approach - rather than having a single facet field with a delimiter, I thought it might be useful to use multiple facet fields, one for each level of the hierarchy.  I was thinking about this in the context of call number faceting: right now, for example, we have separate facet fields for different levels of call number granularity - i.e. dewey_hundreds, dewey_tens, dewey_ones.  It might be useful to show the dewey_hundreds facet first (the high level view), but replace it with dewey_tens after a user selects one of the hundreds values...  and then if they select a tens value, we start displaying the ones values.  I think using multiple fields rather than a delimiter makes for simpler indexing and display code - and now that VuFind has dynamic field definitions, it should be possible to create an arbitrary number of levels without changing the schema.  The other advantage to keeping the fields separate is that, once Solr 4.0 is released, we may be able to use pivot faceting (http://wiki.apache.org/solr/SimpleFacetParameters#Pivot_.28ie_Decision_Tree.29_Faceting) to create a tree of facet options.  For now, though, I agree that showing one level at a time seems like a sensible starting point.

3.)    I like the idea of the facet lightbox, though I think it would be wise to make it a configurable option in case others prefer to stick with the current interface.  Presumably by creating a new action that displays in a lightbox, you also allow deeper facet access for users without Javascript (a small number, I realize, but a group we try to support for accessibility purposes).  For now, I think the limit+1 approach for paging is the best option - I like to use standard Solr distributions in the VuFind trunk - but it's good to see that a patch exists which may someday allow better facet pagination.  I also wonder if the facet lightbox approach could be used to offer more user options: i.e. "exclude this facet," "select either of these two facets," etc., etc. - it would be nice to be able to apply facets in more ways than the current default "AND" approach.  Perhaps this work can be tied in with the existing "or facets" patch on VUFIND-177.  But that's probably something for another day!

- Demian


________________________________
CONFIDENTIALITY NOTICE AND DISCLAIMER
The information in this transmission may be confidential and/or protected by legal professional privilege, and is intended only for the person or persons to whom it is addressed. If you are not such a person, you are warned that any disclosure, copying or dissemination of the information is unauthorised. If you have received the transmission in error, please immediately contact this office by telephone, fax or email, to inform us of the error and to enable arrangements to be made for the destruction of the transmission, or its return at our cost. No liability is accepted for any unauthorised use of the information contained in this transmission.