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

Wow, it's been a long time since I've posted. 

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.

 

 

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)

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. 

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.

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.

OCLC Developer Network

OCLC plans to launch a new developer network and WorldCat Grid early in the new year.  Essentially it seems that it's geared toward providing and developing new library web services/API's, toolkits, resolvers and registries and a network of library technology developers.

Here's hoping for success!  And hopefully for some SOA basis behind the API's. 

- Via Richard Akerman, via Bess

CISTI Lab

Many months back we'd started CISTI Lab, a website for CISTI developers to expose some beta applications and to illustrate some of the more experimental work that's not yet ready for prime time, but that could use some exposure and a few more eyes.

The Lab has recently been revamped, and now includes some of the work being done by the CISTI Research group, as well as a wiki that explains some of the work.  As time goes on we hope to be adding some new additions, hopefully including some SOA-based architecture and related services, tools and applications.  For one, I'm hoping to revamp or replace the CISTI Toolbar application I wrote with something a bit better... most likely LibX based.

From the CISTI Lab site:

CISTI Lab visitors and collaborators will be able to test and evaluate Web-based experimental applications for science libraries. It is a place for CISTI to demonstrate prototypes, collaborate with researchers within NRC as well as Universities, libraries and the private sector and to obtain feedback from early adopters.

CISTI Lab has at its disposal a significant collection of electronic documents and meta-data about these documents as well as a collection of software tools and APIs for building Web applications and Web Services.

From an architecture perspective, it's a place that we hope we can use to help prove architecture and technology concepts, expose some experimental web services, and to encourage innovation in the area of libraries and technology.  More generally, CISTI is hoping to encourage collaboration and interest from like minded individuals and organizations.

Yahoo Pipes

Recently I'd been asked to enable an RSS feed for my SOA category in TypePad.  TypePad allows for the provision of custom feeds, but only though the Advanced Template Set functionality that comes with a Pro account. 

Richard had done some thinking on this awhile back, and suggested using a Blogdigger hack to accomplish it.  While Blogdigger can get the job done, I was a little reticent to use that solution.  Firstly, who's Blogdigger, and when will they change their *ahem* API.  Secondly, the Blogdigger hack doesn't allow much control over how the results are presented, particularly the title of the resulting feed.

Since I'd been looking for an excuse to try out Yahoo Pipes, this seemed the opportune time.  In about 5 minutes I'd created a custom feed from my site that allows an SOA-category-only RSS feed for this site.  Unfortunately, there's a known bug in Pipes that prevents this from being used universally, but hopefully that issue will be fixed before too long.

I also made a more generic one that allows you to configure the category and feed URL as parameters (either via the Pipes site, or on the feed URL directly), so you can try it on your own site.  It should work on most TypePad sites (keeping the aforementioned bug issue in mind).  No warranties are expressed or implied. 

 

All of that to say, Pipes is and awesome example of what SOA and XML should be all about.  You should be able to mix, match and connect these things nearly effortlessly.