CMS, Wikis, Using Databases for Websites, and Usability Testing

My final notes from the Web Manager's Academy Preconference - Computers In Libraries 2007

Jeff Wisniewski, of the University of Pittsburgh, offered an overview of Content Management Systems or CMS'. He described what they are, what they do, what the benefits are, why you’d need one and what the benefits would be. Basically, they are web publishing systems. They allow a planned and controlled process for getting multiple authors to publish to a website. They are useful for the obvious reasons - you know, to allow your webmaster to go on vacation.

Interestingly, it turns out that his institution uses the client-based Macromedia Contribute system as a CMS. It’s interesting that I’ve heard several speakers describe Contribute as a CMS. Yet, my own experience with Contribute is that its functionality is similar to that of FrontPage with FrontPage Server Extensions used for website Administration. And I wouldn’t consider that a CMS. But maybe I should. Or perhaps there’s more to Contribute nowadays.

Darlene Fichter highlighted wikis, which are collaborative web authoring tools (Wikipedia is probably the most famous wiki on the web at this point). She noted that wikis are intended to be simple to use, create, and edit. Usually many people create and edit wikis – sometimes they are open to editing by all visitors, in fact. Wikis are uniquely well-suited for group endeavors. She cited the need for openness and trust among collaborators who develop wikis. She also mentioned that wikis are designed to evolve, to be incremental in their development. Wiki pages can link to other wiki pages, even those that are not yet built – creating a kind of place-holder for these other pages (usually the links to pages not yet built are in red). Wikis progress in an observable manner – you can see the changes being made and review the revision history of wiki pages. Wikis are organic in their structure and will evolve and change over time. Darlene mentioned that if your library creates a wiki, you’ll want to assign “wiki gardeners” to ensure that your wiki links and pages are maintained.

Marshall Breeding spoke about using databases and web services to enhance/empower your website. The key concepts were that you shouldn’t repeat data, but rather put data into databases and leverage those databases by displaying their elements in web pages as needed. Though he showed a dazzling array of examples in which he had built database-backed sites/pages, he told us that creating such things is not technically complex. Though there may be an initial investment in time to learn how to program such things, it is worthwhile because it will allow your library to better meet users' needs via your web presence.

Breeding talked about Service Oriented Architecture (see http://en.wikipedia.org/wiki/Service-oriented_architecture), which is popular in IT and web programming these days. It provides the infrastructure for the behind-the-scenes communication among applications. SOA facilitates data exchange, conversions, lookups, etc. All of the components of SOA are expressed in XML. He then talked about the widespread adoption of web services in many industries, using SOAP – Simple Object Access Protocol -- (http://en.wikipedia.org/wiki/SOAP), the “envelop for XML applications” (supported in all common web environments). He also talked about WDSL – Web Service Description Language (the definition of how the web service operated and the data structures involved, expressed through XML; view an example at http://api.google.com/GoogleSearch.wsdl).

He breezed through these and other complex programming topics more quickly than I could grasp and offered more acronyms than I can do justice to in this blog. If you’re interested in delving into this topic further, try the resources he cited: “Web Services and the Service-Oriented Architecture”, Library Technology Reports 42:3 by Marshall Breeding; “Best Practices for Designing Web Services in the Library Context, by NISO Web Services and Practices Working Group (http://www.niso.org/standards/resources/rp-2006-01.pdf)

Darlene covered "Usability Research Methods to Help Redesigns". She noted that ethnographic methods of testing website usability are being increasingly used, but that they are complex, so that she would not give much time to them in this presentation. She also reminded us that focus groups, while ok, are not ideal ways to increase our website’s usability, due to the fact that most people do not accurately represent how they use the website when asked. Instead, she talked about 3 methods for redesigns:

1. Preference testing
2. Affinity mapping
3. Task based testing

She began by defining usability:

• ease of use
• ease of learning
• fitness for purpose

She then explained that user testing involves actual users interacting with the website. They are asked to perform tasks while usability evaluators observe and take note of their actions. User satisfaction is the more important measure of how usable a website is. Even if a user completed the task, if they are dissatisfied, the site has failed.

Why conduct user tests? Darlene noted that web development is an expensive process, and that supporting a poorly designed system is even more expensive. Even the best designers are not representative of the users of their systems, so they are poor judges of what users want and need. The “bitter truth” as she termed it, is that unhappy users will leave and tell their friends, who tell their friends, and so on.

Before conducting usability tests on your site, you should build on the extensive work and research of others. Darlene suggests http://www.usability.gov/ and http://www.useit.com/ to guide you before you begin testing your site.

When can you test? Darlene noted that you should test the existing site for goals and audience. When you have a paper prototype, you could test organization and labels on your site. She showed the “flip test” with screenprints of various prototypes, wherein the web developers behave like optometrists – showing first one screenprint, then another quickly thereafter and asking the user which one they prefer (this or this?). Finally, when you start creating, you’ll need to test working prototypes, demos, and beta of the redesigned site.

Testing techniques:

• Preference testing: zeroes in on troubling labels (what to call a given hyperlink/navigational cue, e.g.)
• Affinity mapping: offers insight into how to organize your content from the user’s perspective. In it, you list the main content and services on your site. Small teams then group items and label them. Then they vote for the ones that seem most important to them.
• Task-based testing: users are given specific tasks and as they perform those tasks, they are asked to verbalize their thoughts. The tester observes, records, and debriefs the user.

She also mentioned that testing should take place at different levels of user, to ensure that your website is redesigned as optimally as possible for the various users’ needs. Finally, she reminded us how iterative rounds of testing and web development really are. You have to keep testing at every level – to fix problems, then test again (and on and on… you get the picture). This is the best way to ensure the success of your website redesign among your users.

Of the additional resources covered in the Web Managers Academy and accompanying handouts, I have to make special note of a topic that seemed to resurface throughout the day, but that wasn’t necessarily focused on in any of the presentations – the importance of learning how to write for the web. Being succinct and allowing users to scan webpages, as opposed to requiring them to really read text on a page is the ideal. When blogging, I know that one should be brief. That doesn't mean I know how to do it... I guess I need to take a course on how to write for the web myself... ;)

cil2007