VuFind

Better native support for consortia

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: Wishlist
  • Component/s: MyResearch, User Interface
  • Labels:
    None

Description

VuFind is currently in use by several library consortia, but they rely on local modifications. We should try to get some consortium-oriented functionality into the base code so that it requires less work to get VuFind up and running in a consortial environment.

Some example features:

- Ability to filter to a single library or show all libraries' holdings (perhaps a new generic faceting mechanism could be added that inserts a drop-down list into the UI and remembers the setting of the drop-down across all pages).

- Ability to show holdings differently depending on currently selected home library.

- Ability to associate a home library with a user account.

- Ability to take multiple libraries (and possibly multiple ILS's) into account when placing holds.

Please feel free to comment on this ticket with ideas for additional features. When we start implementing this, we should open additional subsidiary tickets so we can track each feature separately.

Issue Links

Activity

Hide
Demian Katz added a comment -
Based on vufind-tech conversations, a proposed algorithm for determining the current user's home library. Note that this is untested code and probably needs some extra details added to validate values; however, it should demonstrate the basic idea.

function getHomeLibrary()
{
    // Is home library already determined in the session? (This may be a cached value from
    // the logic below, or it may have been set by the user via a UI control). If so, send it back:
    if (isset($_SESSION['homeLibrary'])) {
        return $_SESSION['homeLibrary'] ;
    // Home library may be specified via GET/POST or cookie -- all show up in $_REQUEST;
    // this allows flexibility in how different sites set up location-specific instances of VuFind.
    // You can set persistent cookies on machines at particular locations, or you can create
    // custom search forms or links from certain places.
    } else if (isset($_REQUEST['homeLibrary'])) {
        $_SESSION['homeLibrary'] = $_REQUEST['homeLibrary'];
        // If setting did not come from a cookie, we should store one so the setting will remain
        // in $_REQUEST even if $_SESSION gets cleared (for example, by a user logging out)
        // and the GET/POST parameter is no longer present.
        if (!isset($_COOKIE['homeLibrary'])) {
            setcookie('homeLibrary', $_SESSION['homeLibrary']);
        }
    // If no home library was found in the session or the request, default to all available libraries:
    } else {
        $_SESSION['homeLibrary'] = 'All Libraries';
        return $_SESSION['homeLibrary'];
    }
}

Notes:

1.) It would be theoretically possible to add IP detection and mapping between the $_REQUEST case and the default case if we wanted to allow home library to be determined by IP range. However, since there is no current demand for such a feature, it was left out of the prototype code above.

