Tags: language



Defining the damn thang

Chris recently documented the results from his survey which asked:

Is it useful to distinguish between “web apps” and “web sites”?

His conclusion:

There is just nothing but questions, exemptions, and gray area.

This is something I wrote about a while back:

Like obscenity and brunch, web apps can be described but not defined.

The results of Chris’s poll are telling. The majority of people believe there is a difference between sites and apps …but nobody can agree on what it is. The comments make for interesting reading too. The more people chime in an attempt to define exactly what a “web app” is, the more it proves the point that the the term “web app” isn’t a useful word (in the sense that useful words should have an agreed-upon meaning).

Tyler Sticka makes a good point:

By this definition, web apps are just a subset of websites.

I like that. It avoids the false dichotomy that a product is either a site or an app.

But although it seems that the term “web app” can’t be defined, there are a lot of really smart people who still think it has some value.

I think Cennydd is right. I think the differences exist …but I also think we’re looking for those differences at the wrong scale. Rather than describing an entire product as either a website or an web app, I think it makes much more sense to distinguish between patterns.

Let’s take those two modifiers—behavioural and informational. But let’s apply them at the pattern level.

The “get stuff” sites that Jake describes will have a lot of informational patterns: how best to present a flow of text for reading, for example. Typography, contrast, whitespace; all of those attributes are important for an informational pattern.

The “do stuff” sites will probably have a lot of behavioural patterns: entering information or performing an action. Feedback, animation, speed; these are some of the possible attributes of a behavioural pattern.

But just about every product out there on the web contains a combination of both types of pattern. Like I said:

Is Wikipedia a website up until the point that I start editing an article? Are Twitter and Pinterest websites while I’m browsing through them but then flip into being web apps the moment that I post something?

Now you could make an arbitrary decision that any product with more than 50% informational patterns is a website, and any product with more than 50% behavioural patterns is a web app, but I don’t think that’s very useful.

Take a look at Brad’s collection of responsive patterns. Some of them are clearly informational (tables, images, etc.), while some of them are much more behavioural (carousels, notifications, etc.). But Brad doesn’t divide his collection into two, saying “Here are the patterns for websites” and “Here are the patterns for web apps.” That would be a dumb way to divide up his patterns, and I think it’s an equally dumb way to divide up the whole web.

What I’m getting at here is that, rather than trying to answer the question “what is a web app, anyway?”, I think it’s far more important to answer the other question I posed:


Why do you want to make that distinction? What benefit do you gain by arbitrarily dividing the entire web into two classes?

I think by making the distinction at the pattern level, that question starts to become a bit easier to answer. One possible answer is to do with the different skills involved.

For example, I know plenty of designers who are really, really good at informational patterns—they can lay out content in a beautiful, clear way. But they are less skilled when it comes to thinking through all the permutations involved in behavioural patterns—the “arrow of time” that’s part of so much interaction design. And vice-versa: a skilled interaction designer isn’t necessarily the best at old-skill knowledge of type, margins, and hierarchy. But both skillsets will be required on an almost every project on the web.

So I do believe there is value in distinguishing between behaviour and information …but I don’t believe there is value in trying to shoehorn entire products into just one of those categories. Making the distinction at the pattern level, though? That I can get behind.


Incidentally, some of the respondents to Chris’s poll shared my feeling that the term “web app” was often used from a marketing perspective to make something sound more important and superior:

Perhaps it’s simply fashion. Perhaps “website” just sounds old-fashioned, and “web app” lends your product a more up-to-date, zingy feeling on par with the native apps available from the carefully-curated walled gardens of app stores.

Approaching things from the patterns perspective, I wonder if those same feelings of inferiority and superiority are driving the recent crop of behavioural patterns for informational content: parallaxy, snowfally, animation patterns are being applied on top of traditional informational patterns like hierarchy, measure, and art direction. I’m not sure that the juxtaposition is working that well. Taking the single interaction involved in long-form informational patterns (that interaction would be scrolling) and then using it as a trigger for all kinds of behavioural patterns feels …uncanny.

By any other name

I’m not a fan of false dichotomies. Chief among them on the web is the dichotomy between documents and applications, or more broadly, “websites vs. web apps”:

Remember when we were all publishing documents on the web, but then there was that all-changing event and then we all started making web apps instead? No? Me neither. In fact, I have yet to hear a definition of what exactly constitutes a web app.

