May 17, 2012

Some thoughts (none particularly original) I'm having about library futures.

In the library world, I keep seeing posts from libraries and librarians all wondering about how to be relevant, valued, important. Many talk about the importance of librarianship, and the specialized knowledge and skills they have. We focus on better ways to search, and licensing content. Indeed these things have value. But I'm not sure they're actually the core enduring value for libraries. I think the decrease in the perceived value of libraries is more fundamental, and simpler.

It's about content. Libraries used to have content that was unavailable, or otherwise very expensive to own. Sharing via the library was a sensible and logical thing to do. Today that still makes sense - though the types and volume of information that's available via the internet/web reduces the value for many kinds of information (encyclopedias for example, and also books and journals that are available in digital formats - ie: all of them practically).

By my thinking though, the key purpose for a library - providing access to information that is generally otherwise unavailable - is still an enduring value. It's simply that the types of information that are generally unavailable has changed. Today thats not books and journals. It is never-published and/or un-digitized materials, scientific data, lab notebooks, photographs, rare books and manuscripts, old maps, records, documents of enduring (national, organizational, historic) value. Our value is in identifying, preserving, and making these materials available.

so poorly done as to be useless for determining the work to be done and for testing, or

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.

May 09, 2012

In that time, we've launched CISTI Mobile in production. In general, the creation was a positive experience. We learned plenty about JQuery mobile, Metalib API's (used to enable the federated search), and about mobile website development generally.

I think, correct me if I'm wrong, that is was indeed the first Canadian federal library mobile website?

Having accomplished the first goal of providing for a mobile interface for CISTI, we'd now like to pursue the further goal of having people actively use it. We've a few daily users.. but there's plenty of room for more usage.

I'd been thinking of redirecting mobile users from our various applications to the mobile site - but now I realize that that's kind of complicated. The simplest solutions to implement wouldn't place them on their equivalent landing page, and thus would likely cause confusion. It seems that this is one of the key disadvantages to having a "separate" mobile site, rather than skinning existing applications to serve mobile users natively.

That said, the effort to skin all of our applications would have been enormous. Hence, I think I'll see if we can't simply direct users to the common landing pages/static pages to the mobile site - and leave the rest for now.

I've done some recent experimentation involving harvesting Canadian institutional repositories with the OAI-PMH protocol. Mostly this was a personal endeavour to determine how many there were, how much content they had, and how difficult/reasonable it would be to harvest them all and provide a search index. It seems that there's no comprehensive listing of Canadian repositories, so I had to gather and cobble my own.

It seems not to be a common practice for repositories to publish their OAI-PMH addresses. This is a minor tragedy. The list that I gathered follows for the edification of others who might have a similar need.

The list consists of 53 unique Canadian repositories, and where available, their OAI-PMH interface API's.

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.

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.

December 08, 2010

I've been interested in playing with QR codes, and how they might be applied to my work at CISTI. Recently, I found a useful tip from Lifehacker showing how to create a bookmarklet that will make a QR code of the current web page... useful if you want to transfer the current page on your desktop/laptop to your phone for mobile reading. It's a lot more convenient than emailing yourself the URL.

It's dead simple, making use of Googles chart API's. Just make a bookmark in your toolbar with the following as the location information:

June 17, 2010

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:

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.

April 22, 2010

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.