The Interactive Archivist

Cory L. Nimer
May 18, 2009

Introduction

Context of Case Study

During the summer of 2008, the Harold B. Lee Library at Brigham Young University adopted WordPress MU as the organization’s new Web content management system. Prior to this time the library had relied on manual processes for creating and maintaining Web content. Student and staff Web designers developed and maintained custom HTML pages for the library as a whole, and for individual department websites. The L. Tom Perry Special Collections (LTPSC) had been among the first to develop a departmental site, and had assisted in the development and maintenance of the site since 2002. However, due to the growth of the library and its Web presence, by 2008, maintaining hand-coded HTML sites had become overwhelming. The selection of WordPress allowed units throughout the library to maintain their own content with little or no assistance from the Library Information Technology (LIT) Division. Once the announcement was made, Special Collections staff requested to participate as an early adopter of the system.

During the months that followed, LIT and Special Collections staff worked to move the current website content into WordPress and plan for a public launch.¹ One of the implementation decisions reached by the committee was to break up the existing site to include a department site with information about policies, hours, and administrative information, and six subject sites related to the department’s collecting areas. Each of these subject sites was a separate WordPress installation, linked to each other using branded links. This allowed curators for each area to control their own content, and to post new information about collections or events in their collecting areas. With this distributed style of implementation, we turned to RSS as a simple means of sharing information between WordPress installations, as well as sharing new information about our collections with our users.

Brief Description of RSS

RSS, or Web feeds, are a suite of technologies used for syndicating Web content and making it available to users. The first of the RSS versions, RSS 0.9, was developed and deployed by Netscape in 1999. Other versions followed between 1999 and 2002, including RSS 0.91, RSS 0.92, RSS 1.0, and RSS 2.0.² However, these version numbers do not represent a unified development path. While all of the standards are based on Extensible Markup Language (XML), it is applied differently between versions. Even the acronym RSS used in the specifications has different meanings between versions, such as “RDF Site Summary,” “Rich Site Summary,” and “Really Simple Syndication.” In addition to the RSS standards, the Web feed development community has also created the alternative Atom syndication standard.³

Although the standards used to create Web feeds vary, they all have a similar function: to syndicate, or make available, content for inclusion or manipulation by other products or services. Typical feeds include title, date, and descriptive information about Web content, and provide a link back to the originating site. Although Web feeds have often been described as a “push” technology,⁴ they are not useful without a corresponding reader, aggregator, or other service. Users can use their Web browsers, e-mail clients, or dedicated reader applications to read RSS content, while Web-based aggregators can be used to insert RSS content in other sites. Since Web feeds are marked up in a machine-readable format, they also act as a simple Web service, allowing content to be used in mashups and other applications.⁵

RSS and WordPress

WordPress MU is the multiuser version of the popular blog software WordPress. Development of WordPress began as an open source project in 2003, and is freely available under a General Public License (GPL).⁶ In 2005, some of the core developers of the application created Automattic Inc., a software development and services company centered on WordPress. Among these services is WordPress.com, a blog-hosting service that allows individuals to create their own blogs at little or no cost.⁷ To power the site, Automattic Inc. developed a multiuser version of WordPress, dubbed WordPress MU, which allows for the creation and management of multiple blogs from a single installation.⁸

WordPress MU includes all of the features of a standard WordPress installation. This includes a simple Web interface for administering the site, a graphical text editor for writing and editing pages and posts, and an extensible plug-in framework (see Figure 1). RSS functionality is native to the system, which includes a variety of Web feeds.

In its default configuration, WordPress implements most of the standard Web feed formats currently in use. These include RSS 0.92, RSS 1.0, RSS 2.0, and Atom, though by default WordPress uses RSS 2.0.⁹ Feed entries are automatically generated for all new blog posts, and the feeds themselves are available at standardized URLs. WordPress is also able to generate Web feeds for tracking discussion and comments for individual blog posts, posts by tag, and posts by category.

Along with RSS generation, WordPress includes embedded tools (widgets) for aggregating Web feed content. The default installation of the application includes an RSS/Feed Widget that can be used to display RSS content on a WordPress site.¹⁰ While this widget displays only basic feed data, the WordPress Plugin Directory includes nearly two hundred other RSS-related widgets that can be installed and used.¹¹

