It is nice that you can configure the number of facets in facet blocks, but it is frustrating if the facet you're looking for isn't in the block. We should consider an AHAH interface for getting to the facets further down so that none are unreachable.

CommentFileSizeAuthor
#25 solr-facets-modal.png134.94 KBAnonymous (not verified)
#19 improve-list-348215-19.patch1.76 KBpwolanin
#17 apachesolr.patch8.44 KBvladimir.dolgopolov
#10 apachesolr-348215.patch3.68 KBvladimir.dolgopolov

Comments

janusman’s picture

janusman commented

Oh yes, +1 for this.

A strategy might be this.
* Ask ApacheSolr for N+1 facets in the request, where N is the user-configured # of facets to display per vocabulary.
* If the number of returned facets == N+1, then show a "more" link which would load more facets via AHAH

How the "more" link would work:
Option (a) Paging in block: let user page through all facets inside the block. (useful if you have say 50 facets for the current query)

Option (b) Block shows N*X number of facets (say, N*3) and an "even more" link could go to a page listing** which could then have paging.

**Would the ApacheSolr Views integration help out with (b)? I am currently unfamiliar with it, but will surely look into it.

pwolanin’s picture

pwolanin commented

For paging in a block, we'd really have to limit the functionality to those with JS. There would not be a reasonable fallback for non-JS that I can imagine, unless we want to include some of block paging info into the GET string, and non=JS would link to a new page like a normal pager.

janusman’s picture

janusman commented

@pwolanin: Then it would be (a).. paging available, but only for JS-enabled browser.

Those without JS would get directed to a "browse" page. IIUC, that requires some rethinking of the search class, like you mentioned about in IRC.

pwolanin’s picture

pwolanin commented

@Janusman - I made one finding - we can actually find facets on the whole doc set by using q.alt with dismax. However, that's more relevant to facet navigation than facets on search.

anarchivist’s picture

anarchivist commented

+1 for this from me too; subscribing. There's a chance we could throw some developer time at this at MPOW as well.

pwolanin’s picture

pwolanin commented

Jacob suggests that we should just request 20 (or maybe 15?), put them all in the block - then hide via CSS those > 10 and show with JS if the user clicks the link

Doing a separate request is probably a real waste. We would be loading Drupal + Solr, when it's probably harly any extra overhead for Solr to send more back on the initial request.

robertdouglass’s picture

robertdouglass commented

Well, it's hard to measure. If people ask for more facets 1 time out of 100, then we're sending a bigger payload from Solr->Drupal->Browser (two trips) 99 times (with Jacob's proposal). Just a counter argument.

janusman’s picture

janusman commented

I think both robert and peter are right, but "it depends". =)

I prefer user-fired requests for more facets instead of always fetching "more".

Cons:
* more complex code

Pros:
* We save overall bandwidth and is quicker (most of the time fetching N facets vs. pwolanin's always getting >=N*2)
* Getting to do the code to support this also paves the way for doing more stuff with facets (like some sort of Browse navigation)
* Also more convenient if we AJAX-page each facet block, as the User can actually view all of the facets from within the any search results page.

robertdouglass’s picture

robertdouglass commented

Here's a site taking Jacob's approach of hiding extra facets and then revealing them with jQuery: http://ethicshare.org/publications/ethics?sc=publications

vladimir.dolgopolov’s picture

vladimir.dolgopolov commented
Status: Active » Needs review
StatusFileSize
new apachesolr-348215.patch3.68 KB

Here is the patch.
1) request N*2 facets
2) each facet block has a 'more/less' link to expand/collapse the second half
3) has a new file apachesolr.js

pwolanin’s picture

pwolanin commented

This doesn't look quite right - probably making it two separate lists will cause a visual break in some browsers or in some themes.

janusman’s picture

janusman commented

To me the problem is "the user will not *ever* get to see all the facets resulting from certain searches".

