Integrating CSS with Content Management Systems
Published on September 15, 2004
Building CSS editing features into our content management systems allows us to make style changes as easily as we make content changes. In the future, managing the design of a Web site at the tactical level will be as easy and efficient as managing content.
Let’s assume we all run big, important Web sites that require content management systems for editing content. We go to our Web-based forms, edit the content, and publish with style and grace.
Let’s also assume we’re all good boys and girls and have separated our content from our presentation. We not only have content management templates that flow content into XHTML, but our presentation code exists separately in CSS files.
Once we have a CMS that lets us manage our content, the next step in this put-your-feet-up-on-the-desk-and-manage-the-Web-site evolution is a system that lets us manage our presentation, too. Let’s call this a presentation management system, or PMS.
The PMS administration interface
I will tackle process and philosophy later; for now, let’s examine the user interface.
Here are a few sketches of how you might edit your stylesheets from a Web-based interface. They’re listed in order of technical skill required of the user, from most to least.
Web-based CSS upload
- Assumes the user has the technical skill needed to create a valid CSS file.
- Is best suited to a user who edits stylesheets locally and uploads complete files.
- Good for large companies that need the safety of version control and the ability to roll back to previous versions.
- Would have a companion screen in the PMS for deleting stylesheets.
Web-form CSS editor
- Is good for small, infrequent changes.
- Would have a companion screen in the PMS for selecting which CSS file to edit. Alternately, one PMS screen could be used to edit all selectors.
- Example: Textpattern’s CSS editor.
Web-form CSS editor with lists
- Is good for small, infrequent changes.
- Limits the types of changes users can make.
Modular style selector
- Further limits the types of changes that users can make.
- Could segment modules in the following ways:
- Audience (if tied into an authentication system)
- Site section
- Site (if the PMS manages styles for more than one site)
- Could be used to rapidly try new presentation styles.
Monolithic style selector
- Restricts granular changes completely.
- Requires no specific technical skill.
- Provides a one-click way for administrators to change the look of a site.
Using styles in the CMS author interface
One obstacle to more widespread adoption of Web standards is the outdated mark up generated by CMSs. When marking up content in a CMS, all appropriate selectors defined in stylesheets should be made available.
For example, a PMS text input interface should be designed so that authors can select text and apply a style to it.
Rich application CMS add-ins like CSS Web Edit Pro will even do this with a WYSIWYG display.
Why PMS? Why?
A PMS is useful when any of the following is required:
- More efficient editing: In large organizations, uploading files can be time consuming and complex. A developer gives files to a system administrator, who then uploads the files to a staging server. The files are then checked by quality assurance. Once the files are approved, the sys admin can upload them to the live production server. That’s a lot of process for small changes. Content management makes it possible for authors to edit and preview content changes themselves, which is more efficient. Similarly, designers can use a PMS to edit CSS files themselves.
- Editing by those with little technical skill: Like many other advancements in technology, once we have a solid understanding of how to use something, we can make it accessible to those with less technical skill. For example, authors who don’t know how to edit XHTML can now publish properly marked up content using CMSs. Designers who don’t know how to write or edit CSS can make presentation edits using PMSs.
- Editing by business clients: Designers could create alternate designs for business clients’ sites and a number of style sheets could be set up and applied as needed.
- Illustration of the value of Web standards: Imagine a client’s reaction when they see they can easily switch stylesheets on their own site. Add content management to the mix and there’s great potential for less technically savvy people to manage their own Websites more extensively.
It is essential to determine certain user needs when designing a PMS UI.
First, I discover who the users are, what roles they play, and what expertise they have. Next, I use this information to match features to users.
On a particular project I might have two types of users—designers and clients, for example. The designers are given an interface to modify the CSS. In this case they have extensive CSS expertise and only edit styles occasionally, so they are given a PMS interface to upload whole CSS files. When clients (who generally have no Web development skills) create new pages with the CMS, they need a variety of layouts that correspond to the content they’re authoring. They are given a PMS interface that allows them to simply select one of a variety of page layouts.
I’ve found it can be a mistake to match the role to the ability to edit specific files (for example, using a PMS to match designers to a user interface that inserts images into the XHTML). In reality, the separation of content and presentation isn’t that clean. Images can be content, like when a photo accompanies a news story; or decoration, like when a company logo appears in the header. Images can be specified in the CSS or in the XHTML. The CMS and PMS should do the correct mapping of user to function, regardless of how the function corresponds to XHTML or CSS files.
That’s it! If you design a PMS, please post screenshots and link to them from the comments section of this article so we can all learn from each other.