Labels are great. Not just in coding, but everywhere. I like labels because they make sure I never do something stupid like put Vegemite (ewww gross) on my toast. But the label tag is perpetually underrated when it comes to HTML. In the big league of <input>, <div> and <p>, no-one seems to have time to properly craft a little <label> anymore. Which is a shame, because using labels properly doesn’t just make your source easier to read. They can make UI testing bliss. And they can even reach out and give you a helping hand in BDD, if you know how to use them properly.

For more, let’s go straight to the sources mouth [http://www.w3.org/TR/2011/WD-html5-20110525/forms.html#the-label-element]:

The label represents a caption in a user interface. The caption can be associated with a specific form control, known as the label element’s labeled control, either using for attribute, or by putting the form control inside the label element itself.

(emph. yours truly)

Well that’s great, you might think. I can put any old <span> next to a control and associate them by pure proximity. Magic! While that’s not necessarily untrue, it is programmatically false. Let’s check it out with an example:

<p>
<span>First Name</span>
<input type="text" name="first_name" />
</p>

<p>
<label for="surname">Surname</label>
<input type="text" name="surname" />
</p>

Obviously this is a biased example, but I’m not here for a haircut, I’m here to stake my claim for the one true label. If we think DOM for a minute, and you might prefer to think jQuery instead if the word DOM makes you break out feverish, how can we address the <span> and the <label> and their associated <input>s? Well for the <span> if we know the name attribute of the <input> we can probably find the input, and then backtrack to find the previous siblings, something like $(“input[name=first_name]“).prev(). That should get us to the <span> and work indefinitely, or at least it will until we change the structure of the page. Then we’ll have to go back and find a new magical path, utter the voodoo incantation and stand on one foot while we commit. And hope it doesn’t change again. So, who’s excited about developing with that one?

So, problems established, let’s look at that cute little <label>. How do we go about finding it and it’s associated <input>. Well let’s assume, once again, we know the name attribute of the <input>. From there we can (again thinking DOM), find any <labels> with a for attribute that matches the name. This looks really easy in jQuery: $(“label[for=surname]“). In fact, it even reads nicely.

There’s another way to look at the association of course, and that’s via the caption’s text. As a user, that’s definitely how you’d identify each of the text boxes, and no one really enjoys getting out the dev tools/Firebug to go poking through names and id attributes if they don’t really have to. If you start with the caption text instead of the <input> names you can, using jQuery, still find the related <input>s. From the span, you could try: $(“span:contains(‘First Name’)”).next(). Once again, it works now, but it’s brittle – we change the layout and the code breaks. How about from the <label>? $(“input[name=" + $("label:contains('Surname')").attr("for") + "]“);. Wow, that’s certainly not pretty. In fact, there might be a shortcut for it. But importantly a) it’s not going to break when we change the page structure, and b) it’s a selector in user-speak.

Now why do we care about brittleness? Because when it comes to UI testing, the less time we spent rewriting tests when pages change, the better off we are. In fact, having UI tests that are resistant to minor layout changes is quite important. This means we can change the UI with the confidence that the tests will accurately evaluate the functionality of the application. Let’s use Selenium as an example:

IWebDriver driver = new FirefoxDriver();
label = driver.FindElement(By.Css(@"label:contains(\"Surname\")");
input = driver.FindElement(By.Name(label.GetAttribute("for"));
input.SendKeys("Shnoop");

Regardless of where the <label> and <input> are on the page, as long as we can follow the trail of the fantastic for=”", we can find the elements for the test. Your only other options for identifying the <input> in this case would be directly by name (painful to find in the source, foreign to end users), by id (possibly server generated, painful to find, foreign to end users) or by absolute location using xpath (which is very painful to work out, and even more brittle).

Now I mention “foreign to end users”, because we want to do BDD. We want our stories and features to be at least readable by users, even if we can’t get them to write them.

Given I have a new application form
When I enter "Shnoops" into the input named "textbox_surname"
And I click "Save"
...

Given I have a new application form
When I enter "Shnoops" into the box for "Surname"
And I click "Save"
....

Using the label name is instantly familiar to end users, and makes the whole scenario easier to read anyway. It means we can parameterise the steps really easily and still be able to locate the associated <input>s.

All with the magic of for=”"!

I decided to post a small jquery extension to github which aims to make working with localStorage easier for complicated data. It’s called jquery.sofa and it’s self-described as: “A JSON-friendly, lightweight, document-database-like, localStorage wrapper (what a mouthful).”

The Enhancement (Pants-) Party

(note: pants compulsory)

Developers need to be happy. Heck, any job needs to be enjoyable. And one thing that developers really enjoy is working with good code. Good code is easy to read, it’s easy to change and it gives you the confidence to make those changes. Bad code is, yerghh, we all know about bad code. It’s hard to read, it’s difficult to modify and when you finally do, you have this nagging feeling that you’ve broken something else. Worse still, it makes developers unhappy.

One thing developers are happy to do is identify bad code. They’ll tell you about it at length, usually followed by their ground-up redesign and re-arch. But identifying the bad code, the code that smells, is a good place to start when making developers happy.

At work, we’ve initiated a “party” (as in, not another boring “project”), dedicated to developer happiness, with the side-effect of system improvement and code cleaning. It has minimal overhead, low barrier to entry, very little demand on resources and most importantly, it’s easy to get buy-in from the devs. During the party, devs are free to work on improving anything that bugs them about the system and make any small quality-of-developer-life improvements.

The “party” runs like this:

• Every second Friday, starting at 2:00pm we kick-off the “Enhancement Party” with a quick stand-up meeting.
• At the meeting, everyone states what they’ll work on in the next 2 or 2 and half hours.
• Those who haven’t brought anything to work ask for advice and the senior devs usually have a spare item or two that we can spread around.
• All work that will be committed must be finished, code-reviewed and tested in the allocated time.
• This encourages devs to pick small, achievable items, the “that would be so easy to fix if I had just two spare minutes” things.
• Spike work is permissible if it’s purpose is clear, or the research will go towards improving quality of life in the future (an example might be working on auto build/deploy components without completing a full build/deploy system).
• Drinks (beer/soft) are fine too.