Koha has strong separation between OPAC and staff client functionalities. If you log in to the OPAC as a staff user you don’t have any kind of elevated privileges compared to any other user. This is good for extra security, but it can be frustrating for staff if they happen to be looking at a record in the OPAC and want to switch to the staff client.Continue reading →

I’ve talked before about Firebug’s inspector tool for examinating the markup of a page and its associated style. When you inspect a particular element in the markup you can see the CSS rules that have been applied to it. But what if the styles applied to an element change based on user interaction? How do you “catch” the style of a hover interaction, or of an element which has focus?

For instance: In the Koha staff client there is a global style for the color of a link when you hover your cursor over it.

This color is defined in the staff client’s main CSS file, staff-global.css:

a:hover, a:active {
color : #538200;
text-decoration: none;
}

However, if you use Firebug’s inspector to examine a link you won’t see that CSS:

That’s because the Firebug inspector isn’t showing you the “hover” state of the link–at least not unless you’re mouse cursor is hovering over the link at the time:

But what if we want to use Firebug’s Style tab to live-edit the CSS of the hover state? As soon as we move our mouse away from the link the hover state disappears from the style pane, so we can’t edit it. Luckily Firebug has an option built in for “activating” three different interaction states: Hover, Active, and Focus:

By selecting “:hover” we can “pin” the hover state to keep it activated so that we can inspect and change it:

We can test the “focus” option by inspecting the style of any standard text input in Koha, for example the barcode field on the check-in page:

This lets us see that there is a CSS rule defining a default border style for <input> and <textarea>

As of Koha 3.14 the OPAC has a new default theme: Bootstrap. It’s a theme I developed with the intention of offering a flexible, modern, and responsive theme option for Koha libraries. It takes as its visual basis the CCSR theme, added in 3.10. However, it greatly expands the catalog’s mobile-friendliness over the CCSR theme.

The Bootstrap theme is so named because it uses the Bootstrap framework, a set of JavaScript and Cascading Style Sheet tools for use by web developers to quickly and easily add functionality to sites. Bootstrap helps web developers do things like add menus, dialogs, tooltips, etc. Bootstrap also brings some improved default styling to buttons and forms.

Like the CCSR theme, the Bootstrap CSS framework offers something called responsiveness. This means that when the size of your viewport (for instance, the browser window) changes, the layout of the page changes in response. With a desktop browser you can see this by resizing the browser window. Users with mobile devices of varying sizes will see a layout more closely tailored to the size of the screen on their device.

In the CCSR theme there is only one breakpoint. Breakpoints are the pixel dimensions at which the layout changes. When browsing a catalog which uses the CCSR theme, if the viewport size is below 700 pixels the layout changes to accommodate the smaller screen.

Bootstrap offers a few more breakpoints. If you’re reading this in a desktop browser you can view this demo page and resize your browser window to see the effects on the page layout. In Bootstrap there are three primary breakpoints, for large, medium, and small screens.

Koha’s new Bootstrap theme expands on these default breakpoints by adding a few more which are tuned to the layout of the OPAC.

Customization

The Bootstrap theme was designed to be just as flexible for customization as the old default theme. All the customizable regions are there. The same options are available for adding custom CSS and JavaScript. However, the responsive nature of the theme adds some new complications.

If you’re adding content to a region like opacheader or OpacMainUserBlock you’ll need to keep in mind that your content should respond comfortably to the same range of breakpoints that the rest of the catalog does. If you’re simply adding text this isn’t a problem because text flows naturally no matter the page width. If you’re adding something more complicated like images or navigation menus it will require some additional testing.

If you find your custom content is not flowing nicely at multiple screen sizes you can try tailoring that content with CSS using the same major breakpoints which are built into the Bootstrap theme:

If you would like to get visual feedback in the Bootstrap OPAC about which media queries are being applied, add this HTML to the opacheader system preference:

<div id="oh"></div>

Some examples

One of the more common items to customize in the previous default OPAC theme was the logo. My first post here was on Customizing Koha 3’s OPAC logo. The Bootstrap theme no longer has an area designed specifically for a logo. The main search bar area takes up the full width of the screen. This makes it more adaptable to various screen sizes.

There is a Koha logo in the “nav bar” region at the very top of the screen which could be customized using CSS, but it’s quite small and disappears at narrower screen widths.

Image banner

A simple option is to add an image to the opacheader region. This is a simple option because the built-in CSS for images allows an image banner to naturally resize to match the browser width. This method uses the browser’s built-in image resizing algorithm.

At the default browser font size/zoom setting these tabs work with a viewport width down to about 607 pixels wide:

Below that width the tabs start to wrap in an awkward way:

Here’s where the use of CSS media queries can help us out. Let’s say we determine that the layout breaks at 600 pixels wide (a browser extension like Web Developer Toolbar can help us find the correct number). Let’s write a media query which targets a browser window which is narrower than 600 pixels wide:

Now the tabs are styled one way when the screen width is above 600 pixels, and another when the width is below 600 pixels.

I hope this example gives you a sense of what is possible when it comes to customization in the new theme. Planning your customizations for more than one screen width can be time-consuming, and lots of trial and error will be involved. The outcome, however, is a site which will be much more broadly usable.

The Athens County Public Libraries are members of the Ohio eBook ProjectOhio Digital Library, a consortium of libraries who contribute to and share access to a collection of eBooks and other downloadable material through OverDrive. In order to make these resources more discoverable by our patrons we add MARC records for these titles to Koha.

When we started doing this we felt that it was important for the patrons to be able to tell very easily that the title they saw in search results was an electronic resource they could download. We already have many records in our catalog for web sites. We were concerned that these two types of resources would be difficult to distinguish.

An electronic resource in default OPAC search results

