« Journal readership | Main | Save Pandemonium! »

Separating form from content

| 2 Comments

One of the main goals of using Cascading Style Sheets on web pages is to separate presentation from content. The idea is that you can take the same content and present it in many different ways. It can appear in different media (print vs. online, for example), or different layouts (see the amazing coolness of the CSS Zen Garden), or different contexts--like the fact that some of you are reading this on my web page, and others are reading it in LiveJournal or a feed reader, and others are probably reading an excerpted bit that someone has quoted in another blog or in email. Also, different web browsers (and different operating systems) present things differently, even without CSS.

And that is a central fact about the web (and, by extension, about a lot of modern content): you can never be entirely sure what context people will see your content in. Even if your work isn't excerpted and remixed by wacky modern bricoleurs, even if it isn't pirated and posted in all-caps in red text on a black background by some website beyond the reach of American copyright law, even if everyone is reading your work directly from the web page where you posted it, presentation will vary. Some people may be using a text-only browser like lynx; some people may be "reading" a web page using software that reads aloud to them. And so on.

And some of us have learned to try to embrace the loss of control over context and presentation. It's a good idea, for example, to create web pages that can be experienced by blind people as well as sighted people.

And yet, it occurred to me the other day that even though I preach the gospel of CSS, even though I create print stylesheets and strive for accessibility (though I have a long way to go), I don't really believe that content and presentation are entirely separable. It seems to me that they influence each other.

At one end of the spectrum are the blog entries I've been mostly talking about, which might show up entirely shorn of context in someone's feed reader. My friends page in LJ, for example, presents other people's entries with the color scheme and font that I prefer, rather than the ones they prefer.

At another end of the spectrum are works like Edward Tufte's books, with every page carefully designed and laid out to present the content as well as possible, and meticulous attention to exact color matching, and careful choice of typefaces, and so forth.

And it seems to me that what you say and the way you say it are influenced by where on that spectrum you expect your work to be.


This comes up in technical writing quite a lot; I think that's what initially sparked this entry. I was thinking once again, as I have more or less fruitlessly for a number of years now, about The Single-Sourcing Problem.

There are many different forms that software documentation can take. Two of the most common are printed instruction manuals and online help systems.

When I first saw the printed manual for an early version of RoboHelp, I was amused and appalled, because it was simply a printout of the online help system. It wasn't organized like a book; it wasn't written like a book; it wasn't presented like a book. Someone had written a help system, and had printed it out and bound it, and that was the product's printed manual.

But not long after that, I went to work on Dreamweaver's documentation, and we had the opposite problem: we were taking documentation that was written to be a printed manual, and converting it to an "online help" system that didn't read like online help systems should. Online help, in general, should consist of brief to-the-point topics; by and large, when a user consults the online help system, they want to resolve a difficulty they're having. So giving them several pages of conceptual background information may not be a good idea.

Unfortunately, though, software documentation is usually written by too few writers who have too little time. So it's really expensive to have one set of writers writing a printed manual, and another set writing an online help system for the same software.

Also, if you do try to work from two different sources like that, then when the software changes (which inevitably happens moments before it ships), you have to be sure to make equivalent changes in both places. And then there are translation issues. And so on.

And so there are a variety of good reasons to create all your documentation from a single source.

But form influences content. To be most effective, a help system should be written differently from a printed manual.

I've seen documentation departments go 'round and 'round on this. If a department is working from multiple sources, they often eventually decide to switch to single-source. If they're single-sourcing, they often wish for the resources to dual-source.

There are approaches and techniques that combine aspects of both, but they're usually arcane and/or expensive and/or hard to use.

So: what's the answer?

I don't know.

But I do think that, much as I love CSS, and much as I support accessibility, it's important to remember that form and content are not entirely separable. It's convenient to pretend that they are, and there are ways in which they kind of are--but presentation does, in the end, affect the experience of the content, and sometimes it's a good idea to change the content to better fit the presentation.


Now, the above discussion appears to be about blogging and technical writing. But I think some of the same ideas can apply to fiction writing.

In Delany's excellent 1968 essay "About 5,750 Words" (which someone somewhere really oughtta reprint at some point), Delany takes apart the notion that style and content are separate things: "Put in opposition to 'style,' there is no such thing as 'content.'" I wouldn't go quite that far, but his general points include the notions that words derive meaning from context, and that using different words (a different "style") to convey the same general idea (the same "content") may result in very different effects on the reader.

I don't want to overstate my case here. I do think that form and content are somewhat separable; if I didn't, I wouldn't provide a feed of my blog--in fact, I probably wouldn't publish anything online at all, and I certainly wouldn't be a tech writer. But I do think that form--both physical and stylistic--and content are deeply intertwingled.

So whenever you're writing something, give some thought as to the form(s) in which it may be presented. You may have very little control over that, or you may have a lot; either way, it's worth thinking about.

2 Comments

Sometimes,

Form matters

not Content.

Sometimes,

Form matters not.

Content?


First of all, I'm reminded of an Andy Perry story.

Andy was sitting at the SWIL table, when someone (I'm fairly sure it was John Halbert) plopped down across from him, and announced in the enthusiastic tones of the recent convert, "Form IS content!"

Andy replied, "Hmm. Can you put that another way?"

Anyway, great topic, and highly relevant to my team right now, as we're beginning the process of switching our web site to a content management system, with the hope that certain blocks of text can be reused at various points throughout the site, rather than being repeated or having the same material presented in multiple phrasings. Will this lend an inevitable blandness to the language used in those "boilerplate" paragraphs? Probably, I'm afraid, but perhaps avoidable.

One issue, of course, is making sure those blocks of content are easily findable by the people who are likely to need them; hopefully we can have lots of useful tags and descriptions. One can imagine a solution to the online/print manual issue that you describe in which all the content is in a system, with some tagged as print only, some as online only, and most of the key stuff tagged as both. But not easy to make the writing flow reasonably when some of the background material, for example, may or may not appear. And the background material might want to be mixed in amongst the brief to-the-point material, which would make it hard to separate.

Lastly, there's been a perennial question of what exactly makes something a blog entry rather than, say, an essay or a feature article or a humor piece. Perhaps this idea that they have to work when stripped of context is part of what defines a blog?


Post a comment