Methodology – Page 5 – Learning (Lib)Tech

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.

General Guidelines on ‘Writing for the Web’
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.

Getting Quick Feedback: Updating the Help Page

In the past month or so, it became very evident to many of the librarians that the research help page on our site needed to be revamped. As we’ll be piloting a new “Book a Librarian” service next month, I thought it would be a good time to roll out a new help page as well.

There were so many problems with this page, not least of which was that the page and the sidebar had the exact same links only in a different order.

We had a bit of a tight timeline, since I essentially had 3-4 weeks to make mockups, discuss it with the group, get feedback from staff and students, make the page, and get it live.

Getting Quick Feedback

Part 1: The “Committee”

It wasn’t a formal committee, but it was essentially an ad hoc working group. I presented all three mockups to the group. If the group couldn’t agree on one, then I would have taken two of the mockups to staff and students for feedback. However, since the group felt quite strongly about mockup #3, I decided to go ahead with that mockup to gather feedback.

Part 2: Asking the Students – Survey

I decided to do two versions of the mockup based on the meeting’s discussions. Mockup #4 is exactly the same as mockup #3 except with the chat widget in the middle.

We taped the mockups on a movable whiteboard and offered candy as incentive. We pulled students aside as they walked past on the main floor and asked them some basic questions on:

how easy it is to find what they’re looking for,
whether they understood all the terms, and
which design they preferred and why.

We had decided on getting however many students we could in an hour. Since it was a quieter day, we ended up with 7 students.

Part 3: Asking the Staff – Open “Silent Forum”

In order for all staff to have a chance to provide feedback, without having to gather them all together, we decided to post the mockups in the staff room with a couple of questions to think about (similar to the student ones). Sticky note pads and a pen were left for staff to write their comments.

The Results

Of the students we asked, more of them preferred #3 with the chat on the side, because they would never use it. On the other hand, the students who preferred #4 thought the right-side chat widget would be ignored or even mistaken as an ad. Other reasons for #4 included:

balanced and symmetrical
more aesthetically pleasing
better division of groupings
helps to promote the Ask chat service

Of the staff that provided feedback, they unanimously chose #4 for many of the same reasons that students provided.

Other feedback resulted in my adding:

a header for the chat widget,
“Hours & privacy policy” link for chat widget,
hover behaviour for chat widget,
tooltip text for “TRSM”, and
changing the wording of “YouTube” to avoid branding.

While we could’ve gotten more feedback, I think we got enough to help improve the page and implicit confirmation that it works.

Launch

The page, along with the new “Book a Librarian” service and a revised “Research Help Services” page is set to go live on Oct 1.

We will likely also be changing the “Ask Us” logo in the header to direct to this page as opposed to the “Contact Us” page as it does now. Hopefully, it’ll help to promote our services and resources, and get people to the right place.

WordPress Development: Lessons Learned & Downsides

After 8 months, I have finally finished with WordPress development. I definitely learnt a lot, especially in terms of how the back end works and some more PHP.

Lessons Learned

The most important one:

know more PHP than I did.

Admittedly, I knew very little. While I have some experience programming, I only took a 2 day course in PHP. Not having to look up every little thing would have saved me invaluable time.

The other big one was definitely:

know more WordPress.

The documentation is obviously written for programmers (in most cases, those familiar with WordPress). So once again, I spent a lot of time looking things up. In this case, it was even more difficult because I usually had to rely on a couple of different tutorials and piece things together, making things work through trial and error.

Of course, I didn’t have much choice. And if there is one really good way to learn something is to be thrown into it, and make it happen.

Plugins

WordPress could really use some improvements though. One area is definitely in the plugins area. There is little to no cooperation between plugin authors, so there may be anywhere from zero to fifty plugins that do similar things, but all work differently and are of varying quality.

One of the reasons I’ve been posting a lot of plugins review is not only for my own records, but in the hopes that it’ll save other people time from looking through the mass amount of plugins. Unfortunately, because plugins come and go like the wind, plugin reviews become out of date very quickly.

Search

The one other thing I wish WordPress would improve is their search. While the site search uses Google, the plugin search is pretty bad and so is the internal built-in WordPress search. For the plugin search, you cannot refine your search in any way, and the sorting doesn’t seem to work properly.

The built-in WordPress site search (and dashboard pages/posts search) is also pretty bad. It’s organized by date and there is a plugin that allows you to sort by title, but it does full text searching and does no relevance ranking whatsoever. If it even did the minimum of “do these words match words in the title, if yes, put those higher” then that alone would be a huge improvement.

Conclusion

While I think WordPress is a great platform (and it’s open source!), there is definitely room for improvement and may not be the right platform for everyone. In comparison, for example, I get the impression that Drupal has a more cooperative and supportive community with better plugin support and development. On the other hand, I find WordPress easier to teach users.

