Brain on Fire » Blog Tim McCormack says words

There is a fundamental tension when designing social media software with a focus on privacy: The more posts are set to friends-only access, the harder a time the network will have in gaining adoption.

Since social media to a large extent lives and dies by network effects, some combination of these are necessary to grow the network beyond a critical threshold and keep it lively. It must also stay reasonably competitive with other social media systems in attracting users. There are many reasons a person might choose to 1) create an account and 2) "friend" other users rather than sticking with what they already have:

• Being encouraged to by their existing friends
• To see what all the fuss is about (if it's in the news)
• By seeing interesting posts by people they may or may not know

Privacy-positive social media software is by default at a disadvantage in the last category. How can it be made competitive with the likes of Twitter and Facebook without compromising on values? In this post, I consider the notion of "socially local privacy" as a partial solution to the discovery problem.

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, effective, 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.