The Web & Creative Services Blog Takes a Break


Regular visitors to this blog probably noticed that we stopped adding anything new quite a while ago. In fact, we just passed a year since our last post. If you’re still visiting after all this time, we thank you for your loyalty and apologize for our absence. Please don’t think we stopped caring. It’s not you. It’s us.

Through the course of moving to a new content management system, launching a responsive website, and getting more involved in projects that were initially outside of our team’s scope, we got really busy. Something had to give. Unfortunately, the blog gave.

So we’re taking a break from blogging.

But don’t worry, we’re not going away! We’re always more than happy to answer your questions, work with you on projects, and fix things when they break. Contact us any time at

For the time being, that’s all folks!



The Challenging Chore of Enterprise Content Maintenance


With the continual growth of multi-device web browsing, everything we once knew about web content has changed. So there’s a lot of discussion these days about content strategy. Web experts preach best practices for publishing to multiple channels, making content the priority, thinking mobile first, moving away from the WYSIWYG, and creating content chunks.

A lot of these principles are well and good.

They work swimmingly when you’re building a smallish website. Or when everyone contributing to your site has a solid grasp of web best practices. Or when your main goal is publishing articles, posts, or documentation that carries similar content structures—like news sites, blogs, and help forums.

But what about when you have a 20,000 page website with diverse and varied content requirements? What if you have hundreds of web contributors who are experts in finance, biology, or event planning but not necessarily web content management?

I’ve worked in enterprise content management at a university for six years. And I’ve found a lot of the latest web content theories to be useful and relevant on the super-micro or heady-abstract level. But, if I’m being honest, many of the principles just don’t seem to scale when you’re managing a big, complex content system.

Universities, government agencies, and other mega institutions likely get what I mean. Taking these abstract theories and trying to apply them in a highly political, messy, human environment is immensely challenging and maybe even borderline impossible. When you tack on the limitations of your CMS and available resources, it feels like you’re trying to drive a system as incomprehensible as the Starship Enterprise.

So which of today’s web management principles can we actually use in our big messy systems? Is there any way to make the theories more practical or grow them to a larger scale so they make sense for our kind of work?

Here are a few of the strategies I’ve used.

Extend content management beyond the web

One of my big pushes right now is to help people stop thinking of our CMS as a tool for building webpages. Instead, I want us to see it as a system for managing information.

The CMS should be the place to store as much content as possible—not just webpages.

Some info will end up on the web, but not all of it. Some might get sent out through emails or exported for use on print pieces.

We’re trying to take a huge step back and think of not only what’s needed on the web, but what info should be in the CMS that’s currently sitting in word docs on shared drives, Adobe files on desktops, or email inboxes.

For example, this spring we needed to update our print promotional materials for our undergrad academic programs. Instead of looking only at print pieces, we decided to include the websites and work on new content for both at the same time. That way we could identify what content would be shared across print and web and then build out the content requirements in the CMS to house all promotional info together in one place.

Now, when web authors update their site, they’re also keeping content for their print pieces current because it’s all housed in the same template. Next time we need to run a print job, we can pull fresh content right from the CMS and pass it along to a designer for new formatting. When we need a blurb about a specific program for a new kind of piece or an email, we know where to go.

One of today’s web best practices that makes this system work is separating information from presentation. If we think of content as the words and images (the information), and let the CMS take care of the formatting, then the information becomes more portable and useful. The content becomes pieces of information, rather than designed elements stuck to a webpage.

It takes some work on the backend and lots of conversation and planning, but once structures are in place it becomes a lot easier to maintain information going forward. And don’t worry about doing it everywhere. Start with one small section or a single content type and see what you learn.

Find a balance between structure and flexibility

The harsh truth is that you can’t give everyone equal attention. There’s no way you can dedicate the same amount of time and skill and funds to every piece of information when you’re working in enterprise content management. And that means you’re going to have to say no and make tough decisions and prioritize.

I spend a lot of time thinking about content priority. At our institution, all information falls into 5 different content levels.

Assigning content levels to all of our information helps us determine things like:

  • How much time we should spend planning and developing
  • What information needs to go through editorial workflows
  • How much training and support we can provide
  • What tools should be used for building and maintaining content
  • What permissions we should assign to authors and contributors

Content levels also help us find the balance between structure and flexibility.

Top level content gets more flexibility. We spend more time crafting unique layouts and content treatments for higher level information. It receives more design finesse and development magic.

But that means lower level content must have more structure and follow more rules. It’s housed in similar templates and uses basic tools so that we can distribute content production to authors who don’t work with web content all day. Because turnover of web authors is high, structured systems also allow us to streamline training and make it easier to replace authors who have moved on to other roles within the institution.

Finding that balance between structure and flexibility will be different for every institution because of politics, clout, business process, and resource availability. But at the very least, it’s important to spend time prioritizing where you should invest the time to make a splash and where you need to say no to unique requests so that you have time for the projects that will make a bigger impact.

Plan for the life of your content

When you’re dealing with content on such a large scale you have to plan for maintenance. There’s just no other way to keep your sanity. And then you have to do the tough work and carry out your maintenance plans.

This is a huge challenge for us humans. We like to create, but we struggle to sustain because it’s tiring, draining work with little reward.

Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance.

