Inmagic recently blogged about the limitations of using SharePoint for library applications, and this prompted me to write this post sharing my recent experiences setting up a SharePoint site for a library catalogue.

We have been working with a client to create a SharePoint 2010 site for a new resource library to manage codes, standards and related documents.  SharePoint is this client’s preferred platform, and as their processes for getting approval for any new software such as a proper integrated library system are onerous, time consuming and often futile, it was decided to just accept the limitations of SharePoint. 

Once it was established that we would need to design a library catalogue in SharePoint, I went searching the web for advice and suggestions.   This in itself is not easy, as a core concept in SharePoint is “Libraries”,  so it is hard to differentiate terminologies and find results relevant to SharePoint usage in a corporate Library setting.  However the references I did find were mostly concerned with how unsuitable it was, although none gave any detailed specifics of particular issues.  I found one SharePoint based library system advertised, but the vendor website is no longer active, and I chatted to a reputed ILS vendor who mentioned spending three years trying unsuccessfully to port their ILS to SharePoint. 

The prospects for designing a catalogue in SharePoint for our client were therefore not promising!  I started our project with SharePoint 2007, but very fortunately the client was able to upgrade the site to SharePoint 2010 mid way through.  I would never attempt to design a catalogue (or anything else) in SharePoint 2007 again.   However with either version, there are still many frustrations, especially as in our situation we were not allowed access to SharePoint Designer which allows editing the underlying website and HTML.  We were required to work with our client’s templates, stylesheets and site structures to ensure a consistent branding across all their SharePoint sites. All comments below are therefore based on just the out of the box functionality available to a site administrator. 

Designing any site in SharePoint needs a thorough planning process, and discussion of this is beyond the scope of this post.  However for anyone contemplating designing a catalogue in SharePoint, here are some factors to consider.

Specifying content types:

• Most corporate library catalogs will include different types of material, i.e. books, reports, journals, videos, websites etc.  Some of these may require columns (fields) unique to a specific type.  For example you will probably want to add a Frequency column for a journal but not for the rest.
• By default, all columns show in all displays regardless of whether they have data.  (This reminds me of the original library systems which have now all long since hidden any empty fields!)
• To get around this, we set up different reusable Content Types each inheriting from a core set, and different views (display forms) for each type of material.
• Depending on your version of SharePoint and your specific site settings, there may be a lengthy list of content types and existing site columns to choose from.  There is a very rudimentary description of the expected content for each column,  but no indication in advance of parameters such as if the column type is pre-set, i.e as single line of text, multiple line of text, choice, lookup etc.  Changing a column from one type to another after the fact is often not an option.  Some may also have unexpected settings, e.g. the Route to External Location column.  There is no indication when adding it to your content type that this is a Required Yes/No column, or that it is a  persistent or “sealed” column that cannot be deleted!   There are 28 or so of these persistent columns including others with innocuous sounding names such as Article Date.
• SharePoint has several reserved column names that cannot be changed. Therefore “Author” in SharePoint terminology is the person creating the resource (record), not the author of a book. It’s not difficult to add a new column for BookAuthor or equivalent, but on the default search results, all records include this SharePoint Author column which is of course inappropriate in a library context. “Date” is also included by default too, but this is the Date entered not a Publication Date.

Formatting views:

• Most default views in SharePoint are columnar which is perfect for many types of information but does not work well with variable library data where for example, a title can be very short in one record, and very long in the next.  There is no easy way to force a set column width unless you have access to SharePoint Designer.
• There is a Datasheet view option which is very similar to Excel and would be great for quick editing, but SharePoint does not support this type of view if your content type includes any Managed Metadata columns. 

Managed Metadata:

• Managed Metadata provides a new taxonomy capability in 2010 which mitigates some of the other negatives when working with SharePoint. 
• We are using this new column type in several ways:
  • As a controlled vocabulary for our LC Subject Headings so that our technician can start typing and any matching terms are displayed. 
  • Synonyms or abbreviations can be included, so we use this for Publishers so that they are findable by both their full name and their acronym.
  • Terms can be added in a hierarchy so we use this for specifying a general Location and then a specific Office where the items are stored.
  • Multiple terms can be added to a record quickly, and new ones added either on the fly, or through the Term Store.  (However there is no way to batch add an existing list without SharePoint Designer.)
  • Best of all, we can use these Manage Metadata columns as Search Refiners to produce a faceted search results page.
• The downsides are that you cannot import records from a spreadsheet or use a Datasheet view if the list contains any Managed Metadata columns. 

Search Refiners:

• We were able to set up several custom search scopes and set the default search to the Library Catalogue only.  
• Our custom search results page is set up with multiple Search web parts including a Refinement Panel.  Choosing which columns to use as refiners is picky requiring editing a popup XML Editor, but at least it can be done without requiring SharePoint Designer.  However we have not been able to force a consistent order for displaying these refiners, so if a result set mostly belong to the same material type, that refiner is not considered important so it appears lower down the list. 

We have had to lower our expectations regarding what we will be able to accomplish without SharePoint Designer or any IT support. Fortunately the collection is predominantly virtual, so we have not had to think about printing spine labels or shelf lists sorted by LC Classification.  We now have a functioning catalogue and some workflow created with InfoPath forms to support requesting and approving new orders, but there is no question that a purpose built integrated library system would be preferable. 

It may appear that migrating an existing library system to SharePoint or starting a new catalogue would be a cost saving measure if an organization already has SharePoint.  However, as there are no commercial library packages offered on the SharePoint platform, any system will have to be developed and maintained internally.  This reminds me of the many library systems set up over the years in Microsoft Access that end up unsupported when the particular developer leaves. We have converted many of these Access databases to standard library software, but this can be a time consuming process as often the records have limited fields or authority control, requiring us to upgrade the cataloguing. 