I’ve heard plenty of descriptions of web apps; there are many, many facets that could be used to describe a web app …but no hard’n’fast definitions.

One pithy observation is that “a website has an RSS feed; a web app has an API.” I like that. It’s cute. But it’s also entirely inaccurate. And it doesn’t actually help nail down what a web app actually is.

Like obscenity and brunch, web apps can be described but not defined.

I think that Jake gets close by describing sites as either “get stuff” (look stuff up) or “do stuff”. But even that distinction isn’t clear. Many sites morph from one into the other. Is Wikipedia a website up until the point that I start editing an article? Are Twitter and Pinterest websites while I’m browsing through them but then flip into being web apps the moment that I post something?

I think there’s a much more fundamental question here than simply “what’s the difference between a website and a web app?” That more fundamental question is…


Why do you want to make that distinction? What benefit do you gain by arbitrarily dividing the entire web into two classes?

I think this same fundamental question applies to the usage of the term “HTML5”. That term almost never means the fifth iteration of HTML. Instead it’s used to describe everything from CSS to WebGL. It fails as a descriptive term for the same reason that “web app” does: it fails to communicate the meaning intended by the person using the term. You might say “HTML5” and mean “requires JavaScript to work”, but I might hear “HTML5” and think you mean “has a short doctype.” I think the technical term for a word like this is “buzzword”: a word that is commonly used but without any shared understanding or agreement.

In the case of “web app”, I’m genuinely curious to find out why so many designers, developers, and product owners are so keen to use the label. Perhaps it’s simply fashion. Perhaps “website” just sounds old-fashioned, and “web app” lends your product a more up-to-date, zingy feeling on par with the native apps available from the carefully-curated walled gardens of app stores.

In his recent talk at Port 80, Jack Franklin points to one of the dangers of the web app/site artificial split:

We’re all building sites that people visit, do something, and leave. Differentiating websites vs. web apps is no good to anyone. A lot of people ignore new JavaScript tools, methods or approaches because those are just for “web apps.”

That’s a good point. A lot of tools, frameworks, and libraries pitch themselves as being intended for web apps even though they might be equally useful for good ol’-fashioned websites.

In my experience, there’s an all-too-common reason why designers, developers, and product owners are eager to self-identify as the builders of web apps. It gives them a “get out of jail free” card. All the best practices that they’d apply to websites get thrown by the wayside. Progressive enhancement? Accessibility? Semantic markup? “Oh, we’d love to that, but this is a web app, you see… that just doesn’t apply to us.”

I’m getting pretty fed up with it. I find myself grinding my teeth when I hear the term “web app” used without qualification.

We need a more inclusive term that covers both sites and apps on the web. I propose we use the word “thang.”

“Check out this web thang I’m working on.”

“Have you seen this great web thang?”

“What’s that?” “It’s a web thang.”

Now all I need is for someone to make a browser plugin (along the lines of the cloud-to-moon and cloud-to-butt plugins) to convert every instance of “website” or “web app” to “web thang.”

Pursuing semantic value

Divya Manian, one of the super-smart web warriors behind HTML5 Boilerplate, has published an article on Smashing Magazine called Our Pointless Pursuit Of Semantic Value.

I’m afraid I have to agree with Patrick’s comment when he says that the abrasive title, the confrontational tone and strawman arguments at the start of the article make it hard to get to the real message.

But if you can get past the blustery tone and get to the kernel of the article, it’s a fairly straightforward message: don’t get too hung up on semantics to the detriment of other important facets of web development. Divya clarifies this in a comment:

Amen, this is the message the article gets to. Not semantics are useless but its not worth worrying over minute detail on.

The specific example of divs and sectioning content is troublesome though. There is a difference between a div and a section or article (or aside or nav). I don’t just mean the semantic difference (a div conveys no meaning about the contained content whereas a section element is specifically for enclosing thematically-related content). There are also practical differences.

A section element will have an effect on the generated outline for a document (a div will not). The new outline algorithm in HTML5 will make life a lot easier for future assistive technology and searchbots (as other people mentioned in the comments) but it already has practical effects today in some browsers in their default styling.