While WordPress integrates RSS in a number of ways, we have also used two other services in implementing Web feeds: Yahoo! Pipes and Feedburner. Yahoo! Pipes is a Web-based mashup engine, which is used in our implementation for combining multiple RSS feeds from multiple sites into a single feed. While there are some WordPress plug-ins that may be used for this task, such as SimplePie,¹² our LIT Division preferred that we use an existing service for joining feeds. We also use Feedburner, an RSS management and traffic-monitoring service, in order to get usage statistics about our feeds.

RSS Implementation

As we planned for the decentralization of the department’s Web presence, we sought to standardize navigational elements, maintain a consistent look and feel, and share common content. While the visual elements could be addressed through the use of templates, we needed a technological solution to pass information between the different WordPress instances. For simplicity’s sake, we turned to RSS as a means of both distributing information and for providing an aggregate display (see Figure 2).

As part of our planning, we found that some functions of the previous site were best managed centrally. The most important of these was event management, which needed to be displayed both on the departmental site and the collecting area sites. Event information could then be entered once on the departmental site and then pushed out the collecting area sites for display.

Similarly, there was interest in aggregating the content of the blog posts made on the different collecting area sites and making them available on the departmental site. While there was not enough room to display the content, we decided to provide an aggregated feed on the central site that was similar to those found on the collecting area pages. For the feeds, to work policies were developed to encourage standardized categorization of blog posts.

New event notices were posted to the departmental site using standard posts, an RSS widget, and an events page with a custom template. The LTPSC hosts a number of different events during the course of the year, including lectures, exhibits, and films. Our events notifications have also typically been used for the distribution of department newsletters and press releases. Each of these types of event notices was displayed on a separate page, and there was interest in maintaining this structure. This was accomplished using WordPress tags, one of the methods the application includes for managing post content. When creating an event post, users enter a title and description for the activity. This typically includes dates, times, location, and a brief summary of the event. Dates are also entered in a computer-readable format using custom fields included in the WordPress interface. The posts are then tagged using values from a controlled list, marking them as lectures, newsletters, or some other event type, as well as associating them with collecting areas that may be particularly interested in the subject. Finally, using WordPress categories, they are categorized as Events.

Once events are described, tagged, and categorized correctly, they appear in the appropriate event page on the departmental site. These pages do not use RSS for displaying the information, but make calls on the underlying database of WordPress to locate content. These pages are able to sort events by the dates in the custom fields, allowing them to provide separate lists of current events and those in the past.

However, to make event information available between the different collecting area WordPress instances, we rely on RSS. Based on the same classification used for posting to the events pages, WordPress is able to generate an RSS feed specific to a particular collecting area. On the BYU History blog, for example, there is an RSS widget that displays a Web feed of all events related to the history of the university. This Web feed is generated from the departmental page. Each collecting area site includes a similar widget that displays relevant events. By using this central registration, we have been able to more efficiently manage event information, while making it widely available.

Gathering content from the collecting area blogs for inclusion in the aggregate feed is not as complicated a process. On each of the WordPress instances, there are three feeds available, in addition to the site-wide feed: new acquisitions, new resources, collection highlights, and the general feed. All posts to collecting area blogs are required to be categorized into one of these groups, allowing for the generation of category-specific feeds. Within each collecting area site, these feeds are available on all pages. Similar feeds are available on the departmental site, but these are aggregates, bringing together entries from the different categories across all of the collecting area sites.

In order to generate the aggregate feeds, we use Yahoo! Pipes, a freely available, Web-based mashup editor (see Figure 3). Yahoo! Pipes allows users to integrate data from a variety of sources, mashing it up to make something new.¹³ Using their graphical interface, the component feeds are entered and the aggregate feed is exported. These feeds are then made available on the departmental page.

However, before they are made available for subscribing, new feeds are generated using Feedburner. Feedburner provides a number of services for managing RSS feeds, including analysis, optimization, and monetization tools. One of the main benefits for us in using Feedburner was its ability to generate short, human-readable URLs for its Web feeds. While the native feeds generated by WordPress were also understandable, those generated by Yahoo! Pipes were cumbersome. We were also interested in taking advantage of Feedburner’s Web statistics functionality.

