Dopp Juice Archive

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.

Enter: Diaspora

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.

This has received support.

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.

Kevin Marks pointed out that he and Cassie Doll had also worked out a reasonable data organizing solution, which was accepted in the early stages of OpenSocial and Portable Contacts:

gender:
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.

What Else?

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,
~ Sarah

A year ago, I wrote an open letter to Silicon Valley, asking people to stop and think about how they’re handling gender (and race, for that matter) in their community websites.  The short version is that if you’re requiring users to select their gender from a drop-down menu that has two options in it, you’re alienating some people. I didn’t offer alternative solutions at the time — it was just a request for everyone to think about it.

(Note: if you’re not clear on why gender is a complicated issue in data collection, please stop right now and go read that other post before continuing. This will make a lot more sense after you do so.)

After grappling with this problem on a few other projects, and talking about it in a session last week at She’s Geeky (I called it “My gender broke your drop-down menu…”), I’d like to now offer my suggested alternatives.

Alternatives to asking for a user’s gender in a required two-option drop-down menu…

Option 1: Make it Optional

Baby steps.  If the idea of getting fancy with your data collection method gives you nightmares, just remove the red asterisk.  Stop making it required! Most people will still answer the question, and those who don’t want to will select not to.  Put a plan in place for how to treat and account for those who don’t want to declare their genders, and you’re done.  It’s not the most celebratory or inclusive measure, but it is a very clean way to resolve a lot of problems.

Option 2: Don’t Ask At All

Instead of asking for gender, ask for what you actually want to know.

Is it what honorific should precede the person’s name?  Well, then gender’s not going to tell you if they’re a doctor or a reverend, is it? Give them a comprehensive list of options, and allow them to select none, if they wish. (And really, why do we use these again?  My preference is to drop them entirely.)

Is it what marketing you think they’ll respond best to?  Newsflash: not every woman likes baking, and not every man likes cars.  Ask them about their interests and market to them on that basis, instead.

Is gender not actually relevant at all, except that you think it makes for an interesting statistic? Meh. I’d like to convince you that you really shouldn’t touch it, but if I’m not going to win that argument, please see Option 1.

Option 3: Have a Third Option

Your drop-down menus can have more than two options.  Some people are trying three.

I’ve spent a lot of time thinking about this, and here’s my current position:

• “Other” is a poor choice for a third option.  Why? Because gender-nonconforming people are othered enough as it is.
• A more useful choice would be “Decline to State” (or something similar) — then it’s not about non-conformity, it’s about privacy.
• But taking this a bit further, I’d like to submit “It’s Complicated” for consideration as the new third option.  Most gender-nonconforming types will smile at you for it.  It tells them you understand.

I’ve seen some people try to implement a “lots of options” dropdown menu, but I don’t really recommend this route, for two reasons:

1. What if someone looks at the list and doesn’t identify with any of the words?  You just alienated them much further than your male/female dropdown menu was doing before.
2. What if someone identifies as more than one thing on the list?  Take, for example, a transsexual woman who is proud to identify as a woman.  Are you really going to make her choose between “trans” and “woman”?  Come on now.  That’s insulting.

If you change it from a drop-down menu (“pick only one”) to a checkbox menu (“select all that apply”), you solve issue #2, but you still have issue #1 to grapple with.  And let me tell you: if you think you can come up with a finite list of all the possible gender identities in the world, you’re wrong.

Option 4: Redesign the System

So you’re convinced that “male/female” is a deeply flawed data breakdown for the purpose of your website, but you want people to assert their identities, and you want them to get personal about it.  Okay, then!  Time to scrap the dropdowns and do something new.  Here are some ideas…

A “gender spectrum” slider bar. Take a look at how Blackbox Republic is structuring their sexual identity data:

I could see a similar thing done with “masculine” and “feminine” at each end, and letting people self-identify.

Note: one huge problem with the spectrum model is that it’s too flat.  I believe there are people who have “a lot of gender” (i.e. dripping both masculinity and femininity all over the place) and “not a lot of gender” (i.e. minimizing signals of any gender whatsoever), and on the spectrum, they might look the same.  But that brings up my next idea, which is…

A second dropdown that asks how important gender is to them. Take a look at how OkCupid handles religion.  You get one dropdown menu for how you identify, and a second dropdown menu for how important it is to you.  For some people, their gender is a strongly identifying factor in their lives.  For others, it’s nearly irrelevant.  What if we just started asking that question?

You could also…

Get fancy and use Kreative Korp’s SGOSelect menu (or some variation on it), which basically says: if you have a traditional identity, you can use the simple form.  And if you want to get more specific, you can switch over to the Advanced form:

… but it still runs into the “finite number of options” problem, even in the Advanced view.

And that brings me to my last suggestion, which so far seems to be my holy grail. I worked this out with my co-founder team at Boffery while we were strategizing the user interface… with some outside input from Kirrily Robert of Freebase:

An open-ended tagging field that suggests words as you type. I want to be able to define my gender as “female, androgynous, genderqueer.”  And I believe that if we were all encouraged to, we would come up with a great rich vocabulary that uniquely characterizes ourselves in all the ways a two-option gender set is trying to do, but failing at.  If the tagging system were set up to automatically suggest words as you typed, you could either loop in to what others are saying and be associated with that group, or create your own words and add them to the lexicon. The result would be a rich mix of groupable/categorizable labels (marketers: this is far more meaningful than what you’re currently working with), along with the ability for us to self-identify however we want.

I don’t have a picture for you ‘cuz it hasn’t been built yet.  But if anyone understands what I’m talking about and wants to test it out, let me know.

I want in.

Love,
Sarah

ETA: immediately after I posted this, a designer took a stab at the open-ended tagging field idea and sent me early concept mockups.  Check ’em out!

Over dinner last Thursday night, maymay and I spent several hours discussing what makes a Good Web Development Team, based on our particular work styles.  Here’s what we came up with (refined from a crude notebook sketch):

Particular things to note here…

• All team members have direct access to one another, and are encouraged to work together in real-time.  Quality assurance, scope agreements, user experience development, and engineering development all depend on direct collaboration.
• D@n has already pointed out that we left out Sys Admin.  That’s a good point, and it should probably be its own person, with direct lines to Front-End, Back-End, and Project Manager.
• He also expressed concern about QA not being a specific person.  I stand by the current model for dev teams that don’t aspire to grow any bigger than the setup above — peer-checking is sufficient.  As maymay put it, “QA is a state of mind.”  It’s always happening, and it can be structured to happen systematically.
• Job roles and personal skills don’t always perfectly align. In my case, I can play both Front-End Developer and Project Manager, each with a particular flavor.  And maymay can take on both Front-End and Back-End Developer roles if the expectations are right.  But for both of us, it seems the case that if we only have to take on one role per project, we’re able to do better work.

This is just an abstract exercise in theoretical structuring based on our experience — not meant as anything to be set in stone. Take it for what you will, and feel free to expand on it.

Enjoy!,
Sarah