Enterprise Abstraction

Of Requirements

Requirements.  I dislike them.  Mostly because they're usually either

1. so poorly done as to be useless for determining the work to be done and for testing, or
2. so tediously lengthy and detailed that nobody is inclined to use them.

That said, there are many times in life one has to do unpleasant things.  Sometimes requirements are required.

 Therefore, if we must use them, I suggest (read insist) on the following:

• Make your requirements SMART requirements.  That is:  Specific, Measurable, Attainable, Relevant, and (I augment the last one) Testable/Trackable.  In short, if they don't tell you what you need to do, and you can't test them - toss them...  you are wasting everybody's time.
• Have a few requirements as possible, but no fewer.  More requirements definitely does not imply better.  Unless you're dealing with contracts, the purpose is to define the work such that everyone understands, and to be able to later test the work to see if it meets expectations.  Any more than that and you're wasting everybody's time - particularly your own.
• You don't necessarily have to have all the requirements up front.  It's fine to go back and realize you need some adjustments/additions.  That said, be mindful of scope creep. 
• Remember your clients.  Who are your clients for requirements?  In my shop, there are two clients:  The developer (and general project team), and the testers.  Write requirements so that they can do their jobs.

One method I find exceptionally helpful in requirement writing is to use the words "Must, Should, and May" in a very structured manner, as per RFC 2119.  This may seem a bit excessive, but it really helps me control my thinking about what requirements are essential (MUST haves), what would be really nice to have (SHOULD), and what we can have (May - Optional).  It also helps to make the requirement statements clear to everyone - particularly the developers/implementers and testers of the future system.

CISTI Mobile - beta

A quick overview and introduction to our thinking and work on a federal libary mobile website.

In observing the growing trend in the use of mobile devices, a small group of us at CISTI decided to explore the options and best practices for offering better access to CISTI services.

Check out the CISTI Mobile website (beta).

We had been investigating the possibility of producing some sort of application, possibly for the iPhone/iPad... but there are a couple of distinct disadvantages to that approach.  Firstly, we'd need to obtain and retain the knowledge to support application development - or contract for someone to do that work.  Secondly, we'd only be improving access on a small sub-set of the main mobile devices available. 

With that understanding, we pursued investigation into providing better access for mobile devices to our website.  CISTI is an institute of the National Research Council - an agency of the federal government, and hence obliged to meet federal government CLF standards for websites.  Fitting our full featured CLF site into a mobile screen size was essentially impossible.  Moreover, very few federal government mobile websites exist - and those that do seem to be older WAP-based sites designed before the advent of modern smartphones.

Further investigation revealed that the current best practice is to create simplified and separate dedicated mobile website in these cases - reducing the content and services to their core - and offering clients the option of using either the full regular site, or the mobile site as desired.

That said, the site attempts to meet the spirit of federal government CLF policy (branding, look and feel, accessibility and bilingualism) - but could not actually follow the established guidelines as they are based on desktop oriented browsers, and monitors.

Armed with this knowledge, a prototype was created using JQuery Mobile and the beginnings of code to connect with the Metalib API.  This prototype was intended to gauge the amount of effort that would be required to produce a fully functioning mobile website - and to demonstrate the concept to interested stakeholders.  Development of a functional prototype took far less time than expected, and demonstrated that a mobile website was achievable with minimal effort. Further, the prototype was able to demonstrate that we could create a single mobile website suitable for most common and modern versions of iPhone, Android and Blackberry devices.

Most library mobile websites provide contact/location information, hours of operation, access to search the library catalogue, and often - particularly in the case of academic libraries - reserves, holding information, course notes, etc. 

CISTI, as usual, is different in this regard.  We are not, particularly, a conventional lending library, nor an academic library, and the resources of most interest to our clients (and particularly the research staff of the National Research Council) are the licensed electronic access to scientific and technical articles.  A simple search of the Catalogue would not do.  Hence, we focused our effort towards providing access to search across large sets of scientific articles in addition to our library catalogue and local institutional repositories.  Though the Metalib x-server api, we were able to construct queries and receive results from any sets of licenced and local resources required - and format those results to make them suitable for display in most mobile devices.  Taking advantage of Metalib means having to code this once - and having mobile access to all of our available search resources.

Location and contact information (phone, maps) are something that most mobile devices support very well - and we thought it would be a useful (and easy) addition to the content of the mobile site. 

Further, links to CISTI's Twitter, Facebook, the ubiquitous "about us" pages, and a link to CISTI's full website were included.

More information is available on the CISTI Lab Website page for CISTI Mobile.  Comments and suggestions on CISTI Mobile (beta) are welcomed at this blog, or via any of CISTI's usual communication channels.

Journal cover images - in SFX Link Resolver

I been learning SFX administration - adding some features here and there... last week I added the Google Books covers service - which turned out to be quite satisfactory.  It got me thinking that there must be a similar service for journal covers.  Apparently not.