Download the HTML document I’ve thrown up at https://gist.github.com/1360458 and open it in the latest version of Safari, Chrome or Firefox. You’ll notice that the same element (h1) will have different styling depending on whether it is within a div or within a section element (thanks to -moz-any and -webkit-any CSS declarations in the browser’s default stylesheets).

So that’s one illustration of the practical difference between div and section.

Now with that said, I somewhat concur with the conclusion of “when in doubt, just use a div”. I see far too many documents where every div has been swapped out for a section or an article or a nav or an aside. But my reason for coming to that conclusion is the polar opposite of Divya’s reasoning. Whereas Divya is saying there is effectively no difference between using a div and using sectioning content, the opposite is the case: it makes a big difference to the document’s outline. So if you use a section or article or aside or nav without realising the consequences, the results could be much worse than if you had simply used a div.

I also agree that there’s a balance to be struck in the native semantics of HTML. In many ways its power comes from the fact that it is a limited—but universally understood by browsers—set of semantics. If we had an element for every possible type of content, the language would be useless. Personally, I’m not convinced that we need a section element and an article element: the semantics of those two elements are so close as to be practically identical.

And that’s the reason why right now is exactly the time for web developers to be thinking about semantics. The specification is still being put together and our collective voice matters. If we want to have well-considered semantic elements in the language, we need to take the time to consider the effects of every new element that could potentially be used to structure our content.

So I will continue to stop and think when it comes to choosing elements and class names just as much as I would sweat the details of visual design or the punctation in my copy or the coding style of my JavaScript.

The Language of the Web

The Breaking Development conference is wrapping up here on spacecraft Opryland One. It’s been a wonderful experience. The conference itself was superbly curated—a single track of top-notch speakers in a line-up that switched back and forth between high-level concepts and deep-dives into case studies. I hope that other conferences will take note of those key phrases: “single track”, “curated”, “top-notch speakers” (see also: An Event Apart, dConstruct, Mobilism).

I opened the show with a talk that sounds controversial: There Is No Mobile Web. Actually, it wasn’t as contentious as it sounds (I originally proposed a talk called Fuck The Mobile Web: Fuck It In The Assthen it would’ve been controversial). You can download a PDF of my slides if you want but, as usual, they won’t make much if any sense outside the context of the presentation.

Jeremy Keith @adactio

My talk was concerned with language; political language in particular. When I say “there is no mobile web,” I mean it quite literally: there isn’t a separate world wide web for mobile devices. But by using the phrase “mobile web” we may be unintentionally framing the discussion in terms of separate silos for different kinds of devices (desktop and mobile) in a similar way that a term like, say, “tax relief” automatically frames the discussion of taxation as something negative. By subtly changing the framing from “the mobile web” to a more accurate phrase such as “the web on mobile” we could potentially open new avenues of thinking.

By the same token the phrase “one web”—which is the drum that I bang—is really a tautology. Of course there’s only one web! But the phrase has political and philosophical overtones.

So I asked the assembled audience if we could come to an agreement: I’ll stop saying “one web” if you stop staying “mobile web.” How about …”the web”?

I also talked about the power of naming things, invoking the foreword I wrote for Ethan’s book:

When Ethan Marcotte coined the term “responsive web design” he conjured up something special. The technologies existed already: fluid grids, flexible images, and media queries. But Ethan united these techniques under a single banner, and in so doing changed the way we think about web design.

I’m not invoking here, I just wanted to point out how our language can—intentionally or unintentionally—have an effect on our thinking.

One of the other phrases I discussed was “web app.” The timing couldn’t have been better. Fellow Breaking Development speaker James Pearce has just written a blog post all about defining what makes something a web app. It’s very detailed and well thought-out but I’m afraid at the end of it, we’re still no closer to having a shared agreed-upon definition. It’s like the infamous Supreme Court definition of obscenity: “.”

My concern is that the phrase “web app” is wielded as a talisman to avoid best practices. “Oh, I totally agree that we should care about accessibility …but this isn’t a web site, it’s a web app.” “I think that progressive enhancement is great …for websites; but this is a web app.” The term is used as a get-out-of-jail free card and yet we can’t even agree what it means. I call shenanigans. I don’t think it is useful or productive to create an artificial boundary between documents and applications when the truth is that almost everything on the web exists on a continuum between the two poles.