Since Koha gives us the ability to inject custom JavaScript into our OPAC, a JS-based solution seemed like the best option. The goal was to be able to use JS to examine each search result and look for a clue that any particular result was an Ohio eBook Project record. Luckily all the OEP records have something in common: A URL (stored in the MARC 856u) beginning with “http://ohdbks.” Here’s the JavaScript I came up with:

We loop through each td within the table inside #userresults, storing the index of each iteration as i.

The matched td is stored as a variable for easy reference.

The script finds an anchor tag which matches the string we’re looking for and stores that in a variable.

We want to refer later to the <a> tag’s parent container, so we use jQuery’s parent() to store that as linkc.

We pull the href attribute value for the previously select <a> tag.

If an href was found…

…hide the availability and “actions” (“Place hold,” “Add to cart”, etc.) elements which we don’t consider relevant to e-resource records.

Replace the contents of the original anchor tag’s container with new html which uses the previously-saved href attribute but changes the text of the link and adds a special CSS class.

We chose to label each eBook link “Check the Ohio Digital Library for availability” because Koha has no way of knowing whether a particular title is checked out. The link is styled by CSS added to Koha’s OPACUserCSS system preference:

Electronic resource detail page

When the patron clicks to view more information about one of those electronic resource titles they come to a detail page which presents additional opportunities to simplify the display for this type of record.

Since this kind of title is available only through the Ohio Digital Library web site we don’t actually have any local holdings, but when we add MARC records for these resources we include a dummy item to which we can attach some additional information. One reason for this is to be able to have a searchable collection code attached to each record. But showing holdings information to the patron isn’t very useful because none of it is relevant:

Holdings information displayed by default for electronic resources

Another aspect of the detail page which is less than ideal is that the link to the Ohio Digital Library is pretty well hidden in the other details about the title like publisher, subject headings, etc. We again turned to JavaScript to solve both of these problems at once:

This code is very similar to what we used on the search results page, but a little simpler.

Again we trigger this function when this particular area of the page (“span.online_resources”) has completed loading.

We find the link to the Ohio eBook Project download page and store the href attribute.

If an href was found…

Replace the holdings table (identified by theID #holdings) with an image which links to the OEP download page.

In four lines of JavaScript both goals are accomplished: The meaningless holdings table is gone, and a prominent link is added to the Ohio eBook Project download page for the title the patron is looking at.

It’s been almost three years since I wrote Colorizing the Cart and Lists buttons. My conclusion then was that we needed a fairly complex combination of markup, CSS, and background images to create the appearance of the buttons.

This works fairly well in Firefox, Safari, and Chrome. Unfortunately, it fails not only in Internet Explorer 6, 7, and 8, but all versions of Opera too. For the time being, our more-complex process gives the desired result to a wider audience.

The time has come for the simpler version. My patch for Koha bug 7584, “Update cart and lists buttons style using CSS3 features” has just appeared in Koha’s master branch, the development version which precedes an official release.

What has changed? Firefox, Safari, and Chrome have had updates since then, which has at the very least expanded the number of users of those browsers who are on a more recent version. Opera, one of the holdbacks in 2009, now supports the features required. Internet Explorer 6, 7, and 8 still linger of course, but Internet Explorer 9 is available now. IE9 offers better support for the features we need.

For me what has changed is that I now think that Koha should be a little more aggressive about taking advantage of the features of up to date browsers even if that means the experience isn’t the same for users of older browsers.

The new style

Let’s take a look at the revised markup. Where the previous version needed a lot of extra elements (<i>, <span>, etc) the new version doesn’t:

<a href="#">Cart</a>
<a id="listsmenulink" href="#">Lists</a>

I’ll quote the relevant declarations from the CSS. First, both buttons are assigned rounded corners:

Notice the variations: “-webkit-border-radius” is specific to Chrome and Safari. “-moz-border-radius” is specific to Mozilla-based browsers like Firefox. When we specify a single value like “5px” the value is applied equally to all four corners. You can also specify different values:

The values are applied clockwise starting with the upper left-hand corner.

Background Gradients

The other primary aspect of the buttons are their background colors. Previously we used a transparent image to give the button background a gradient. With CSS3 we can specify the gradient values right in our CSS. The easiest way to accomplish this is using the Ultimate CSS Gradient Generator.

A web-based tool for designing CSS gradients

With the CSS Gradient Generator you can use the visual tools for creating a gradient and the CSS will be generated for you. It generates CSS declarations specific to several major browser versions including Internet Explorer. There is even an option to upload a gradient image and have the Generator automatically match the colors.

Eight lines of CSS each doing the same thing for different browsers, starting with a solid background color for browsers which don’t support CSS3. This is the same kind of code which will be generated by the CSS Gradient Generator with one exception: The OPAC CSS also includes a background image for the Cart button in order to display the little cart icon.

There’s more to the styling of the buttons than rounded corners and background-gradients, but nothing which we haven’t seen before. Fire up Firebug (or your favorite browser’s DOM inspection tool) and inspect the buttons for more information.

What have we gained?

Just looking at the HTML markup it would seem we’ve gained a lot of efficiency over the <span>-heavy buttons in the older version. But the multiple lines of CSS more than make up for it. What advantages does the new design offer? Importantly, flexibility. We don’t have to create custom-colored 24-bit transparent images when changing the background color of the search bar. We can make all our changes, including changes to the Cart icon, right in the CSS. Border color, border radius, background-color (or gradient), it’s now 100% CSS and can be affected by a custom stylesheet or by changes to the OPACUserCSS system preference.

This change is going to require some revisions if your library has existing CSS customizations to these areas of the OPAC, but I think going forward these changes are going to prove to be beneficial to those seeking to customize their OPAC’s appearance.