Inclusive data structures
One of the most aggravating things about much of the infosphere is that a majority of software is designed with a heteronormative, cisnormative, gender-binary, and usually ethnocentric worldview built into its basic operating assumptions. This is especially a problem with social media. The upshot is usually this:
- The gender field is a drop-down menu or pair of radio buttons with two choices.
- There’s a separate field for first names, last names, and sometimes middle names.
- There’s no way of encoding relationships with multiple people.
The naïve solution to these problems is to add choice. Instead of “male” and “female” radio-buttons, a well-meaning programmer might put in a drop-down list including male, female, questioning, queer, and agender. Great. What about bigender people? Genderfluid people? People from specific non-white cultural traditions, like two-spirits or hijra? Okay, maybe we can expand the list to include them. If you account for every discrete gender identification, you’ll eventually wind up with a very long list that’ll cover maybe 90% of people.
What about the remaining 10%?
What about people who have their own way of describing their gender? What about people who more or less fall into an established category but for whatever reason feel uncomfortable with the label the developer offers?
And for some extra fun, what in god’s name happens when you try to localize the list of genders for, say, Arabic?
The point is that this is approaching the problem in exactly the wrong way. Gender is a continuum (in more than one dimension, incidentally) and the standard approach is to refine it down into something discrete. The correct solution? Don’t fuckin’ make people tell you what their gender is.
Seriously, you really don’t need to know. The only real practical application of this data is marketing, and gender-based marketing is poisonous, corrosive muck anyway.
If it’s a social network, of course, there are some problems with that model. The service provider has no reason to know the user’s gender, but the user might want hir friends to know. There’s a fairly obvious solution to this: Add a text field in the “About Me” section. Label it “Gender.” Accept an arbitrarily long string. Allow people to leave it empty and hide it. This is actually easier than radio buttons or a drop-down menu, for chrissakes.
The other potential problem is pronouns. The simple solution is to let the user supply their own, maybe with some examples so they don’t need a linguistics degree to figure out which forms of “xe” are the nominative, accusative, genitive, and oblique. Unfortunately, while this is something that can be resolved in English, other languages aren’t so fortunate. Arabic enforces a gender binary marked on nouns, adjectives, and verbs, and it permeates the language, as do a lot of other languages. Ultimately, there’s no easy answer here. The best one is to avoid constructions that require indicating a user’s gender: instead of “داليا تحب مجلتك” , write something like “يحب شخص مجلتك: داليا.” Use icons instead of text as much as possible without damaging the UX.
(Of course, there are languages where this is a non-issue. Swahili doesn’t mark gender at all except in some lexical items, and uses “yeye” for everybody.)
What about the ethnocentrism? It’s a very European assumption that everybody is going to have a given name and a family name, or a given name and a patronymic that can be cleanly separated into a “first name” and “last name.” It also conflates given names with “first names”, so in particularly stupid designs, a Chinese person might have to put their name in backwards so the program will be able to deal with their given name.
"But," the developer will exclaim, hands wringing anxiously, "we don’t want to call somebody Jonathan Q. Tastyzots everywhere in the UI; he should show up as “Jon” or “Jonathan” to his friends, and “Mr. Tastyzots” to his business contacts! Without a distinction between first and last name, how are we supposed to know which form of the name to use in which contacts?”
Great question, imaginary developer! WHY DON’T YOU ASK THE USER?
Instead of “First Name” & “Last Name” ask the user for all the forms of their name you need. “Full form,” “Personal form,” and “Official/business form” will be enough to handle all the needs above. So Mr. Tastyzots could reply “Johnathan Q. Tastyzots”, “John,” and “Dark Lord Thunderpants the Despoiler” (because also why are you assuming even Europeans have predictable name forms?) and Muhammed Husayn Abū ‘Umār Ibn ‘Abd ir-Rahman can answer “محمد حسين أبو عمار ابن عبد الرحمان”, Abu ‘Umār “ابو عمار، and Sayyid Husayn “سيد حسين” or whatever reflects how he uses his name. And it means the developers have less work to do! (Also, you fucking better have Unicode support, or I will wreak a terrible vengeance upon you and your next twenty descendants.)
There’s a pattern that’s beginning to become evident, isn’t there? The old way of doing things asks users for a specific set of information, and then the software assembles a model in the background which it uses to provide surface forms. What we’re doing is eliminating the middle-man, and letting users supply the backend model directly.
Can we apply this model to relationships, though? Yes. This article sums it up better than I ever could, but the basic principle to keep in mind: do not arbitrarily collect data. When you need information, instead of trying to assemble a model from pieces of user-supplied information, just ask them directly. Do you want to know who their spouse is so you know who to contact in an emergency? How about instead you just add a field labeled “Emergency Contact?”
Software should be generic. This applies every bit as much at the cultural level as it does at the engineering level.