Luke has published his excellent notes from my talk. You should read ‘em. While you’re at it, you should read all of the notes that he took at the conference.

Make sure you check out the notes from Stephanie’s mind-blowing case study of browser.nokia.com. The slides are on Slideshare too.

As I said, the Breaking Development conference did an excellent job of balancing the practical with the inspirational. Stephanie’s intensely useful case study was perfectly balanced by an absolutely incredible call to arms from Scott Jenson called Why Mobile Apps Must Die (and you thought my talk title was contentious), in which he expanded on his brilliant writings over on the Beyond Mobile blog.

The next Breaking Development event will be next April in Orlando. Single track. Curated. Top-notch speakers.

Badge of shame

The W3C have unveiled a logo for HTML5. I’m not sure the world needs such a logo, but I think it looks pretty good. It reminds me of some of the promotional materials used by the Web Standards Project back in the day—simple bold lines that work well at small sizes, with a whiff of Russian constructivism.

But I take issue with the scope of what this logo is supposed to represent. From the Frequently Asked Questions:

The logo is a general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.

What. A. Crock.

What we have here is a deliberate attempt to further blur the lines between separate technologies that have already become intertwingled in media reports.

Don’t get me wrong; I don’t mind if marketers and journalists use HTML5 to mean everything under the sun, but I expect working web developers to be able to keep specs separate in their mind. If Apple or Google were pushing this kind of fuzziness, I wouldn’t mind …but this is coming straight from the horse’s mouth (or, in this case, straight from the horse’s ass).

“But,” cry the cheerleaders of ambiguity, “we need some kind of term to refer to HTML5 plus CSS3!”

Citation needed.

We never needed a term to refer to “XHTML 1.0 plus CSS2.1” or “HTML4.01 plus JavaScript” or “any combination of front-end technologies.” Why this sudden all-conquering need for a term that covers so many different technologies as to be completely meaningless? As I said before:

Clarifying what is and isn’t in HTML5 isn’t pedantry for pedantry’s sake. It’s about communication and clarity, the cornerstones of language.

But I guess I’ve lost that battle. Now even the W3C are intent on blurring the distinction between different technologies to the extent that using a particular font file format qualifies as HTML5.

So now what do I do when I want to give a description of a workshop, or a talk, or a book that’s actually about HTML5? If I just say “It’s about HTML5,” that will soon be as meaningful as saying “It’s about Web 2.0,” or “It’s about leveraging the synergies of disruptive transmedia paradigms.” The term HTML5 has, with the support of the W3C, been pushed into the linguistic sewer of buzzwordland. Instead, I will try using phrases:

  • “HTML5, no really”,
  • “The parts of HTML5 that are documented in the specification labelled HTML5”,
  • “Actual HTML5”

But I think the term that’s going to be most accurate is:

  • “HTML”

Update: The W3C have changed their mind. Yay!



You keep using that word.

In a comment on one of Jeffrey’s blog posts, Tantek wrote:

We as a community that is learning/relearning/teaching all this stuff need to vigilantly clarify what’s what rather than calling things “HTML5″ that are not actually HTML5 (e.g. CSS3, Geolocation, etc. etc.), and correct the marketing messages being shouted from various rooftops so we can better understand and reliably build HTML5 websites and web applications that use HTML5.

Jeff Croft argues just the opposite:

Sometimes we just need a word to rally behind. And put in job descriptions. And claim we “support” (another word that is mostly meaningless). It’s a language thing and a human psychology thing.

For the most part, I think what Jeff is saying is fine …assuming we’re talking about managers, marketers, and other people who aren’t making websites for a living. For the rest of us down in the trenches, I think it is important to understand what is in which spec. As Jeff later clarifies:

That “HTML5” means something different to marketers than it does to web developer is an annoyance, no doubt — but I don’t think it hinders us any real way, and I don’t know that we need to, as Tantek suggests, “vigilantly clarify” the matter.

Fair enough. If someone in middle management wants to use the term HTML5 where they previously used, say, “Web 2.0”, that’s fine. But here’s the problem…

A couple of weeks ago, I got a got phone call out of the blue from a local web developer. My mobile number is listed right here—anyone is free to call me whenever they want. He had a reasonable enquiry. He wanted to know if he could pop ‘round to the Clearleft office and buy a copy of my new book directly from me rather than ordering it online.

