Home > Articles > Web Development > Content Management Systems

  • Print
  • + Share This
From the author of

Multiple Device Issues

If I've implemented all of the above suggestions, and I have this fantastic, abstract, presentation-neutral, XML-based content management system, why should I have to worry about multiple devices? Isn't all that taken care of at the presentation or content distribution layer? Shouldn't the content in its raw form be divorced from presentation or specific device issues?

Well, yes and no. The fact is that serving content to multiple devices is where "single-source" content begins to fray at the seams. Single-source, 100% presentation-neutral content management was always a bit of a loony idea. Consider the following scenario. Your content is a catalog of electronic merchants. Each merchant needs to have a name, a category, and a link to the merchant's site. Sounds simple enough. But consider that each of these merchants might have a web site and a WAP site. Which URL should you link? Obviously, this decision should be based on what device the user is using at the time—but in order to support this ability, you have to encode both web and WAP URLs in your content. You have to encode device-specific information in your content.

Further, you can afford to display a longer description on the web, where the user has a large screen, than on a WAP, where you want to keep the description concise. Now you have a large description and a short description—again, due to device-specific issues.

How about a logo for each vendor's store? If your user is on a black-and-white WAP phone, you want to send a black-and-white logo, as opposed to the full-color logo you can use on the web. Now you're carrying around two different versions of the logo, again based on device type.

Classify Your Devices

To put it plainly: the content needs to understand different classes of device. The presentation layer can worry about making device-specific changes, as long as your content management is device-class-aware (see Figure 3). For instance, taking the above example of the vendor catalog, the content management system can keep track of a short description and a long description, and different logos for WAP and web, but doesn't have to know about specific presentation on specific handsets. So, for instance, your presentation logic could decide not to display the logo image on a particular handset that you know has a very small screen.

Figure 3Figure 3 Content management versus content delivery. Content management needs to be aware of device classes, content delivery needs to be aware of specific device characteristics.

I think of content management and content delivery as two interlocking systems. Content management's job is to get content "ready" for the delivery stage, where it's actually delivered to wherever it needs to go (web, WAP, email or SMS, PDA, syndication feeds, or whatever). The delivery layer can be aware of and responsible for those different channels of distribution, as long as it can rely on the content management layer to "prepare" the content for that kind of multichannel distribution. For more discussion of content delivery issues, see my previous article, "Using XSLT To Serve Content to Multiple Devices.

  • + Share This
  • 🔖 Save To Your Account