So what does Naked Day really accomplish? Alas, not much. As others have remarked, only a relatively small clustering of people “get it” while the rest are left stumped as to why these sites look so ugly. The vast hordes never see these niche sites anyway. This stunt will do little to convert anyone who isn’t already a member of the choir.

But for all its frivolity and me-tooism, Naked Day is still an effective exhibition of semantics in action. But moreover, it really drives home the point that, while content is king, design is still important. Not just decoration and fluffery, but real, honest, true design.

There has been much pontification over what “Design” is and how it’s different from “Art.” For my money, Art is a free, emotional expression of self while Design is an intellectual application of artistic principles under specific constraints. Art can exist for its own sake, Design always has an agenda — to guide and sway the manner in which a person engages with a thing. The best design is subtle and invisible, but its absence is noticed immediately.

A graphical browser’s built-in style sheet is the epitome of undesigned design. It will inject margins to separate blocks of text and can stylistically differentiate headings from paragraphs from links. But that’s about all it does. These legacy styles — holdovers from days when the web was the exclusive domain of programmers and computer scientists, before graphic designers got their grubby, ink-stained fingers on the medium — are just not very well designed.

A few minutes’ surfing a few naked sites quickly shows that they all look very much alike. You’re forced to actually read to know where you are, without the benefit of a recognizable visual identity. And I’m a huge fan of liquid layouts, but a line of text quickly becomes unreadable without something constraining its maximum length. The wider a line of text stretches without some proportional adjustment of white space, the more cramped and unscannable it becomes. The content may be readable in its default presentation, but it takes considerable effort to read it.

A little more attention paid to typography and spatial arrangement makes a site better, and not just better-looking. A well-designed site can draw the eye to the most important content, direct the reader’s attention to the fundamental message. An unstyled site fails to do that. Everything runs together and looks alike. I don’t know where to look or what to remember or how to find what I’m after. Skillful design, applied unobtrusively through clean application of CSS, makes a site smoother, more usable, more memorable and more pleasant to be around.

Naked websites are ugly, but they work. That’s the real point we’re making. And we can breathe a sigh of relief when it’s all over and we toggle our CSS back into effect. Web design is dead, long live web design.

I discovered ALA around 2003 while reading Jeffrey Zeldman’s seminal masterpiece “Designing With Web Standards.” As has happened to so many others, it was DWWS that finally made me sit up and pay attention to web standards. Prior to that I was using tables to lay out my pages and CSS was only good for removing underlines from links. But Zeldman’s book is a wakeup call for presentational designers. It’s as much about the “why” as it is about the “how.” I took it upon myself to learn more about the mysteries of CSS, and it was zeldman.com and ALA that were my gateway.

I followed links and discovered Mezzoblue, Simplebits and StopDesign (I had seen and enjoyed the CSS Zen Garden, yet oddly had never visited Dave’s home site, Mezzoblue, until following a link from Zeldman). From there the linktrail led me through the broad network of standards-oriented blogs: Andy Budd, Shaun Inman, Jeremy Keith, Jeffrey Veen, Molly Holzschlag, Ethan Marcotte, Richard Rutter, Joe Clark, Dunstan Orchard, Andy Clarke, Eric Meyer, and many many more names that deserve dropping. Every new site I discovered brought new links of its own to expand the network of know-how, and it was through reading the writings of these people, these bright luminaries of semantics and style, that I found a new passion.

It began with technique. Faux columns, elastic layouts and horizontal navigation lists with sliding doors were handy reusable design patterns, tricks to employ to make my pages look good. But gradually came the realization that this whole “separation of content from presentation” hullabaloo was more important than mere technique; it’s the very cornerstone of the web medium.

I realized that the web isn’t really visual by nature, it’s merely a visual representation of the underlying ideas. The web is a conduit for the transmission of thoughts. Thoughts articulated in words, made portable by markup and given presence through style. If any one of those aspects of the medium takes precedence over the other two, it’s the thought behind it that suffers the damage. I developed a new appreciation of HTML as nothing more than markers to denote the meaning of text. It’s the text that really matters and the ideas behind it, the message driving your content, that thing that something about something is about. Presentational markup hurts content, and design that harms content is bad design.

Until a few years ago, browsers’ support of CSS wasn’t strong enough to make CSS design practical. We resorted to table hacks because there were no other options. But today’s generation of browsers, bugs aside, support CSS well enough that we needn’t keep designing pages the way we did in the olden days. We must unlearn what we have learned, readjust our attitudes and start doing it right. When I see the work of a designer who still uses tables and font tags, it just broadcasts loud and clear that they haven’t updated their skillset in half a decade. There is simply no acceptable excuse for designing web pages today the same way we did in 1999.

So why are there so many practicing designers — those who would call web design their profession — who still haven’t jumped ship? For some it’s just a symptom of ignorance, a lack of exposure to the books and blogs that have been preaching web standards methodologies. Those people need to be welcomed with open arms, offered understanding and guidance on their new journey. But others willfully resist, dismiss CSS as “too hard” and all this web standards mumbo jumbo as hype. They’re comfy with the sloppy, inaccessible presentational pasta that has cluttered the web for far too long. After all, it seems to get the job done. Everything looks just as it should, right?