Alas no, I said. That’s my personal stash, not for resale.

But while he had me on the phone, he asked a couple of questions about what’s in the book. I started talking about semantics and forms. He asked Does it cover CSS?

No. Nope. Definitely not. The book is very specifically about HTML5, not CSS3.

And then he said But CSS3 is part of HTML5, isn’t it?

He’s not in management. He’s not in marketing. He builds websites. And the scary thing is, I think he’s probably fairly representative of many working web developers.

Don’t get me wrong: I honestly don’t care that much about whether something like geolocation is technically part of HTML5 or not: that’s a fairly trifling matter. But CSS3? C’mon! In what universe is it in any way acceptable that a web developer wanting to learn about web fonts begins by Googling for HTML5?

Still, it could be worse. At least, to the best of my knowledge, no working web developers are quite as misinformed as the New Media Age journalist who listed some HTML5 Key Facts such as:

  • Supports sophisticated typography…
  • Supports social content and sharing…
  • Key features are part of CSS3…

Clarifying what is and isn’t in HTML5 isn’t pedantry for pedantry’s sake. It’s about communication and clarity, the cornerstones of language.

In Politics and the English Language, George Orwell wrote:

A bad usage can spread by tradition and imitation even among people who should and do know better.


So Anand Giridharadas has written a piece about the word so, tracing its ascendency as a sentence-opener to Silicon Valley:

And “so” suggested a kind of thinking that appealed to problem-solving types: conversation as a logical, unidirectional process, proceeding much in the way of software code — if this, then that.

This logical tinge to “so” has followed it out of software. Starting a sentence with “so” uses the whiff of logic to relay authority. Where “well” vacillates, “so” declaims.

It declaims. That’s the reason Seamus Heaney chose it as the translation for the opening word of Beowulf:

Conventional renderings of hwæt, the first word of the poem, tend towards the archaic literary, with ‘lo’, ‘hark’, ‘behold’, ‘attend’ and — more colloquially — ‘listen’ being some of the solutions offered previously. But in Hiberno-English Scullion-speak, the particle ‘so’ came naturally to the rescue, because in that idiom ‘so’ operates as an expression that obliterates all previous discourse and narrative, and at the same time functions as an exclamation calling for immediate attention.

Listen for yourself:

Beowulf on Huffduffer

Beautiful truth

I’ve tried to articulate my feelings about data preservation, digital decay and the loss of our collective culture down the memory hole. I’ve written about Tears in the Rain, Magnoliloss and Linkrot. I’ve spoken about Open Data, The Long Web and All Our Yesterdays.

But all of my words are naught compared to a single piece of writing by Joel Johnson on Gizmodo. It’s called Raiding Eternity. From the memories stored on Flickr, past the seed bank of Svalbard, out to the Voyager golden record, it sweeps and soars in scope …but always with a single moment at its center, a single life, a single death.

Please read it. It is beautiful and it is truthful.

When old age shall this generation waste,
Thou shalt remain, in midst of other woe
Than ours, a friend to man, to whom thou say’st,
Beauty is truth, truth beauty,—that is all
Ye know on earth, and all ye need to know.

John Keats

Dyson ball

When I was in Japan last year, I noticed that most advertisements don’t mention URLs. Instead, they simply show what to search for. The practice seems to be gaining ground over here too. Advertising for the government’s Act on CO2 campaign didn’t include a URL—just an entreaty to search for the phrase.

The current television advertising for the latest Dyson vacuum cleaner finishes with the message to search for “dyson ball.” Sure enough, the number one search result goes straight to the Dyson website …for now. That might change if Google were to implement any kind of smart synonym swapping. There would be quite a difference in scale if the word “ball” were interchangeable with the word “.”


The current issue of A List Apart is the proud bearer of a superb article by Ethan called Fluid Grids. If the title isn’t enough of a hint, it’s all about grids …wot are fluid.

It’s an excellent tutorial. I’ve made no secret of my love for a good liquid layout and Ethan’s article is a great resource for anyone brave enough to take up the challenge.

Another excellent resource comes to us courtesy of Zoe Mickley Gillenwater. She’s written a book called Flexible Web Designs. Buy it now. You won’t regret it. I thought I knew my stuff when it came to wrangling CSS but this book had techniques that were new to me.

