For the last few years, I’ve been neck-deep in conversations about non-normative gender. Those conversations just expanded today with the announcement that Diaspora‘s alpha launch collects gender as an open-ended text field (which was met with some backlash). For everyone just getting to this conversation, here is some context and backstory, based on what I’ve experienced so far. Note that this is limited to my own perspective and exposure, so please add links to other sources in the comments, in an effort to better flesh out the bigger picture.
The Preface, from Doppland
Two years ago, I wrote an open letter to Silicon Valley, requesting that everyone think about how they are approaching Gender in their data collection forms. If you’re the least bit totally baffled by why we’re even talking about gender at all right now, PLEASE start by reading that letter. It’s gentle, it’s in plain English, and it explains a lot.
(I should also add: I organize Genderfork.com, a community expression blog about gender variance, which gets over 20,000 readers and a helluvalot of contributors and commenters per month. This is a large group of people who don’t don’t fit well in traditional gender categories, and their numbers are only scratching the surface of a bigger demographic. They exist. They vary. I know many of them personally. And I identify with them in many ways.)
Last year I attended the She’s Geeky unconference in Mountain View, where I led a discussion called “My Gender Broke Your Dropdown Menu.” I started by reading that letter, and then tasked the group with trying to solve the design problem of “what would be better than a two-option dropdown menu?” It turned into a conversation about all of the user experience, data management, and business issues that get pulled onto the table when Gender is in question, as well as a brainstorming session on how we might solve them. No surprise: we didn’t come up with a clear answer. But we did learn a lot more about the problem. Really, it comes down to the question of “why do you need the data?” Is it about encouraging self-expression, helping people find dates, making marketing decisions, or reporting user statistics to investors? Your primary goal impacts your choices for implementation.
I followed up on that workshop by writing another post called “Designing a Better Drop-Down Menu for Gender,” which listed all the ideas I thought could reasonably improve the data collection process, from a user experience standpoint (again: just go read it — this will all make more sense if you do). This set of ideas was a work in progress, and the last idea in the post — a method for open-ended tagging — sparked a few follow-ups. A designer proposed some early, stylized mockups; Kirrily Robert at Freebase created an alpha version, and Phil Darnowsky further riffed on the idea. We were all just messing around with ideas at this point.
Then it got real.
Diaspora is an open-source, community-funded social networking platform that aims to have better privacy than Facebook and lets you own your own content. It’s in the very early stages (they just let in the first round of alpha testers last week), and is facing a lot of criticism on the quality of its code. But it’s still a great idea.
Sarah Mei, a contributor to the Diaspora project, was in that She’s Geeky workshop about gender and drop-down menus. That discussion, coupled with her own personal and professional experiences, led her to change the data collection method to an open-ended text field. She writes about the process she went through to get to this decision over here: Disalienation: Why Gender is a Text Field on Diaspora.
It has also perturbed some people.
…which has sparked further support for the change.
Since Diaspora’s code quality still has a long way to go before it’s accepted as stable, I’m sure there will many more iterations to this field. So let’s keep an eye on the conversation and advocate for the best possible scenario.
vCard (and Microformats, and OpenSocial)
Guess what? Diaspora’s not the only project dealing with the Gender Data issue this week. As we speak, the vCard specs team is pinning the next iteration of how our address book data will be organized. Their original plan was to have a field called SEX that allowed for the following attributes (based on the ISO):
- 0 = not known
- 1 = male
- 2 = female
- 9 = not applicable
Tantek Çelik proposed a two-field solution: SEX (male, female, other, or none/not applicable) and GENDER IDENTITY (an open-ended text field), based on data and solutions he’d explored earlier at Microformats.org. This seems like a reasonable solution to me. (Note: this suggestion is strictly about organizing data behind the scenes. “What will profile forms look like?” is a different conversation.)
I chimed in with an explanation of about why the ISO system is inadequate and offensive, and expressed support for Tantek’s plan.
The gender of this contact. Service Providers SHOULD return one of the following Canonical Values, if appropriate: male, female, or undisclosed, and MAY return a different value if it is not covered by one of these Canonical Values.
In other words: male, female, nuffin’, or fill-in-the-blank. Works for me.
Things are still being finalized, but it looks like vCard will settle on one of these solutions, or a close variant of it.
That’s about the extent of my knowledge on the Gender Data Collection story as it’s playing out right now. Let’s pool any links that show where progress is happening, and bring solutions to this obscure but highly sensitive design dilemma to light. Comments offering more constructive views and info are encouraged here (and flaming won’t be tolerated).
Thanks so much,