I couldn’t comprehend that mindset, how anyone could learn about web standards and still reject them by choice. I finally figured out what the problem is; their brains just don’t work right.

A strictly visual thinker is not concerned with semantics and accessibility. They’ll treat a web page as a picture of a web page, and commit whatever HTML sins are required to bend pixels to their will. They don’t appreciate the significance of markup as a support system for content, don’t understand that every presentational tag and attribute is an obstacle hindering the movement of information. They’re thinking like an artist, obsessed with the experience while neglecting the message and the mechanics. Understanding web standards — not just how they work but what they mean — takes more than memorizing techniques for presentation. A web page serves a purpose above and beyond surface aesthetics.

Nearly two years ago I started drafting a post on this topic, exploring the mentality of standards-aware design and the thought process that goes into it. It’s difficult to articulate without a lot of hand-waving and abstraction, so the post lamented in draft stasis, occasionally being dusted off and reworked before going back into the locker unfinished. When Krista Stevens contacted me about writing something for ALA (on a reference from Aaron), I decided it was high time I brought that post out of storage and gave it to the world. I hope someone out there can glean some nuggets of truth and inspiration from How to Grok Web Standards and will use that to further the advancement of the web as a whole. I’m honored to contribute to a publication that has contributed so much to me.

Semantics Semantics – A Plain English Guide to Web Standards Jargon

Every specialized field evolves its own internal language of jargon, slang, insider references and buzzwords. We’ll cut through the technobabble and define the terminology of modern web development in plain English, and in so doing, reach a better understanding of the concepts behind the vocabulary.

There was a 75-word limit for the description at submission time, so if that isn’t quite enough to get your juices flowing, allow me to elaborate.

Whenever I attempt to learn some new and different technical thing, the first hurdle I struggle with is learning the new vocabulary. New acronyms and abbreviations, strange new words I’ve never heard and familiar words that have very different meanings (“Getting a good bead” means something entirely different to a sniper than it does to a welder). Familiarizing oneself with jargon is one of the main obstacles in any learning curve.

A few years ago I decided I wanted to learn Perl, so I borrowed my friend’s copy of O’Reilly’s llama book, “Learning Perl.” It seemed like a good place to start. That particular book assumed some prior knowledge of programming (I had none) and right off the bat referred to a mysterious and arcane rite called “looping through an array.” I knew what each of those words meant, just not in that order. I was completely lost, and immediately abandoned my Perl studies. Not only did I lose interest in Perl, but was so stung by that first experience of frustrated confusion that to this day I have a strong aversion to dealing with Perl.

Many web designers have a similar experience on their first dive into standards and CSS. Advanced books, articles and tutorials must assume prior knowledge to avoid rehashing the basics and so tend to use language that confounds the beginner (“We can use image-replaced sliding doors for our tabs without sacrificing semantics…” Huh?). At the same time, there are relatively few introductory resources that define these terms, and those tend to be too elementary for someone with a little experience under their belt already (“I know what a ‘tag’ is, but what’s the difference between a ‘tag’ and an ‘element’?”)

Unfamiliar jargon can make the learning curve seem too steep, and hence make standards-based design with CSS seem “too hard.” Some will struggle on through confusion and adversity, while others give up and resume the tag soup they’re comfortable with. Worst of all are those few who decide that CSS is a bunch of complicated hooey that doesn’t really work. If John Dvorak knew what the word “cascade” means, maybe he wouldn’t have made such a fool of himself.

Simplifying the language will simplify the concepts. Understanding the jargon helps you understand what it refers to. When a community of designers and developers can agree on what these words mean, we can better talk to each other. And best of all, comprehending the subject in plain language will help you talk about it to your bosses and clients when the need arises.

The presentation at SXSWi will be aimed at beginners and intermediates, but will hopefully appeal to experts as well. My intent is to reexamine some of the core concepts of web standards by boiling down the linguistic ambiguities that crop up when we discuss them.

So please mosey on over to the Panel Picker, find mine listed under “CSS / standards”, and give me a vote to stroke my fragile ego.

See ya’ll in Austin.

Update: On December 18 I finally received word that my panel didn’t make the final cut. I shall not be presenting at Suckswuh. I take this news with a mixture of disappointment and relief. Even so, feel free to ask me about web standards jargon in the hallways, but you won’t get to see any pretty slides.

I knew I would be presenting to co-workers and collegues, skilled and experienced web developers, though mostly of the back-end sort, so I decided not to delve too deeply into design matters. I chose to focus on the guiding principles of standards-based development, with special emphasis on writing valid, semantic, accessible markup. For the CSS section, I stuck to basic technical aspects of what Cascading Style Sheets are and how they work. The ultimate goal of this exercise was for each coder to leave the room with a better understanding of how the web works, and some tangible guidelines they could immediately apply to their work.