Please contact us if you would like further information.  Check out our blog post on options for integrating DB/Text data into SharePoint, or ask about the SharePoint integration capabilities in Presto for DB/Text.

Although much of our work is with databases and web search applications we also help clients with other information organization tasks. Recently we were approached by the Harry Lash Library at Metro Vancouver to help redesign an intranet site. 

The Problem

Metro Vancouver has an extensive SharePoint-based intranet with detailed team sites for the many departments and groups within the large organization. The library's presence was small, with a large amount of information crammed onto a few pages, and library staff, as in many small libraries, had more urgent priorities and an intranet redesign never quite made it to the top of the daily task list (sound familiar?). This meant that the website was stale, visually unappealing, and lacking a lot of useful information that staff had been accumulating over the years.

The Solution

Library staff approached Andornot to help move the intranet redesign forward. We met with staff to understand their goals for the site – what sort of information they want to provide Metro Vancouver staff, what resources they manage and services they provide, and how they’d like to present themselves to Metro Vancouver.

Based on these meetings, we drafted a new site architecture – a two-level, 15-20 page organization of content that describes who and what the library is, the many print and electronic resources it manages, and the services it provides to Metro Vancouver staff. We also included topic pages for specific departments within Metro Vancouver to guide staff to resources of greatest use to them, including materials within the library's Inmagic Genie catalogue.

Working within the existing SharePoint site, we created the pages from the new hierarchy and populated them with content. This included newly-written and assembled materials, as well as information that was previously buried in other documents. In particular, we developed canned searches into the catalogue for journal titles by subject, replacing a labour-intensive, stand-alone list that had existed on the previous website.

 

 

Once the new site was about 80% complete, we scheduled a round of usability testing. We invited staff from a few departments to preview the new site and assigned them information discovery tasks. We watched as they navigated the site and noted where they had trouble, then modified some aspects of the site to smooth over the rough patches. This level of usability testing is simple to perform, but provides valuable feedback. A more extensive survey of the information needs of Metro Vancouver staff is also planned.

Once the site was as close to complete as possible (and of course, it will continue to evolve), the library held a launch party, complete with muffins and cupcakes, in the library.

 

 

"The launch went really well – we had almost 70 people! I'm really glad we did the launch as a way of 'marking' the event. People really seemed to like the website and I picked up a few suggestions for content." says Thora Gislason, Metro Vancouver Corporate Librarian.

 "I owe you both a huge thank you for that initial meeting that got me motivated and to Jonathan for drafting the navigation, doing the usability testing, and kick-starting the population of content!!"

 

 

With each new release, SharePoint becomes both more useful and more prevalent in organizations of a certain size. Used both for intranets and public-facing web sites, SharePoint provides tools to help users communicate, collaborate and share and manage documents and information.

While SharePoint offers document storage and search capabilities itself, many DB/TextWorks users prefer the interface and features they are most used to, and wish to continue using DB/TextWorks to manage their databases and collections. Replicating administrative workflow in SharePoint is often not practical or cost effective. Those with WebPublisher PRO may wish to continue providing web browser search access in that fashion.

Fortunately, it’s quite feasible to use DB/TextWorks and WebPublisher PRO with SharePoint as there are many options for integrating one into the other. However, before rushing to do so, one should consider the consequences, such as:

 

• If users are used to a particular search interface or syntax, will a switch to SharePoint cause confusion or frustration? Will you continue to provide access to the previous interface?
• How many records are in an existing SharePoint site compared to ones in the DB/TextWorks databases? Will including the latter in SharePoint overwhelm the site?
• Will significant capabilities be lost, such as the ability in WebPublisher PRO to create See Also hyperlinks, browse indexes or bring in book covers from Google?

 

A few of the options for integrating DB/TextWorks databases into a SharePoint site are:

 

1. Use the SharePoint Page Viewer web part to iframe Inmagic WebPublisher PRO search and results pages. This is the simplest approach, but requires that you have WebPublisher PRO and has usability drawbacks (iframes are harder to bookmark, navigate and size correctly). Search results will not appear in any SharePoint site-wide searches, which may be the desired approach if they would overwhelm the results.
2. Export data from Inmagic databases to a CSV format and import into SharePoint Lists, where they can be searched, sorted, filtered, etc., the same as all existing data in the SharePoint site. A search scope can be defined in SharePoint to allow users to focus a search only on the imported data, if desired. This approach does not require WebPublisher and can be done manually with one or two connector tools, or automated with one or two more.
3. Export data from Inmagic databases to XML and import as a SharePoint Data Source. As with #2 above, this can be automated. However, the data is less usable without further effort in SharePoint as a Data Source compared to a List.
4. Set up a connection to the WebPublisher PRO SOAP interface as a SharePoint Data Source, either to import data, or to construct a real-time search interface. As with #1, this requires that you also have WebPublisher PRO installed, and will require further effort to make good use of the data within SharePoint.
5. Write a custom .NET connector to WebPublisher PRO within SharePoint Business Connectivity Services either to import data or for real-time searching. This requires that you have WebPublisher PRO and requires the most initial effort and skill, but also offers the most options for customization to meet very specific needs.

 

Each of these options has pros and cons based on the effort and skill required to implement, and the features that result. For those with DB/TextWorks but not WebPublisher PRO, option 2 is an excellent choice in that it is not too complex nor costly to implement, but provides reasonably useful results.

This blog post outlines just a few of the issues and options for using DB/TextWorks and WebPublisher PRO with SharePoint. We would be pleased to advise you on the best strategy for your organization and needs.