Archive: May, 2009

The newest episode of Radiolab has the highlights from one of their occasional live events. This one revolves around the deliberately contentious premise of television vs. radio.

Seeing as Huffduffer is all about audio rather than video, you can probably guess that I’ve got a soft spot for radio. Not that I have anything against the moving image; it’s just that television, film and video demand more from your senses. Lend me your ears! and your eyes. With your ears and eyes engaged, it’s pretty hard to do much else. So the default position for enjoying television is sitting down.

A purely audio channel demands only aural attention. That means that radio—and be extension, podcasts—can be enjoyed at the same time as other actions; walking around, working out at the gym. Perhaps it’s this symbiotic, rather than parasitic, arrangement that I find engaging.

Neal Stephenson draws a distinction between vegging out and geeking out:

To geek out on something means to immerse yourself in its details to an extent that is distinctly abnormal — and to have a good time doing it. To veg out, by contrast, means to enter a passive state and allow sounds and images to wash over you without troubling yourself too much about what it all means.

He expanded on this distinction in a talk at Gresham College on Science Fiction versus Mundane Culture.

I enjoy vegging out in front of the television. I enjoy geeking out with podcasts.

We have some new location-centric toys to play with. Let the hacking commence.

Flickr has released its shapefiles dataset for free (as in beer, as in it would be nice if you mentioned where you got the free beer). These shapefiles are bounding boxes that have been generated by the action of humans correcting suggested place names for geotagged photos. Tom put this data to good use with his neighbourhood boundaries app.

Speaking of excellent location-driven creations by Tom, be sure to check out Clarke; a little OS X app that updates your FireEagle location every five minutes by triangulating your position with Skyhook.

Meanwhile, in another part of Yahoo, Placemaker has been released in Beta form. It looks very nifty indeed. Pass it some human-readable text and it will try to figure out what physical locations are mentioned in the text. You can help it along by using structured data like the geo and adr microformats, but it seems to be pretty good at natural language parsing. Christian has put together some good examples to illustrate his JavaScript Placemaker/YQL mashup.

Slowly but surely we’re heading towards a future where everything is geotagged.

This 1969 vision of a future household is remarkably prescient in some ways but unfortunately dated when it comes to gender roles:

What the wife selects on her console will be paid for by the husband on his counterpart console.

By 1993, AT&T were showing a more equally balanced vision of the future.

Given that those ads are a mere sixteen years old, it’s hardly surprising that they’re generally pretty accurate (although mobile phones are conspicuous by their absence).

Paul Saffo said we routinely overestimate short-term change and underestimate long-term change, but it’s those long-term predictions that are the most entertaining and fascinating.

Paleo Future is a blog by Matt Novak dedicated to A look into the future that never was. The archive is structured by decade, going back to the 1880s. The site is an orgasmofest of steampunk, retro-journalistic soothsaying and zeppelin-inspired musical theatre (calm down, Simon).

Meanwhile, looking in the other direction of the light cone, why has it taken me so long to discover Near Future Laboratory? Julian Bleecker and friends seek out design and cultural trends, often viewed through the lens of science fiction (see, for example, Design Fiction Chronicles: The Stability of Food Futures).

In some ways, science fiction is the safe route to future prediction. Paul Saffo again:

Wild cards sensitize us to surprise, and they push the edges of the cone out further. You can call weird imaginings a wild card and not be ridiculed. Science fiction is brilliant at this, and often predictive, because it plants idea bombs in teenagers which they make real 15 years later.

The expectations set by science fiction result in the hipster chic of wearing a T-shirt emblazoned in Helvetica with where’s my jetpack?

Ray Bradbury takes another tack:

People ask me to predict the future, when all I want to do is prevent it. Better yet, build it. Predicting the future is much too easy, anyway. You look at the people around you, the street you stand on, the visible air you breathe, and predict more of the same. To hell with more. I want better.

Science fiction doesn’t just show us the future we hope for further down the light cone; it also shows us the design and culture we want to prevent.

After I started rewarding machine tagging on Huffduffer with API calls to Amazon and Last.fm, people started using them quite a bit. But when it came to displaying tag clouds, I wasn’t treating machine tags any differently to other tags. Everything was being displayed in one big cloud.

I decided it would be good to separate out machine tags and display them after displaying “regular” tags. That started me thinking about how best to display machine tags.

One of the best machine tag visualisations I’ve seen so far is Paul Mison’s Flickr machine tag browser, somewhat like the list view in OS X’s Finder. Initially, I tried doing something similar for Huffduffer: a table with three columns; namespace, predicate, and values.

That morphed into a two column layout (predicate and values) with the namespace spanning both columns. The values themselves are still displayed as a cloud to indicate usage.

This is marked up as a table. The namespace is in a th inside the thead. In the tbody, each tr contains a th for the predicate and td for the values.

<table>
 <thead>
  <tr>
   <th colspan="2"><a href="/tags/book">book</a></th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <th><a href="/tags/book:author">author</a></th>
   <td><a href="/tags/book:author=arthur+c.+clarke">arthur c. clarke</a></td>
  </tr>
 </tbody>
