The system isn’t quite prime-time, but I want to show you how I went about trying to solve this problem: at some point within the last year, we discovered that our website outgrew our ability to maintain its content. When we updated our hours I had to track down every instance; when we hired a new subject specialist, we underestimated how many pages named her predecessor; when it was time to change a menu item, I had to do it fifteen times. Being midnight–which seems to be the time when I feel like blogging–I’m sure I’ll exhaust myself before I can address every content problem [although, if someone wants to offer me a book deal ... !], so I want to focus on my favorite artifact of bad library content: the event.
The library event is a fairly interesting piece of content because it arguably serves the most important purpose: increasing mindshare, fostering the library’s communion with public good-will which preserves us in low times. But if you look at a few library websites you see that events can be pretty fucking nasty hobbitses:
- Problem: events are most often presented in carousels, an antipattern bad for accessibility, one that is simultaneously a pain for vestibular disorders (46% of adults) and looks like a bad ad.
- Problem: events are commonly advertised as text on uncompressed low-res images. They either look blurry or they’re slow to load. There’s no middle ground.
- Problem: events advertised with images aren’t usually semantically marked up and lack alternate text.
- Problem: events are often presented bundled on a hard-to-navigate list or calendar.
- Problem: events aren’t personalized or tailored to the circumstance of the user; the likelihood of encountering a senior book club is the same as storytime.
- Problem: events appear on the home page and on the events page … and that’s about it.
I point out these common issues because I think it’s important to contrast these with the good-intentions bound-up in them. Library events aren’t ads, and that’s the point. Free, cultured, and educational, they are a feather in cap of the institution and the community. We want them to be seen. We aren’t selling a product or selling our user’s data, but we fall victim to the tropes of sleazy advertising and the constraints of having no content strategy.
Today’s web encourages us to free-up our content to let it flow everywhere. In large part, libraries’ homepages are swamps: standing water, slow to change, not for tourism. It is a place where the promise of an event is strangled and ingested by slithering clutter. At the Sherman we knew this content deserved better, so we started with a wish-list:
- First, we want our events to be on as many pages as make sense without manually changing them.
- Can we ensure a certain level of quality of our content?
- Can our events be smarter? “Storytime” is just filler in a business database.
Content Wants to be Quality Controlled
The larger the pool of content creators, the more important your measurements for quality. The Sherman has a relatively large amount of content creators, and while my job is roughly UX and development, I don’t actually write much for our sites. So I have a few pet peeves:
- Every time a bogus, non-English character weasels its way into copy because someone copied-and-pasted, I want to die inside.
- Every time someone embeds an image or highlights the text bright blue, I actually do die inside – just a little.
- For every typo, overly-erudite, or laughably sparse–there are some events that have just one sentence–I take a moment to kill some people in Battlefield 4.
Then there’s the general dysfunction where the public librarians aren’t aware of an upcoming exhibit, and yet they are chastised for having arranged no corresponding programming. Pretty bad for morale. This had to stop.
Part One: Getting Everyone on the Same Page
Our prior calendar was reserved for finalized events because it was publicly visible. If when an event went live and it was unfortunately the first time one department heard about another department’s program, it was too late to organize and budget. You can’t ensure good content if you can’t ensure a good environment for creating it. I wanted everyone on the same page – literally.
In full disclosure, I’m actually presenting this whole scenario out of order. This is actually one of the recent problems, and at this point I already had an entire underlying infrastructure with special post types tailored for event creation and syndication that I could tap into. So when it comes off like, “Hey! I took a few minutes and did this,” I’m totally glossing over the fact that it’s just a brick on a lego tower.
The first thing I did was jury-rig a special view of our new calendar–a traditional calendar layout displaying essentially just a WordPress archive of our custom “event” post-types [small tangent: we don't really expect many users to "browse" the calendar; I essentially made it to replace the old one, but we hope most will stumble on events that we promote in other ways]–so that when staff were logged in they saw all programs at various stages of planning and publication – from kernel of an idea to a full-blown doozy.
Enabling staff to see ahead, to peer into the goings-on of other departments, smoothed over the gentle myth that all things introduced in managerial committees trickle down to all staff. A simple balance to human error, forgetfulness, and misinterpretation. I also gave the staff view a separate color code, so rather than colors indicating type of event they indicated stages of readiness and quality. See, while content is essentially crowdsourced, only a handful of staff have the privileges to publish it into syndication. Now at a glance we are able to see that, “Oh! This exhibit has been elevated from a draft. Now I can check to make sure it has the proper SEO, the correct image-size, and stuff like that.”
The second thing was to serve a different template to staff when they viewed an event. Clicking onto a program from the calendar takes users to the individual posting where the event is displayed in glory with a full-width banner and some attitude. For staff, I spun-up an ugly but useful template that displayed all in one go the bulk of the content associated with the event, what was missing, what needed work, the featured images and associated thumbs, dates, targeted audiences, and all of the mechanics that are otherwise hidden from users so that the “mysterious” process of syndication was made transparent.
Part Two: Chunky Content
The way that crap gets into WYSIWYGs is because it’s a big blank slate imbued with paralyzing freedom. I started writing an explanation to that sentence, but I’m just going to leave it as is. Basically, my demands of event creation weren’t entirely reasonable of content creators:
- All images needed to be a specific resolution and in a 16:9 ratio, properly compressed
- All times and dates had to be in a very specific format
- If an author didn’t complete the SEO by Yoast plugin fields, she or he couldn’t publish
- An event needed to be targeted to specific audiences and categorized with specific event types, but if the author went category-happy, they couldn’t publish
- Etc., ad nauseum.
And there wasn’t really a good way to enforce this with a WYSIWYG. So I took it away. In its place, I broke up all of the different parts of what made an “event”–time, place, audience, promotional materials–into different chunks, storing these in custom fields so that I could not only have granular control when designing the template for an event, but also so that I could saddle these fields with validations and make some required. All of this is largely inspired by a concept called “content modeling” introduced by Karen McGrane in her book Content Strategy for Mobile.
The upshot is that creating an event is a fairly straightforward, step-by-step process where when needed I’ve been able to add explanations, while controlling the important pieces–date and time format, etc.
Creating “Smart” Content
“Smart” content is a bit of a misnomer. What it is is content over which you have granular control, and granular content is the result of content modeling. We gave our content muscles by creating a few very controlled site-wide taxonomies. We have one set called Audience–broad strokes, like “Public,” narrowing to “Teens” or “Alumni”–and, my favorite example, Subjects. These potential subjects with which to associate an event are the same subjects that organize our research indices. A subject category with the nicename “Business” has the unseen slug “zbu.” ZBU is the three-letter designation for databases that are categorized under “business.” Of course, no actual human with a life would notice this – but our taxonomies match. This begets magic.
I wrote a custom controller for the WordPress JSON API called “taxonomy” which will find all posts–in this case, events–in a certain category. Let’s imagine that the sidebar of our research indices has an empty
<aside data-event="$aid"></aside> and we are browsing under “Business.”
- The three-letter subject designation appears as a parameter in the URL:
- jQuery in the footer grabs a random upcoming event by passing the subject in the WP JSON API:
Subject-oriented pages like databases or library guides are fairly low hanging fruit for contextual event advertisement, but with a little extra work and educated guessing you can do this based off audience type – especially if you happen to be passing a cookie around after the user logs in [which we aren't, yet].
There’s More to Say
This is where I’m going to call it quits for the night, but I’m happy to elaborate or dig further into geek. There’s more to say, and there’s certainly more to think about. I didn’t explain how we chose to address responsive images, what we are making our events look like–i.e., how exactly are we trying to make them less ad-like?–and so on. Not to mention that all the other content types are similarly granular, but maybe a little less controlled because we’re not always attaching huge, performance-affecting images to them. What about the actual, human work-flow for content creation? I’d like to hear your thoughts!