Koha Development Conference Cook & Fuller / Improving the Koha OPAC Interface: Supplement 1(10)

August 2012 Get full documentation at http://libill.hartford.edu/koha REV 803/1325

Improving the Koha OPAC Interface

What’s possible, what we’ve done, and how we got there.

By SAM COOK & BRANDON J. C. FULLER University of Hartford Libraries, West Hartford, CT

— CONTENTS —

Part 1 General Display……………………………………………………………………………………………………………………….. 2

1.1 Overview & CSS…………………………………………………………………………………………………….......................... 2

1.2 Using JavaScript when CSS isn’t enough………………………………………………………………………………………….. 3

Part 2 XSLT…………………………………………………………………………………………………………………………………..….. 6

2.1 What is it? ……………………………………………………………………………………………………………………………….. 6

2.2 Modifying XSLT…………………………………………………………………………………………………………………………. 6

2.3 What you can do with it………………………………………………………………………………………………………………. 7

Part 3 Going Mobile………………………………………………………………………………………………………………………..…. 8

3.1 That’s possible? ……………………………………………………………………………………………………………………….. 8

3.2 Understanding how it works…………………………………………………………………………………………………………. 8

3.3 Feature Set………………………………………………………………………………………………………………………………. 9

3.4 Interface………………………………………………………………………………………………………………………………….. 10

Supplement to the University of Hartford Libraries’ webinar presentation at the 2012 Koha Development Conference, August 6, New York, NY.

Koha Development Conference Cook & Fuller / Improving the Koha OPAC Interface: Supplement 2(10)

August 2012 Get full documentation at http://libill.hartford.edu/koha REV 803/1325

Improving the Koha OPAC Interface What’s possible, what we’ve done, and how we got there.

By SAM COOK & BRANDON J. C. FULLER

University of Hartford Libraries, West Hartford, CT

Supplement to University of Hartford Libraries’ webinar presentation at the 3rd annual Koha Development Conference, August 6, 2012, New York, NY. PART 1

General Display 1.1 Overview & CSS The University of Hartford Libraries Koha OPAC interface looks drastically different from the “out-of-the-box” (or “Blue Bar”) version. To give you an idea, here’s the two OPAC styles side-by-side, with our current OPAC on the right:

The vast majority of these changes are made with a single CSS stylesheet. This stylesheet is implemented through the opacstylesheet setting in Koha’s system preferences. Through this file, nearly all HTML elements on the page can be styled to your choosing.

LEARN MORE If you’re not familiar with CSS, you can learn at www.w3schools.com/css. Here are some of the major differences between the Blue Bar version and ours: FIXED WIDTH The Blue Bar version adjusts the OPAC’s width to match that of the browser window, and it keeps

adjusting when the window is resized. While this method might grant more space, it doesn’t allow for much control over the layout of page contents, since the contents “float” in the window and reposition themselves according to the browser window size.

By setting a fixed width for our OPAC window, we can easily define where contents are positioned in relation to each other, making for a cleaner and more consistent layout—and we can guarantee this layout across various monitor sizes.

BACKGROUND Another advantage to fixed width browsing is that a distinction can be made between page

content and the background of the site. The presence of a background helps the user orient themselves within the site, since content is not spread across the entire width of the browser. It also provides uniformity between pages.

FONTS When a lot of information is being presented, it is imperative that font sizes and colors be used

to provide hierarchical structure, so that the relative importance of information is visibly clear. Such is the case on results pages. Titles stand out first and foremost, while other supporting information is neatly organized with distinguishable labels. Variation in color is reserved only for very special information; having a different color for every piece of information would defeat

Koha Development Conference Cook & Fuller / Improving the Koha OPAC Interface: Supplement 3(10)

August 2012 Get full documentation at http://libill.hartford.edu/koha REV 803/1325

the purpose. In our OPAC, titles are large and red, while other information is black and small with bold labels.

COLORS The general color pallet is kept to a minimum; lots of colors make it difficult for users to

understand what to focus on and to attach meaning to particular colors they see. When colors do arise in images, like bookcovers for example, they have less of a chance of interfering with a minimal color scheme, and vise versa. If the eye is not used to seeing lots of color on the site, any images will be that much more prominent.

The color pallet of our OPAC is essentially neutral shades of grey with red accents. The red accent color was chosen to conform to the overall University of Hartford visual identity. Red fonts are reserved for links; all other fonts are black or grey depending on their importance. There are a handful of links, mainly in the results control header, that are blue; this helps differentiate these control links from the red title links in the results list. By being consistent with these color choices, any other colors that appear immediately stand out, since they’re few and far between. Take, for example, the green checkmarks used to label items which have copies available: green appears nowhere else in the catalog, so seeing this color automatically associates with item availability.

