Best Practices for LibGuides at UCLA

A web page, such as a LibGuide, differs fundamentally from a printed page. A printed page is a document. People recognize that it has a fixed place in time and a completed form. No one sends mail to a book author pointing out typos or mistakes with the expectation that the book in their hands will be corrected.

But web site authors do get that type of mail. Popular web sites may get hundreds of such messages a day. That's because people expect web sites to change, to be constantly under revision. A web page is a service, an ongoing commitment to provide the best and latest information available. When you create a web page, you are implicitly promising to your readers that you will do your best to keep that information current for as long as that page remains online.

This is even more important in the "Web 2.0" world, where most web sites are dynamically generated, pulling content from multiple sources, aggregating it, and presenting it in a fashion which is customized to individual user needs. While LibGuides preserves the concept of "authored content", it is also designed to allow authors to reuse one another's content, present dynamic content, and interact with external sites. Other librarians may be linking to or reusing content in your guides, with or without your knowledge. We're already exploring ways to integrate LibGuides with course websites developed in Moodle. In this type of interrelated environment, outdated content isn't just a pecadillo of your own guide—it's bad data which spreads and corrupts the other services which rely upon it.

To put it bluntly: if you don't intend to continuously update, revise, and improve your LibGuide, then don't bother making one. If you want to present a static guide, then there's nothing wrong with writing a guide in Word, converting it to PDF, and uploading that to the web. Both Word and PDFs can include internal and external hypertext links, fulfilling the exact same function as a web page. We can even index and link to such files from the LibGuides system. But there's no danger that other authors will be pulling isolated chunks of that content into their own guides. More importantly, users will understand that those formats are documents (there's a reason they're called Word documents and portable document format) and that the information contained therein has a date on it and must be used with that limitation in mind.

Assets

Assets include Links, Books in the Catalog, Documents, Widgets... basically all of the different content types other than Rich Text/HTML. (Databases are also assets, but have their own list.)

• Assets live "outside" the guides, so they can be centrally managed and re-used in multiple places.
• When an asset is used on a guide it's said to be "mapped" to that location.
• Re-used assets can only be edited from the original guide where it was placed or from the Assets list.
• If all of the mappings to an asset are deleted from guides, the asset continues to live on in the Assets list. It can only be fully deleted from the list.
• Each asset has an owner, the person who originally created it.

LibGuides has two tools to help you manage your Links. The Link Checker (found under Tools) and the Assets list (found under Content).

Assets List

Users with lots of guides will find it convenient to manage their links from the Assets list, especially if you've been good about re-using links rather than creating dozens of copies which have to be maintained independently.

Link Checker

LibGuides' Link Checker runs every Saturday, producing a weekly report which looks much like the Assets list, but only shows broken links (Links, Databases, and Books). Some notes:

• You can edit a broken link directly from the Link Checker, but if you want to delete it, you need to go to the Assets list under the Content menu.
• Even if you're the owner of an asset, don't delete it if it’s being used on guides other than your own. Just delete its appearances on your guides and let one of the admins know. They can re-assign the asset to a person who’s still using it, and it will become their problem.
• As with any link checker, LibGuides does give occasional (and sometime consistent) “false positives” on certain sites. Unfortunately there’s no way around this other than to learn to recognize and ignore them.
• Because assets exist outside of the guides, there's no way to filter out links on unpublished or private guides. Theoretically, the only reason for keeping an unpublished guide is to eventually publish it or to re-use the content, so it should be kept up-to-date anyway. If you just want to save a "historical copy" of your guide, export the guide as xml and delete the original. (Plus, old guides can be found in the Internet Archive.)
• You can make the Link Checker ignore any link by moving the URL out of the URL field into the Description or More Info field. Of course this renders it unusable by users also, but it's a quick and easy way to temporarily "fix" a link which only appears on unpublished guides. It will stop showing up in the broken link reports, but all of the info will be there for you to do a real fix should you decide to re-publish or re-use.

Check out the Statistics menu for a host of reports which can tell you how your guide is being used.