Reviewing and Improving Workflow and Productivity: Methods and Tools

Most of our libraries and organizations have been around for numerous years, sometimes hundreds. Often that means many processes are created, changed as needed, and left in place long past their due date. Unfortunately, that means we are frequently working inefficiently, following old processes or cobbled together workflows.

The first part of the presentation will suggest methods for understanding and reviewing workflow. In the second half, we will take a look at various simple and lightweight tools and ways to use them to make work more efficient, especially in processing text, files, and data in batches.

Originally titled Tools, Tips, and Tricks to Making Work More Efficient. This webinar was presented for Florida Library Webinars on March 8, 2017. https://floridalibrarywebinars.org/events/16003/ Continue reading Reviewing and Improving Workflow and Productivity: Methods and Tools

Code4libBC Presentation: Getting Things Done: Discovering Efficiencies in Workflow

This lightning talk was presented at Code4lib BC 2016.

For a copy of the slides, please see the presentation on SpeakerDeck (also below) or the version on GitHub.
Continue reading Code4libBC Presentation: Getting Things Done: Discovering Efficiencies in Workflow

Guide Rework Part 2: Guide to Accessible Formats

Last week, I posted about updating our “What Format Do You Need” guide and taking a different approach in helping our users decide what format they need. Looking at the guides, I realized that my draft could be a possible replacement for the quick guide, but cannot replace the more detailed version (below). The detailed version has so much more information and obviously breaks down the information differently. Continue reading Guide Rework Part 2: Guide to Accessible Formats

Guide Reflow: Deciding on Your Accessible Format

We have two existing guides that help coordinators and students decide on their preferred format, but they seem to reflect all the formats we could produce rather than the more practical reality of what we normally produce. Continue reading Guide Reflow: Deciding on Your Accessible Format

Getting Thrown into the Deep End

So I started at CILS 3 weeks ago, and oh boy does it feel longer. My first week was a lot of getting settled in sort of thing (which means orientation and a lot of paperwork), and being given the simplest of stuff. After the first week, I was thrown into the deep end. Continue reading Getting Thrown into the Deep End

Issue Tracker (Redmine) Implementation Update

In a previous post, I talked about how we chose our issue tracker and then our implementation. Unfortunately, at the time, we had some trouble getting staff to use it so the team had strategized on how we might improve uptake. Continue reading Issue Tracker (Redmine) Implementation Update

Implemeting an Issue Tracker (Redmine)

For more than half a year now, I’ve been trying to get an issue tracker fully implemented for our IT team within the library. I admit that I’m still working on it. Getting the system up and running was easy enough, but trying to work it into people’s workflow isn’t so easy.

Choosing the Issue Tracker

There are a lot of issue trackers out there, but we are a small team and I wanted the issue tracker running easily and quickly. It’s not something I wanted to spend a lot of time getting up and running, because we had a lot of other projects happening.

Other requirements included:

  • support multiple projects
  • non-members being able to report issues
  • support email issue management (either built-in or plugin)
  • low to no cost

preferable

  • support CAS or LDAP login (either built-in or plugin)
  • documentation area and/or wiki
  • code repository integration
  • open source

I asked around a little bit, and these were the recommendations I got:

  • Asana: 2
  • FogBugz: 1 Against: 1
  • Footprints: – Against: 1
  • Github: 2
  • JIRA: – Against: 2
  • Pivotal Tracker: – Against: 1
  • Redmine: 5
  • Request Tracker: 1 Against: 1
  • SupportPress (for WordPress): 1
  • Trac: 3 Against: 1

Trac and Redmine seemed to be the two forerunners. My problem with Trac was that it didn’t have clear project organization, and no one could confirm that the email issue management plugin worked.

Installation & Setup

Our system administrator took a couple of (not full) days to get it installed and going, and following the instructions were apparently fairly easy. Then it took me maybe half a day to set up all the projects and users with the settings I wanted. The e-mail creation also worked well out of the box. We just had to make sure we had the right settings for what we wanted.

Staff Issue Creation & Management

In order to make it so that staff can file issues without ever having to see Redmine, I created a form in our Intranet (webform module in Drupal). The form had most of the standard fields:

  • Name: automatically filled in with username
  • E-mail: also automatically filled in
  • Related to: options which were essentially the project names
  • Need: options equivalent to tracker e.g. Support, Bug Fix, etc.
  • Priority: options equivalent to priority
  • Summary: email subject line, which then turns into issue name
  • Description: issue details

Once it’s submitted, a copy is sent to our team’s email. Through a cron job (every 5 minutes or so), the email is picked up, and filed.

If the user already exists in the system, Redmine will use the email from the user account to match it to the user, they will automatically become the ‘reporter’ of the issue, and get a copy.

If the user does not exist in the system, Redmine will say that ‘Anonymous’ reported it. This will always happen the first time someone reports an issue as I did not add everyone on staff to the system. So, the first time this happens, I then add the user to the system, and add them as a watcher to the issue.

The one issue I ran into was that I forgot you have to set both the email plugin and each project to accept issues from anonymous users. Simple carelessness really.

Getting Staff to Change their Workflow

I think the hardest part with implementing any issue tracker is getting staff to use it. Within the team, it hasn’t been too difficult. We have a small team and the developers in particular have no problems using it. The only problem I sometimes have is making sure they close issues when they’re done with them.

But even within the team, sometimes it can be difficult to get people to report issues using Redmine. While our manager wanted us to start using it just for the website, it has worked well enough, so we’re strategizing how to get the rest of the staff using it now.

We’ve concluded that it kind of needs to be an all or nothing. So we’ve decided that all non-urgent issues should be done through the intranet form regardless of the project, and that should people email us, we’re going to be emailing them back to submit it through the form.

For any urgent issues and for immediate support, they can still call us. After all, trying to walk someone through editing something on our website or intranet is much easier by phone anyway.

Before we start enforcing it, we’ll be introducing this workflow to staff through various committee meetings in part to gather feedback.

So… we’ll see how it goes.

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.

Making Announcements: On-Site vs. News Blog

We’ve recently had to put up a couple of announcements due to some patches and upgrades on our library website server. Right now, I’m doing it the way I’ve seen it done on most library websites and that’s to simply put up an announcement on the front page.

Ryerson Home page with Announcement

However, there are numerous downsides to this method.

First, the way I’ve done it, it only shows on the home page, and no other page.

Second, you have to visit the website beforehand while the announcement is up in order to know that the site will be down later.

Using the Blog

One way to get around the second problem at least, is to use the blog. Posting on the blog automatically pushes the downtime announcements to the homepage feed, meaning that anything following the feed will see the notice even without visiting the site. On our blog, we can also automatically push to Twitter and Facebook if we choose to do so.

On the other hand, it’s very much time sensitive, and if the person doesn’t visit the site during the early hours of the morning, they wouldn’t even notice. Is it something people really need to be notified off-site? If someone visits often enough, they’ll see it.

Notification Bar

To fix the first problem though, I have been pondering the use of a notification bar. Much like the ones you see when your JavaScript or Cookies are disabled (see the stackoverflow example below).

Example of Notification Bar with Stack Overflow's site

Of course, best practices seem to be to only use notification bars for browser related issues.

Pop Up

What might work better is to have a in-page popup on first visit (once the announcement is set), with the option to dismiss it. Using cookies, you could then locally store a simple variable to see whether the person has dismissed that particular announcement already.

Ideally, we could do it in such a way that it will work across the entire domain rather than just the one site.