1) the original request mentioned "We should consider an AHAH interface for getting to the facets further down so that **none are unreachable**"
2) With the proposed patch, we're still getting "just" N*2 facets; what if the wanted facet is N*2 +1 ?

Instead of the patch there is a much simpler solution (perhaps not as pretty?), using CSS: limit the block's content height, and add overflow:auto so that a scrollbar shows. Like so:

.block-apachesolr .content {
  height: 10em;
  overflow:auto;
}

So, yes, the patch would help (thanks!) but not actually solve the basic problem (in my point of view)

I'll better get coding and shut up now =)

robertdouglass’s picture

robertdouglass commented

I see myself falling in janusman's camp here. What's wrong with an AHAH callback?

pwolanin’s picture

pwolanin commented

@Robert - right now, I think we wanted to just get a really simple implementation working. I think we should postpone the refactoring necessary to handle the callback until after we have re-worked the facet code so that we only handle the active facets.

JacobSingh’s picture

JacobSingh commented
Status: Needs review » Needs work

@janusman: If you feel really called to write the AHAH stuff, I encourage you to go for it, although as pwolanin notes, we are pretty coupled to hook_search and this would need to change first before we did it. We (Acquia) decided it was not worth the engineering time, and made the module a little more complicated, but I think if you did the work, and it was really effective, we'd be okay with you committing it. Also, that approach is by default not accessible (unless you do a full page refresh).

We choose the # desired times 2 because typically a user will not need to see more than 20 (the default) number of terms and this makes it flexible. If the admin feels like 25 terms are needed, set the default to 13. This seems like a reasonable default, do you have another suggestion here?

In regards to the patch in question:

