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.

Innocuous little phrase, isn’t it?

If one takes a moment to consider it, however, the idea can be taken to it’s logical conclusion: ‘You (or your browser) are incapable of handling the full experience we want to present, so here’s a cut-down version.’

At its core, the mere concept of ‘graceful degradation’ belies a lack of respect for one’s users and, more critically, a fundamental misunderstanding of the medium in which we work.

The fundamental building block of the web is not JavaScript. Nor is it CSS. If your user experience relies on either of these, rather than features native to HTML, then that user experience is fundamentally flawed for use on the web.

The key is to design user interactions with naught but HTML‘s base features in mind, later using CSS and JavaScript to enhance that experience (most likely streamlining it or making it more efficient). Done right, this enhancement can even be done in progressive levels, based on the availability of given features in the browser.

As a community, we coin phrases with nary a thought to deeper connotations these might have. Under scrutiny, the idea of ‘graceful degradation’ simply doesn’t align with user-centric design and development.

Progressive enhancement it is, then.

Disclaimer: I have no knowledge of Microsoft’s true plans for XAML. These are simply my observations based on what I’ve read and seen on the Internet, and cursory fiddlings with XAML as part of the WinFX pre-release SDK

What is this XAML you speak of?

XAML is Microsoft’s new application markup language (as noted in the name ‘eXtensible Application Markup Language’).

This, then, automatically implies that its primary focus is applications or, more specifically, client-side applications. These could be the likes of Microsoft Word, or they could be something that runs on the client, but is hosted in a browser environment (read: Flash applications).

The raison d’être of XAML, rather than being to replace HTML, is (or rather, would appear to be) to allow client-side application developers to seperate their user interface ‘code’ from their functional code.

Why all the hubbub?

Web developers know that having a hulking great piece of JavaScriptECMAScript to build their entire user interface isn’t good for code maintenance. Why should the same not be true for client-side applications? After all, you don’t hear anyone crying think of the children! when people talk about XUL which is, ultimately, a different implementation of the same concept.

Personally, I think most of the noise is because Microsoft is making (and, in fact, has to make) noise about the benefits of XAML over the old-school way of doing things. Your average in-house developer, closed off from the outside world, that only uses computers for their day job will probably only care about what comes from the hand of God. Add to that the fact that Microsoft has to get the message out to what probably amounts to millions of developers, and they need to make a lot of noise.

Compare this again to XUL: it’s not the default framework for the most used operating system in the world; it has a handful of ‘big’ adopters (who are, in terms of user base, significantly smaller than that of Windows) and a (relatively) small, vocal developer-base.

The point, however, is that XUL and XAML have very similar goals in mind: seperation of interface structure and presentation from ‘logic‘.

Implementation

As a very strong advocate of semantic, accessible web development, the implementation details of XAML grate against my nerves slightly, but not as much as you might think.

Usability

Look at the CD Catalogue, that’s less usable friendly than what Amazon is. That makes me wonder if the web is turning too looks specific. Soon the content will be forgotten and it’ll only be about looks. With that, it looks as though its taking the focus of what the web’s built for (‘To house globally accessible documents’).

I’m not sure Zach’s comparison of the CD Catalogue tech demo with Amazon is a fair one; a better one would be to something like CoverFlow with Amazon integration. It’s also worth bearing in mind that this is a tech demo we’re talking about, not a final product.

Further, I would reiterate the point that XAML is for applications, not documents.

Semantics

Zach also laments the lack of semantics within XAML, referencing setting an attribute value (Value="verticalgradient LimeGreen Green"), rather than some seperate, more semantic notation (he seperates the three values into their own attributes).

This is one point I’d tend to agree with Zach on and, in fact, take one step further: if Microsoft really want to seperate things, allow seperation of structure from presentation, too. As I noted earlier, I’ve a strong feeling that this is already possible, to some degree but, if it is, it’s almost certainly not enforced in any way (like, say, a completely different markup tailored for each, with some form of referencing).

Platform specificity

Every year more people are switching to a Mac for various reasons(I’m not going to get into a debate here), what about them? Will Mac retaliate and do their own version thus leaving Windows users in the dark on some of the web pages. Will their [sic] be a port? Will it get taken back by Microsoft in the hope to fish some Mac users over?

Looking at the direction Microsoft appear to be taking with their Sparkle Interactive Designer (as a tool to create rich applications on Windows and the web), you can almost taste the ‘we want a piece of Flash’ sentiment. Add to that the fact that Microsoft explicitly state that the output from Sparkle will work cross platform and device (in their Expression family tour). I wouldn’t be in the least surprised if we see:

• A gradual uptake (mostly by Microsoft shops and geeks, initially) of Sparkle in addition to Flash (or, perhaps, instead of, for some geeks).
• A cross-platform .Net runtime environment that is, in some way, endorsed by Microsoft. This might be in the form of support for Mono or the like, some extension of the current shared source initiative, a fully-fledged, Microsoft-built .Net runtime for the Mac and *nix, or something in between.

Final thoughts

This is something I’ve actually been mulling over for quite a while and, much as I don’t like the approach Microsoft are taking in terms of the actual markup, I can see XAML making my life (and the lives of those I work with) far, far easier when we have to manage future application interfaces.

It is far from the panacea Microsoft are suggesting that it is, but it is still far superior to the current code-soup approach in most Windows applications.