Both Zoe’s book and Ethan’s article are commendable for showing how to do something without wasting much time talking about why. Frankly, there’s been enough debate on issues like this. We don’t need more debate, we need more tutorials. This is something I struggle with myself. I’ve spent far too much time talking up the benefits of web standards, microformats, unobtrusive JavaScript, accessibility and, yes, liquid layouts. I think I’m done with that. If I haven’t convinced someone at this stage, I’m not sure I can muster the enthusiasm to pimp any more kool-aid.

But I do have one last little piece of propaganda I’d like to promulgate…

In any discussion of liquid layouts—for or against—it’s common for the subject of the “horizontal scrollbar” to come up. The term is an oxymoron. If text is moving vertically—movie credits, for example—then it is scrolling. If text is moving horizontally (as seen on CNN, BBC, and every other news channel), it is crawling. Therefore, the term “scrollbar” can only correctly be applied to an interface element that allows content to be moved vertically. The correct term for a UI element that allows the user to move content horizontally is a crawlbar.

Say it with me: crawlbar. Sounds a bit more negative, doesn’t it? A negative-sounding term seems fitting for a very negative user experience.

If you like this bit of political language, start using the word “crawlbar” in your meetings and documentation. You might get some strange looks to start with, but if enough of us do it, we can perform a little piece of linguistic corrective surgery.

Feedback loopy

24 Ways is back again this year. Today’s article is a little something I penned called The IE6 Equation. Share and enjoy!

The design of 24 Ways has been refreshed for this festive season and it has prompted quite a varied reaction. That’s always a good sign. You might love it or you might hate it but you’re probably not ambivalent about it. Veerle has written more on this subject, provocatively asking Do you innovate or opt for the safe route in web design?

The implementation prompted as much feedback as the design itself. Clearly, 24 Ways is a site with an immovable deadline. It’s an advent calendar so it must go live on December 1st. This year, that meant that some cross-browser issues weren’t sorted out on the first day. A few days after the site launched, everything was hunky-dory but in the interim, there was a clamour of epic fail! from indignant visitors to the site. I’m finding that Andy’s thoughts on this term of derision has become the canonical document to point people to for a healthy dose of perspective.

Merlin Mann’s observation, delivered in fewer than 140 characters, deserves to be framed and mounted next to every input device:

Some days, the web feels like 5 people trying to make something; 5k people turning it into a list; and 500MM people saying, “FAIL.”

If you’ve ever created anything on the web—a story, a picture, a video or an application—then you’ll be familiar with the range of responses that will result. I don’t just mean the laughably mindless babblings of the Diggtards and Reddidiots; I’m referring to that peculiar effect that sitting behind a monitor has on otherwise level-headed well-adjusted people. In the same way that some people undergo a Jekyll and Hyde transformation behind the wheel of a car, computer keyboards have a tendency to bring out the fuckwad in many of us—I include myself amongst that group.

The upshot of this effect is that criticism tends to be harsher online than if it were delivered in real life, which might just be due to the lack of . Should you find yourself on the receiving end of some criticism, having built a labour of love, I’ve put together a hierarchy of verb tenses by which you can weigh the feedback you’re receiving:

  1. Past. Advice from someone who has also built something is valuable. Their opinion is informed by experimental data.
  2. Present. If someone else is also building something, it’s worth paying attention to what they have to say.
  3. Conditional. This is the bottom of the pile. If someone describes what they “would” have done or what you “should” have done, it isn’t worth wasting your retinas on the photons of that feedback.

Although this hierarchy of verb tenses was prompted by web-native creations, it probably works equally well for film-making, plumbing, literature, dentistry, music, or just about any endeavour of the human spirit.

Reading immaterial

In an interview with Rolling Stone last year, William Gibson said:

One of the things our grandchildren will find quaintest about us is that we distinguish the digital from the real, the virtual from the real.

Bear that dying distinction in mind when I tell you that Joe’s new book is out. It’s called Organizing Our Marvellous Neighbours (geddit?). It’s all about spelling in Canadian English. If you buy it, you’ll get the book in HTML and PDF with very liberal licensing.

You can print it out if you want a physical artefact but it’s made to be read on-screen. If you fancy reading it on an iPhone or iPod Touch, I recommend getting the FileMagnet app which allows you to transfer files—including PDFs—from your computer to your i(Phone|Pod) over WiFi.