Using block height is not sustainable (can't count on that). It also not accessible because people without JS would never see the hidden ones.

The proper implementation (without the AHAH work) is to show a reasonable number of terms, and then use JS to hide the 2nd half on load and show the more button. This way, a user without JS would just see the entire list, with no more button.

The way this was implement is incorrect though. There should only be one list, and for the

  • 's which are greater than the number of terms to show initialy, they should get a class like "hidden-facet".

    The JS on load would like $("#whatever-block-i-am").$(".hidden-facet").hide() ;

    The JS on the more link would be something like $("#whatever-block-i-am").$(".hidden-facet").show(); $("#whatever-block-i-am").$(".more_link").hide();

    Does this make sense? Vlad, can you re-do your patch with this approach?

    Best,
    Jacob

    • pwolanin’s picture

    pwolanin commented

    One way to improve the simple approach here is that each block we should be able to specify in each block's configuration both the # of facets to show initially and set how many additional facets to retrieve and hide. The would get around the inflexibility of just retrieving 2x the number every time.

    vladimir.dolgopolov’s picture

    vladimir.dolgopolov commented
    Status: Needs work » Needs review
    StatusFileSize
    new apachesolr.patch8.44 KB

    Here is a new patch.
    1) used one ul list with hidden items.
    2) rewrote apachesolr.js. Not sure the if-condition here is optimal. Maybe jQuery masters give a more proper way:
    if ($(this).prev().find('.apachesolr-hidden-facet:visible').length == 0) {}.
    3) There is a new setting per block: Facet Query Initial Limit (from #16).
    4) I not sure the link 'more' should be hidden. I replace the text with 'less'.

    JacobSingh’s picture

    JacobSingh commented
    Status: Needs review » Patch (to be ported)

    I made a couple changes language on the block config page and committed.
    I think we'll probably refactor this a lot as we move to a unified facet block building setup, but for now it's working okay.

    Nice work Vlad!

    pwolanin’s picture

    pwolanin commented
    Status: Patch (to be ported) » Needs review
    StatusFileSize
    new improve-list-348215-19.patch1.76 KB

    The js file was never added to CVS - I jsut added it with minow text changes to the links.

    Also, here's a cleanup of the list code. theme('item_list') expects a numerically indexed array - so with this patch, the 1st hidden item was getting the "first" class, ratehr than thte first item in the list.

    pwolanin’s picture

    pwolanin commented
    Status: Needs review » Fixed

    committed to 6.x

    pwolanin’s picture

    pwolanin commented
    Status: Fixed » Closed (fixed)
    Anonymous’s picture

    Anonymous (not verified) commented
    Status: Closed (fixed) » Active

    This thread is over a year old, but what about the original post's request to drill down to **all** available facets? That last patch didnt't seem to solve the first post's problem. It only added that show more/less feature, which still limits my facets to a maximum of 100. But I have hundreds of 'organisation' type taxonomy, and want my users to drill down to the very last one #300 if needed. Long lists are not prefered, rather like to see an ajax mini-pager.

    For now it seems we need to go for a CSS solution mentioned in #12, so I'll try that, but am opening the thread because I think its necessary to work on an ajax mini-pager for facets.

    Anonymous’s picture

    Anonymous (not verified) commented

    Or an even better idea: what about a modal popup via a 'show all' link, just like ebay? Then you can have a modal window with the full facets list by title (perhaps even searchable by autocomplete keyword itself)? Then after makeing a selection via checkboxes, you click "apply" and the filters are applied to SOLR search.

    Wouldn't be too difficult? Let's see if I can figure something out. I'd give my thumbs up for an eBay-style facet-modal-window.

    pwolanin’s picture

    pwolanin commented

    You shoud looks at the existing AJAX library for Solr - a patch might fit better there and also for UI ideas this RoR project

    http://blacklight.rubyforge.org/

    deployed, for example now at UAa:

    http://virgobeta.lib.virginia.edu/
    http://www.lib.virginia.edu/digital/resndev/blacklight.html

    Anonymous’s picture

    Anonymous (not verified) commented
    StatusFileSize
    new solr-facets-modal.png134.94 KB

    I found a way to easily do this using the lightbox2 module.

    I added something like this:

      $arg = '';
  if (arg(2)) {
    $arg = '/'.arg(2);
  }
  $modal_link = '<br /><a href="'.url('search/apachesolr_search').$arg.'?modal=true&filters='.urlencode($_GET['filters']).' #block-apachesolr_search-'.$delta.'" rel="lightmodal[solr|width:400px; height:400px; scrolling: auto;]" class="apachesolr-showhide">'.t('Show more').'</a>';

    in function theme_apachesolr_facet_list.

    To make it work, there's several variables you need to tweak. Most importantly in apachesolr_Search.module at the end of function apachesolr_search_taxonomy_facet_block():

          return array(
        'subject' => t('Filter by @name', array('@name' => $vocab->name)),
        // Morningtime: provide $delta
        'content' => theme('apachesolr_facet_list', $items, $limit, $delta),
      );

    $delta is needed to create the correct modal url.

    You also want to set the maximum facet limit to something higher, 

                // Morningtime: no limit for modal
            $params['f.' . $facet_field . '.facet.limit'] = 1000;

    And in apachesolr.js you want to disable the "Show more" javascript, because you're changing it to html modal link:

    Comment it out:

      /*$('<a href="#" class="apachesolr-showhide"></a>').text(Drupal.t('Show more')).click(function() {
    if ($(this).parent().find('.apachesolr-hidden-facet:visible').length == 0) {
      $(this).parent().find('.apachesolr-hidden-facet').show();
      $(this).text(Drupal.t('Show fewer'));
    }
    else {
      $(this).parent().find('.apachesolr-hidden-facet').hide();
      $(this).text(Drupal.t('Show more'));
    }
    return false;
  }).appendTo($(Drupal.settings.apachesolr_show_more_blocks, context));*/

    See the result attached screenshot!! It works awesome!! I know it hurts non-JS visitors,... so we still need a better solution...

    One problem I know: the extra facets are still hidden with CSS (.apachesolr-hidden-facet); I couldnt find a way to detect wether we are inside a modal window or not with php. If you have a really large set of facets, like 1000s, you might kill your browser experience.

    I'll dig deeper to improve this solution.

    milesw’s picture

    milesw commented

    @morningtime

    Did you ever come up with a solid solution for this?

    I have to believe others have needed this feature too - it's a pretty common requirement for search interfaces.

    pwolanin’s picture

    pwolanin commented
    Project: Apache Solr Search » Facet API
    Version: 6.x-1.x-dev »

    Should be using an offset, not fetching all facets http://wiki.apache.org/solr/SimpleFacetParameters#facet.offset

    Moving to Facet API for future consideration

    cpliakas’s picture

    cpliakas commented
    Version: » 7.x-1.x-dev
    cpliakas’s picture

    cpliakas commented
    Project: Facet API » Apache Solr Search
    Component: User interface » Code

    Punting back to Apache Solr Search Integration. Although this has to do with facets, this would actually be accomplished in the Apache Solr Search Integration module by setting the facet.offset parameter (as pwolanin mentioned in #27) in the ApacheSoleFacetapiTerm::execute() method. The value could be set by retrieving data from a query string variable.

    nick_vh’s picture

    nick_vh
    he/him
    Location Ghent
    commented
    Status: Active » Closed (works as designed)

    Since you can set these facet settings in the admin and this thread has been inactive for a while now I think we can safely close this one.

    cpliakas’s picture

    cpliakas commented
    Status: Closed (works as designed) » Active

    Are you sure? This request is about paging though facets, not just limiting them via JavaScript. As far as I can tell there is no code that allows you to set the facet.offset parameter, which would allow you to do the paging.

    nick_vh’s picture

    nick_vh
    he/him
    Location Ghent
    commented
    Title: Interface for seeing more facets in facet blocks » Possibility to set the facet.offset in order to allow paging in facets

    Well, the title is very non-descriptive in regards of what was requested? Do you think facetapi needs more work to support this kind of change or does it already support this?

    cpliakas’s picture

    cpliakas commented

    Yes, the scope did creep past the title. Facet API wouldn't need to do anything unless we decided that this should be abstracted out. I personally don't feel like it needs to be, so all of the implementation could be done in Apache Solr in the locations I mentioned in #29 above.

    pwolanin’s picture

    pwolanin commented

    @cpliakas - Well, I'd suggest this is more a facetapi feature request, since I assume you need some kind of pager or ajax callback to load more facets? That would be in facetapi.

    milesw’s picture

    milesw commented

    How are you guys imagining the UI would work? Since Solr isn't returning a count of the total available facet values, you can't include a real pager, right? Would it just be a forward/back kind of thing?

    cpliakas’s picture

    cpliakas commented

    @pwolanin, You're right. The pager display would have to be in the Facet API side, or Facet API would have to provide a way for backends to add the pager. I am not convinced that this is a backend agnostic feature, which is why I punted it here initially. Maybe Facet API will have to add another "supports facet pager" or something.

    @milesw I am not really envisioning anything :-) I haven't looked much into this, was just gardening the issue queue and added my thoughts. If you are interested in this, would love to hear your ideas on who it could be implemented with some of the technical barriers that might be encountered,

    milesw’s picture

    milesw commented

    @cpliakas - Come on, you're the FacetMaster, I expect you to have all the answers :)

    I feel like this is an important feature, so I'm willing to dig into it further, just not sure where to start.

    There are a few patterns I've noticed for making the complete set of facet values available...

    A) Traditional pager, with numbered pages and prev/next links, similar to the standard Drupal pager
    B) Modal or popup dialog box containing all facet values
    C) Autocomplete text field below the facet, searches for facet values (LinkedIn does this nicely)

    (B) and (C) obviously rely on Javascript. If it's technically possible with Solr, (A) is the probably most bulletproof of these three, but it's also most cumbersome to use.