If I had to do it again, I would definitely have taken the time to learn more about the overall WordPress framework and how different parts fit into the puzzle before diving into making the theme.

The Ends do not Justify the Means: The Necessity of Code Review

Hopefully this post does not sound like just a rant as I admit that this post has come up from my frustrations from using other people’s work, but I think this is particularly symptomatic of areas where there are not always IT experts, as is the case with many libraries. I also do not boast that I always know what I’m doing, but that’s why I think it’s invaluable to have some kind of code review process.

Making it Simple

As a general rule, better to make things as simple as possible rather than using complex methods if they both achieve the same things. I’ve been told that simple and clean code is the best kind of code.

There may be efficiency concerns involved, but then that seems to be left behind in the cases I’m talking about anyway. (Case in point, our website had 5+ CSS files, not all which had clear purposes, many of which were overwriting each other’s classes, which I had to rework into two files.)

Document and Comment

While some of the simple things might be obvious and self-explanatory, I don’t think I’ve ever seen anything over documented/commented in the ‘real world’ (as opposed to school work), so more is (generally) better. I think it’s doubly important where the creation of a product/tool might be outsourced, but the maintenance of it is done in house (as frequently seems to happen), that the code can be understood by a new/beginner programmer-type person.

Too often I have looked at code recently and thought “what does this do?” or “how many pages does it affect?” While I admit that it’s not always easy to know what or how much needs to be documented, because you don’t always know who will look at it in the future and things you write yourself tend to make sense, but do at least a minimal amount of documentation and commenting.

On a side note, do not name files or functions after yourself (one former student’s name is now unforgettable for that reason and this was created months before I started).

Get Feedback

Ideally, there is someone who is an actual programmer on your team or in your unit who you can ask to take at least a quick look over what you’ve done and give you feedback on whether you’ve done it correctly. If there’s no one ‘inside’, consider asking someone on the ‘outside’.

Within a team or unit, if there is more than one programmer-savvy person, consider establishing a Review/Feedback step in the process as you typically see before code commits (if this doesn’t already exist of course).

If you really can’t get feedback from someone else, then much like editing your own writing, step back from it (for, preferably, a couple of days) and look at it with fresh eyes and ask yourself some of the important questions, but namely:

would someone else be able to step in and easily understand what your code does?

Supervising Students

I believe that all the above points apply when working with students too. It’s okay if you’re not a programmer. At least take a brief look at the code, see if commenting is done, ask about the general process/framework, ask if they think a beginner programmer would be able to understand their code easily, etc. If you ask, it will at least make him/her think about it!

My Point

The end product does not mean it is what you want. Other people also need to be able to maintain and customize/modify. This all seems so obvious, but I think it bears reminding sometimes.

AACR2 and MARC: Rules that Give You Individuality

The last couple of weeks in cataloguing have been on descriptive cataloguing using AACR2 (Anglo-American Cataloguing Rules) rules and MARC (MAchine Readable Code) coding. If ever we think that librarians cannot be decisive, then one area where they can be is cataloguing. Our instructors did not lie about this, and yet, being decisive and being consistent is not entirely the same thing.

Considering the number of rules in AACR2, I was initially under the impression that it would be like APA citation. Essentially, that there is a rule for everything and no matter who does it, it will look the same. Obviously, the areas left for local use (such as most of the MARC fields with a 9) will differ between libraries, as well as specific code classification, but I thought the descriptive part would be uniform. Then I discovered that I was quite wrong.

Title Information or Not?

Despite the numerous rules, there are many areas that leave room for interpretation. One of the items I had for our assignment was a directory for an auto exhibition. The main title was fairly clear, but then I wondered whether the location (the exhibition hall) which was on the title page should be listed as other title information considering it was written underneath the title almost as if it was a subtitle.

Another issue which to consider the primary language (which would be listed first) in a bilingual book. [insert pictures] Would you do it based on the primary language of your library or would you use any other clues you could find? (I used both since the centrefold picture was in the same direction as the primary language of the assignment.)

How much Publisher Information to include?

As publisher information can be from a variety of sources, how much would you include? In the case that there is no (clear) publisher, which is more important? Distributor? Printer? Copyright holder?

In the end, I somewhat made up the statement of responsibility and came up with this:

Taipei : Printed by Wuchou Color Phtoengraving for Taiwan External Trade Development Council [organizer], 2008

Notes

Finally, there’s notes. The extend to which it’s filled out and exactly how is up to the cataloguer, which of course means that it will differ. Interestingly, they may not be as different as one might think as there are a far amount of rules surrounding the order, how one might format it, and MARC coding will even separate numerous notes into specific fields. It may be more or less complete, but having looked at various catalogue entries for the same item, they are fairly consistent.

Right or Wrong?

What I begin to wonder is who’s to say which way is right or wrong? Who might be able to say which way is better? I’m starting to think there must be a listserv of some sort for this sort of thing that maybe us students just don’t know about yet…