Assessing RSS Use

Due to the varied uses of RSS in the LTPSC Web presence, assessing the success of our implementation must include various criteria.

As a means of sharing events information between WordPress instances, RSS has been successful, though not entirely adequate for the task. Event posts made on the departmental site are reliably distributed to the collecting area sites and are displayed by the RSS widget. Yet, the sequential format of Web feeds has led to confusion by users and debate among curators. RSS widgets on all pages are set to display the five most recent event posts relevant to that area. While this works well on the departmental page, in some collecting areas, the infrequency of events results in a severely outdated list of events.¹⁴ Some members of the department also feel that the process of tagging and categorizing blog posts that enables the feeds is overly complex, which has led to infrequent postings.

It is also unclear how successful our application of RSS has been for sharing information with our users about new content. Web statistics for our most popular feed, the aggregate LTPSC Collection Highlights feed on the departmental page, indicate rather limited use. Four months after implementation, there are only five subscribers listed for the feed, though it appears that this is resulting in a rising number of hits. But for most of the available feeds, there have been no subscriptions and no traffic reported through Feedburner.

Our data suffers from some limitations, which makes it difficult to reach firm conclusions. While anecdotal evidence from user surveys suggest that some of our users take advantage of our RSS feeds, our statistics are not currently complete. While we do use Feedburner for gathering RSS statistics, this does not cover native feeds generated by WordPress itself. This includes the events feeds used for sharing data between blog instances, site-wide feeds found by autodiscovery features, and other feeds that might be configured by users.

Lessons Learned

Although our decision to use RSS for event management was originally based on expediency, it appears that it is incapable of meeting our users’ needs. This is in part due to its inability to be limited by event date, as this necessarily means that some older events may appear in Web feeds after the event is over. The larger problem, however, was the persistent lack of events in some collecting areas. While this could be solved by increasing outreach efforts and scheduling more events, it may be easier to simply replace the RSS feeds for specific collecting areas with the general departmental events feed.

Another problem with using RSS for event management has been the complexity of creating event posts. Simpler methods of posting events are needed if our staff is going to use the system.

It appears that changes will need to be made to improve the subject-based Web feeds generated by the collecting area blogs. Since the implementation of the new system, participation by curators has varied between the WordPress instances. In some areas, there have been only a minimal number of posts, which perhaps does not lead users to see the use in subscribing to an RSS feed. This is also suggested in our Feedburner statistics. Collecting area blogs with no new content do not report having subscribers—though having content actively contributed does not necessarily lead to RSS activity either.

Future Plans

Over the coming months, we hope to make some significant changes to our LTPSC Web presence to correct some of our current problems. Among these changes will be a migration away from RSS for events management, in the hopes in implementing a simpler, calendar-based system. In April 2009, the library completed development of an event-scheduling Web application for their own uses, and it is hoped that we will be able to pull event information from that system for inclusion in our sites using Web services. We will also be exploring ways to encourage our staff to add content to their collecting area sites in order to increase interest and Web traffic. Through building an engaged community, the power of RSS is greatly increased.

Despite these difficulties, we are still looking for ways to use RSS to bring information about our repository to our users. We are particularly interested in taking advantage of other data sources about our materials generated elsewhere in the library, such as getting new acquisitions information from the library catalog, or new resources from the digital library. We have recently pushed to have RSS enabled in our library’s CONTENTdm implementation, allowing us to further explore this possibility.

Finally, we also hope to better understand our patrons’ use of the current RSS options on the site by obtaining more complete statistics. Though we have already redirected many of our custom feeds to Feedburner, we will look at using WordPress plug-ins to redirect the default feeds to Feedburner as well. With better statistics, we hope to further improve our services and the availability of our resources.

Resources

Feedburner. “About Feedburner.” Feedburner. http://www.feedburner.com/fb/a/about (accessed April 14, 2009).

__________. “Feeds 101.” Feedburner. http://www.google.com/support/feedburner/bin/answer.py?hl=en&answer=79408 (accessed May 29, 2009).

Finkelstein, Ellen. Syndicating Web Sites with RSS for Dummies. Hoboken, NJ: Wiley, 2005.

