Round 2 of the 2007 SXSW Interactive Panel Proposal Picker has just gone live and I’ve got one proposal in the bunch.
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.
Dumbing everything down may seem appealing to the beginners, but it’s appalling to the experts. Imagine if every time a doctor talked to another doctor, they had to say “that little pink thingy that hangs in the back of your throat” instead of the proper medical term. And yes, to be an expert in the arena, we expect doctors to go through years of training to bridge their knowledge to the body of work that has come before them.
I’m here because you mentioned “Learning Perl” (which I wrote). Specifically, you understood that the book was targeted at programmers, not non-programmers. I can assure you that the intended audience knew what an array is, and a loop, and that’s why there’s no “bridging” of those words into language that you understood. I didn’t (and perhaps couldn’t anymore) write an explanation of “what is an array, and how do I use it?”, because there’s a large enough audience of existing programmers to make the book worthwhile even without adding the fifty extra pages it would have taken to teach the material to non-programmers, such as you, apparently.
There ARE books on Perl for the non-programmer. I just didn’t write one of them. Don’t try to get the industry to stop using jargon though: the jargon terms have a precise meaning for those who need to communicate without including all the explanation and context each time. That’s a valid use for jargon. It’s not just to be different or exclusive: it’s about being precise and optimal.
Defining jargon for the benefit of beginners and non-experts isn’t dumbing down the subject, it’s smartening up the audience.
Jargon is good. It’s how experts communicate with each other. It is, however, an obstacle to the non-expert wishing to become an expert. It’s why doctors go through years of pre-med before entering medical school. At some point early in their education, someone had to define for them what a uvula is, so they can then use the term correctly.
I have no wish to abolish jargon. I quite like it, in fact. I’m not going to stop using the words “tag” and “element” simply because some people don’t know the difference between them. They’re the right words to use.
One must define terms before using them. If you’re quite certain your audience is already up to speed on the terminology, you can skip the definitions. “Advanced books, articles and tutorials must assume prior knowledge to avoid rehashing the basics.” That’s why those resources are advanced, and hence not for beginners. But where does the beginner turn for guidance? Who will explain what all this is about? My session is aimed at those people.
Randal, my anecdote about “Learning Perl” was my own failing. Your book was too advanced for me, and that’s fine because I was not your intended audience. I have since learned what looping through an array is because I found other resources that were more my speed. So now, should I ever wish to return to learning Perl, I’d probably return to “Learning Perl.”