However, some colleagues in the Twitterverse recommended using the journal covers supplied by Elsivier.  It's not an API call, nor am I able to directly call the images remotely - but I have some space - so I decided to download and link them locally.

All the files are named XXXXXXXX.gif - where XXXXXXXX is the ISSN of the journal.  (I've since renamed the files to XXXX-XXXX.gif to support the way that SFX deals with ISBN's).  After downloading and untarring the image files, I placed them in a web-accessible directory.

Then, it was simply a matter of linking, unobtrusively, to the images in SFX (or presumably from any application that deals with ISSN's).  For SFX, I inserted the following - but this code would work for any page as long as you can insert the desired ISSN in the appropriate places:

<!-- SKA EXPERIMENTAL - Adding journal cover images -->
<!-- Will show image if available, or will show 0 height 1px image otherwise -->
<!-- Note:  Without Javascript in IE, will show no-image icon if image does not exist -->
   <TMPL_IF ISSN>
        <a href="http://lab.cisti-icist.nrc-cnrc.gc.ca/anthonys/journalcover/<TMPL_VAR NAME="ISSN" ESCAPE='HTML'>.gif">
          <img src="http://myserver.mydomain.ca/journalcovers/<TMPL_VAR NAME="ISSN" ESCAPE='HTML'>.gif" height=90 alt="" onerror="this.src='http://myserver.mydomain.ca/journalcovers/px.gif'; this.height='0';">
        </a>
    </TMPL_IF>
<!-- END SKA EXPERIMENTAL -->

In my case, I inserted this code in sfxmenu.tmpl, just after the area where the Google Books cover would load.  The <TMPL_IF ISSN> prevents this portion from being rendered if the item in question does not have an identified ISSN (for example - if it were a book, or other work).

One could certainly that the portions - removing the <TMPL> portions that are specific to SFX, and insert this code anywhere.  In most cases, if the ISSN image is not available, it will display px.gif (which is a 1 pixel white image).  In Firefox it's totally transparent - but in IE, it will show a broken image if the ISSN image is not found - and the user has disabled JavaScript.  I hope to resolve that problem eventually.

Some examples:

Example 1

Example 2

Example 3 (No cover available)

Change

We've recently released a new website for CISTI - reorganizing some things in conjunction with the CISTI Transformation and the changes in document delivery services.

Externally, the website has changed it's structure - and is still transitioning as the rollout of the new partnership for document delivery proceeds.  That said, essentially the same services and content remain available.  We've added a new metasearch function - that we hope will simplify things - particularly hoping to simplify the answer to the question "Does CISTI have this?"   Now you should be able to find out - in one place.

Internally, things have changed significantly.  In the past, CISTI provided a separate portal dubbed the "Virtual Library" for the exclusive use of NRC.   We have merged the functionality of this portal with our main website - http://cisti-icist.nrc-cnrc.gc.ca - such that IP recognized persons (or those using our NRC proxy server) will see many more options including the ability to browse and search licensed and free e-journals, databases and other resources, librarian authored subject guides, and have an assortment of federated search options.  Integrating the ILS/Catalogue, metasearch, and CISTI-hosted databases (Discover and NPArC) is CISTI's link resolution service Find@CISTI - now finally being used essentially EVERYWHERE there's a bibliographic citation presented on the website.

Presently, we're working to improve the site, and to release (finally) a version of the LibX Toolbar for NRC Staff - that I hope will bring the capabilities of the library more readily available for researchers in their work.

It's been a busy time.

SFX and JavaScript

I'd been hunting around for a means to have our local SFX implementation (Find@CISTI) run without requiring JavaScript.  I'd done the requisite Google search, and submitted a request - to no avail.  The solution turned out to be rather trivial - and seems to have been implemented in subsequent releases of the SFX templates.

In your SFX instance, at /templates/sfxmenu/target_list.tmpl, add the following noscript line:

<!-- end extra comments --> <tr> <td height="0"> <noscript><input title="Navigate to target in new window" type="submit" value="<TMPL_VAR NAME='SERVICE_NAME'>&nbsp; <TMPL_VAR ESCAPE=HTML NAME='TARGET_NAME'>"></noscript> </td> </tr>

Our line had been removed or was missing... problem solved.  The buttons presented with JavaScript off are not particularly pretty - but they are functional. 

Making allies of adversaries in libraries

[This post concerns mainly libraries serving a campus of patrons - public libraries or those with a general public mission have other concerns]

Google is not the enemy.  Nor publishers, nor vendors (entirely - but I wouldn't turn my back on a vendor in a dark alley). 

The library role based on having/holding content is diminishing.  More and more libraries (particularly science libraries) no longer hold collections but instead license content. 

Moreover, the role of a library as a search enabler is also compromised by technologies.  WebOPACs and ILS systems, federated search platforms are diminished by the fact that they are either not client-oriented interfaces (WebOPAC), or that if others don't the job better - they at least are further up on the list of patrons first stops on their research journey (Google, Google Scholar, Scopus, etc).

So, what to do?  Turn your adversaries into allies.

Libraries will not be a starting place for researchers - deal with it.

Libraries will not be the holders of information - the value of "collections" is diminished - deal with it. 

How?  Libraries still have a valuable role - to be connectors to information.

Indeed, encourage patrons to search anywhere/everywhere!  Go to Amazon if that meets your needs, browse wikipedia, start at your favourite journals website, use Scopus and other tools if you have access!  I believe that it is the job of the library to get patrons to information - regardless if that information is in our collection or not.  And regardless of where the patron decides to begin their search.

It is possible, with a small set of commodity technologies to bring access to patrons no matter where they start.  In order of importance:

1. Link resolver - connects your own technologies and 3rd parties to appropriate copies and information services for your patrons.
2. Proxy server - allow off-campus access to IP-restricted resources.  Alternately, you might use Shibboleth or some other kind of authentication/authorization mechanism.
3. Federated search - Allows for broad searches across local, remote, paper and digital collection.  Not a silver bullet - but at least your patrons are not expected to perform 30 searches on 30 different data sources - and still remain generally unaware of the vast quantity of expensive resources you license on their behalf.  More importantly perhaps, a federated search platform can be the foundation for your "discovery layer" - hooks and landing areas to connect multiple information services and sources together.  In a rare instance, a patron might even begin their search there - but I doubt it.  Finally - at the very least - the patron will not be forced to look at your WebOPAC... nobody should have to look at that.  Apply all the lipstick you want.
4. Library Toolbar - You can make one for your library via LibX in an hour.  This is for me the paradigm shifter.  It is well known that patrons rarely start their search at the library.  Don't try to change patron behaviour, go with it!  If they start their search on a 3rd party website - the library toolbar should travel with them on their research journey - pointing out places where the library can help them.  Oh, I see a ISBN, or a citation, or a DOI - here's a link back to your library to find out more information or get more services!   
5. Other goodies - Alerting, citation management, visualization, analysis tools, recommendations, facets, personalization... all of these and more can be tacked onto the federated search and link resolver... you're adding more and more value!

Why are we afraid of Google and others?  Don't fear them, embrace them!    And connect patrons from wherever they go to where they need to be.

The Future of Library Information Services in a Web 2.0 World

For those in the Ottawa area, Stephen Abram is giving a talk entitled "The Future of Library Information Services in a Web 2.0 World". 

Monday, March 23, 2009, 2:00 pm
Ottawa Public Library, 120 Metcalfe, Auditorium

Checkout the CASLIS event notice for admission and details.

LibraryFind SRU Example

I've been playing a little with LibraryFind, a free and open source Federated Search.  The project is very active - and seems to have gone a very long way to filling the gaping hole in this area.  Z39.50 support seems well established:  It took just minutes after install to get the application running with several library catalogues - including CISTI's.  However, SRU support is currently restricted to MarcXML, with Dublin Core on the way (I need MODS!). It also does Open Search and OAI-PMH - but I've not played much with those aspects.

Anyone interested in using or demonstrating the SRU functionality may be interested in the following configuration information - as I had a difficult time to get a working example of SRU running... mainly due to the aformentioned lack of support for MODS:

Name: sru_loc
Alt name: Willamette Dspace SRU
Conn type: sru
Host: http://libmedia.willamette.edu/SRW/search/dspace
User:
Pass:
Record schema: marcxml
Definition:  ti=245;ti=130;au=100;au=110;au=700;au=710;callnum=099;callnum=090;callnu
m=086;callnum=050;ass_num=907b7;note=500;pub=260b;date=260c;subject=650;
subject=651;static=856u
Isword: 0
Url:
Mat type: Article
Virtual:
Vendor url: http://libmedia.willamette.edu/
Bib attr:
Proxy: 0
Harvested:
Is parent: 0

Wordle

Wordle is a web application that allows you to submit text, or use your delicious username, to produce interesting tag clouds.  Lots of sites let you do this, but Wordle is particularly pretty.  No surprises in mine - yep, that's what I'm interested in.

That, along with a FICO score should probably be the inputs for a good dating service. 

CISTI LibX Edition

I've been fooling with library toolsbars, sidebars, web and widgets for awhile now... and a few months back I'd resigned myself to finally getting around to doing a LibX library toolbar for CISTI.  I'd even gotten a mostly-working version done a few months back.  At the end of last week I decided it was time to finish.  Lo and behold, I go to the LibX site and discover the wonder that is the LibX Edition Builder!  Holy moly, it's just wonderful.  Within 15 minutes I had a working toolbar for CISTI.  Of course the details and testing tool a day or so, but I finally think I've gotten a version decent enough to make live and public. 

This version is intended mainly for staff of the National Research Council - CISTI's parent organization - but I imagine it would still be useful for most CISTI patrons.

Check it out, and let me know what you think:

• CISTI LibX Toolbar @ CISTI Lab - Some info from me, and access to the IE version installer.
• CISTI LibX Edition @ LibX - The main edition site on LibX - Firefox only install.