LOGGING IN We’ve eliminated the login area on the startpage in favor of a couple links to the dedicated login

page. Users often get confused when they see prominent fields prompting them to enter their username and password, because they think they have to do so in order to conduct a search. We’ve found that the best way to eliminate this confusion is to simply not even give them the option of logging in directly from the startpage.

CONSISTENCY One of the biggest components of graphic design, and web design especially, is consistency.

Just like with the color pallet, all of the fonts, buttons, icons, and menus have been styled specifically to conform to our custom OPAC design, and are consistent throughout. Never at any point should a user feel like something is out of place.

Through all of the major points outlined above, consistency of design and logic of layout can be

achieved in a custom OPAC. There is no reason why a user should be confused as to what information is important, what they’re looking at, or how to do what they need to do.

LEARN MORE For a more technical look at how our design works, visit libill.hartford.edu/koha/development. 1.2 Using JavaScript when CSS isn’t enough While CSS is very powerful, there are, of course, several things it can’t do—simply because it’s not meant to. There are a lot of display features we’ve added to our version of Koha which aren’t attainable through CSS or by setting a system preference. Instead, we’ve used JavaScript, one of the most popular web scripting languages there is. Any custom JavaScript or links to external JavaScript files can be implemented through the opacuserjs setting in Koha’s system preferences.

LEARN MORE If you’re not familiar with JavaScript, you can learn at www.w3schools.com/js. A number of important display updates are made with a single JavaScript file we’ve dubbed FaceLift. Just like in Koha’s system preferences, there are a series of preferences in the beginning of the file that allow each feature of FaceLift to be turned on or off individually. Here are some of the major features of FaceLift: BOOKCOVERS Bookcovers provided by Google Books API are made much larger on both the results and record

pages. These large coves are clearer and less cluttered, and help put visual emphasis on materials. Using CSS, the bookcovers can be styled to fit with the general OPAC theme; we’ve added a thin white border and subtle drop-shadow to add depth and realism to the covers and the overall page itself.

Koha Development Conference Cook & Fuller / Improving the Koha OPAC Interface: Supplement 4(10)

August 2012 Get full documentation at http://libill.hartford.edu/koha REV 803/1325

To make bookcovers larger, FaceLift dynamically adjusts the “zoom” parameter that appears in the URL of each bookcover image. The default zoom factor is 5; we changed ours to 1 (which, oddly enough, is larger).

RESULTS PAGE RECORD PAGE

SMARTWRAPPING Depending on the size of the browser window and the length of an item's record, SmartWrapping

automatically chooses whether or not to wrap text around the bookcover on record pages. Long records wrap all the time, to save space; medium records generally wrap, unless the browser window can accommodate it; short records never wrap, preserving a neat layout.

FaceLift does this by analyzing the height of the record and the height of the browser window. It then decides whether or not to wrap text based on how those properties compare to certain thresholds. By default, if the record height is greater than 700px, or if the window height is less than the record height plus 200px, the text will wrap to save space. Otherwise, the height of the bookcover container is set to 15 percent greater than the height of the record, preventing wrapping. These thresholds can be adjusted to meet your particular catalog’s needs.

SHORT RECORD LONG RECORD TOP NAVIGATION You can now browse through pages of results at both the top and bottom of the list. If you've

sorted results alphabetically, you'll no longer have to waste time scrolling to the bottom of each page in order to get to the next one. That’s because FaceLift copies the page navigation from the bottom of results lists and adds a second one at the top.

Koha Development Conference Cook & Fuller / Improving the Koha OPAC Interface: Supplement 5(10)

August 2012 Get full documentation at http://libill.hartford.edu/koha REV 803/1325

HOLDINGS TABLE FaceLift can help clean up holdings tables on record pages by removing empty summaries. In

Koha, records with linked summaries display holdings by nesting one table inside another. Often, though, those summary displays are empty in the OPAC and take up an enormous amount of space. By using a handful of XSLT code to tell FaceLift when it’s OK to remove that outer summary table, only the inner holding table remains.

Items with holdings summaries, like periodicals, still display summary information. The types of

items you'd like to have display holdings summaries can be set through XSLT.

BOOK PERIODICAL PRESERVE QUERIES FaceLift keeps your search queries, format selection, and keyword search type between pages,

so you can start a revised search from anywhere without having to re-select those options. This feature is currently being developed in the sandbox.

