91Èȱ¬

Here's another crop of links that caught our eye recently. We're changing focus a little this time, pulling out some more technical posts.

In praise of Git's index

Aristotle Pagaltzis has a good (via ). This is one of those things that isn't immediately obvious, but quickly becomes invaluable.

Alternatives to inheritance

Curtis "Ovid" Poe has written quite a lot about for code reuse in Perl. His latest post examines the options for using for his new project at the 91Èȱ¬.

Live SPARQL end-point for 91Èȱ¬ Programmes

Yves Raimond announced an experimental , including a description of how the service was created. It's a great addition to the variety of linked data provided by 91Èȱ¬ Programmes. See also this case study on the use of .

New Browser Security Features

The had a good post about , but also in Internet Explorer, Firefox, Safari and Opera. It's nice to see browser vendors centering around standards to solve these problems.

Here's another set of articles that have caught our attention during the week...

Semantic Versioning

Tom Preston-Werner, one of the co-founders of , has written a specification for a standard . Many of our teams already use approximations of this (in fact the Glow team document theirs) and find it works well, but as the article says:

The problem is that "close" isn't good enough. Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management.

It's a great piece of common sense and we'll be looking at how we can follow this spec more widely around these parts.

Building the Mobile 91Èȱ¬page

Some of the key issues tackled in creating the the personalised mobile 91Èȱ¬ homepage are discussed on the Internet Blog. While modern devices are looking to blur the lines between the mobile and desktop web, it's clear that building a compelling mobile experience still poses its own unique challenges.

The Digital Revolution

An upcoming documentary on the history of the internet, Digital Revolution has already made some great interviews available with key internet people available on the site, with more permissive licensing than usual. Gizmodo has published an and it looks like it's going to be a must-see for anyone interested in the web.

52 Weeks of UX

Something else that has caught our eye this week is the early output of . The project is aiming to stimulate discussion around User Experience design through a year-long series of short posts on various aspects of the subject. To software engineers the visual design process can often seem a vague thing, lacking definitive answers, so we're hoping this will help improve understanding of just how important this part of our job really is.

By the way...

...we're trying to pick things from the week that might have missed your inbox, so please feel free to let us know if there are any interesting things that seem to have missed ours.

Like at any other company, the email accounts and feedreaders of our developers are always overflowing with new articles from around the web. Here's a quick set of some of the links creating discussion among bbc.co.uk development teams this week.

Asynchronous Servers in Python

There has been a lot of hype around the project over the last couple of months. Whilst not a brand new concept, JavaScript does seem particularly well suited as a language to the event based model of I/O. Nicholas Piël has written a detailed comparison of and it will be good to see this expanded to cover frameworks in other languages such as Node.

Alt and Title Display in Browsers

Steve Faulkner from the has done a thorough examination of the in the major browsers. We really liked the methodology here, taking a discrete problem and covering it completely, rather than trying to boil the ocean.

iPlayer Stats

Over on the internet blog Paul Murphy gives an overview of the latest iPlayer usage stats. Particularly noteworthy is the uptake of iPlayer on new platforms such as Wii and Playstation 3, which now makes up 6% of requests for TV programmes.

Woosh - JavaScript Performance Testing

The Glow guys are hard at work on Glow 2 and to make sure it's as fast as it can be, they've developed a speed testing framework. Frances from the team has written an .

A little while ago I was talking to our interaction designer Pekka about a link we had in the masthead that was under-performing. We suspected it was the wording that wasn't working, and after thinking up a few possible options Pekka said it would be great to be able to "A-B test" some of them. This led to some blank gawping from me, and so in turn to an explanation from him.

It turns out '' is a way to show different options for part of the UI to two (or more) groups of users, and then monitor what they do as a result. This can be done in normal of course, but more interestingly it can also be done on a live site with large numbers of users - getting real world results on a statistically valid scale. In our very simple case we could show the different wording options to different groups and see which one generated the most clickthroughs.

This sounded like a great idea, but not something I could fit onto the project backlog at the time. Luckily, some teams here set aside a little time within their project planning specifically to let developers 'scratch that itch'. No, not like that. I mean work on something that's bothering them rather than whatever's needed next in the project. Our team uses a system within our normal project planning process, , to give us up to a day a fortnight for this.

