00:00:08.599
Um, I'm actually really excited about this talk. This is something that is going to make my life easier because I'm dealing with these issues myself. Our speaker is Karina Zona. She's a San Franciscan and has been a Ruby developer for five to six years. She does a lot of work with RailsBridge and Women Who Code, and she's also a sex educator with the San Francisco Sex Information phone line and service, which is nationally known. She's going to be speaking to us about schemas for the real world. So thank you, Karina.
00:00:53.239
Well, hello! As Josh noted, I am both a developer and a sex educator. I think a lot about how these two things overlap. Research, culture change, and self-reflection have stirred an increasing range of labels that people ascribe to their important relationships, sexual orientation, and gender. Social apps, in particular, are now being pressed to adjust. Imagine walking through the world knowing that everyone's first assumptions about how you see yourself, who you love, and what feels right for you are completely wrong. Now imagine signing up for a cool website and then being required to select an option from a drop-down menu that doesn't include anything that represents you.
00:01:34.760
You'll feel defeated. You'll want to argue that whatever they think they're learning from you is not really true. You want to tell them that they're adding to your humiliation by making you do this. You'll want to tell them that they're missing a huge part of you. Users are giving us pushback against ill-fitting assumptions, and if you feel out of depth in dealing with these issues, well, you're not the only one.
00:02:09.200
So, what would a canonical set of relationship statuses look like? Three years ago, Facebook figured this was a pretty good model and arguably even pretty progressive—right? We got stuff here like "open relationship." Users disagreed, and they disagreed strongly. So, under pressure, Facebook had to nearly double the options in just two years. When Google Plus launched last year, it largely adopted that list, although for some reason, they left out 'separated' and 'divorced.' We still don't know what a canonical list looks like.
00:02:44.560
Notice that they also added something else: the choice to opt out of being labeled at all. This allows users to identify their relationships using labels of greater personal significance. This shift was driven by people rejecting a user experience that wasn't working for them. It's not about monetization; Facebook doesn't even care, and they're not providing the option to advertisers. We're dealing with three core problems.
00:03:09.200
First, there's a premise that deeply personal stuff about humans can be reduced to lists. Second, there's the assumption that canonical lists for these things do and must exist, or at least that we can create them. And the third problem is our faith that the first two can be easily solved just by adding more list items. This is not going to work, and worse yet, it makes you look like a fool. This is what happens when we try to throw more labels at the problem instead of examining the assumptions in the database schema.
00:03:54.080
For example, an open relationship is definitionally a one-to-many join. The usual understanding is that the actual number of relationships could be zero, one, or many. But this is Facebook failing at modeling relationships in a relational database. The schema forces the user to choose, so you either look evasive or are inauthentic. And it's not just about relationship statuses; it's not just for people in open relationships. They're being made to feel like they don't exist or have to lie.
00:04:41.359
It's the tip of the iceberg. In 2008, Sam Hughes set out to create a modern relational schema for marriage. He went through about 14 iterations in SQL before realizing that the problem was never going to be solved that way; the foundation itself was wrong. Relational databases couldn't model real life's complexity. A graph database is what would be needed. So how do we bring modern realities into data views and logic? We start at schema.
00:05:27.000
Developers are being tugged in two directions: keep that code base manageable, right, and design for modern complexity. We can build a foundation for great user experience and sound development. Let's look at what the approaches are. First, we have to get schemas into alignment, and I said schemas plural because we have two different types. We have mental schemas, which are an individual's set of preconceived ideas—a framework for representing some kind of aspect of the world and our personal system for organizing information, especially as new information comes in. Then we have database schemas, which are essentially the same thing, just a mental schema translated into blueprints for a database.
00:06:24.080
When we use rails generate scaffold or rails generate model, we're creating a migration. And maybe you created something like this. Those migrations ultimately get translated into a unified schema to be used by the environment's database. So, when you're looking at all this UX, these are just manifestations of mental schemas. Our schemas and our UX are leaving people behind, and we can fix it by starting with a question: What benefit will the user notice?
00:07:05.840
When developing a schema that asks a person about their experiences, feelings, sense of self, and identity, there isn't going to be a single right way for me to tell you to solve this. But what we can do is evaluate the trade-offs and ask what benefit the user will notice. That's not equivalent to asking how the user will benefit. That's a question that grants us a lot of latitude to assume that whatever we want to do will be to their benefit, right? Because we are making a product that's awesome and will work for them.
00:07:40.080
Evaluating from the user's perspective is how we keep focus. I've got this lovely little chart here. The problem is that there's absolutely no point on it where everyone is going to see maximum benefit. All we can do is really look at choices and try to work out the trade-offs.
00:08:30.320
First off, let’s agree that it feels terrible to be told, "No, you are wrong about who you are." Checkboxes, radio buttons, and select menus imply that all possible values can be represented. The message is, "Hey user, just pick the right ones and everything will be fine." But think back to those opening slides I showed you—does that stuff look like it maps to checkboxes or radios? No way! It's real world being rejected for not matching our mental schemas. Checking a box is a one-step action and that's really great for usability, while entering text is not. It can be seen as a free-form solution that doesn't automatically seem exciting.
00:09:32.200
Nevertheless, that form field can deliver striking user benefits. MetaFilter has had a text field for gender for over a decade. Initially, there were programmers who shuddered at the thought, but they soon jumped on board because it allowed users to express themselves fully and authentically. That text field grew into a beloved institution at MetaFilter. What users put into that field reveals something about them. The freedom to input anything or nothing says something about what MetaFilter is meant to be.
00:10:32.120
The schema's trust in users was the foundation for users to start asking, "MetaFilter, can we please share more?" Now, MetaFilter's users are trusted with many free-form fields, including ones most developers would instinctively constrain or thoroughly validate. Even nonsensical values are fine, and field values can blatantly contradict each other without objection. The message is, "Hey user, this is your profile. Put whatever you want in it. Make it comfortable, make it personal, make it messy if you want to. Because we as developers can handle it."
00:11:30.320
It's easy to get into the habit of structuring data for easy analysis, but we need to step back and wallow in the user's perspective for a moment because data does not have to be for analysis; it can be for sheer expressiveness. It can have character, individualism, and distinctiveness. Diaspora is a project that many in this room are familiar with. A couple of years ago, Diaspora turned gender into a text field. Just like on MetaFilter, users had fun.
00:12:14.080
However, on the other hand, developers did not enjoy this change. One major complaint raised was about the effect on the internationalization of gendered pronouns. Here's what I have to say about that—it's a rabbit hole, and it gets messy hell quick. When you deal with internationalization, it comes with a level of complexity that English hasn't wrapped its head around.
00:12:48.320
Grammatical gender and what you and I would call gender are completely independent of each other. You're not going to be able to extrapolate, so internationalization based on gender is going to cause significant issues. If it's a requirement, then the best way to cope is to straight up ask. Here's Randall Munroe from XKCD who has examined this problem thoroughly in relation to English language projects. He found that asking straight up, "Which pronouns do you prefer?" is truly the best approach.
00:13:17.040
While this matrix may look a bit crazy, it gets so much worse in any other language. If you insist, there are some Ruby gems you can check out, though I refuse to recommend them. One of them, Sex Machine, uses a database of first names from countries worldwide and tries to predict a name's gender based on associated probabilities. But it’s still just a guess, and many would be offended if you called them by the wrong pronoun, especially if you could have gotten it right easily.
00:14:19.440
The second gem is l18n inflector, which uses Rails inflector. This operates more like a whitelist—essentially allowing you to pick out words that should be detected in a gender field and mapping them to male or female, based on your judgment. However, this method is likely to fail miserably.
00:15:11.760
As developers, we have this vision of what a good code base should be: structured, orderly, and predictable. That's why we love relational databases, with their easily grabbable and sortable qualities. We want lists to be neat and exhaustive so we can provide nice, clean analytics. But when we try to do this with personal identity data, we end up doing tons of code, validations, and throwing exceptions because people don't fit our assumptions.
00:16:05.960
Then we have to deal with all these conditionals and partials to meet conditions, resulting in tons of code for premature optimization. We won't be able to keep up because cultures vary so much in how they use these labels, and whether they exist at all is highly subjective. It's a moving target; many of these labels were not even popularly known just 5, 10, or 20 years ago.
00:16:52.920
We're never going to stop making lists, which means all our decisions are going to be based on false premises. As engineers, we instinctively recoil from not structuring data for easy analysis. This feels wrong, and I truly understand—it's unsettling. But again, the foundational question is: what benefit will the users notice? This is not about serving our interests.
00:17:47.160
If necessary, we can find a middle ground in cases where an auto-suggest feature can help. If it's necessary to get some kind of structure, we can try minimalist suggestions rather than offering every possible value we have in the database. For instance, for gender, you could suggest two values that you think are interesting. As soon as someone types something that doesn't match, it becomes completely free form. Structured data will still be there if needed, making this a balanced solution when you’re willing to tolerate some ambiguity.
00:18:38.360
Of course, there are trade-offs to consider: data quantity may be lower since people often opt out of providing personal information, but data quality will likely improve when users can choose when to share and when not to share. This has been proven by MetaFilter's experience—despite the fact that people can enter anything, 40% of users choose to provide nice, simple structured data.
00:19:32.520
It's fine to mix and match these solutions to find what’s right for your app, your users, and your business objectives. Facebook, for example, makes relationship status completely optional, but it's coercive for those who choose to opt in—they have to set a value. In fact, most users do opt in, with 60% selecting some relationship status.
00:20:01.520
So the bottom line is that we want everyone to feel excited about what we build. We want users to feel passionate about their involvement and, of course, we want analytics, monetization, and all of that to be based on sound premises. Collecting data through coercive approaches carries risks—some people may lie because lying has become a requirement to get past barriers.
00:20:50.520
Conclusions drawn from this bad data misdirect our decision-making for the next stage of development. Restrictive options might not have to be marked as required. However, the way we set up schema often embeds assumptions that we should, and will. A field that's not allowed to be null is essentially destined to become mandatory.
00:21:37.560
And if you have a short value set, such as indicating only male or female, this implies that transgender identities aren't reasonable values. People who identify as transgender will likely be coerced into giving an inauthentic response due to the very first line of the schema.
00:22:13.560
This moment showcases how easy it is to solve this issue. It lays a foundation for a completely different user experience. Notice the ninja move here: doing absolutely nothing. You can create flexible fields upfront, optimizing for storage and indexing later.
00:22:39.040
Ultimately, a discretionary field allows the user to decide whether to respond or not. As developers, we may consider this somewhat redundant; however, making it explicit that null is allowed communicates intent and documents a product decision that can be revisited later.
00:23:15.840
Here are the key takeaways I hope you’ll have today: First, modeling the real world is complex, and it’s going to be okay. Second, assuming we know who users are surrenders our opportunity to learn who they really are. Early constraints in the schema met with misleading data, so keep constraints out of the user schema at first.
00:23:52.760
Gather enough initial responses for some raw data mining and watch that data for a while to spot trends. Right now, we're being pushed from behind. This should not become mere innovation; rather, we should adapt to what’s happening, anticipating rather than waiting for users to express frustration.
00:24:37.240
Finally, freeform does not have to harm us. Data quality improves when our lies are optional, not required. We don’t have to be dishonest, and this yields specific data that reveals undetectable patterns when the data is generic. We want users to feel trust toward us because that fosters their engagement, passion, and loyalty—all foundations for a great user experience.
00:25:07.080
Any questions?
00:25:15.360
(Audience member) I think this is a really interesting topic. I was curious; there are a lot of ad-driven revenue models, like Google and Facebook. How do aspects like this play into the demographics used by advertisers?
00:25:56.040
(Karina) Well, I'm not sure. If NBC wants to advertise a show targeting 18 to 49-year-old males and the database options are limited, it could pose an issue. But MetaFilter is financed purely by Google ads and has never run analysis on gender data—despite users showing curiosity back in 2010. Clearly, Google ads don’t seem to care, which suggests it might not matter.
00:26:39.560
(Audience member) Given that many users are gender normative, would it be worth using simple checkboxes instead of text fields for a better user experience?
00:27:45.840
(Karina) I agree that these trade-offs are necessary based on your user set's and your app's needs. The ambiguity in this information must be tolerated to provide users with authentic experiences. If you handle this upfront, it's less polarizing and allows for richer interaction.
00:28:11.680
(Another audience member) In dating apps, users often seek gender-specific matches. If many users have gender normative expectations, how would you handle a freeform input for gender seeking functions?
00:29:46.720
(Karina) Using auto-suggest can be very helpful here. Users who don’t fit into gender normative categories often appreciate the ability to find matches reflecting their individuality. This provides an opportunity to enhance the experience for everyone.
00:30:19.360
(Audience member who made Diaspora's change) I can attest to the user base’s positive reception of introducing a text field for gender. Even users fitting the gender normative categories appreciated the ability to customize their input. They felt empowered to express themselves freely, which enriches the overall user experience.
00:31:00.520
Thank you all for the engaging discussion. Let's grab lunch and perhaps continue this conversation.