</table>

Table markup allows for some nice :hover styles (in browsers that allow :hover styles on more than links). Whenever you hover over a table cell, you are also hovering over a table row and a table. By setting :hover states on all three elements, wayfinding becomes a bit clearer.

table:hover thead th a
table tbody tr:hover th a
table tbody tr td a:hover

See for yourself. I think it’s a pretty sturdy markup and style pattern that I’ll probably use again.

It’s been a busy week for microformats.

Google announced that it was following in the footsteps of Yahoo’s SearchMonkey in indexing microformats and RDFa to display in search results. For now, it’s a subset of microformats—hCard and hReview—on a subset of websites, including the newly microformated Yelp. The list of approved sites will increase over time so if you’re already publishing structured contact and review information, let Google know about it.

But the other new announcement is equally important. After a lot of hard work, the value class pattern is ready for use.

The what now? I hear you ask. Well, if you’ve been feeling hampered by the combination of the datetime and abbr design patterns, the value class pattern offers a few alternatives.

To my mind, that’s one of the greatest strengths of the value class pattern: it doesn’t offer one alternative, it allows authors to choose how they want to mark up their content. I think that’s one of the reasons why datetime values have proven to be such a sticking point up ‘till now. Concerns about semantics and accessibility really come down to the fact that, as an author, you had very little choice in how you could mark up a datetime value.

You could either present the datetime between the opening and closing tags of whatever element you were using:

<span class="dtstart">
 2009-06-05T20:00:00
</span>

…or you could put the value in the title attribute of the abbr element:

<abbr class="dtstart" title="2009-06-05T20:00:00">
 Friday, June 5th at 8pm
</abbr>

Those were your only options.

But now, with the value class pattern, all of the following are possible:

<span class="dtstart">
 <abbr class="value" title="2009-06-05">
  Friday, June 5th
 </abbr>
 at
 <abbr class="value" title="20:00">
  8pm
 </abbr>
</span>

<span class="dtstart">
 <span class="value-title" title="2009-06-05T20:00:00">
  Friday, June 5th at 8pm
 </span>
</span>

<span class="dtstart">
 <span class="value-title" title="2009-06-05">
  Friday, June 5th
 </span>
 at
 <span class="value-title" title="20:00">
  8pm
 </span>
</span>

<span class="dtstart">
 <span class="value-title" title="2009-06-05T20:00:00"> </span>
 Friday, June 5th at 8pm
</span>

Personally, I’ll probably use the first example. I like the idea of splitting up the date and time portions of a datetime value. I think there’s a big difference between putting a date string into the title attribute of an abbr element and putting a datetime string in there. In the past, when I argued that having an ISO date value in an abbreviation was semantic, accessible and internationalised, Mike Davies rightly accused me of using a strawman—the issue wasn’t about dates, it was about datetimes. That’s why I created the date design pattern page on the microformats wiki; to disambiguate it as a subset of the larger datetime design pattern.

Now, others might think that even using dates in combination with the abbr design pattern is semantically dodgy. That’s fine. They now have some other options they can use, thanks to the value-title subset of the value class pattern. Me? I don’t see myself using that. I’m especially not keen on the option to use an empty element. But I’m perfectly happy for other authors to go ahead and use that option. When it comes to writing, there are often no right or wrong answers, just personal preferences. That’s true whether it’s English, HTML, or any other language. As long as you use correct syntax and grammar, the details are up to you. You can choose semicolons or em-dashes when you’re writing English. You can choose abbr or value-title when you’re writing microformats.

The wiki page for the value class pattern doesn’t just list the options available to authors. It also explains them. That’s just as important. Head over there and read the document. I think you’ll agree that it’s an excellent example of clear, methodical writing.

The microformats wiki needs more pages like that. One of the biggest challenges facing microformats isn’t any particular technical problem; it’s trying to explain to willing HTML authors how to get up and running with microformats. Given Google’s recent announcement, there’ll probably be even more eager authors showing up, looking to sprinkle some extra semantics into their markup. We’ll be hanging out in the IRC channel, ready to answer any questions people might have, but I wish the wiki were laid out in a more self-explanatory way.

In the face of that challenge, the page for the value class pattern leads by example. Ben and Tantek have done a fantastic job. And it wouldn’t have been possible without the help and support of Bruce, James and Derek, those magnanimous giants of the accessibility community who offered help, support and data.

I’m Irish (well, half-Irish anyway). Most of the time, that’s something I can be proud of. Lately though, I’m feeling downright ashamed of my country.

ISPs in Ireland are facing legal threats by the recording industry trying to strong-arm them into cutting off internet access at their say-so …’cause, y’know, that worked out so well for New Zealand. Eircom have willingly rolled over. Other ISPs are resisting. A New Zealand-stlye blackout campaign is being organised.

While the recording industry tries to push through a policy of guilt by association, the Irish government is trying to revive an older form of guilt. Would you believe that, in Ireland, it might soon be possible to be found guilty of blasphemy? The supreme court says such a law is unenforceable, common decency says it flies in the face of separation of church and state, but the Irish justice minister says gimme that ol’ time religion.

