For the third year running, now, I’m on my way to Austin, Texas for SXSW.

Past

The first year (2006), travelling with Fatty (whom I had met but once before), was an incredible experience. I got to make lots of new friends and, generally, learn a huge amount and have a brilliant time.

Fast-forward a year to 2007 and Fatty and I were joined by Ben, and I got to share a room with the inimitable Faruk. There were lots of complaints, from others, of the conference becoming too big for its own boots, of too many panels with too little content, and so forth; generally, there seemed to be an air of malaise about SXSW.

Socially, for me, it was bigger and better than my first year: I went to more parties, spent time with more people, and generally made more friends than in 2006. It was good.

Present

I fully expect this year to continue that trend given that, at the airport this morning, Ben and I (alas, no Fatty this year) bumped into Stuart Colville before we had even checked in, Paul Duncan over breakfast, Cyril Doussin and Tristan Turpin (who, along with Stuart, are on the same flight as Ben and me) just after breakfast, and Gareth Rushgrove in the departures lounge.

All this, mark you, before we had even left Gatwick Airport.

Granted, this was aided in no small part by the magic of Twitter (and generally being better acquainted with more people in the web scene), but there was also a certain amount of serendipity thrown in for good measure, too.

Near-Future

Compared to the last two years, my aims have ever-so-slightly changed, too. Rather than, as last year, placing the focus on attending sessions and parties, my focus this year will simply be on “am I making the most of this time?”. I intend to be rather mercenary about this, in fact: last year and the year before, there were times when I stayed at a party for fear of not knowing anyone at another. That shan’t happen this year.

Further, I intend to be very much, to use an NLP phrase, “in the moment”. Also, in a change to normal programming, I shall be drinking alcohol (although hopefully not to the levels of excess seen at d.Construct 07).

The biggest change, though, is that I shall, finally, be attending SXSW music. The past two years, I’ve lusted after that extra week of partying and gigs (and envied Keith horribly when he’s stayed on); this year, I get to partake myself (along with Ben, Alex Lee, and Lindsey Mooney). Not only that but, thanks to contacts in Yahoo! Music UK, I may have wangled access to closed recording sessions for Yahoo! Music with Ben, Alex, and Lindsey.

I’m looking forward to it all more than you can possibly imagine.

It must be the best solution, mustn’t it, if all these sites use similar techniques?

The objective of my affection

If we step back for a moment, to examine the user’s needs, we can see two objectives for the average searcher: find something and [perhaps] make it of this type.

The ‘something’ for which the user is searching is, in their mind, the foremost concern. Everything else is secondary. When searching, a user’s first instinct will almost always be to enter their search terms (and why should it be otherwise?). Everything about a search interface is geared toward this: the keyword input has the most visual weight on the screen — on a typical search index page — and the most prominent position — either near dead-centre or in the head of the page, depending on the type of page.

The accepted solution, happily, cedes to this under all circumstances.

The second objective, then, is the type of results that will satisfy the search. The introduction of this second objective is where user behaviour will begin to deviate: depending on their priorities and personal inclinations, users’ execution of this may take place before, after, or even during the steps to meet the primary objective. Unlike the emphasis placed on the keyword input, the type of results to return should be — and, typically, are — de-emphasised where possible, but be present — and have their presence known — should the user require them (either to confirm their beliefs or to make a change).

Humbled

But the accepted solution only pays lip-service to this more complex interaction: for any user without JavaScript, the only acknowledged paths for them to change the channel in which they are searching is to select it before they begin their search or, assuming that the search engine alters the links based on the latest query, directly after (and before they attempt to manipulate their search further).

By using JavaScript to bludgeon links into selecting from a choice of mutually exclusive channels, the user experience of what should be a simple search form is broken for many users when they attempt to interact with it in a way that seems natural to them. To compound this issue further, the use of links means that screen reader users may never be able to use this functionality, as links within the form will never be announced when they are entering their search terms.

The problem is that whomever has implemented these solutions (or their forebears) had the mindset of ‘HTML is static, JavaScript is dynamic’ — or simply didn’t care enough to question the accepted norm — and so overlooked what was staring them right in the face: HTML already has a perfectly good input device for selecting one and only one item from a collection:

The humble radio-button.

Given a little semantic markup and CSS (with a smattering of JavaScript to add extra styling hooks), it’s entirely possible to style a group of radio-buttons in a more visually apt way to indicate that it is filtering the search input, whilst offering a far more interactive experience to all users of the site, not just those with JavaScript.

So I did.

That’s what you can see in action on the new Yahoo! UK and Ireland TV (along with France, Germany, Italy, and Spain).

Implementation notes

As noted above, the main components of the form are a list of radio-buttons, a textbox, and a submit button. Of particular note is the way the radio-buttons are scripted and styled, and the structure of the radio-button labels relative to the form’s <legend>. Further, implementing the search this way requires that the server-side script be able to handle the new field being passed its way appropriately.

Scripted style

For all users, the core functionality of the radio-buttons is available, with these styled as an inline list for users with CSS enabled. The JavaScript, when enabled, will simply add a class to the root of the list, along with an extra <span> to allow styling of the labels in accordance with the design. When the radio-buttons receive focus the ‘selected’ class is moved to the new selection. This activity takes place on focus, mark you, and not click: click events fire on the originating control which, when navigating with the keyboard, will mean the previously selected radio-button.

A <legend> in its own life-time

It was brought to my attention that a form’s <legend> will, by default, be announced before each and every form field by screen readers. To make this as unobtrusive as possible, each radio-button’s <label> is worded such that it makes the most possible sense when preceded by the legend text. In English, for example, the radio-buttons will be announced as ‘Search… the web’, ‘Search… for images’, and so forth (where ‘Search’ is the form’s <legend>).

The radio-buttons’ full text, though, would not make sense in a visual context: they should be presented as tabs titled ‘Web’, ‘Images’, and so on. To achieve this, the visually inappropriate portions of the <label> are wrapped in <span>s and positioned outside the browser’s viewport — along with the form’s legend and the radio-buttons themselves — such that they may still be accessed by screen readers and the like.

Furthermore, because the radio-buttons are still present in the content of the page, keyboard users may navigate the form fully through the keyboard (using arrow keys to move between items radio-buttons in a collection).

Once again, this can all be seen in action on the new Yahoo! UK and Ireland TV (along with France, Germany, Italy, and Spain). [Links added at Mike's suggestion]

Thanks

I can by no means take full responsibility for the successful implementation of this concept, though: I’d particularly like to thank Norm!, Mike Davies, Alex Lee (our designer), Tim Huegdon, and Ann McMeekin (of the RNIB) for all their help, advice, and patience (particularly when I got things working and made lots of excited noises at them), and this wouldn’t have ever been a reality on Yahoo! TV for Europe if it hadn’t been for the receptive, responsive attitude of the engineers working on Yahoo! Search for Europe.