Getting Staff on Board and Using a CMS: Moving to WordPress

The hardest part of moving any website is getting staff trained and changing their workflow to actually use the CMS. We previously had a static HTML type site, so everyone would email changes to one or two people. It was a big shift to suddenly have people take care of their own content.

As part of the training session, I briefly reviewed why we moved the website to a CMS and more importantly, how it benefits our patrons. It covered the usual, shifting resources and staff time, less maintenance, keeping content current, etc.

Tutorials

I found the best WordPress tutorials for staff were the WordPress.com support articles related to creating content. The only differences come from the plugins that are installed, but in our case, this only affects the “Upload/Insert” section above the editing area.

We also have access to lynda.com video tutorials, so I suggested the relevant sections (5 + 6) of the WordPress Essential Training.

I also wrote up a short blurb on how to check for broken links in a more visual way (and for our non-WordPress pages). I basically referred them to install and use LinkChecker (a Firefox plugin).

Content Guidelines

In addition to training staff on the actual CMS, I wrote two sets of guidelines for them to follow.

  1. General Guidelines on ‘Writing for the Web’
  2. Using WordPress to Make Content Accessible (to come in a future post)

To make it easy for staff to use, I wrote it as a page on the intranet (with anchor links for a short table of contents), and also made a PDF version for them to easily print it off.

Making Staff Responsible

I think the most important step in shifting web content management from a single team to the entire staff is assigning responsibility. If no one “owns” a page, it will not be regularly reviewed. If you assign ownership, at least it increases the chance of that happening. Here are the short blurb I wrote on staff’s responsibility of content:

Page Ownership Responsibilities

While you may delegate the task of creating or updating content on any page you own, you are ultimately responsible for it. This includes:

  • Content is up to date
  • Content, especially audio/visual, conform to Accessibility Guidelines
  • Copyright is cleared for all content (if applicable)
  • Transferring ownership when needed (long term leave, end of term)

Please Note: When links are found to be broken, you will automatically be notified via e-mail. However this is not a full-proof system as many broken links will not be “marked” broken. See the ‘How to Check for Broken Links’ page for more information.

Assigning Ownership

We explicitly mention that editing of pages can be delegated, because we decided that librarians would be responsible for pages. We identified and changed each page’s author to the librarian who would become the owner.

We still have about a dozen pages outstanding in which our team maintains as needed, but we also expect that staff may edit it if they find mistakes.

The Result

So far, it’s been fairly successful (yay!). While I get calls on occasion for help, staff seem to be finding it easier to use than Drupal (which we have for our intranet), and most seem to have no problems using it.

Content on a lot of pages are being updated, though as always, it really depends on the owner. One of the problems is that we migrated the existing pages, and there’s a lot of overlap in information, which we really need to consolidate. So, making the website better as a whole will take a bit more time, but at least content is now being updated on a more regular basis.

Guidelines on Writing for the Web

So as part of the website redesign and working on making the site WCAG compliant, I wrote a couple sets of guidelines. One of them was on writing content for the web. Some of the points and the example I got from a coworkers, but most of it I just consider sensible advice. Overall, I tried to keep it fairly short and simple in the hopes that staff members will actually read it!

Writing for the Web

Web readers skim pages and look for keywords, links, and other information that will help them find what they’re looking for quickly. Therefore, when writing new or revising content:

1. Be Clear and Concise

  • Make your page title descriptive and concise, keeping it fairly short.
  • Keep sentences, paragraphs, lists, and other information short and simple.
  • Use lists wherever appropriate, especially when users have choices. Use numbered lists for complex instructions and include important screenshots.
  • Unless you’re creating a policy page, keep the entire page short (e.g. 2-3 screens worth).

 Bad Example:
To find information on citation styles, go to the Library’s Home Page, click on Research Help, then click on Citations and Style Guides and choose APA Style Page, MLA Style page or RefWorks.

Better Example:
For more information about citation styles, check the

  •  APA Style Page
  •  MLA Style Page or
  •  RefWorks

2. Speak to Your Audience

  • Avoid acronyms and “library” vocabulary when writing content for the library’s webpages.
  • Write at a Grade 7-8 level in a direct voice, using “you”. For example, use “get” not “obtain”.
  • Because users scan pages and don’t read them, information needs to be written clearly and concisely and at a reading level that doesn’t impede typical user behaviour.

3. Be Meaningful

  • Links, in particular, should be meaningful. The words of a link should tell your reader what the link is about.
  • Screen readers have the option of listing all of the links on a page, so think about whether a user would know what your links refer to out of context.
  • In addition, don’t overuse links. Only use them where it makes sense, such as for a list of resources.

The Downsides of a CMS in Keeping Up: WordPress & HTML5

As a web developer, I cringe at deprecated code and try my best to keep up to date, which right now means familiarizing myself with HTML5 and CSS3. In reflecting on how best to update our website, I realized that with a CMS, naturally some things are out of my control.

Giving Up Control & Relying on Developers

Whether it’s the core or plugins, users of a CMS are reliant on its developers to keep things up to date. Is that lost of control worth the benefits? Generally, I would say yes, but that doesn’t stop me from wishing that the technology that we use to adopt new specifications.