Ah, Ireland. You’ve got the best music and the nicest people …but outdated business models and outdated superstitions make you the laughing stock of Europe.

What need you, being come to sense,
But fumble in a greasy till
And add the halfpence to the pence
And prayer to shivering prayer, until
You have dried the marrow from the bone;
For men were born to pray and save:
Romantic Ireland’s dead and gone,
It’s with O’Leary in the grave.

Stan has written a thoughtful piece called What’s Golden. Therein he examines the tried and trusted golden ratio and finds it very difficult to apply to the unpredictable dimensions of the web browser:

I’m not saying that using these principles is a dead end, what I am saying is their usefulness is questionable for web design. … I’m not in favor of restricting content to a scrolling box, or jumping through hoops to regulate the size of content, pages, and browser windows. These methods push the problems on the viewers.

Jackson takes on the truism that the ideal line length for print also applies to the web. In The Line Length Misconception he rebuffs this cut’n’dried solution, backing up his claims with research (and finishing up with a call for more research):

So should you really be limiting your line length to 75 characters? This research suggests you shouldn’t. Users will be perfectly fine reading longer columns of text. … There may be a good opportunity for some new and more thorough research in this area that could offer some valuable new insight.

Malarkey then clobbers us with his Lead Pipe, rightly pointing out that there is no one single correct value for line-height. He lists a range of factors that should affect the decision:

…dark text against a light background … your line lengths … the x-height of your chosen typeface?

I, for one, welcome our rulebook-questioning overlords. Yes, we can learn from the many years of work that went into divining rules of thumb for other mediums but we should also remember that the web is not just a new and different medium; it’s an ever-changing, ever-evolving medium. That can be frustrating but I also find it incredibly exciting and liberating.

John wrote A Dao Of Web Design almost a decade ago. It rings truer with each day:

Now is the time for the medium of the web to outgrow its origins in the printed page. Not to abandon so much wisdom and experience, but to also chart its own course, where appropriate.

The web’s greatest strength, I believe, is often seen as a limitation, as a defect. It is the nature of the web to be flexible, and it should be our role as designers and developers to embrace this flexibility, and produce pages which, by being flexible, are accessible to all.

The journey begins by letting go of control, and becoming flexible.

I know I’m not the sharpest knife in the drawer but there’s one recurring topic that makes me feel downright stupid. I’ve heard a lot of my fellow designer/developers talking about how page zoom (rather than text zoom) spells the death of liquid layouts.

Now, forgive me for being dense, but I just don’t get it. I totally understand how page zoom could spell the death of elastic layouts; using ems for layout won’t be necessary if browsers natively resize pixel-based layouts. But both pixel- and em-based layouts have a set width and that width doesn’t change depending on the width of the browser window.

A liquid layout will resize depending on the browser width, right? Page zooming doesn’t do away with that flexibility. If I open a fixed or elastic width page in a browser window that’s narrower than the size dictated by the designer, I’ll get a crawlbar. Now I could use the browser’s page zoom feature to shrink down everything until the content fits within my browser window but the content would become illegible.

Text-resizing and viewport-resizing are related only in as much as they are both ingredients in good bulletproof design:

1. Ensuring that a design works for different text sizes.
2. Ensuring that a design works for different viewport sizes.

Native page-zooming in browsers obviates the first concern. It does absolutely nothing for the second concern.

I’m perplexed. Either a whole swathe of my peers are confusing elastic and liquid layouts or I’m missing something fundamental.

A more plausible explanation for this strange equation of page zoom and liquid layout mortality is that designers who have already decided that they don’t want to deal with liquid layouts—for the very understandable reason that they’re harder to do than fixed layouts—are attempting to retroactively justify that decision without really thinking through the argument.

Rather than clutching at ill-thought-out strawmen like page zooming, their time might be better spent reading a good book.

Lionel Schriver’s piece in the Standpoint called Dashed Bad Form is a witty affair, comparing and contrasting the semicolon and the em dash. Alas, the self-describing nature of the article is completely lost in the online version—though presumably not in the print edition—having suffered the all-too-common fate of emdashculation; every instance of an em dash in the article has been converted into a plain ol’ hyphen. Oh, the irony! …proper irony too—not that confused Alanis Morissette kind.

It’s probably a CMS issue. But, hey, it’s as good an opportunity as any to point to the classic article on A List Apart, The Trouble With EM ’n EN (and Other Shady Characters). It’s almost eight(!) years old now and I’d still consider it required reading.

The article makes a brief mention of the soft hyphen (­ or ­) but back then, browser support was pretty shoddy. Browser support was still pretty shoddy when Richard wrote Hyphens a soft problem three years later.

But now the situation isn’t too shabby. Richard’s test case is faring a lot better now in Safari, Firefox and Opera. Internet Explorer (surprisingly) has been doing it right since version 6.

Admittedly, using a soft hyphen is a royal pain in the ass compared to having a browser just figure it out automatically but until hyphenation is sorted out in CSS3—which might be quite some time—we’re stuck with inserting the entity by hand.

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 CO² 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 “sphere.”