Thus I decided to spend a day writing this mechanism for doing A-B testing on bbc.co.uk.

The code

The JavaScript is split into two parts. The first is used for new visitors, and, aside from checking the function's configuration is valid, simply uses the probability value to decide whether the user is going to be part of the test, and cookie them accordingly.

The second is used for those who already have a cookie, and have been randomly selected for testing. It cycles through all the links on the page, checking for any that have a class starting 'abtest_'. When it finds one it adds an onclick which, when activated, makes a call to a tracked image so that the click is counted.

This tracking is done using the 91Èȱ¬'s stats system, known internally as 'go-tracking', which allows us to easily get reports from the server logs showing how many times particular URLs are visited.

To make these calls I used img.src="..." to make an asynchronous call from JavaScript. Note however, if the link in question goes to a new page about 1/3 of browsers won't complete the request before the page unloads. If this was an issue for a particular test the links' hrefs could be changed, so they go via a tracked URL instead.

Finally, in the page itself we place some small snippets of SSI (though we could easily use more Javascript or PHP) that check for the cookie, and change what the user gets shown according to its value.

Example use

For 5 in 100 people to get a two-option test running for 24 hours the function is initialised like this:

abtest.init(
    'mydemo', {
        probability:5, 
        numOfOptions:2, 
        path:'/includes', 
        duration:24
    }
);

Within the markup, content is changed according to the cookie value:

<!--#if expr="$HTTP_COOKIE=/abtest_mydemo=a/" -->
	Text a
<!--#elif expr="$HTTP_COOKIE=/abtest_mydemo=b/" -->
	Text b
<!--#else -->
	Default text
<!--#endif -->

And classes like this are added to links that are to be counted:

class="abtest_mydemo"

Any clicks on that link will result in an asynchronous call to an image with a path that includes "mydemo" from the class and the option value (e.g. "b") from the cookie:

/go/abtest/int/abtest_mydemo_b/

Thus after the test we can count the totals for each option, and use those figures to help decide which solution to go with.

And the winner is...

Well, whaddya know: the design changed, removing the button in question, so I'm still waiting for my first excuse to use it. However, my friend Manjit over in World Service has just run a test of the wording for the main link to their syndication widget, and immediately proven a small tweak would be three times as effective at getting users' attention. Not a bad first outing.

As a method it's not without its dangers of course. Your presented options must be realistic, and not just chasing clickthroughs for example - but with an experienced information architect at the helm I think this little snippet may come in quite handy.

What do you think? Have any of you used this kind of testing?

Text fields in forms need to have labels, so that people know what they're meant to enter into them. Next to a username field, for example, it'll say something like "Enter your username". The HTML you'd use for this would involve a <label> tag, with id and for attributes tying everything together. The association between <label> and <input> lets the browser know which hint applies to which field.

Username

<label for="username">Username</label>
<input id="username" type="text" />

When properly associated like this, the label becomes a handy way for users of visual browsers to send focus to the field. Users of non-visual browsers, however, need the label to be there so that when the field is reached, there is any information about it at all.

Multi-labels

The pairing of one input tag with one label tag only allows space for one chunk of text for each field. It's not unusual for a design to call for more than one chunk to be associated with a field, often with the second one appearing elsewhere on the page.

This design pattern often appears when we need to explain more than one thing about a field: the fact that the username can't contain spaces, or that it needs to be more than a certain number of characters, for example. It's also a common way to show feedback after form validation.

Can't we just add more labels?

Sadly, no. You might think that if you need two labels, you could just use two label tags. But as Roger Johansson pointed out in a while back, this appears not to work. Generally, only one or other of the labels is noticed by screenreaders.

As a result, out in the wild, extra bits of hint text usually end up separated from the label, inside another tag, with CSS then positioning them according to the design. The HTML generally looks something like this:

<label for="username">Username</label>
<input id="username" type="text" />
<span id="username_info">Pick a name to use on this site.</span>

The problem with this approach is that the second hint chunk won't always be read out by screenreaders, as only the main label tag, "Username", is explicitly associated with the input. To use a common but sometimes hard-to-pin-down phrase, this way of doing things is inaccessible.