WordPress & HTML5

Image Tags & Properties

I think it’s interesting that in HTML5 there is now the figure and figcaption elements. If they are taken advantage of, I think it definitely helps to parse information in a webpage and to identify text that is directly related to images.

One thing that does bother me about WordPress (which actually has noting to do with HTML5) is that it forces users to have a title, and leaves alt text blank by default. I don’t know what the best solution may be, but I would propose to insert the title text into the alt text by default and then allowing the user to change it. If they want to leave it blank, then there should be a checkbox to mark it “intentionally left blank” or something. Perhaps this could be an admin option, but I would definitely want something like that since I would really like to force our users to have alt text, but I don’t want to touch the WP core obviously.

Text Formatting Tags

It’s a bit of a minor thing and while some may argue the usefulness of the different semantic tags, users of the rich text editor would have no notion that they’re using <strong> instead of <b> or <em> instead of <i>. While I admit that even I struggle on the appropriate use of each (I have to look it up every time I think about it), if we want to see widespread adoption, then we need to get users to think about their writing and what they intend to do when using any of strong, em, b, i.

Tables

While we avoid tables and it should never be used for layouts, users will still want to insert tables to display data without resorting to an image. I’ve always wondered that WordPress doesn’t have a table insertion button even under the kitchen sink. What worries me is that then users who have a basic knowledge of HTML will insert it themselves using the HTML view with improperly formed code.

Layout & Forms

You might wonder why I’d lump the two, and that’s because, other than (using the default) comment form, both of these are dependent on a WordPress setup.

Forms will generally depend on the plugin. Similarly, whether the layout is in HTML5 is very dependent on the theme, along with many elements of accessibility.

Unfortunately, while HTML5 themes are relatively easy to find, most form plugins do not tell you whether they are using HTML5 or how much of it.

Why Not Adopt HTML5

I do realize that while there are a number of advantages to HTML5, especially in terms of structure,  it’s still in development. Working in an educational institution, it’s also more work and sometimes difficult in some cases to ensure backwards compatibility.

In particular, screen readers do not necessarily support all the new HTML5 elements and will frequently ignore whole chunks of text or have difficulty with reading links, etc. Even the newest versions of screen readers do not necessarily recognize elements and properties designed to make webpages easier for screen readers to interpret.

I would like to think that since WordPress talks about trying to be accessible that anything in the WordPress core will be updated once there is widespread adoption not only among browsers, but also screen readers. Obviously, adoption will take time though. For example, many form input types have been adopted by most browsers, but has not been adopted by IE at all (will be in IE10).

One can only hope that adoption will pick up once various part of the HTML5 specifications are ‘cemented.’

TRY 2012: Drupal for Libraries at UTL

Just a warning that some of this gets fairly technical, especially with hardware setup, and without the related diagrams, it may be difficult to understand, but the basics are there.

Presenters

  • Marc Lalond
  • Andrew McAlorum
  • Graham Stewart

Evolution of the UTL Website

  • recognized need for CMS back in 2003
  • 2005 – used Plone
  • 2008 – had to move frontpage out of CMS, which meant more maintenance
  • 2010 – took another look at new CMS since current CMS needed a lot of Python knowledge and decided on Drupal
  • 2011 – launched new site in Drupal

Drupal

  • little coding work
  • modules (much like WordPress plugins) that are available
  • steep learning curve, but coding not necessary

Drupal Related Additions

  • Drupal Commons – community distribution, pre-configured package
  • Islandora – digital asset management, Fedora database backend
  • Solr – well integrated into Drupal, especially for faceted searching

Implementation

  • multi-site drupal allows multiple instances
  • especially useful for simpler sites with little custom code and modules that are updated
  • built custom Drupal distribution for UTL with all modules, theme, settings
  • theme built on LayoutStudio starter theme
  • next: responsive version

Training

  • regularly schedule training, about once a month
  • covers setup and config, users, content, etc.

Performance

  • 2000 visits per hour
  • single page load = 279 MySQL queries
  • initial loads for 2000 page loads = 558,000 MySQL queries
  • Drupal on one box: User <-> Apache Web Services <-> PHP <-> MySQL
  • problem occurs when there is a bottle neck with a single point of failure
  • Solution: horizontal scaling with multiple servers with Drupal functions split into smaller boxes
    • very flexible
    • less expensive
    • more adaptive
    • fully redundant

Setup

  • individual servers are virtual machines, buil using KVM virtualization with Ubuntu Linux
  • High availability with Keepalived
  • Load balancing with HAProxy
  • Caching using Varnish and XCache
  • Storage on shared high performance disk
  • MySQL query caching with Memcached and Keepalived
  • MySQL master/slave replication + Keepalived

Results

  • 5 minute downtime (planned and unplanned) between Sept 2011 and April 2012
  • load time = < 2s on campus, 4.1 on simulated DSL in Virginia
  • 100% Open Source

As I posted on twitter, I’m quite glad we don’t take care of our own hardware, especially since we just don’t have the people and resources (including not having any server admin), but I was quite impressed with the setup of the UTL Drupal setup. Quite interesting to hear what they’re doing.