Organizing thoughts

So with my goals and approach decided, next came the intimidating task of choosing which points to make and in what order. Obviously, one must begin at the beginning. My introductory segment would explain what web standards are, what they mean to us as web users, and what we stand to gain as web devlopers: faster downloads, improved accessibility, easier maintenance, better search indexing, etc. It’s the same case that has been made a thousand times, but there’s always someone who hasn’t heard it before.

I began with an outline, adding new bullets for each point I wanted to make, then reshuffling those bullets so one point logically led to the next. A second level was added to list points-within-points. If a point demanded more than three or four sub-points, then the point was probably big enough to break into more than one chunk. If I found myself wandering down a tangent that strayed too far from the top-level point, the entire branch was severed. For example, that whole discussion of the visible electromagnetic spectrum when demonstrating shorthand hexadecimal color codes. Fascinating but way off-topic, so it had to go.

Even after some drastic clearcutting, there was just way too much to cover in the original three-hour slot (and three hours is pushing the limits of the average attention span, not to mention the average bladder). So the presentation was split into a pair of two-hour sessions, and I still had to omit a lot of valuable information and quickly gloss over some other points. I slashed the discussion of CSS hacks, rather than spend 20 minutes covering something I would end up recommending against anyway. The segment on CSS2 and CSS3 selectors was axed because it seemed too advanced for this go-around, we’ll stick to CSS1 for now. And I had a good 6 minutes on the <q> element that concluded with the phrase “but we almost never use it” so I decided it wasn’t worth mentioning.

The end result of my outlining process was a lengthy bulleted list. Gods no, not a bulleted list in a slide presentation, anything but that.

Sliding

With outline in hand I was ready to start crafting slides. The few speech and debate classes I took taught me that you should know your material, not read it. Slides should serve as illustration, support, example, and backdrop. I want my audience to listen to me, not read what’s behind me. Out of 150 total slides, I’m ashamed to admit there are two occurrances of bulleted lists, but they were included strictly in the name of brevity.

As I sought to illustrate my key points in slide form, I began thinking through just what it was I intended to say, making notes as I went along. It was at this stage that my outline expanded and evolved into something resembling a screenplay, each beat of dialog interspersed with short descriptions of the on-screen action.

Eventually I found myself writing the entire presentation in full paragraphs of complete sentences. I had intended to avoid this, lest I fall into the trap of reciting instead of talking, but it turned out to be useful. Through the process of writing and editing, I accidentally became pretty well prepared to talk about it.

Delivering

As is typical, I underestimated the workload. Putting together an entertaining and informative presentation is labor-intensive, and I am lazy, so I slacked off until the last minute and wound up pulling an all-nighter to finish the slides for Part 1. About half an hour before the appointed time, I tested the slides on the conference room projector. Too dark. Much too dark. Note to self: test the projector well in advance to allow time for adjustments. My nicely dimmed background images were completely black when thrown against the screen. I scrambled to brighten them in Photoshop and update every slide, one by one, and was still doing this as the group filed into the room. Note to self: learn about master slides in Keynote.

Though I was tired and dehydrated, Part 1 went exceedingly well. Part 2 was delivered two weeks later, but expectations were different and the topic was dryer (more code, less concept) so the reception wasn’t quite as warm. Still, I think I made my point, and my co-workers seemed pleasantly surprised and/or impressed by what I hope was a refreshing alternative to the typical display of small-fonted code samples or, sigh, a PowerPoint bullet parade.

And now I am officially initiated into the world of speaking in public about web standards. I’ve learned by watching some of the best (Veen, Shea, Molly, Malarkey, Keith, et. al.). Granted, this was a small group of a dozen or so, hardly the grandeur of SXSWi or @media, but you gotta start somewhere.

Sharing

So, I’ve put all this effort into formulating an engaging and moderately comprehensive presentation, but only a handfull of people will ever know about it unless I share this with the world. I have a fragile ego to boost and a reputation as a standardista which has barely begun to bud. Gotta get this sucker online, doncha know.

Keynote 3 offers numerous export options, but the real problem remains: slides are mostly useless without the accompanying content. Since the slides are only illustrations and examples — not the content of the presentation — watching a silent slide show just doesn’t get the message across. I didn’t have the forethought to record the sessions for podcasting, which is just as well since I hate the sound of my voice on playback. But I do have copious notes, written in complete sentences no less.

Months later, I’ve at long last polished up my notes and exported my slides (after some modifications). I’m opting for Quicktime interactive movies to preserve the carefully-timed cinematic effects (we’ll see what this does to my bandwidth). I suggest opening two windows and clicking along as you read. Enjoy.

Web Standards – A crash course, Part 1

Introduction to web standards concepts and best practices and an exploration of semantic markup.
Presentation text.
Presentation slides (interactive Quicktime movie, 6.1MB).

Web Standards – A crash course, Part 2

A brief review of Part 1 and an introduction to Cascading Style Sheets.
Presentation text.
Presentation slides (interactive Quicktime movie, 6.5MB).