In the future, you’ll probably be able to just transfer the files directly to your brain.

The L words

You can lose

  • games,
  • money,
  • keys,
  • the will to live.

You can loose

  • the dogs of war,
  • earthly bonds.

Semantic brevity

When I write here at adactio.com, I often sprinkle in some microformats. As I wrote in Natural Language hCard, I’ve developed a sense of smell for microformats:

Once I started looking for it, I started seeing identity and event information in lots of places… even when it doesn’t explicitly look like cards or calendars.

If I’m linking to somebody using their full formated name, then it’s a no-brainer that I’ll turn that into an hCard:

<span class="vcard">
<a class="fn url" href="http://example.com/">
Joe Bloggs

But what if I don’t want want to use the full name? It would sound somewhat stilted if I wrote:

I was chatting with Richard Rutter the other day…

When you work alongside someone every day, it sounds downright weird to always refer to them by their full name. It’s much more natural for me to write:

I was chatting with Richard the other day…

I would still make his name a hyperlink but what can I do about making this text into an hCard? Should I change my writing style and refer to everyone by their full formated name even if the context and writing style would favour just using their first name?

Enter the abbr element:

ABBR: Indicates an abbreviated form

I can write “Richard” in my body text and use the semantics of (X)HTML to indicate that this is the abbreviated form of “Richard Rutter”:

<abbr title="Richard Rutter">

From there, it’s a simple step to providing an hCard containing the formated name without compromising the flow of my text:

<span class="vcard">
<a class="url" href="http://clagnut.com/">
<abbr class="fn" title="Richard Rutter">

Now a parser will have to do some extra legwork to find the formated name within the title attribute of the abbr element rather than in the text between the opening and closing tags of whatever element has a class of “fn”. But that’s okay. That’s all part of the microformats philosophy:

Designed for humans first and machines second

Specifically, humans who publish first, machines that parse second.

If I were to link off to Richard’s site from here, I’d also combine my microformats: hCard + XFN:

<span class="vcard">
<a class="url" rel="friend met co-worker" href="http://clagnut.com/">
<abbr class="fn" title="Richard Rutter">

Now I’ve got a bounty of semantic richness:

All of that in one word of one clause of one sentence:

I was chatting with Richard the other day…


Dear Auntie Beeb,

Like countless pedants before me, I am sad enough to take some time out of my day to point out a minor error in the article On the road with wi-fi and video:

Nokia’s gadget suffers the sins of many of its mobile phones — confusing menus and a sluggish response make it irritable to use.

While I have no doubt that having a journalist constantly pressing its buttons would make any device irritable, I suspect that the intended meaning is that the device is irritating to use.

Insert standard closing remark about license fees and education standards including the words “in this day and age” somewhere.


Irritated in Brighton.

P.S. Are you reading Grammarblog? Then your life is not yet complete. Go, read and nod your head vigorously in agreement on issues such as “loose” vs. “lose” and “I could care less”.


Stop what you’re doing and watch this utterly charming and beguiling video entitled Wordmaking: What it take to succeed in hacking English and invent a new word. It’s a presentation by as part of the TechTalks series at Google.

How is it that I had never come across the term before?* I asked Jessica this rhetorical question and the next thing you know, I’m learning all about . Clearly I need to improve my linguistic knowledge.

On a tangentially related note, I’ve discovered kindred spirits out there in blogland, to whit:

Ever notice hand-written signs with letters in all-caps, except for the letter L? It looks like an uppercase i … WHY DO PEOPlE WRITE lIKE THIS?

*Update: Edward O’Connor points me to his wife’s blog, The Snowclone Database.

A brief word

As if further proof were needed that Hollywood is, in fact, not run by Jews, Mel Gibson has a new film out called Apocalypto.

For the past week, television ads have been running in continuous rotation. The plot of the movie is teasingly summarised and the most exciting segments are shown to titillate the senses. These advertisements finish with an announcement that the film can be seen in cinemas from “jan five”.

That’s exactly what’s said: jan five. Not “January fifth”, or “the fifth of January”, or even “January five”. Nope: jan five.

I guess it’s fortune that Mel’s movie is being released in such an easy-to-pronounce month. I’d hate to hear the announcer have to wrap his mouth ‘round dates like “sep one” or “apr three”.