KEY COMMANDS FaceLift, or JavaScript really, has the power to add key commands for any function you can think

of. We’re currently experimenting in the sandbox with some commands for navigating search results, returning to results lists, and beginning a new search.

LEARN MORE You can learn about and download FaceLift at libill.hartford.edu/koha/facelift.

Koha Development Conference Cook & Fuller / Improving the Koha OPAC Interface: Supplement 6(10)

August 2012 Get full documentation at http://libill.hartford.edu/koha REV 803/1325

PART 2

XSLT 2.1 What is XSLT? To understand what XSLT is, you have to see it in context. We begin with a bit of MARC.

100 10 $aSandburg, Carl, $d1878-1967. Behind the scenes, this piece of MARC gets transformed into MARCXML, moving closer to a format that a web browser is able to read. <datafield tag="100" ind1="1" ind2="0">

<subfield code="a">Sandburg, Carl,</subfield> <subfield code="d">1878-1967.</subfield>

</datafield> The XSLT takes this data and transforms it into HTML, specifying what fields and subfields should be displayed, how and where they should be displayed, creating links, and adding in text where needed. Most impressively, the displays can be modified based on item format or any other variable, allowing the best display for that particular item. <h5 class="author">By Sandburg, Carl, 1878-1967. </h5> The XSLT to make the above example work would look something like this: <xsl:if test="marc:datafield[@tag=100]">

<h5 class="author"> By <xsl:for-each select="marc:datafield[@tag=100]”> <xsl:value-of select="marc:subfield[@code='a']"/> <xsl:value-of select="marc:subfield[@code='d']"/> </xsl:for-each> </h5>

</xsl:if> This translates to “If there is a 100 field, then display subfields a and d within an <h5> HTML tag and put the word By in front of them.” 2.2 Modifying XSLT There are currently four XSLT stylesheets available in Koha, all of which can be edited in Koha’s system preferences:

• MARC21slim2OPACDetail (OPAC details page) • MARC21slim2OPACResults (OPAC results page) • MARC21slim2intranetDetail (Staff Client details page) • MARC21slim2intranetResults (Staff Client results page)

If those settings are currently blank, you can use the XSLT Manager within Tools to populate them with the default XSLT. This also allows you to reset the XSLT sheets to the defaults if you have modified them. Simply select the templates you would like to reset and click on Submit Query. XSLT is a very picky code, which will result in an error message from even the smallest coding error. Make sure you have a copy of your last functional XSLT sheet saved somewhere so you can revert to that if modifications go wrong.

LEARN MORE See http://libill.hartford.edu/koha/docs/koha_XSLT_howto.pdf for more Koha XSLT information.

Koha Development Conference Cook & Fuller / Improving the Koha OPAC Interface: Supplement 7(10)

August 2012 Get full documentation at http://libill.hartford.edu/koha REV 803/1325

2.3 What you can do with it Let’s look at an example of the details record for a CD to see how we can use XSLT to improve the display of this record. The below screenshot is of a CD with two works on it using the default XSLT.

Here it the same recording with University of Hartford’s modified XSLT:

Important changes include:

1. Inclusion of the complete 245 field in the title line.

2. Including all subfields for the 240 uniform title, turning “Sonatas, viola da gamba, harpsichord” into “Sonatas, viola da gamba, harpsichord, BWV 1028, D major; arr.”, which adds in very valuable information.

3. Removing the “By” line in favor of the more logical (and easier to read) sections “Works on this sound recording (Uniform Titles)” and “People/groups involved with this recording.” This takes advantage of the ability in XSLT to specify different displays based on format.

4. Adding in the 511 Performers note to clarify the roles of the people involved with the recording.

5. Adding the Format information to clarify that this is a CD (also required extra code to distinguish CDs from LPs, as the default XSLT treats them both as Sound Discs).

Koha Development Conference Cook & Fuller / Improving the Koha OPAC Interface: Supplement 8(10)

August 2012 Get full documentation at http://libill.hartford.edu/koha REV 803/1325

6. Moving the MARC views to the bottom of the page, as regular users will not need them very often, and removing Card View as all the data that used to be available only there is now available on the Normal view.

LEARN MORE For more examples of XSLT changes from the University of Hartford, see:

Results: http://libill.hartford.edu/koha/docs/koha_XSLT_resultschanges.pdf Details: http://libill.hartford.edu/koha/docs/koha_XSLT_detailschanges.pdf

PART 3

