I like LibGuides. I'm generally rather sniffy about building-blocks web content because it's usually quite limiting and ridden with javascript (*shivers at the memory of certain VLEs*). But LibGuides is different: there's none of the painful clunk and nested frames one often gets with these things, and, most importantly, a LibGuide can be as simple or as complicated as you want it to be. In a good way. In a proper web-standard sort of way. LibGuides uses boxes of content which you can arrange around your page. The box content can be edited using a WYSIWYG editor or by using a Plain-Text source editor, so you can be as simplistic or as tricksy as you like when adding stuff to the page. In theory your page could just be one big box which you edit as you might edit any other web page. You can use their basic bits of Duplo, or you can mortar in some real solid bricks. And this flexibility is good, because it suits Walter who's up for retirement and has no interest in engaging with HTML, and it suits Zoe the web whiz-kid who wants to employ all the tricks she learnt in her computer science days.
My first encounter with this fully codable and customizable world was when I was playing around with my LibGuides profile and accidentally misused the <plaintext> tag. <plaintext> does not change styled text into unstyled text as I had guessed it might. <plaintext> renders any subsequent HTML code as plain text, and should be accompanied by a closing </plaintext> tag. I did not accompany it with an accompanying </plaintext> tag, and consequently the LibGuides profile web-form melted before my eyes into a slurry of pointy brackets. I had to hack the code in my browser (see last month's post on the virtues of Opera) to save my LibGuides from the internet version of a China crisis. It was a frightening moment, but one which excited me to the freedoms inherent in LibGuides.
So lesson one: don't use a <plaintext> tag in LibGuides. On a related note, always be sure to close any <div> tags you might use, lest they hang beyond your box and prevent you from editing it ever again. In other words: it is very easy to break bits of LibGuides and there is no "undo" button. If you're going to play around, do it with either a) a little knowledge (a dangerous thing) or b) a browser that lets you tweak the script locally should the worst come to the worst.
The last paragraph was needlessly alarmist, you will be relieved to hear. While it is very easy to break bits of LibGuides, you are unlikely to ever do anything that will break bits of LibGuides. LibGuides is pretty sturdy even if it can be unforgiving.
Last December I was charged with the task of setting up a booking system on LibGuides (using its sister application: LibCal) and spent a couple of weeks tweaking the style-sheets to get them to match the library branding. I had used style-sheets before, on my own web-pages, but never for anything more than setting fonts. It was an exciting learning experience, and I began to get an idea as to the more unconventional areas of LibGuides customisation.
During my time at the University of Hull this year I was asked to research the ways that other institutions use their LibGuides. We then pulled together something of a wish-list of ideas: what we thought should be on the guides, and how we might make them look and work in a way that would be foolproof to navigate. I was given the job of putting some of these ideas into practice.
The image above shows your typical average LibGuide (the content and tab order represent the mode of the top umpteen Google hits for libguides.ac.uk and subjectguides.ac.uk domains). There is some logic to this content which is why it occurs with such regularity, but the appearance owes most to the box from which it came: we're looking at a factory default, and not everything in that default is strictly useful.
In this post I'm going to talk about some of the tricks I learnt in the process of giving Hull's LibGuides a facelift. The reasons for the changes we made, both cosmetically and in terms of content, are probably better left to those still involved with the project: this is not a corporate account of a rebranding. I'm here to talk about the mechanics of LibGuides more generally, and what can be achieved. But as an illustration you might like to compare the above generic page with one of the new Hull guides (Computer Science, for example).
The secret to customising LibGuides lies in mastering the CSS. Before I started playing about the other month I didn't know very much about the finer points of style sheets, but nosing at the page source of various LibGuides across the country alerted me to some useful bits of code, and the first one of any real import was:
Don't want some part of LibGuides to show up on the page? {display:none;} is your friend. Say you were worried that the LibGuides search box distracted from your catalogue search box, you could switch off the former by putting <style>.lgsearch{display:none;}</style> somewhere in your page (the custom CSS section if you have that option, though any old bit of box via Plain-Text Edit will do). All you need to know to switch off a part is its element name (e.g. .lgsearch in the case of the search box) and that's the hardest part. The slow way of doing it is to parse the page source with a fine-toothed comb and a knowledge of HTML and CSS. The quick way is to use a DOM inspector, and that's the approach I took to taking, using the Opera browser's built-in DOM inspector: Dragonfly. All I then had to do was right-click on the bit of the page I was interested in and inspect it. I could even tweak the code 'live' to see what would happen. I have no better words to describe such playing about than: "well cool!" Pretty much every bit of a LibGuide has its own class and can therefore be turned on or off. Say you wanted to generate a list of guides by using the built-in box options, but you didn't want the names of the list owners to be displayed (as they are by default in such lists). It so happens that the list authors have the class ".pdisplay_author", so you can consign them to the back of the net with a quick line of code.
{visibility:hidden;} is {display:none;}'s more sophisticated sister: she renders elements invisible rather than non-existent. Applying {visibility:hidden;} to this paragraph would leave an enigmatic gap on the page, while {display:none;} would shunt the next paragraph up into its place.
But it's not just about turning things on or off or obscuring them from view. You can set the font styles of every single different flavour of text, so if you wanted bigger type for your lists of links, <style>.itemlist li {font-size: 200%;}</style> would double the default font-size. A similar approach can be applied to the tabs at the top of the page, should you favour a chunkier look.
As with all things, the more you fiddle, the more you learn. http://www.w3schools.com/css/ has become a regular reference as I've sought to put ideas into code. Hours have been spent shunting box content around with margin tags. The best way to find out how something works remains to find an example of that something and to take it apart (this was the approach I took when replicating the quick links menu from the main University website). This is not as easy as it used to be a decade ago, because things are increasingly held in separate style sheets (which is why a DOM inspector is a handy bit of kit to have to hand). Not everyone's going to want to do that. Most of you are probably already reeling at the various different flavours of brackets and punctuation I've thrown at the page. But even if you know only the faintest smattering of HTML or CSS, you can stick it into LibGuides quite freely, and that is something rather refreshing and also rather liberating.
There are still some frustrating limitations with LibGuides, chief among them being that you can't create replicable directory structures as you might with web-pages: a link to a tab on one guide will need to be replaced if you make a copy of that guide, requiring a fair bit of tedious mucking about if you're rolling out a new template that makes use of such links. But mostly LibGuides are a Good Thing: straight, friendly webpages put together in a way that suits beginners and experts alike. And that's why I like them.
Some useful element identifiers:
My first encounter with this fully codable and customizable world was when I was playing around with my LibGuides profile and accidentally misused the <plaintext> tag. <plaintext> does not change styled text into unstyled text as I had guessed it might. <plaintext> renders any subsequent HTML code as plain text, and should be accompanied by a closing </plaintext> tag. I did not accompany it with an accompanying </plaintext> tag, and consequently the LibGuides profile web-form melted before my eyes into a slurry of pointy brackets. I had to hack the code in my browser (see last month's post on the virtues of Opera) to save my LibGuides from the internet version of a China crisis. It was a frightening moment, but one which excited me to the freedoms inherent in LibGuides.
So lesson one: don't use a <plaintext> tag in LibGuides. On a related note, always be sure to close any <div> tags you might use, lest they hang beyond your box and prevent you from editing it ever again. In other words: it is very easy to break bits of LibGuides and there is no "undo" button. If you're going to play around, do it with either a) a little knowledge (a dangerous thing) or b) a browser that lets you tweak the script locally should the worst come to the worst.
The last paragraph was needlessly alarmist, you will be relieved to hear. While it is very easy to break bits of LibGuides, you are unlikely to ever do anything that will break bits of LibGuides. LibGuides is pretty sturdy even if it can be unforgiving.
Last December I was charged with the task of setting up a booking system on LibGuides (using its sister application: LibCal) and spent a couple of weeks tweaking the style-sheets to get them to match the library branding. I had used style-sheets before, on my own web-pages, but never for anything more than setting fonts. It was an exciting learning experience, and I began to get an idea as to the more unconventional areas of LibGuides customisation.
During my time at the University of Hull this year I was asked to research the ways that other institutions use their LibGuides. We then pulled together something of a wish-list of ideas: what we thought should be on the guides, and how we might make them look and work in a way that would be foolproof to navigate. I was given the job of putting some of these ideas into practice.
What most LibGuides tend to look like.
The image above shows your typical average LibGuide (the content and tab order represent the mode of the top umpteen Google hits for libguides.ac.uk and subjectguides.ac.uk domains). There is some logic to this content which is why it occurs with such regularity, but the appearance owes most to the box from which it came: we're looking at a factory default, and not everything in that default is strictly useful.
In this post I'm going to talk about some of the tricks I learnt in the process of giving Hull's LibGuides a facelift. The reasons for the changes we made, both cosmetically and in terms of content, are probably better left to those still involved with the project: this is not a corporate account of a rebranding. I'm here to talk about the mechanics of LibGuides more generally, and what can be achieved. But as an illustration you might like to compare the above generic page with one of the new Hull guides (Computer Science, for example).
The secret to customising LibGuides lies in mastering the CSS. Before I started playing about the other month I didn't know very much about the finer points of style sheets, but nosing at the page source of various LibGuides across the country alerted me to some useful bits of code, and the first one of any real import was:
{display:none;}
Don't want some part of LibGuides to show up on the page? {display:none;} is your friend. Say you were worried that the LibGuides search box distracted from your catalogue search box, you could switch off the former by putting <style>.lgsearch{display:none;}</style> somewhere in your page (the custom CSS section if you have that option, though any old bit of box via Plain-Text Edit will do). All you need to know to switch off a part is its element name (e.g. .lgsearch in the case of the search box) and that's the hardest part. The slow way of doing it is to parse the page source with a fine-toothed comb and a knowledge of HTML and CSS. The quick way is to use a DOM inspector, and that's the approach I took to taking, using the Opera browser's built-in DOM inspector: Dragonfly. All I then had to do was right-click on the bit of the page I was interested in and inspect it. I could even tweak the code 'live' to see what would happen. I have no better words to describe such playing about than: "well cool!" Pretty much every bit of a LibGuide has its own class and can therefore be turned on or off. Say you wanted to generate a list of guides by using the built-in box options, but you didn't want the names of the list owners to be displayed (as they are by default in such lists). It so happens that the list authors have the class ".pdisplay_author", so you can consign them to the back of the net with a quick line of code.
{visibility:hidden;} is {display:none;}'s more sophisticated sister: she renders elements invisible rather than non-existent. Applying {visibility:hidden;} to this paragraph would leave an enigmatic gap on the page, while {display:none;} would shunt the next paragraph up into its place.
But it's not just about turning things on or off or obscuring them from view. You can set the font styles of every single different flavour of text, so if you wanted bigger type for your lists of links, <style>.itemlist li {font-size: 200%;}</style> would double the default font-size. A similar approach can be applied to the tabs at the top of the page, should you favour a chunkier look.
As with all things, the more you fiddle, the more you learn. http://www.w3schools.com/css/ has become a regular reference as I've sought to put ideas into code. Hours have been spent shunting box content around with margin tags. The best way to find out how something works remains to find an example of that something and to take it apart (this was the approach I took when replicating the quick links menu from the main University website). This is not as easy as it used to be a decade ago, because things are increasingly held in separate style sheets (which is why a DOM inspector is a handy bit of kit to have to hand). Not everyone's going to want to do that. Most of you are probably already reeling at the various different flavours of brackets and punctuation I've thrown at the page. But even if you know only the faintest smattering of HTML or CSS, you can stick it into LibGuides quite freely, and that is something rather refreshing and also rather liberating.
There are still some frustrating limitations with LibGuides, chief among them being that you can't create replicable directory structures as you might with web-pages: a link to a tab on one guide will need to be replaced if you make a copy of that guide, requiring a fair bit of tedious mucking about if you're rolling out a new template that makes use of such links. But mostly LibGuides are a Good Thing: straight, friendly webpages put together in a way that suits beginners and experts alike. And that's why I like them.
| topnav | The bar at the top that contains: |
| breadcrumbsl | The breadcrumbs trail |
| bc_library_home | The library homepage part of the breadcrumbs |
| bc_lbguides_home | The libguides homepage part of the breadcrumbs |
| bc_guide_name | The current page in the breadcrumbs |
| guide_header_title | The page title |
| guidedesc | The page blurb |
| guideattr | The bar containing: |
| lastupdate | Last update |
| guideurl | URL |
| printguideurl | Print guide option |
| rssupdatelink | RSS feed |
| addthis_button | Share button |
| tabsI | Tabs (other versions available depending on set-up) |
| stitle | The bar containing: |
| guide_tab_title_bar_page_name | Page name |
| guidse_tab_title_bar_page_print | Print page option |
| lgsearch | Search box |
| innerbox | Internal box content (generic) |
| headerbox | Box title (generic) |
| roundbox outerbox | Parts of the whole box (generic) |
| boxatt | Generated content (generic) |
| box_comments | Box comments line (generic) |
No comments:
Post a Comment