Hammersley, Ben. Content Syndication with RSS. Beijing: O’Reilly, 2003.

Holzner, Steven. Secrets of RSS. Berkeley, CA: Peachpit Press, 2006.

Johnson, Dave. RSS and Atom in Action: Web 2.0 Building Blocks. Greenwich, CT: Manning, 2006.

LeFever, Lee. “RSS in Plain English.” Common Craft. http://www.commoncraft.com/rss_plain_english (accessed April 14, 2009).

Langer, Maria and Mariz Jordan. WordPress 2. Berkeley, CA: Peachpit Press, 2006.

Sabin-Wilson, Lisa. WordPress for Dummies. Hoboken, NJ: Wiley, 2007.

Sauers, Michael P. Blogging and RSS: A Librarian’s Guide. Medford, NJ: Information Today, 2007.

Sennema, Greg. “Using WordPress for Our Library Blogs.” Partnership: The Canadian Journal of Library and Information Practice and Research 2, no. 1 (2007), http://www.criticalimprov.com/index.php/perj/article/viewArticle/266/378 (accessed April 14, 2009).

W3 Schools. “RSS Tutorial.” W3 Schools. http://www.w3schools.com/rss/ (accessed April 14, 2009).

WordPress.org. “WordPress: Blog Tool and Publishing Platform.” WordPress.org. http://wordpress.org/ (accessed April 14, 2009).

Yahoo! Pipes. “Pipes: Rewire the Web.” Yahoo! http://pipes.yahoo.com/pipes/ (accessed April 14, 2009).

Notes

1. The site was launched in September, 2008. See Harold B. Lee Library, “New Special Collections Site,” Brigham Young University, http://lib.byu.edu/sites/news/2008/10/29/new-special-collections-site/ (accessed April 14, 2009).

2. Ben Hammersley, Content Syndication with RSS (Beijing: O’Reilly, 2003): 3-6.

3. Wikipedia, “Atom (standard),” Wikimedia Foundation Inc., http://en.wikipedia.org/wiki/Atom_(standard) (accessed April 14, 2009). Atom feeds currently represent about 15 percent of all Web feeds. See Syndic8, “Site Statistics—Feeds,” Syndic8, http://www.syndic8.com/stats.php?Section=feeds#tabtable (accessed April 14, 2009).

4. Wikipedia, “Web feed,” Wikimedia Foundation Inc., http://en.wikipedia.org/wiki/Web_feeds (accessed April 14, 2009).

5. Tim O’Reilly, “What is Web 2.0: Design Patterns and Business Models for the Next Generation of Software,” Communications & Strategies no. 65 (2007): 31.

6. WordPress.org, “WordPress: Blog Tool and Publishing Platform,” WordPress.org, http://wordpress.org/ (accessed April 14, 2009).

7. Automattic Inc. “Automattic: About Us,” Automattic Inc., http://automattic.com/about/ (accessed April 14, 2009); WordPress.com, “The Features You’ll Love,” Automattic Inc., http://en.wordpress.com/features/ (accessed April 14, 2009).

8. WordPress MU, “WordPress MU: About,” Automattic Inc., http://mu.wordpress.org/about/ (accessed April 14, 2009).

9. WordPress.org, “WordPress Feeds,” WordPress.org, http://codex.wordpress.org/WordPress_Feeds (accessed April 14, 2009).

10. WordPress.org, “Plugins/WordPress Widgets,” WordPress.org, http://codex.wordpress.org/Plugins/WordPress_Widgets#Using_RSS_Widgets (accessed April 14, 2009).

11. WordPress.org. “Plugin Directory: Tag RSS,” WordPress.org. http://wordpress.org/extend/plugins/tags/rss (accessed April 14, 2009).

12. WordPress.org, “SimplePie Plugin for WordPress,” WordPress.org, http://wordpress.org/extend/plugins/simplepie-plugin-for-wordpress/ (accessed April 14, 2009).

13. Yahoo! Pipes allows for the manipulation of a variety of data sources, including RSS, Comma Separated Value (CSV) files, JavaScript Object Notation (JSON), and others.

14. On the BYU History collecting area blog the most recent event currently listed occurred in May 2008, while the oldest event happened in November 2004.