- Kurt Vonnegut

There’s no slick trick for ensuring your information is maintained. It’s just a lot of work. But there are some strategies we use to make it a bit easier.

First, we don’t create or publish new content unless there is a dedicated author for the information. Our web team members are not information experts. They’re here to set up web systems that work for the institution. They’re not here to know when information is out of date. All content needs someone looking after it once it’s created.

Second, everyone goes through training. We try our best to not only train people on how to use tools but also on how to create good content—from information architecture to heading structure to linking best practices.

Third, we meet regularly with those responsible for maintaining content and give them new information. Through monthly meeting ups, our authors have an avenue to ask questions, connect with each other, and build their skills.

There’s a lot more I could say about enterprise content management because it’s a huge, challenging task not for the faint of heart.

Be encouraged that there are others out there trying to figure out how today’s best practices apply to the complex work you do. There are likely times when you dream of being able to build and support a 50-page website focused on a single product or service, but know that lots of people appreciate and rely on the work you do behind the scenes to keep your giant systems running.

Keep up the good work, and know that every small step moves you forward.

The Responsive Image Challenge – Part 2


In our last post, we talked about why images are getting increasingly complicated on the web. It’s a challenge we’ve put a ton of time into solving here at Bethel so that our system is easy to use for authors, designers, and developers.

To create the right solution, we needed to resolve 3 big issues:

  • Selecting the correct image size using dynamic JavaScript and HTML
  • Creating different sizes of the original image automatically
  • Uploading original images into the CMS

So, what did we do? We first looked into getting some JavaScript and HTML to select a good image size. This task was made easier with a little help from our friends across the pond.

Selecting the Correct Image – Imager.js

The BBC has an awesome library called Imager.js. Without burdening you with too much technical jargon, Imager.js is a JavaScript library to dynamically put an image into a placeholder element when the page loads. There are quite a few different libraries to do this, but what separates Imager from the rest of the pack is that it uses the width of the container element, instead of the width of the entire screen. So if we only need an image 100px wide to fit a container (even if the screen itself is 2560px wide), that’s the size we get.

Another thing we liked about Imager was that it loads images by the exact width, rather than using generic identifiers like “small”, “medium”, “large” to specify size. This helps us follow our third rule from the last post, “don’t serve a bigger image than you need.” Imager will select the exact size to fit the screen area. I won’t go into the coding specifics, but it’s documented well and easy to use.

Once we had Imager working correctly, the next problem was figuring out what to do with tons of different sizes of the same image. Dumping them into our CMS would make the system very cluttered and unfriendly. So it was time to look into solutions for automatically creating different sized images of an original image outside the CMS.

Creating Image Sizes – Thumbor

After some searching, we found a Python application called Thumbor.

Thumbor is pretty easy to install, and very easy to use. You simply call the Thumbor service using a URL and send a few parameters. Most notably, you send a width and height. Then it will download the original image, resize, crop if necessary, and return the new image. This means we can put Thumbor URL’s directly in our <img> HTML tags and it will work just like a normal image.

Remember how Imager used exact pixel width instead of a size? This was perfect for Thumbor. It was extremely simple to configure Imager.js to work with a Thumbor URL using an exact width.

Thumbor also has a few other neat tricks. First, it can set the height of the updated image automatically based on the width. It also stores versions locally. So if you request a 300px-wide image, it will resize, crop, and return that image. But it will also save a local copy, either on the filesystem or in a database. This means that next time you request the same 300px-wide version of the image, it won’t have to resize, crop, and return. It will simply return the smaller version it saved. This means that Thumbor overhead is extremely small. It only has to crop an image once. This made meeting our second rule, “have your resized images ready to go before they’re needed” pretty easy. Thumbor stores the versions for us.

To make it even faster, we have a simple script to request popular sizes of Imager from Thumbor when each image is uploaded. This means all our images will be available when we need them.

So once we had Imager and Thumbor working seamlessly together, the last step was pretty simple.

Uploading Images

Now there’s only one rule left to worry about, “always upload the largest copy possible.” Unfortunately, there isn’t some fancy Python script to make sure our web contributors upload the largest image size possible. This step requires some training. However, there might be a few helpful things you can do depending on your CMS. Maybe you can set a minimum width and height for new image uploads? Or a minimum file size? Who knows…just brainstorming.

But once the image upload process is actually started in the system, we can start having some fun. The first thing we do when an image is uploaded is automatically upload it to the server. Nobody thinks to publish an image after upload anyway. The CMS automatically pushes this image to the CDN, which triggers the script to request the different widths from Thumbor. This means that there are now 5, 10, 15, or even more versions of the image ready to go.

The best part? The web contributor can work with the image within the CMS just like normal. They have no idea that the image they are working with is never actually used. And that’s not a problem at all. They embed their image onto a page, and the template configures Imager to create the Thumbor-friendly URL inside the <image> tag. And then, when the page itself is published and viewed, the resized images are ready to go, just like any other images.

Aside from a few installs and a little template work, it’s completely seamless for authors, designers, and developers. And, to top it all off, no overhead for end-users. Just like that, we’ve created a 2007-style way to interact with images that works seamlessly with 2014-compatible complexity.