2.) There was some discussion of using a user's home library (as defined by ILS) to determine their setting after they have logged in. However, it could be very confusing for users if logging in caused their search results to suddenly change (due to different location-specific filtering). If we want logging in to affect the home library setting, it would only really make sense as some kind of "opt-in" setting, and that seems of marginal value at best. We're omitting the whole possibility for now.
Show
Demian Katz added a comment - Based on vufind-tech conversations, a proposed algorithm for determining the current user's home library. Note that this is untested code and probably needs some extra details added to validate values; however, it should demonstrate the basic idea. function getHomeLibrary() {     // Is home library already determined in the session? (This may be a cached value from     // the logic below, or it may have been set by the user via a UI control). If so, send it back:     if (isset($_SESSION['homeLibrary'])) {         return $_SESSION['homeLibrary'] ;     // Home library may be specified via GET/POST or cookie -- all show up in $_REQUEST;     // this allows flexibility in how different sites set up location-specific instances of VuFind.     // You can set persistent cookies on machines at particular locations, or you can create     // custom search forms or links from certain places.     } else if (isset($_REQUEST['homeLibrary'])) {         $_SESSION['homeLibrary'] = $_REQUEST['homeLibrary'];         // If setting did not come from a cookie, we should store one so the setting will remain         // in $_REQUEST even if $_SESSION gets cleared (for example, by a user logging out)         // and the GET/POST parameter is no longer present.         if (!isset($_COOKIE['homeLibrary'])) {             setcookie('homeLibrary', $_SESSION['homeLibrary']);         }     // If no home library was found in the session or the request, default to all available libraries:     } else {         $_SESSION['homeLibrary'] = 'All Libraries';         return $_SESSION['homeLibrary'];     } } Notes: 1.) It would be theoretically possible to add IP detection and mapping between the $_REQUEST case and the default case if we wanted to allow home library to be determined by IP range. However, since there is no current demand for such a feature, it was left out of the prototype code above. 2.) There was some discussion of using a user's home library (as defined by ILS) to determine their setting after they have logged in. However, it could be very confusing for users if logging in caused their search results to suddenly change (due to different location-specific filtering). If we want logging in to affect the home library setting, it would only really make sense as some kind of "opt-in" setting, and that seems of marginal value at best. We're omitting the whole possibility for now.
Hide
Till Kinstler added a comment -
More ideas:
- individual themes for consortium member libraries, so libraries may create/configure their own user interface
- ranking based on "home library": boosting of locally held (or even "available) items (the bq parameter of the dismax handler is one way to do that)
- integration of ILL, but we'll need to investigate what can be done here because there seem to be many different ILL policies and ILL protocols out in the wild. Maybe ILL drivers like the ILS drivers?
Show
Till Kinstler added a comment - More ideas: - individual themes for consortium member libraries, so libraries may create/configure their own user interface - ranking based on "home library": boosting of locally held (or even "available) items (the bq parameter of the dismax handler is one way to do that) - integration of ILL, but we'll need to investigate what can be done here because there seem to be many different ILL policies and ILL protocols out in the wild. Maybe ILL drivers like the ILS drivers?
Hide
Mark Noble added a comment -
Our implementation of VuFind for the Marmot Library Network has made good progress in implementing a great deal of support for consortia. Our consortium consists of public libraries, academics, and schools so we should be a worst case scenario. Our implementation includes:
Detection of library system based on a subdomain of the opac. I.e. aspen.opac.marmot.org sets up the opac for the Aspen school district. This has some custom code as well as a library table which stores parameters for each system.
Themes based on library system - when a subdomain is used, we optionally override the logos and add a custom css file to each page. Individual templates can also be overridden, but that feature doesn't have many users yet.
Facets based on library system - when a subdomain is used, we optionally override the default facet file for VuFind.
Detection of individual branch by IP address. We have an ip_lookup table that defines the IP address(es) that belong to each branch and custom code to correlate this to an entry in a location table that defines parameters for each branch.
Restriction of holdings to a library system or branch. To do this, we use settings in the library and location tables to apply default filters to the search which can't be removed by the user, and we use some of the scoping functionality built into Millennium to restrict the holdings which are shown (this could also be done by filtering the holdings list).
Sorting of holdings by branch. We sort holdings based on the physical branch a user is in, the user's home branch, nearby locations, and other locations. This involves some custom coding which currently resides in our driver but could be made more generic.

We will be looking into some of the relevancy ranking ideas in an upcoming sprint.

We would be happy to share any or all of this code with the VuFind community.
Show
Mark Noble added a comment - Our implementation of VuFind for the Marmot Library Network has made good progress in implementing a great deal of support for consortia. Our consortium consists of public libraries, academics, and schools so we should be a worst case scenario. Our implementation includes: Detection of library system based on a subdomain of the opac. I.e. aspen.opac.marmot.org sets up the opac for the Aspen school district. This has some custom code as well as a library table which stores parameters for each system. Themes based on library system - when a subdomain is used, we optionally override the logos and add a custom css file to each page. Individual templates can also be overridden, but that feature doesn't have many users yet. Facets based on library system - when a subdomain is used, we optionally override the default facet file for VuFind. Detection of individual branch by IP address. We have an ip_lookup table that defines the IP address(es) that belong to each branch and custom code to correlate this to an entry in a location table that defines parameters for each branch. Restriction of holdings to a library system or branch. To do this, we use settings in the library and location tables to apply default filters to the search which can't be removed by the user, and we use some of the scoping functionality built into Millennium to restrict the holdings which are shown (this could also be done by filtering the holdings list). Sorting of holdings by branch. We sort holdings based on the physical branch a user is in, the user's home branch, nearby locations, and other locations. This involves some custom coding which currently resides in our driver but could be made more generic. We will be looking into some of the relevancy ranking ideas in an upcoming sprint. We would be happy to share any or all of this code with the VuFind community.
Hide
Markus Fischer added a comment -
We use an IP based location switcher at http://bibnet.org/vufind

IP based detection in our case is very useful. We use it for individual print availability and for online availability over the german EZB, which affects automatically over 560 libraries without doing anything but transmitting the requesting IP.

The code is very simple. We took it straight from the language selecter. The code is documented here:

http://journal.code4lib.org/articles/4438
Show
Markus Fischer added a comment - We use an IP based location switcher at http://bibnet.org/vufind IP based detection in our case is very useful. We use it for individual print availability and for online availability over the german EZB, which affects automatically over 560 libraries without doing anything but transmitting the requesting IP. The code is very simple. We took it straight from the language selecter. The code is documented here: http://journal.code4lib.org/articles/4438
Hide
Phil Fenstermacher added a comment -
One major downside to using $_SESSION variable for libraries is that persistent URLs for search results can break. If I'm at library A and send a search results page to someone at library B then they could see different content on that page based on their session. To keep the persistent URLs something URL based is likely better, likely using the setevn option.
Show
Phil Fenstermacher added a comment - One major downside to using $_SESSION variable for libraries is that persistent URLs for search results can break. If I'm at library A and send a search results page to someone at library B then they could see different content on that page based on their session. To keep the persistent URLs something URL based is likely better, likely using the setevn option.
Hide
Demian Katz added a comment -
Good point. Of course, it's okay to store the value in the session so that it persists across searches as long as it is also embedded in URLs; a solution similar to that used for VUFIND-357 might be appropriate.
Show
Demian Katz added a comment - Good point. Of course, it's okay to store the value in the session so that it persists across searches as long as it is also embedded in URLs; a solution similar to that used for VUFIND-357 might be appropriate.
Hide
Demian Katz added a comment -
I am attaching a patch (courtesy of Joe Thornton and the Upper Hudson Library System) which adds a library selector to VuFind using the "building" field in a hidden filter in the search object. This does not address the persistent URL issue discussed above, but it might be a useful starting point for others. If anyone has time to adapt the patch to take the URL issue into account, please share!
Show
Demian Katz added a comment - I am attaching a patch (courtesy of Joe Thornton and the Upper Hudson Library System) which adds a library selector to VuFind using the "building" field in a hidden filter in the search object. This does not address the persistent URL issue discussed above, but it might be a useful starting point for others. If anyone has time to adapt the patch to take the URL issue into account, please share!

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated: