Think systems, not pages

People are used to thinking about the web in terms pages. Most modern CMSes can make pages, but if you’re using them properly what you’re actually creating is a system of interconnected content. That’s a whole lot more awesome than pages. That’s the difference between creating structured content vs. having unstructured pages. Structured content allows you to:

  • Filter or sort only the content you need
  • Syndicate content across a site
  • Have more control over the markup/style of the content
  • Create consistency for all pieces of a particular content type (e.g. events, announcements)

Structured content has many pros, but it takes a little while to get used to this paradigm. People used to editing pages might not be used to thinking in terms of systems. This is a pretty minor problem because once the power of structured content is seen, most people understand the value in it. At work, we’re shifting from a model of pages to structured content because of a CMS switch to Drupal.

A paradigm shift is needed to really utilize and harness the full potential of a CMS like Drupal. What makes Drupal special is the ability to easily create structured content. Oswego’s current CMS allows you to create unstructured pages. This means that all content is dumped into 1 area, which has many limitations. Some of which include:

  • The system isn’t aware of a “type” of content, because everything is a page
  • Unable to filter/sort content
  • Markup and data is intertwined and not easily teased apart

This presents a problem if you want to sort all your event pages or list faculty members by department. If your events and faculty profiles exist as pages and not as structured content, these types of things are not easily possible. As an example of what can be done with structured content, watch this video for a few minutes starting from 11:00 in. I would recommend watching the entire video because it really hammers home how to think in systems.

Structured content can help an organization do all sorts of neat things like sorting and filtering while unstructured pages lock the content in so it can only exist within the page it was created in. Structured content can be displayed on any number of pages and any number of styles. It can also be updated once and changes can be seen everywhere that content is referenced. This can save so much time and effort if you’re duplicating content the old fashioned way (copy & paste).

Thinking in systems is initially more difficult because it involves more planning. Once the system is built, it will provide a lot less work to users who are tasked with editing their content.

Think of this example use case that happens daily. A department wants to make an event. So they create a new page for the event, and use the WYSIWYG (what you see is what you get) editor to paste in their content from a Word document. The user enters a photo for the image, a start date and an end date. Life is good now because there’s a page for the event. Now the user needs to add a link on their home page to this event. So the user checks their home page out of the CMS and adds a link to this upcoming event. This event should also be listed on the “Events” page within the department, so the user checks that page out and adds a link to the event.

If that wasn’t enough work, the user’s boss came and said “Hey, we switched the name of this event from XYZ Event to ABC Event, update the website for me.” That’s a legitimate request, making sure content is up to date and relevant should be high on anyone’s list of priorities. After the boss’ request, the poor user now must check out 3 pages and change the title of the event in 3 different pages (event page, home page, event listing page). This is a huge waste of time and it doesn’t have to be like this.

There is a better way

Luckily, if you think in systems, not pages, then this type of scenario will be a thing of the past. In a system, you have structured content that you can filter and query. With pages, you have disparate files that have no relationship between each other. Wouldn’t it be nice to update the event title in one place and have that propagate to all places where that event is listed? With proper planning this is absolutely doable and will save lots of time and headaches.

Drupal will allow us to do things like this and much more, but proper planning is required. With proper planning, you can utilize Drupal to be so much more than a CMS. What you’re really creating is a data layer for the organization. In the back end, you’ll have all your announcements within structured content types. Same with faculty profiles, events, student testimonials, etc. No longer are the just a page. Within this paradigm lies a whole new world of possibilities for organizations and I can’t wait to see where it brings us at Oswego.

What do you think?