Learning Management System Demo Week Notes

Ryerson is going through a public consultation for a new LMS. I mostly went to the sessions where an instructor came in to talk about their experience with a product. When that wasn’t available, I went to the vendor presentations.

Full schedule and links to the session recordings: http://lms.blog.ryerson.ca/2013/03/20/announcing-lms-demo-week/

Continue reading “Learning Management System Demo Week Notes”

Redesigning the Digital Commons Page

Recently, our team has been assisting with a new initiative to make sure documents sent in to our institutional repository (IR) are accessible. I won’t go into much detail, but since this new initiative was being launched, it was proposed to have the digital commons (our IR) page redesigned for the launch.

Old Page

The old page was really just a lot of text, and too much of it. I’m also not sure how long it had been since anyone had revised it. The biggest problem was that it was difficult to find what you wanted, especially how or where to submit a document.

Old Digital Commons Page
Old Digital Commons Page

Mockups

So the first mockup was actually given to me by the group working on the IR project. While a vast improvement over the original page, I was not a fan of the quadrant look. I’m probably biased because it was overused at my last work place, but regardless, I thought I could do better.

Mockup #1
Mockup #1

One thing that didn’t make sense to me was why you would have a link to a search page instead of just building in a search on the page (same with the news). While a search box was thought of, I’m not sure how it would’ve worked into the square design. I was actually working on the Articles redesign around the same time, so I ended up using some of the ideas I had floating around in my head already.

Mockup #2
Mockup #2

The colours I used were based on the first mockup, which were in turn based on the IR site’s colours.

Redesigned Page

The redesigned page came out pretty much exactly as the mockup. However, the project members called me the day after to tell me that the green shows as a very ugly yellow if the screen or projector is not properly calibrated. So, I ended up changing the colours to our library’s colours.

Current New Digital Commons Page
Current New Digital Commons Page

Most of the text that was on the original page is now on the About page linked from this landing page. I think it’s a huge improvement, so hopefully it helps to encourage more of our users to submit things to our IR.

Workshop: Communicating the Library’s Value in Academia

The librarians had a half-day workshop where the activities focused on how we can communicate the value of librarians and the library to the rest of the university. Continue reading “Workshop: Communicating the Library’s Value in Academia”

Setting up WordPress CMS for an Academic Library

A lot of people have setup WordPress, and obviously each organization needs to set it up a specific way to fit their needs. Nevertheless, learning how different libraries set up their CMS is something I have found useful in the past, so I thought it might be helpful for someone else if I shared the way I decided to set up WordPress at my work.

The Install

As we have more than one site, it was an obvious choice to use the MultiSite flavour of WordPress. We set it up to use the directory structure option since we would be under a subdomain already, we decided against having sub-subdomains.

We installed it on its own virtual server through our central IT. We discovered in the process, however, that by default, a lot of modules are disabled by IT, so we had to request a number of them to be installed. For the core, the only one was:

  • GD Support – required for creating the different image sizes (i.e. thumbnail, medium, large)

Various plugins uses PHP modules that are part of the standard PHP install, so may not point out the need for enabling them. For plugin requirements, I’ll note them in the plugins section.

Setting Up The Sites

Creating the sites were simply a click of a button of course, but a lot of settings had to be changed. While most of the defaults were fine, I did change a number of settings. In particular, one of the settings was only accessible (through the Dashboard) by manually entering into the address bar, options.php

image_default_link_type = ‘none’

For most of our sites, there is no advantage to linking to the attachment page or a full size version of the image. Additionally, the images that are uploaded are usually close to the size that is being used on the page. The one exception I made was for the Archives & Special Collections site.

We also do not allow users to set up their own sites, so staff have to contact a network administrator.

Making The Themes

The lengthiest part of the process was making the custom themes. I won’t actually go into details here, but will later post details on the creation of the library’s theme. I have already talked about the options I implemented in the post about Branding the Library Website.

I will note that we avoided making a ‘mobile’ theme by making the themes responsive. They’re not the prettiest, but at least they work.

I did have to make a standard template to use for our non-WordPress sites, including the ILS, Special Collections, and ColdFusion stuff.

