Tag Archives: YUI

Customizing your Koha OPAC using YUI Grids

In a previous post I talked about YUI Grids and how we use them to structure Koha pages–all very abstract unless you’re interested in designing Koha pages.  But there are some opportunities to use the Grids techniques in OPAC customization.

Two OPAC system preferences, opacheader and OpacMainUserBlock, are good candidates for some Grids experiments. Both let us add our own HTML markup to the Koha OPAC design, and both are placed within the default page structure defined by the Grids framework. That should let us use our own structure of grids and units to create containers for our content.

Let’s start with opacheader, and the basic grid/unit example of two equal-width containers, or columns:

<div class="yui-g">
<div class="yui-u first">
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.</p></div>

<div class="yui-u">
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.</p>
</div>
</div>

Add that to your opacheader system pref and you’ll get this:

Click to enlarge screenshot

Click to enlarge screenshot

If that doesn’t look terribly thrilling (or even practical), think of it this way:

Click to view screenshot

Click to enlarge screenshot

Somewhat more practical, at least? And remember, you’ve got a selection of preset grids to choose from:

Quoted from the YUI Grids page

Customizing OpacMainUserBlock

OpacMainUserBlock is the place where it would be the most useful to leverage the Grids framework’s power. The main page of the OPAC is a blank slate for your library’s custom content. It would be great to be able to use the built-in grids system for laying out that content.

Let’s try the same sample markup from the previous example. Two easy and equal-width columns, right? Wrong:

Click to enlarge screenshot

Click to enlarge screenshot

What’s going on? That doesn’t make sense, does it? Well…It makes a certain amount of sense. We have to remember that when dealing with OpacMainUserBlock we’re already working within an existing grid:

The default structure of the OPAC main page, non-logged-in state

The default structure of the OPAC main page, non-logged-in state

The OPAC template for the main page defines a grid with a 75% block (“yui-u first” in the diagram above) and a 25% block (“yui-u”). That means that when we add markup to OpacMainUserBlock, we’re adding that markup within a <div class=”yui-ge first”>. The YUI Grids documentation tells us that if we want to nest grids we should do so by nesting <div class=”yui-g”> directly. Try this in OpacMainUserBlock:


<div class="yui-g first">
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.</p></div>

<div class="yui-g">
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.</p>
</div>

This is the result:

Click to enlarge screenshot

Click to enlarge screenshot

Better. Usable, anyway. But why did we get another 75%/25% split? We didn’t add a grid with the “yui-ge” class. To be honest, I’m not sure whether there is any way to avoid getting the 75%/25% split when we nest a grid here.  It seems that any time we nest a grid inside a “yui-ge” grid, we get another “yui-ge” grid. In other words, it’s turtles all the way down:

Click to view example

Click to view example

Not freedom, only some flexibility

It seems were left with very limited choices if we want to try to leverage YUI’s Grids system in the context of OpacMainUserBlock. If you’re content with a 75%/25% split, then you’re okay. Otherwise you’re on your own to define a content layout your own way.

If you want to use tables, I won’t tell.

YUI Grids and the Koha OPAC

Koha uses the Yahoo! UI Library Grids CSS framework for both the OPAC and the staff client. When we revamped the Koha interface for 3.0 the Grids framework was chosen because it would simply the process of structuring pages while giving us a pretty good selection of possible layouts.

A nice feature of the Grids framework is that you can control the layout of your page with relatively minor changes in markup. Here’s an example for one of the basic layouts:


<div id="doc">
<div id="bd">

<div id="yui-main">
<div class="yui-b">
<p>Main Content</p>
</div>
</div>

<div class="yui-b">
<p>Sidebar</p>
</div>

</div>
</div>

You can see that YUI’s Grids framework suffers from the same problem a lot of CSS frameworks  have: the class names are pretty nonsensical if you’re not used to them. I consider this to be par for the course: Better that they be nonsensical than have semantic-sounding names which aren’t appropriate for your actual page structure.

How does the framework make it easy for us to change page layouts? I’ve put together a simple example. This example uses JavaScript to swap out one class name. Try it and see how much can change based on one class name:

yui-layout-demo1

Click to try the demo

The above example shows how the “primary” page structure can be changed. I say primary because you can only choose one of those layouts at a time. If you want to have additional columns or blocks within that layout you can use “grids” and “units” within that main page structure:

Just like with the page structure, there is a set of pre-defined grid structures you can use within your page. The simplest is a set of two equal-width containers:


<div id="doc">
<div id="bd">
<div class="yui-g">

<div class="yui-u first">
<p>First grid unit</p>
</div>

<div class="yui-u">
<p>Second grid unit</p>
</div>

</div>
</div>
</div>

Just like with the page structure example, a change to the grid’s class name can affect the layout of the units within it. Notice that the grid/unit structure is changing within the page structure we defined before: a single main block with a left-hand sidebar:

Click the try the demo

Click the try the demo

The power of the framework’s grid/unit structure really comes into play when you start nesting grids within grids. Start with a grid which creates two equal columns, and then nest the same two-column grid within each of those columns:

<div id="doc">
<div id="bd">
<div class="yui-g">

<div class="yui-g first">

<div class="yui-u first">
<p>Unit one, sub-unit one</p>
</div>
<div class="yui-u">
<p>Unit one, sub-unit two</p>
</div>
</div>

<div class="yui-g">

<div class="yui-u first">
<p>Unit two, sub-unit one</p>
</div>
<div class="yui-u first">
<p>Unit two, sub-unit two</p>
</div>
</div>
</div>

</div>
</div>

In the markup above, instead of nesting a unit (‘<div class=”yui-u”>’) inside a grid (‘<div class=”yui-g”>’), we’re nesting a grid inside a grid. The containing grid can still be altered to change the layout of the units inside it:

Click to try demo

Click to try demo

The Koha OPAC’s grid structure

How is this implemented in the Koha OPAC? Koha has to take advantage of  the Grids framework’s flexibility when obeying different conditions in the OPAC. Take, for example, the main page of the OPAC. There are four possible layouts the user might see based on state and system preferences:

opac-layout-no-opacnav-logged-out

No OpacNav, not logged in

opac-layout-no-opacnav-logged-in

No OpacNav, logged in

opac-layout-with-opacnav-logged-out

OpacNav, not logged in

opac-layout-with-opacnav-logged-in

OpacNav, logged in


Using some logic in the Koha templates, the layout can be easily altered based on each of those conditions. And because the Grids framework makes it so easy to switch between those different layouts, the template can be much simpler:


<!-- TMPL_IF NAME="OpacNav" -->
<div id="doc3" class="yui-t1">
<!-- TMPL_ELSE -->
<div id="doc3" class="yui-t7">
<!-- /TMPL_IF -->

The template logic can check one condition (whether the OpacNav system preference is populated) and alter the page layout accordingly.

What does this mean to me?

Unless you’re hacking Koha templates you won’t many opportunities to build your own grids. However, there are a couple of instance where you might want to try it, and I’ll talk about that in my next post.