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.