Roles & Capabilities

All the sites use the default Roles & Capabilities, except for the main site. Using the Advanced Access Manager plugin, I changed the permissions so that:

  • Administrators: Due to the Carousel plugin, some staff were made administrators, but with restrictions at the user (rather than role) level to have similar permissions as editors.
  • Editors: have unfiltered html (using the Unfiltered MU plugin)
  • Authors: can also edit/publish pages and delete own pages, moderate comments to own posts
  • Contributors: can edit/publish pages (instead of posts) and delete own pages, and add/edit/delete own media

Pages that have JavaScript or custom CSS are also locked down so that only editors and administrators have access.

Migrating the Existing Sites

We migrated from static HTML sites and single install WordPress blogs (I don’t know why this wasn’t a MultiSite to begin with).

WordPress Sites

For WordPress sites, I used the standard export/import that you have to install, but is integrated into the core. The one problem is that in MS, if you import images, it will copy the images over with the metadata, but will not update the links in the posts themselves (see ticket #16404). To solve this problem, I used the Search and Replace plugin to change all the old links to the new ones in one go.

HTML Sites

We settled on using the HTML Import 2 plugin. It worked well, especially since it supports Dreamweaver templates, which were used with most of our pages. It didn’t catch all the links, so we had to update some of them manually, but using the Search & Replace plugin helped a great deal.

The other thing that took a bit of time was to replace thumbnail images with the WP version and delete the original thumbnails. My coworker also uploaded all the images with the thumbnail crop option on, so I used the AJAX Thumbnail Rebuild plugin to force WordPress to recreate all the thumbnails.

Updating the Site

As with any move, it’s a good opportunity to update the site. Unfortunately, we had too tight a timeline to update the content and organization of the site (except for some minor changes). As a result, the site looks more or less the same, but I updated and coordinated the updating of a lot of the code.

I consolidated the CSS files, updated the template to use HTML5 and meet WCAG2.0, and most time intensive of all, got rid of all layout tables (with some other staff helping).

Plugins

Here is the list of the plugins I ended up with including those to help with migration:

For reasons why I may have chosen some of these plugins, take a look at my other posts on WordPress plugins.

Oh The Time

So, the most time intensive part really is sifting through WordPress plugins and updating content.

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.

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.

Old Research Help Page

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.

Mockup #4

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.

New Research Help Page

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.

Injecting Personality into a Library Website

While moving our website into WordPress, I came across a blog post about adding some personality into a website (I’ve unfortunately lost the link to it). So, I thought I’d find some small ways to do that with our site too.

I was recently reading as well about how successful GVSU Library has been with their construction updates using a twitter account by giving the building a persona.

404 Page

One of the most common ways that a site will show some personality is with its 404 page. One of my favourites is the Github 404. I thought maybe we could do something a little more amusing than the standard 404, so with the help of my partner, we came up with this:

404 Page with Dewey joke

Unfortunately, I got various complaints that the 404 page was confusing and didn’t make any sense (from staff, it was changed before the site went public). I knew from the beginning that it wouldn’t fly with making it public for our users because they wouldn’t get it, but I thought at least one staff member would get the joke.

I may have another stab at it with a simpler one, perhaps with just a headline, but that won’t be in at least a couple of months.

Custom Avatar

One of my thoughts for the blog was to have a custom default avatar that would be a picture of our university mascot or just a version of our library’s logo. Unfortunately, I couldn’t find a plugin that worked on multisite that would allow me to set a custom avatar only for the main site (and not all the subsites).

Placeholder Text

I actually mentioned this in a previous post that I decided to have a little fun with placeholder text, but here it is again.

WP Comments Form Edited version 2

Eggy the Ram is the name of our university mascot. No one has actually noticed this since our blog hasn’t been moved. Thankfully, unlike the 404, the placeholder text here should have no chance of confusing people.

Badges

Another idea I recently thought of that might be fun is for students to get badges during orientation or even throughout their time in school for completing workshops or similar things. Instead of an in-house system, it could be done using something like Open Badges.

I’d be interested to see if other more formal institutions have done any of these or other things to add some ‘personality’ to their sites.