Tag Archives: information design

How WordPress falters as a CMS: Multiple content fields

WordPress is amazing and keeps getting better, but I want to be clear about an inherent limitation that WordPress has as a content management system (CMS). That limitation is that WordPress doesn’t handle multiple content regions on web pages.

Too strong? With WordPress, you can try to use custom fields or innovative hacks like Bill Erickson’s approach to multiple content areas using H4 elements in his excellent theme “Thesis”. Unfortunately, neither of those approaches really deals with the depth of the design problem that often requires multiple content areas for pages.

As an information architect/user experience designer, I’ve been involved in many projects that required more types of content on any single screen than WordPress is designed to handle.

Let me draw out what I’m talking about here.

Exhibit A: Page content that WordPress is designed to handle

In a standard WordPress page or post, you’ll see these author-controlled pieces of content.

  • Post/page Title
  • Body
  • Excerpt (often not-used)
Standard WordPress content fields include the title, excerpt, and body.

Standard WordPress content fields include the title, excerpt, and body.

There are other sets of data for a page or post that an author can control, too, but these are meta-data such as tags, categories, slug (shows up in the URL), and possibly search engine optimization information like title, description, and keywords.

For a normal blog, many online trade journals, and a lot of basic websites, this really covers the bases. The body contains the bulk of the content including images, video, and audio that can be intermingled with the text itself. This model is very flexible, and it has definitely proven itself.

Exhibit B: Page content that pushes WordPress too far

In 2009, there was a small project at work to develop the website Covenant Musicians, and because the person who would keep the site updated was already using WordPress, we made the decision to build this site with WordPress too.

Well, if you look at one of the destination pages for this site, the musician profile page (here’s one for example), you’ll notice some different pieces of content which may or may not be present on any particular musician profile page. When they are present, they need to be in certain places and sometimes with certain content.

This custom WordPress page uses fields in addition to the standard options: Musician Image, URL, and Video.

This custom WordPress page uses fields in addition to the standard options: Musician Image, URL, and Video.

The problem is, to control those extra pieces of content: the video, the band image, the link to the band’s website, the site owner needs to use WordPress’s custom fields in very precise ways, without the benefit of WordPress’s content editing tools. What a drag!

To make life easier for the site owner, we ended up recording screencast instructions on how to use these fields and delivered those help files with the site itself. (We used Jing by Techsmith, by the way.)

It would’ve been better had the interface been clear enough so that we didn’t feel the need to document the process of updating these destination pages, but that’s the trouble with stretching WordPress beyond its default content fields.

Ask too much of WordPress and ease-of-use is the casualty

Do you see the difference? When an effective design solution requires multiple types of content per page, using WordPress will actually make your website difficult to manage. WordPress is usually so easy to use that when you hit this wall, it is very apparent.

When you’re at that point, WordPress is probably not the right CMS to choose.

Should WordPress improve in this area?

Whether through the core application or through an excellent plug-in (is there one already that I missed?), if WordPress is going to grow in the content management systems field, this shortfall will need to be addressed.

However, WordPress is really excellent at what it does already, and the better course might be to decide to keep the features in check and let other systems compete in the mid-to-enterprise scale CMS arena. Scope creep never stops, and a good application strategy knows when to say “no.”

Am I wrong?

Am I off-base here? This is just one aspect of WordPress that should limit its use. Another that should cause designers to think twice is when dealing with faceted-navigation which requires more than one dimension (tags can probably handle one dimension). But, again, those are more complex design requirements.

I’m not a WordPress consultant, and I’ll bet some of you would like to point to the errors in my thinking. Let’s hear it.

Seams between systems and the Vignelli NYC subway map

I just read “Mr. Vignelli’s Map” by Michael Bierut over at Design Observer. In the post, Bierut remembers and analyzes why the public rejected Vignelli’s map of the New York City subway system. (Here’s the Vignelli subway map.)

The Vignelli map smartly acknowledged that for passengers of the subway focused on navigating the subway system itself, above ground geography was nothing but a factor of added complexity. So the map instead was oriented around the subway lines and stops themselves, abstracting actual geography. This was a keen simplification from an information design perspective.

But consider this observation from Bierut’s article.

To make the map work graphically meant that a few geographic liberties had to be taken. What about, for instance, the fact that the Vignelli map represented Central Park as a square, when in fact it is three times as long as it is wide? If you’re underground, of course, it doesn’t matter: there simply aren’t as many stops along Central Park as there are in midtown, so it requires less map space. But what if, for whatever reason, you wanted to get out at 59th Street and take a walk on a crisp fall evening? Imagine your surprise when you found yourself hiking for hours on a route that looked like it would take minutes on Vignelli’s map.

The concept of designing the seams between systems has become apparent within the user experience design community over the last couple years. This is an example of that problem of seams.

Passengers of the subway system are also navigators of the city itself, so their context of use spans beyond the subway and the end of their decisions are not merely which stop to get on and off of, but where they are going once they get out of the subway.

Bierut makes the point:

The problem, of course, was that Vignelli’s logical system came into conflict with another, equally logical system: the 1811 Commissioners’ Plan for Manhattan.

How can designers consider the seams between the subway system and the city plan to result in a better-designed subway map?

