- Your Own Words: Got Style?
- Your Own Words: Coding Your Content: The Web Reader as Browser, Part 1
- Your Own Words: Coding Your Content: The Web Reader as Browser, Part 2
- Your Own Words: Content Planning: Two Simple Document Design Strategies that Work
- Your Own Words: Education, Composition, Alteration, Hibernation: How to Improve Your Content before Publication
Ever opened a web page in Notepad? Ever used your web browser’s “view source” feature? I certainly hope so. But if you haven’t, give it a try sometime.
Code is extraordinary in its blandness.
Find even the slickest web page and have a look at the code. Those cascading slide-out menus are simply long lists of instructions. That subtle balance between background and font color? Just an appropriately-placed hexadecimal here and there.
And that striking graphic that makes your pulse pound? It’s not even really there on the page. But a string of code pointing to that graphic is there.
It’s true. A naked web page is not a pretty thing (to most people anyway), but rather a mess of brackets and tags and pointers and referentials. What’s more, web pages don’t even do anything but sit on a server and wait for that special someone to come along and view them in a whole new way. And that Prince Charming is otherwise known as a web browser.
See, the intelligence is not in the code itself but within the browser. Browsers have the ability to literally render beauty from that mess of code, and have the whole thing make sense. With that code—plus whatever style sheets, scripts, graphics, and other needed files that reside on the server—a browser creates the web experience for its user.
Put another way, a web browser re-translates a programmer’s creativity from the lifeless code in which it was packaged and shipped.
Intelligent Browsers, Intelligent Readers
Thus ends the technical portion of this column. Maybe.
But what if language worked the same way? I’d argue that in a lot of ways it does. I’d go so far as to say that in the relationship between any piece of writing and its reader, it’s the reader doing the real creating. The words just sit there and take it.
But just like a good programmer controls the web user’s experience, so too can a good writer control the reader. It’s all in the code.
In Part 1 of this article, I’d like to throw some examples at you to prove the point and prepare you for Part 2, in which I’ll give you some specific advice for translating your message into this code called language in such a way as to assure that your reader renders it accurately.
We use punctuation every day to tag our writing; and like HTML tags, punctuation does nothing until an intelligent reader comes along to reproduce the effects we placed there when writing. Many marks of punctuation even have an HTML equivalent. They give readers the same instruction that their counterparts give web browsers. Here are a few examples:
‘The Period’ and ‘<./HTML>’
Obviously, you would use the Period (.) to mark the end of a sentence just as you would use to mark the end of an HTML page. Reader and browser both know to treat what comes before these tags as a cohesive whole.
‘The Colon’ and ‘<.OL>, <.UL>, <.DL>’
While the colon (:) has several functions, quite often it’s used to precede lists. The following tags instruct the web browser to treat a string of text in the same way: <.OL>, <.UL>, and <.DL>.
‘The Dash’ and ‘<.IMG>’
The dash (—) is great for inserting examples or illustrations—like web producers would use <.IMG>—into your sentences.
‘Parentheses’ and ‘<.!–comment –>’
We use Parentheses to insert useful information (a dash means something entirely different) while preserving sentence flow. In the same way, <.!–comment –> hides text from your browser’s window while still making it available.
‘Ellipsis and ‘<.HREF>’
Ellipsis (…) mark omissions in a piece of writing and let you know that more information is available on a particular topic. Perhaps the most powerful tag of them all, <.HREF> allows web producers to make more information available to visitors instantly. Just click…
The examples above were provided to acquaint you with a fresh topic (an approach to language) by comparing it to one you already know a little about (programming for the world wide web).
In the world of writing instruction, this is referred to as the ‘Given-New Contract.’ Start with the given and introduce the new.
You know, way back when I was learning HTML, I can recall comparing individual tags (the new) with what I already knew about language (the given). Thanks to you, the Absolute Webmaster reader-browsers, I get to stand the Given-New Contract on its head.
Next month I’ll make a few more comparisons between the language of the web (your specialty) and the language of the web visitor (my specialty). I’ll use these comparisons to give you hands-on advice for making your readers render beauty from all that blandness.
This article is a re-post of a column I wrote for the Netmaking newsletter in 2004. While the technology and uses of the web have changed significantly since then, much in the way of content development—the actual processes by which writers create for the web—has not. This column is being re-posted here for archival purposes, and in the hopes that it may be of some use to fellow writers out there. My Norwegian friends at Netmaking [English] are still going strong and doing great work with the eZ publish platform. I encourage you to check them out.