Brain on Fire » Blog Tim McCormack says words

I want social space online, but none of the social media software currently in existence meets my needs. Beyond that, I believe that many of the offerings are actively harmful to privacy, security, and democracy. I know many people feel the same way, but can't opt out for lack of alternatives. Clearly it's time to build something new. Something that's useful, efficacious, and responsible, but also attractive. What elements will it need?

I have finally joined the ranks of bloggers who have designed their own blog themes. Wheee.

At some point I'd like to go for membership in the My Blog Actually Looks Nice club, but that could be a little ways off.

Edit: Thanks to Russ for the snazzy header image!

Edit 2006-05-07: If you're looking at this blog using Internet Explorer, you'll notice I really don't give a crap. However, if Safari, Konquerer, or Opera users notice something wrong — let me know!

When I heard the news that Google was hiring Doug Bowman as a design coordinator, the first thought that came to my mind was, "Who is Doug Bowman?" (Like myself, you may know him better not by name, but as the founder of Stopdesign.) The second thing I thought of was Apple's success at maintaining product design consistency. They manage to keep their operating system, their gadgets, their programs, and their web sites sleek, trim, and clean. I imagine an entire department of design coordinators working around the clock at Apple HQ, comparing iPods to iTunes to MacOS, making sure nothing breaks out of the image they've built up so well.

Google traditionally kept to the server-side applications until a few years ago, when they began exploring the thin-client web apps (e.g. Google Calendar) and client-side server apps (e.g. Google Desktop). With the advent of new products, they must have realized that their branding had to consist of more than just colorful letters and replacing an "o" in "Google" with a relevant round object or symbol. When Larry Page and Sergey Brin started the company, it wasn't even a consideration. (Check out their original site -- complete with the ubiquitous "BETA"!)

I think Doug will do an excellent job, if his work at Stopdesign is any indication. Watch out, Apple!

Problem

There is no accessible, standards-compliant way to code radio buttons in XHTML, because the label association mechanism conflicts with name and id attributes in radio buttons.

Solution

Replace the radio buttons with a select element.

Explanation

Form elements create key-value pairs through the use of name and value attributes. The form is serialized as an ampersand-delimited string of fields, where each field takes the form of name=value. This is fine for text input fields and checkboxes, which have a single-source structure in the HTML. However, radio buttons present a special problem. Each radio button in a group has the same name and a different value, indicating that they are the possible values a field can take.

Recall that label depends on the id of the form element with which it is associated, as well as the requirement that the name and id not differ on an element.

<label for="address">Address</label>
<input type="text" id="address" name="address" value="" />

How, then, does one code radio buttons with labels? Since all the radio buttons in a set will need the same name, each element with a label will need an id, and the id must match the name, the radio buttons will have identical ids. This is not in compliance with the W3 specifications, however, leading some web designers to choose accessiblity over compliance by appending an index digit to the id of each radio button.

There are further accessiblity issues that I will not explore here, such as visibility of the radio button itself, association of a label with the entire radio set, and visual interference between multiple radio sets.

A better solution is to scrap the radio buttons altogether in favor of the select element. The dropdown list is far more accessible, supports internal grouping of options, and consumes less real estate, yet preserves the data structure of the radio buttons.

Resources

• Alternatives to radio buttons: How to decide on a solution and refactor the associated text.

I'm taking a quick break from studying for my CS 152 final. I'm currently on the Chapter 14 study guide, dealing with OOD. Now, this is something I find completely instinctual. Heck, I nearly reinvented it on my TI-89 graphing calculator, using BASIC. Then someone told me about Java, an OO language, and I just wanted to smack myself.

I've never thought about how a class hierarchy is designed -- when I go to make one, it just falls into order magically. I have gut reaction to improperly designed code. Unfortunately, I have to explain how it works on an exam, and my own description won't cut it. It has to match the book's description, which means I essentially have to memorize a specific description of something I know by heart. Bleagh.

I agree that being forced to think about something you've been doing unconsciously can be a good thing -- I don't dispute that. It teach you things you missed, and expose flaws in your subconscious reasoning. But when I'm forced to regurgitate formulaic descriptions, that's when I object.