Carl Spitzweg’s The Poor Poet (1839)

Writing copy for online consumption still seems to be something of a black art. Most web professionals know what works, but figuring out how to achieve it is quite a different matter.

This article brings together a few of the themes that I encounter in my activities around the relationship between information design and editorial policy.

The shock of the new

Often I encounter writers and editors more used to ‘traditional’ communications, raised on a diet of press releases, white papers and speeches. Some may even express impatience with the business of writing online copy: normally this is just a mask for unfamiliarity.

Indeed it’s probably understandable that those who work with such copy will tend to focus almost exclusively on the message rather than the medium, particularly if their subject is highly specialised. If looks could kill, it’d be best not to mention the word ‘Twitter’.

Successful online delivery requires method, usually arrived at through trial and error and a healthy dose of self-restraint. Specifics are beyond the scope of this article but certain characteristics are essential:

• Brevity
• Structure
• Pattern

Writing styles and content management

Therefore when authoring content for online consumption, there tends not to be much room left over for personal style. Sometimes writers and their expectations need to be managed.

Consider a situation I experienced recently: a changeover of editors on a website consisting of 20,000+ units of content. In newspaper journalism the content model is often so strict that editorial changes are barely noticeable but here in public sector policy and statistics, the effect of the swap was both immediate and profound.

The outgoing editor had a fastidious attention to detail. He was concerned to substantiate all assertions very carefully and maintained a subtractive, minimal approach to copy. His replacement took a freer hand and preferred to discuss matters at length.

Both writers were drafting materials essentially on the same subjects, yet the texture of their respective outputs was markedly different: the former produced shorter items peppered with links and endnotes whilst the latter delivered lengthy paragraphs and fewer headings.

Involvement in the content writing process

When should the information architect take a hand? How involved should she be in the editorial process?

The answers to these questions depend on the environment. Some writers and editors will be interested in hearing about information architecture, others may be rather more buffeted by the tides of strong personality.

What seems clear to me is that some guidance is essential for those less familiar with the online domain, but any imposition of strict editorial rulesets will send out the wrong message and will probably be ignored.

Unclaustrophobic guidelines explained by common sense should be adopted more or less silently (not to say gratefully) by most writers and editors and negate the worst excesses of any prima donna. I outlined the seeds of this approach in an earlier article about testing content for relevance: it should just be a matter of turning principles into friendly advice.

Turning good habits into workflow

Here’s a quick reminder of the information design process at its simplest:

Data --> Information --> Communication --> Knowledge

Acronyms and abbreviations might well be the bane of modern communications. Why? Well, only prior knowledge gives access to the information, which is a subversion of the above.

In a technocratic environment, content writers risk making too many assumptions about the prior knowledge of their readers. In an international environment meanwhile, OTAN, PALO and EASS can all mean the same as NATO.

Online content writers should be encouraged to develop good habits and apply them regularly, then editors will ensure they’re kept up. The proper explanation of acronyms and abbreviations is just one example among many others that collectively form a corpus of editorial best practice and produce highly-skilled online writers.

Conclusion

Information design shouldn’t stop at the launch of a content management project or limit itself to technical development.

There is also an important role to play in the creation of institutional best practice and it’s a role that requires considerable sensitivity and lots of teamwork.

Internally, migrating and modelling content is a major task that depends on collective knowledge and must be completed in a collaborative context. Externally, the needs of the end-user must be properly understood and reflected in the published content.

This is only a problem, so far as I can see, when you’re using backgrounds on the unfloated element(s), because thr background image or colour will overrun your floated element.

Want to try it? The situation is as follows:

1. Float an element containing either an image or text
2. Continue with unfloated elements so that under normal circumstances they wrap around the floated element
3. Give the wrapped text a background property, such as a background colour or image

The code so far:

/* CSS */
.floated {float: right;}
p {background: #fc0;}
...
<!-- HTML -->
<div class="floated"><img src="/images/tmp.jpg" /></div>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit</p>
<p>Class aptent taciti sociosqu ad litora torquent per conubia nostra per inceptos himenaeos</p>

Up to this point everything’s normal:

So far so good. Now add font-style:italic; to the rule for p.

Here’s Firefox, with no surprises:

But here’s Internet Explorer 7:

The only (il)logical answer seems to be the addition of overflow: auto to the rule with the background.

I was clued in by a slightly different issue with the same fix already discovered long ago. Just to remind you once more, this is IE7 only, folks!

Source: Wikimedia Commons

The virtues of @media print have been explained elsewhere, best of all by Eric Meyer in his seminal A List Apart article Going to Print, whose original publish date (May 2002) makes me feel a bit old!

Yet one of the most annoying aspects of developing CSS for print is testing it.

Now I know that testing print CSS doesn’t take a huge slice of our lives, but it annoys the heck out of me. So if you’re a tolerant sort of person who’s happy to rub along with naff workflows, you might find this article and indeed the fact that there’s a whole article on the subject, just a bit finicky.

Thing is, I hate testing print CSS.

Sure, simple markup and layouts only need buffing to a shine to be ready for print, but an increase in complexity or a requirement for absolute fidelity in printed material can lead to ugly scenes round my way.

Print CSS: browser testing !== Print Preview testing

Developers tend temporarily to substitute their screen CSS for their print CSS, run it in the ordinary browser environment, et voilà. Rinse and repeat.

Yet the actual conversion to the printed page can sometimes lead to unexpected results, as can be seen in the image: different browsers, different Print Preview results – even though in the browser there was nothing obviously objectionable.

Print Preview !== a tool for development

Finding fiddly print CSS issues would be a lot easier if testing tweaks was a smoother process. Every change cycle equates to:

1. Refresh the page
2. Invoke Print Preview
3. Review the change
4. Close Print Preview

Testing print CSS as opposed screen CSS appends two additional steps 2 and 4 – invoke Print Preview (Alt + F + V in Windows for both IE and Firefox) and close Print Preview (correspondingly Alt + F4) . Those two simple steps make the business very laborious, even if you can remember those shortcuts.

Slight workflow improvement: an IE-only trick

A dirty little script in IE only takes care of the task of invoking Print Preview, which slightly shortens the workflow. Yes, it’s IE only, but given that it’s usually IE giving me print CSS grief, every little helps:

<script type="text/javascript">
function printpr()
{
var OLECMDID = 7;
var PROMPT = 1;
var WebBrowser = '<OBJECT ID="WebBrowser1" WIDTH=0 HEIGHT=0 CLASSID="CLSID:8856F961-340A-11D0-A96B-00C04FD705A2"></OBJECT>';
document.body.insertAdjacentHTML('beforeEnd', WebBrowser);
WebBrowser1.ExecWB(OLECMDID, PROMPT);
WebBrowser1.outerHTML = "";
}
printpr();
</script>

This script automatically invokes IE’s Print Preview. Dump it just before the </body> and save yourself a shortcut! You could also call printpr() from anywhere else, of course. And here’s the source of the original code snippet, which also shows a few other unrelated options such as Save As.

Why can’t we refresh the Print Preview?

All of which finally begs the question, why can’t we simply refresh the Print Preview with an F5 shortcut, just like we have in the browser itself?

Probably because I’m the only person in the world who gets genuinely annoyed by testing print CSS in Print Preview. More fool me, I guess.

For me, Flash development pretty much dropped off the radar in 2004. Jakob Nielsen famously killed the idea of Flash as the be-all and end-all of websites and suddenly, like the stock market interest in the dotcoms, the buzz had gone.

I wrote about Flash again in 2006 on the occasion of the technology’s tenth birthday, noting at the time that it was thanks to Flash that the online video boom had happened.

Flash design 1.0

Why did everyone stop doing Flash sites?

1. Good design goes to heaven, it is often said, and bad design goes everywhere. Accessibility and usability suffered while the keyframes fizzed by. If you allowed your website to become a puzzle, as Nielsen concluded, users would just go elsewhere.
2. The Internet has always been a fickle sort of business, particularly once the marketers got into it. Flash as a key differentiator eventually and inevitably reached saturation point. There was no longer a wow factor to be had in whizzing keyframes: like the bodykitted Vauxhall Nova, every idiot had one.
3. The future of the Internet was predicated on ‘social’ (and therefore interactive), user-generated content and relationships yet 99.9% of Flash sites were 99.9% read-only.
4. Javascript libraries reignited, then accelerated, the capabilities of the ‘traditional’ XHTML-CSS interface.

A place in the sun

The environment in which Flash finds itself today is rather different. Accessibility, usability and web standards are essential factors. Browsers are generally much improved. Business efficiency and profitability are paramount.

And within that environment Flash still has a place that, when implemented correctly, continues to be unchallenged in terms of relevance and effectiveness. It’s the format of choice for online video and music delivery, it’s still interoperable with excellent XML support and it continues to gain traction in the ever-growing mobile market.

Progressive enhancement and visualisations

Though much maligned as a user experience killer in the bad old days, most developers recognise the benefits of Flash in small doses. Flash was and is incredibly useful for visualisations. The last time I used it heavily, for example, was in the development of a floorplanning tool. I use it more often, however, for graphing numbers and geographical mapping (though GoogleMaps has increasing advantages).

When the metaphor is necessarily visual and the data is dynamic, there isn’t much out there that can match Flash for quick, effective results.

Now with ‘modern’ methods, we can also provide an accessible experience. Any HTML table of data, or an ordered list of countries and their attributes, is a candidate for visualisation and pre-formatted data source. The original data will still be there on the page but a bit of simple DOM work can convert it into something Flash can use.

Faust and the DOM

As with many of these ‘development trends’, we’ve been doing it for years but some smart folks had to put a name to it. In this case, it’s the agency Space150 and they’ve named it after everyone’s favourite devil-dealer Faust.

The idea is to provide content on the page and have Flash use that content via its support for XML. The visualisation is displayed and, typically though not always, the original content is hidden by recourse to Javascript.

So it follows that the content exists without Flash requesting it, which means that it’s accessible and search-engine friendly.

What’s interesting though, is how the developers got around DOM limitations caused by Internet Explorer’s serialisation of HTML rather than XML. Consider the following example:

<ol id="countries">
<li id="cty-1"><a href="#">Algeria</a></li>
<li id="cty-2"><a href="#">Argentina</a></li>
<li id="cty-3"><a href="#">Australia</a></li>
<li id="cty-4"><a href="#">Belarus</a></li>
<li id="cty-5"><a href="#">Brazil</a></li>
<li id="cty-6"><a href="#">Canada</a></li>
<li id="cty-7"><a href="#">Chile</a></li>
</ol>


In Javascript, we ask:

alert(document.getElementById('countries').innerHTML);

or with JQuery if you prefer:

alert($('#countries').html());

Here’s the DOM excerpt from Firefox:

Now note the equivalent excerpt from Internet Explorer:

See how the nodes get capitalised and the @id is stripped of quotes? This isn’t “illegal” behaviour, but it is exceptionally irritating. Passing that IE excerpt as a string to Flash via flashvars is a recipe for trouble.

The developers “sanitise” this DOM output by converting it to XHTML (and therefore well-formed XML) using a (relatively) simple function contained in their innerxhtml.js:

// innerXHTML
// -------------------------------------------------------
// Copyright (c) 2006 space150, LLC and released under the CPL license:
// http://opensource.org/licenses/cpl1.0.php
// -------------------------------------------------------
function innerXHTML(obj, encode) {
   // It is an option to pass innerXHTML() a string indicating an id attribute
   if (typeof obj == "string") {
      obj = document.getElementById(obj)
   }
   var open = '';
   var content = '';
   var close = '';
   var tagname = obj.nodeName.toLowerCase();
   var emptytag = (obj.nodeName.match(/area|base|basefont|br|col|frame|hr|img|input|
      isindex|link|meta|param/i)) ? true : false;

   // Write open tag
   open = '<'+tagname;

   for (var i=0; i<obj.attributes.length; i++) {
      if (obj.attributes[i].specified && obj.attributes[i].value != "null") {
         open += ' '+obj.attributes[i].name.toLowerCase()+'="'
            +obj.attributes[i].value+'"';
      }
   } open += (emptytag) ? ' />' : '>';

   if (!emptytag) {
      // Write tag content
      for (var i=0; i<obj.childNodes.length; i++) {
         var node = obj.childNodes[i];
         if (node.nodeType==3) {
            content += node.data;
         else if (node.nodeType==1) {
            content += innerXHTML(obj.childNodes[i], false);
         else {
            content += " ";
         }
      } // Write closing tag
    close = '</'+tagname+'>';
    }
    // URI encode the content if desired
    return (typeof(encode)=="undefined" || encode==true) ? encodeURIComponent(open+
      content+close) : open+content+close;
}

Et voilà! Beautifully done.

When I’m testing work done with jQuery in Internet Explorer, I’m normally a karmic cow. I wonder if Mr Resig and friends ever thought about their specific contribution to world peace.

Indeed with jQuery, you can almost forget about the bad old days. At least until something comes along like it did this morning, when I hit a situation using .html().

Using .html() to return elements with bound events

If we use jQuery to bind events to an element and then take a look at the DOM, Internet Explorer may well return unexpected results. Here’s the code:

<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript">
//<![CDATA[
$(document).ready(function(){
$('#countries li a').click(function(){alert('clicked!');})
alert($('#countries').html());
});
//]]>
</script>
...
<ol id="countries">
<li id="cty-1"><a href="#">Algeria</a></li>
<li id="cty-2"><a href="#">Argentina</a></li>
<li id="cty-3"><a href="#">Australia</a></li>
<li id="cty-4"><a href="#">Belarus</a></li>
<li id="cty-5"><a href="#">Brazil</a></li>
<li id="cty-6"><a href="#">Canada</a></li>
<li id="cty-7"><a href="#">Chile</a></li>
</ol>


Consider the result from Firefox below. Predictable isn’t it?

Now look at Internet Explorer 7 and notice the junk that’s found its way in there:

Results for IE7 + jQuery 1.4

It’s like Sizzle just ate a bag of shell-on peanuts in your taxicab. The behaviour has been described briefly by Matthew Pennell.

It’s only a problem if for some reason you need clean, well-formed XHTML.

Don’t depend on .html() for well-formed XML snippets

For example if – like me – you were using XHTML from the page as a dataset for use in a dynamic Flash object (via progressive enhancement) then that could be a problem: Flash balks at this stuff in IE.

Moral of the story: check your code

My quick fix was to change the order of business. I simply did my jQuery event binding after the data had been sent. A hard lesson learned, then, in view of the amount of time I spent tearing my hair out, but an important one nonetheless.

It was published only a couple of years ago (a long time in Web world, of course) and it’s interesting to trace the arc of developments since then.

Whilst much of the methodology described in the book is becoming increasingly normal nowadays, I certainly wasn’t aware of the scale of Zeldman’s achievements with regard to ending the so-called Browser Wars with the Web Standards Project until now.

Web standards implementation as a strategy has exploded into the forefront of my job, so it is now important to put together a strong business case in order to get buy-in from developers and management. It is no longer enough, it seems, to encourage topical best practice from colleagues.

For many people I’m dealing with, the understanding of (X)HTML standards seems to be quite practical – “table avoidance” is one of the most visible concerns and, as Zeldman also points out, the problem of automatically generated code from content management applications.

Time will tell how far I can take it, especially for internal systems, but it looks set to be a pretty lonely path for now!