A few months ago, at my workplace, I was asked to give a short talk to the development team on the subject of web standards. It seems three years of my quiet (sometimes not so quiet) evangelism had taken some root and it was decided to be high time the other coders got up to speed on current best practices in HTML and CSS. I jumped at the opportunity, eager to preach uninterrupted to a captive audience.
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).
Hey, awesome going Craig! I love the “jargon alert” bits in your write-up :)