A quick aside about forms mode

When interacting with forms, some screenreaders enter 'forms mode'. This switches the keyboard over from page navigation (using the keys to jump to different parts of the page) to allow regular text input. This allows you to type your username, rather than perform browser-related shortcuts. In this mode, only form-related tags are read out. Other tags (apart from links) tend to be ignored as you move around the page.

This means that if the text in your second chunk of label text is important, it may be ignored. This could be a problem:

<label for="user_code">Please enter your user code</label>
<input id="user_code" type="text" />
<span class="hint">but only if you want the nuclear reactor 
	 to shut down immediately</span>

The importance of being important

If the additional chunk of text isn't vital for users to read, then you might say it doesn't matter that it's not available to screenreaders. In the example above, the hint text "Pick a name to use on this site" is arguably not as critical to understanding the form as the nuclear reactor label. But if something's important enough to be in the page, then - all other things being equal - it should be available to everyone... otherwise, it arguably shouldn't be there at all.

Two for one

Time for some actual answers. Provided we don't use it as an excuse to write an essay inside the label tag, a solution to the 'two labels' problem is to place both the main and hint chunks together. As they're both important to understand, it's really just one label anyway.

<label for="username">
	<span class="main">Username</span>
	<span class="hint">must be more than 5 characters</span>
</label>
  	
<input type="text" id="username" />

If a screenreader reads this out, however, it'll join the two hints together as if they're a single sentence, and this might sound slightly odd. To make things read more sensibly, we can insert a hidden full-stop. This makes the screenreader pause for a moment and read the two chunks as we might expect them to be read: "Username [pause] must be more than 5 characters".

<label for="username">
	<span class="main">Username</span>
	<span class="hide">. </span>
	<span class="hint">must be more than 5 characters</span>
</label>

<input type="text" id="username" />

Presentation

There are lots of ways that you might want to present the label and its hint text, and even more approaches to the CSS. But to separate the hint and place it below the field, you could do something like this:

#container {
	background-color: #eee;
	position: relative;
	width: 270px;
}
#container label { display: block; line-height: 1.5em; }

#container span.main {
	font-weight: bold;
	display: block;
}

#container span.hint {
	display: block;
	margin: 1em 0 0 0;
	text-align: right;
	font-size: 0.9em;
}

#container input {
	position: absolute;
	top: 0;
	right: 0;
	width: 13em;
}

.hide { position: absolute; left: -2500px; width: 1px; }

Which turns out like this:

Username . must be more than 5 characters

Potential issues

Nothing is ever simple, though. While this technique works well, it doesn't work everywhere... and in particularly quirky cases, we can end up with a situation where nothing is read out. This is, of course, exactly the problem we were trying to solve in the first place...

Voiceover 3.0 on Mac OS X, for example, appears to ignore elements inside the label that are set to display: block; this problem doesn't seem to happen in earlier versions. And using absolute positioning to move the hint chunk into place can, in some situations, cause problems in JAWS. More work needs to be done to pin this one down, but it seems to involve the vertical height of the hint relative to the main label, and which elements (the label and the spans) are set to display: block.

One way to resolve this, although it's a shame to have to do this, is to add the label and hint text as a title attribute on the input tag:

<label for="username2">
	<span class="main">Username</span>
	<span class="hide">. </span>
	<span class="hint">must be more than 5 characters</span>
</label>

<input title="Username. must be more than 5 characters" type="text" id="username2" />

In the absence of a label, the title is read out by Voiceover as if it was working normally. When things are working as expected, the title should be ignored in favour of the label.

hammer.crack("nut");

In summary...

• Form <input> fields need to be properly paired with a <label> tag
• Screenreaders in forms mode tend to ignore anything other than single <label> tags
• If you need to add more than one chunk of text to a label, try putting both chunks inside the label, and then moving the chunks into place with CSS
• Use hidden full-stops to make things flow as expected
• Always test what you've done as widely as you can, because these things can be unpredictable...

This is a tricky problem, so if you have any thoughts or suggestions, or have a chance to try these examples in assistive devices that you have access to, it'd be great to hear from you.