What is the point of this? Is any time really being saved by pronouncing abbreviations as if they were complete words?

Of course, this is nothing new to sports fan. Not a week goes by without an advertisement for a match like “Arsenal vee Chelsea.” At first I wondered what the hell “vee” meant. Then I realised that it was supposed to be shorthand for “versus”.

Considering that this is the country where English was invented, they do a remarkable job of butchering the language sometimes.

The language of accessibility

While I was in Berlin for the BIENE awards, I found myself thinking a lot about language and meaning… as one does when one is in a foreign country.

First of all, I think I may have inadvertently insulted my fellow jury members, and just about everyone else I came into contact with, by continuously using the familiar, rather than the polite form. I never could figure out when to use “du” and when to use “sie”, so I’ve always just stuck with “du.”

Secondly, I was thinking about the German word being used to describe accessibility: “Barrierefreiheit”, literally “free from obstacles.” It’s a good word, but because it’s describes websites by what they don’t contain (obstacles), it leads to a different way of thinking about the topic.

In English, it’s relatively easy to qualify the word “accessible.” We can talk about sites being “quite accessible”, “fairly accessible”, or “very accessible”. But if you define accessibility as a lack of obstacles, then as long as a single obstacle remains in place it’s hard to use the word “barrierefrei” as an adjective. The term is too binary; black or white; yes or no.

Thinking further along these lines, I realised that English is not without its problems in this regard. Consider for a minute the term “making a website accessible.” There’s an implication there that accessibility is something that needs to be actively added, something that requires an expenditure of energy and therefore money.

The BIENE awards ceremony began with some words of wisdom from Johnny Haeusler, the German of equivalent of Jason Kottke and Tom Coates rolled into one:

In der realen Welt steht fast immer die Frage im Mittelpunkt, was wir tun müssen, um Menschen mit Behinderung zu integrieren. Im Internet müssen wir umdenken und fragen, was wir tun müssen, um niemanden auszuschließen – und dabei spielt die Barrierefreiheit eine zentrale Rolle.

In the real world, we’re almost always asking what we can do to include handicapped people. On the Internet, we need to rethink this question and ask what we can do so that we don’t shut anybody out—and accessibility plays a central role in that.

This highlights a really important point: good markup is accessible by default. As long as you’re using HTML elements in a semantically meaningful way—which you should be doing anyway, without even thinking about accessibility—then your documents will be accessible to begin with. It’s only through other additions—visual presentation, behaviour, etc.—that accessibility is removed.

Far from being something that is added to a site, accessibility is something we need to ensure isn’t removed. From that perspective, the phrase “making a site accessible” isn’t accurate.

Just as “progressive enhancement” sounds better than “graceful degradation”, talking about accessibility as something that needs to be added onto a website isn’t doing us any favours. Accessibility is not a plug-in. It’s not something that can be bolted onto a site after the fact. So here’s what I’m proposing:

From now on, instead of talking about making a site accessible, I’m going to talk about keeping a site accessible.

Join me.

The ugly American

I’m sitting in a big room at XTech 2006 listening to Paul Graham talk about why there aren’t more start-ups in Europe. It’s essentially a Thatcherite screed about why businesses should be able to get away with doing anything they want and treat employees like slaves.

In comparing Europe to the US, Guru Graham points out that the US has a large domestic market. Fair point. The EU — designed to be one big domestic market — suffers, he feels, by the proliferation of languages. However, he also thinks that it won’t be long before Europe is all speaking one language — namely, his. In fact, he said

Even French and German will go the way of Luxembourgish and Irish — spoken only in kitchens and by eccentric nationalists.

What. A. Wanker.

Update: Just to clarify for the Reddit geeks, here’s some context. I’m from Ireland. I speak Irish, albeit not fluently. I’m calling Paul Graham a wanker because I feel personally insulted by his inflammatory comment about speakers of the Irish language. I’m not insulted by his opinions on start-ups or economics or language death — although I may happen to disagree with him. I’m responding as part of the demographic he insulted. If he just said the Irish language will die out, I wouldn’t have got upset. He crossed a line by insulting a group of people — a group that happened to include someone in the audience he was addressing — instead of simply arguing a point or stating an opinion. In short, he crossed the line from simply being opinionated to being a wanker.