Going Mobile 3.1 That’s possible? Yes, as a matter of fact. Not only is it possible, it’s quite necessary. Developing a mobile version of the online catalog is critical in giving patrons the tools they need to find materials wherever they are. In designing such a catalog, a lot of thought must go into what users might like to accomplish on a mobile device, and how best to allow them to do so. A mobile version of any website must allow the user to do nearly as many tasks and get as much information as they otherwise would on a standard browser, but with a minimalist interface. The library catalog is no different, and we’ve designed our mobile version, dubbed the “mOPAC”, with that in mind. Detection of mobile devices is normally done server-side. Since there’s no mobile detection build into Koha, however, our mobile catalog works by detecting mobile devices client-side using JavaScript. This method is less reliable, but it can get the job done for most modern smartphones, like iPhones and similar devices. We’ve tested our mobile catalog using the latest iOS, Android, and Windows Phone mobile operating systems, and it may work on others too. 3.2 Understanding how it works It is incredibly important to realize that the mobile catalog is not running on a separate website, server, or with other software. It is the exact same site and URL as the regular, full-blown catalog. The only difference between the two is how they look—essentially the CSS stylesheet they use. As the page is loading, a JavaScript file (put in through the opacuserjs preference) determines whether or not the catalog is being viewed on a mobile device. If it’s not, the script stops and the catalog appears as normal. If it is, though, the script continues and replaces the main OPAC stylesheet with one optimized for mobile devices, and the catalog appears formatted for small screens. The JavaScript also makes some changes to the page after it loads, hiding some elements, adding others, and changing syntax, etc.

Koha Development Conference Cook & Fuller / Improving the Koha OPAC Interface: Supplement 9(10)

August 2012 Get full documentation at http://libill.hartford.edu/koha REV 803/1325

3.3 Feature Set There’s quite a lot of things that users do in the OPAC that they simply won’t care about in a mobile version. Finding information using a phone is supposed to be quick and simple, with as little distractions as possible. The main goal of a mobile catalog is to be just that: a catalog. It should do two things, and do them well: allow users to search for materials, and allow them to check their library account. Here’s an overview of the major differences between the full OPAC and our mobile version: OPAC Mobile GENERAL User Accounts Yes Yes Login Display as link Display as link Cart Yes No Lists Yes No

ACCOUNT My Summary Yes Yes My Fines Yes Yes* My Lists Yes Yes* My Personal Details Yes Yes My Borrowing Relations Yes No Change My Password Yes No My Messaging Yes No

SEARCHING Search Bar • Display elements inline • Display elements stacked • Show on every page • Show on startpage only Advanced Search Yes No Tag Cloud Yes No Course Reserves Yes Yes* RESULTS Information Included Title, author, edition, type, format, Title, author, location, availability literary form, nature of contents, other titles, publisher, location, availability, other actions Search Facets Yes No Results Controls Yes No Bookcovers Yes No RECORDS Save Record Yes No

View Options Normal, MARC, Exp. MARC, ISBD Normal Bookcovers Yes Yes * Indicates features still in development for mobile.

Koha Development Conference Cook & Fuller / Improving the Koha OPAC Interface: Supplement 10(10)

August 2012 Get full documentation at http://libill.hartford.edu/koha REV 803/1325

3.4 Interface It’s hard to describe the mOPAC without actually using it. Like any mobile website or app, you have to see and touch it to really get a sense of its intuitiveness and functionality. Remember, this is still the same catalog site as the full OPAC—it just looks different. Here’s how different:

LEARN MORE You can learn more about our mOPAC at libill.hartford.edu/koha/mobile, or visit it by browsing over to hartford.waldo.kohalibrary.com on your smartphone, beginning August 7th, 2012.

STARTPAGE The mobile version of the catalog makes searching for material your number-one priority. All the search options you're familiar with on the full site are available here too, in the same logical order. If you've come to the catalog to manage your library account instead, logging in is just a tap away. The startpage is formatted so that all search options, including the search type and format dropdown menus, are still visible even while your phone's keyboard is, too.

RESULTS Results pages are easier to browse through than ever. Only the essential information is there, including the title, author, location, and availability. More information isn't far away — simply tap a title to bring up an item’s record. And chances are, if you're browsing the catalog from your phone, you may already have an idea of what you're looking for. Consolidated results helps keep your focus on what really matters.

RECORDS All the information you're used to seeing about items in the full catalog is available in the mobile version, too. Record pages are headlined by the bookcover, title and author. Below is publisher and edition data, subject information, and general notes and summary where applicable. Use the navigation buttons up top to move between items in the results list, with out having to go back and forth. Ready to start a new search? Tap the header to return to the startpage.