NYC, of course, has a functioning subway map. Is functionality the only litmus test?

(I’ve taken the subway in New York City only once, and managed to get from Point A to Point B successfully, although with some anxiety.)

A Sad Tale of Pagination

I imagine some professional chefs are accused of over-analyzing a bowl of soup now and then. Like that, as a user experience designer, I get caught up in little pieces of user interface on a regular basis.

This particular story concerns a navigation system that utilizes pagination in what at first seems an obvious choice, but upon observation it is clear that this is a very poor approach.

Background: Company setting

Covenant Eyes, Inc., is an  8 year old software company in Michigan with about 50 employees. About a dozen are customer service representatives, some for enterprise customers and some for individual or family accounts. There are about 10 in the IT team, which includes myself.

Background: What service does our company provide? Internet accountability.

Take 2 actors, George and his friend Paul. George is addicted to online porn, but he really wants to beat his addiction because he feels it is wrong and could really mess up his life. To attack his problem, George installs our software on his computer. The software keeps tabs on George’s activity, and once a week sends a report of that activity over to Paul. Paul can then talk with George about George’s Internet activity. It seems simple, but removing the anonymity of his addiction is powerful.

The point, in a nutshell, is accountability. If George is trying to kick some bad online habits, his friend Paul now has information in these reports that he can use to hold George accountable.

The current design calls for pagination

These Accountability Reports are like executive summaries that include links over to what we call the “Detailed Logs.” This log is a full list of URLs that George visited.

Depending on the amount of activity, the log may have thousands of entries for Paul to navigate.

When these logs first became available, customers’ download speeds were more of an issue than they are today, so the developers knew that they could not simply put all the entries on a single page because the pages would take far too long to load.

Pagination to the rescue! The developers broke up the long list of URLs into pages, each page having 50 URLs. To help Paul navigate this long series of pages, numbered page links and “Previous” and “Next” links were placed at the top and bottom of each page.

So, let’s say Paul is looking at page 50. He would see something like the pagination navigation shown in Figure 1.

Figure 1: Pagination

Figure 1: Pagination

This seems a good approach on two fronts.

  1. Paul won’t wait to download one page with over 8,000 URLs on it, but if we divide that time into, in this case, 165 separate downloads, each page will seem pretty quick.
  2. Pagination will work for Paul because he uses pagination on nearly every search engine results page. It’s nothing new to him.

Bingo. Problem solved. Right?

But why does it take so many clicks to find the right info?

I was standing next to Mike, one of our Customer Service Representatives, and asked him a seemingly simple question. “Mike, can you bring up that log and show me what was going on last Tuesday at 11:32 AM?”

I did not intend it to be a usability test, but it might as well have been. Mike helps people every day by walking them through reports and logs, so he is as expert as anyone gets at navigating these logs. Yet, the basic task of finding a page with a specific time on it was accomplished by a series of guesses, each slightly more informed than the previous guess. It took 8 tries before Mike got us to the right page.

Since then, I have seen people repeatedly click the “Next” button, flipping through each page to find the one page they want. With 165 or so pages in a log, this can take far more than 8 clicks.

If someone knows the date and time they want to view in a Detailed Log, shouldn’t they be able to get to that page without guessing on the first try?

20/20 hindsight: Why is it so hard to find the right page?

Pagination is a valid interface design pattern, and is perhaps most often seen on search engine result pages. Still, it does not work well here.

So, why doesn’t pagination work here? Thinking in information architecture terms can help answer the question.

Pagination is a metaphor from the print world

We’ve all grown up reading books and magazines, and so page numbers are a tool we take for granted. In print, they are used to keep track of where we left off so we can pick back up at the right point. They are also used as non-digital hypertext, like in a magazine where we see “continued on page 58.”

On the web, pagination has become something slightly different, but the metaphor carries over well enough to work for us. On search results pages, we now expect to see a pagination interface at the bottom of the search results to allow us to continue to the next page of 10 or 20 links. One difference on the web is that we expect those links on the first page to have higher relevancy than those on the following pages.

So, on the web pagination is an answer to a finding question, and is based on an underlying organizational system of quantity ordered by relevancy.

However, in this case, the list is ordered by time but paginated by quantity. In this case, people want to find by time, but quantity is not metered evenly against time. So, page 1 might have 50 entries that cover 5 seconds of activity, and page 2 might have 50 entries that cover 32 hours of activity. There is no predictability of how much time will be represented from page to page of results, and that is why people are left with so much guess-work.

Match the interface to the underlying information architecture and users’ information needs

In recent work, we’ve shifted to a time-based pagination (Figure 2) from a quantity-based pagination (Figure 1). We think this will go a long way towards helping people find what they want without having to guess.

Figure 2. Find-by-time instead of pagination.

Figure 2. Find-by-time instead of pagination.

I’ve observed a few users have their first contact with this revised interface, and it has worked well so far. We may have introduced other usability issues in the process, but this is a step in the right direction.

Moral of the story?

Before implementing a user interface design pattern, be sure you first understand the information architecture and users’ information needs. Otherwise you risk using the wrong pattern, hurting your users’ experiences, and missing out on an opportunity for innovation and good design.