 I'm actually really excited about this talk. This is something that is gonna make my life easier because I'm dealing with these issues myself. So our speaker is Karina Zona. She's a San Franciscan. She has been a Ruby developer for five to six years. She does a lot of work with Rails Bridge and Women Who Code. And she's also a sex educator with Svissi. What's the full name of Svissi? San Francisco Sex Information. Okay, and they're a nationally known sex information phone line and service. And she's gonna be speaking to us about schemas for the real world. So thank you, Karina. Thank you, Josh. Well, hello. As Josh noted, I am both a developer and a sex educator. And I think a lot of these do things overlap. XKCD, by the way, of course. Research, culture change, and self-reflection have stirred an increasing range of labels that people are ascribing to their important relationships, their sexual orientation, to gender. And social apps in particular now are being pressed to adjust. Imagine walking through the world, knowing that everyone's first assumptions about how you see yourself, who you love, 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. You'll feel defeated. You'll want to argue that whatever they think they're learning from you, that it's not really true. You'll 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, great part of you. So users are giving us pushback to ill-fitting assumptions. And if you feel out of depth in dealing with these issues, well, you're not the only one. 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? I mean, we got stuff here, like open relationship. Users disagreed. They disagreed strongly. So under pressure, Facebook had to nearly double the options in just two years' time. And when Google Plus launched last year, it largely adopted that list, although for some reason they left out separated and divorced. So we still don't know what's a canonical list here. Notice that they also added something else. Choice, the right to opt out of being labeled at all. Allowing users to identify their relationships with labels of greater personal significance. This was being driven by people rejecting a user experience that wasn't working for them. It's not about monetization. Facebook doesn't even care. They're not even providing the option to advertisers. We're dealing with three core problems. First, there's a premise that deeply personal stuff about humans can be reduced to lists. Second, the assumption that canonical lists for these things do and must exist. Or at least surely that we can create them, right? And the third problem is our faith that the first two can be easily solved just by adding more list items. And this is not gonna work. And worst yet is that it makes you look like a dumb ass. This is what happens when we try to throw more labels at the problem instead of examining the assumptions in the database schema. An open relationship is definitionally a one to many join, okay? With the usual understanding as an engineer about what that means, that the actual number of relationships could be zero or one or many. But this is Facebook failing at modeling relationships in a relational database. The schema forces the user to choose. Either get to look evasive or be inauthentic. And it's not just for relationship statuses and it's not just for people in open relationships. They're being made to feel like they're not real or don't exist or have to lie. And 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 gonna be solved that way, that the foundation itself was wrong. Relational databases just 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 then? We start at schema. As developers, we're being tugged in two directions. Keep that code base manageable, right? And get designed for modern complexity. We can build a foundation for great UX and same development. Let's look at what the approaches are. First, we had to get schemas into alignment and I said schema's plural. That's because we have two different types. We have mental schema. That's an individual set of preconceived ideas, a framework for representing some kind of aspect of the world. And it's our personal system for organizing information, especially new information as it comes in and trying to fit it into that existing schema. And then we have database schemas which are essentially the same thing. It's just a mental schema translated into blueprints for a database. When you use Rails Generate Scaffold or Rails Generate Model, it's creating a migration, right? Well, maybe you created something like this one. Those migrations ultimately get translated into a unified schema to be used by the environment's database. So what you're looking at, all this UX, this is just manifestations of mental schemas. Our schemas and our UX are leaving people behind and we can fix it. And we start with a question. What benefit will the user notice? When developing a schema that's going to ask a person about their experiences, their feelings, their sense of self and identity, there just isn't gonna be a single right way that I can tell you to solve this. But what we can do is evaluate the trade-offs and ask what benefit will the user notice? That's not equivalent to how will the user benefit. Okay, that's a question that grants us a lot of latitude to just assume that whatever we wanna do, it's gonna be to their benefit, right? Because it's just making a product that's awesome and that'll work for them. Evaluating from the user's perspective is how we keep focus. So I've got this lovely little chart here. The problem is that there's absolutely no point on it where everyone is gonna see maximum benefit. All we can do is really look at choices and try to work out the trade-offs. So first off, let's agree that it really feels shitty to be told, no, you are wrong about who you are. Checkboxes, radio buttons, select menus, they're all implying that they're all possible values can be represented. So the message is, hey, user, just pick up the right ones and everything will be fine. But think back to those opening slides that I showed you. Does that stuff look like it maps to checkboxes or radios? No fucking way. It's real world being rejected because it doesn't happen to look like our mental schemas. Checking a box is a one-step action and that's really great for the usability. Entering a text string is not and so that's a free form solution such as a text area or a text field that we don't automatically see is exciting. Nevertheless, that form field can deliver striking user benefit to users. A metafilter gender has been a text field for over a decade and initially there were programmers there who just shuddered at the thought. I know you are too. And that was for about five seconds and then they jumped on board because you know what, you could be creative and you could be silly. And because they could express this thing about themselves fully with authentic voice, that text field grew into a beloved institution at Metafilter. And what you as a user now put into that field is saying something revealing about you. What you're allowed to put in and that you're allowed to put in anything or nothing says something revealing about what Metafilter is meant to be for. That schemas trust in users was the foundation for the users to start asking Metafilter, can we please, please share more? And so today Metafilter's users are trust with many free form fields, including ones most developers would instinctually constrain, pardon me, or thoroughly validate. So even unsensical values are fine. Hell yeah, just go for that. And field values can blatantly contradict each other too. And there's no objection to that either because the message here 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. And it's easy to get into that habit of structuring data for easy analysis. We're gonna need to just step back, wallow in the user's perspective for a minute because data does not have to be for analysis. It can be for sheer expressiveness. It can have character and individualism and distinctiveness. Diaspora is a project that many in this room are familiar with. Couple of years ago, diaspora's Sarah May turned gender into a text field too. And just like on Metafilter, the users had fun. On the other hand, this time developers did not. One of the major complaints that was raised was the effect on internationalization of gendered pronouns. And here's what I have to say about that. It's a rat hole. It gets hella messy. It does it hella fast when you deal with internationalization. It's a plan that comes with a level of complexity that English just hasn't wrapped its head around. In a level, sorry, in a lot of non-English languages, again, XKCD, grammatical gender and what you and I would call gender, they're just completely independent of each other. You're not gonna be able to extrapolate. So internationalization based on gender is gonna screw you over so bad. So you wanna think about ways to avoid dealing with gendered pronouns altogether, not how to cope with them. If it's a requirement, then the best way to cope is to straight up ask. So here's Ryan O'Monro, who is XKCD and he's examined this problem pretty thoroughly a number of times just in relation to English language projects. And he found that asking straight up which pronouns do you prefer was truly the best thing he could possibly come up with. And you know, this looks a little crazy already. This matrix gets so much worse in pretty much any other language. You don't wanna go there. If you insist there are some Ruby gems that you can check out, I refuse to recommend them. The first one, Sex Machine, is using essentially a database of first names from countries around the world and it's trying to predict for you based on a name you feed it how likely that name is to be male or female. Especially if you hand it off a country, it can be a little more accurate in its predictions. But it's still just giving you a guess and probability factor. I think most people, well I don't know about most people. There's plenty of people in the world who'd be pretty offended if you called them by the wrong pronoun. Especially if you could've just gotten it right really, really easily. So I don't know that there's any amount of wrong in a gem that's gonna be okay. And the other one we have here is L18N inflector. And this is using Rails inflector and this is using something more like a whitelist. Essentially you can pick out words that you think should be detected in a gender field and map them to male or female in your opinion. This is gonna fail even bigger. So as developers we've got this vision of what a good code base should and should not be. What we want, we want things to be structured and orderly and predictable. And that's why we love stuff like relational. And we got indexes so it's all really easily grabbable and sortable. And we think that we can make lists that are neat and exhaustive. And we wanna do it right because we wanna be able to do things like nice easy clean analytics. And why do we do that? Because we wanna be able to make good decisions. But what we get when we try to do this with personal identity data is we have to start doing tons of code. We've gotta do validations of what we think human beings are like. And then we're throwing exceptions because they're not. And then you gotta deal with all these conditionals and partials for meeting each of these conditions. So you've got all this code you're throwing at it and you're trying to do premature and optimization. And you're never ever gonna get exhausted because cultures vary so much in how they use these labels or even whether they have some of these labels. And it's all individual perspective anyway. You really are not gonna be able to assign this stuff to people. And of course it's a moving target. So many of these labels were not popularly known and some of them didn't even exist. Say five, 10, 20, 40 years ago. We're never gonna stop making lists. So all of our decisions are really gonna be based on completely false premises anyway. As engineers, we've got this instinct. We're uncomfortable. We wanna step away from this. To deliberately not structure data for easy analysis just feels so wrong. And I feel you cause I really, really get freaked out by that idea. But again, that foundational question is what benefit will the users notice? This isn't about serving our interests. And if necessary, we can strike some middle ground. This is where a guided response comes in, auto suggest. And if it's really necessary to get some sort of structure out of it, we can try just doing minimalist suggests rather than every possible value that we've got in the database. Safe or gender, you can suggest the two values that you think are interesting or the four or the seven, whatever it is. And as soon as I start typing something that doesn't match that, then it becomes completely a free form. But you're still getting some data. So the structure data is gonna be there if you want it. And this can be a really balanced solution in cases where you're willing to tolerate some ambiguity. And of course, there's trade-offs on that. The data quantity is definitely lower. People, once they're freed to opt out of providing personal information, of course some of them do. On the other hand, I think that data quality is gonna improve when people get to be honest and get to choose when they share and when they don't. And that's really proven by meta filters experience. Despite that fact that people can put in anything they want, other people who do put in something, 40% of them do choose really nice, simple structure data that we can use. So it's fine to mix and match from some of these solutions to find the one that's right for your app and your users and your business objectives. So Facebook, for instance, they make relationship status completely optional, but it's also coercive to those who do opt in. They have to set a value. And most actually, most, pardon me, most users do opt in. 60% of them select some relationship status. So the bottom line is that we do want everyone to feel excited about what we build. We want users to feel passionate about their involvement with what we build. And of course we want the analytics, the investors, monetization. We want all of that to be based on sound premises. But the data that's being collected by coercive approaches, the risk is that it's all bullshit. Some people are lying, because lying has been made a requirement for getting past our barriers. Because conclusions drawn from that bad data misdirect our decision making about the next stage of development. So restrictive options, that stuff I showed you in the bottom left, those don't actually have to be marked required. That's not what the meaning of this is. But the way we do set up schema often embeds assumptions anyway that we should and we will, so we do. A field that's not allowed to be null is pretty much destined to be mandatory. And a field that sets a really short value like this, a short length, is asserting that any reasonable value is gonna be under that length. So this migration is implying, you're gonna be either male or female. Transgender definitely is not a reasonable value in this context. And if you're transgender, you're gonna wind up being coerced into a response that's inauthentic. And that's all being set with the very first line, with the schema itself. So boom, this is how easy this is to solve that. This is a foundation for a whole different user experience. And notice what the cool ninja move here is doing absolutely nothing. I love that. You can make this stuff flexible up front. You can optimize for storage and indexes later. Just decide what's valid later. All that code later. So there you have what a discretionary field is. It's when a value can be optional, where the user is left to decide whether to respond at all. And as developers, we may look upon something like this as really obviously redundant, and that's unnecessary, right? But making this explicit that null is allowed is a communication to the team and to your future self. It's a statement of intent. It's documenting a product decision. This is something to refer back to later. So here are the takeaways that I hope you're gonna have today. First, that modeling the real world is complex, and it's gonna be okay. Two, assuming that we know who users are, is surrounding our opportunity to learn who they are. Early constraints in the schema, net crappy, misleading data. So keep constraints out of the user schema, at least at first. You can go there in a while if the data justifies it, but gather enough initial responses that you can do some just like raw data mining, and watch that data for a while. See what happens. Keep an eye out for emergent trends. Right now, we're being pushed from behind. This is not innovation. This, this can be innovation, where we get there first and adapt to what's actually happening instead of waiting for users to be irate. Let's find out what discoveries that we can make. And third, preform is not gonna kill us. We really can't handle this. Data quality improves when our lives are merely optional, not required. We don't have to be false. And it gives us data that's rich and specific so that we can unearth patterns that were undetectable when the data was generic and pre-provided. We get to discover, we get to adapt. When we show trust in people, they get to feel good about placing trust in us in return. And their response to all that is engagement, passion, loyalty, all the stuff we want out of them. Those are foundations for great user experience. Any questions? Nice cupcakes. Okay, so questions, hand up high. I think this is a really interesting topic. I was curious, the thing running through my head during the presentation is there's a lot of ad-driven revenue business models, especially like Google and Facebook. I was wondering how something like this might play into the demographics used by advertisers and if you've given any thought to that. Could you be a little more specific for me? I wanna make sure I'm answering the right question. Well, like if NBC wants to advertise a show targeting 18 to 49 year old males and the things in the database are like fella and dangly bits, I was just wondering how maybe that plays out if there's any way to kind of get close enough to what the advertiser's looking for. I can't speak to that specifically but I can tell you that Metafilter is financed purely by Google ads and since there is no gender information, in fact Metafilter doesn't even run any analysis on it. The first time, and only time they did was in 2010 and it was purely because users were kind of curious. So they just like spat out the values. They weren't even running any sort of analysis on that. But clearly Google advertising doesn't care enough. So it doesn't seem like it has to be an issue. And we could really be educating clients as well that you have the potential to learn who else is in this audience and you can start to address niches. Yeah. So not to diminish people who don't follow the particular category but say for the case of a check box versus a text field. Would you say that, well arguably that it's a worse user experience for the majority of people to have a text field versus having a simple check box or radio box? And I guess the question is like, at that point is it worth it to do that? To me that's the question. I agree. I agree. Like I said, these are all trade-offs that have to be out of your user sets needs and your apps needs and what you're willing to tolerate. I mean like I said, there's a lot of ambiguity. You have to be willing to tolerate in this stuff in order to get this kind of information and get this kind of experience. And there's absolutely no way to make everyone happy. In fact, you will get some people really polarized over this. But this earlier you do it, the less polarizing it is. Metafilter did this right from the start and it wasn't a problem. Diaspora went from a select to a text field. And so they had a lot more pushback because people were used to doing it a different way and they had built a lot of code around the assumption that it would always be that way. Sarah, I saw your hand. Somebody get her a bike. Oh wait, someone here. So you seem to be advocating this for all sorts of demographic data. Personal identity data, which isn't necessarily all demographic. But go ahead. Well, there seems to be some legal requirements that might be in conflict with this and is personal identity data not part of the advertising category model? I have to answer any question about how advertisers do their stuff with I don't know, that's not my field. What legal requirement were you thinking of? The only one I'm aware of is age where you have to be over 13 or else you're not supposed to let them into the site. But that isn't the kind of stuff that I'm asking. There's also ways you can do that if necessary, like a checkbox saying I am over 13 instead of actually collecting their birth date. But I don't know enough of the details of law to say whether that's considered acceptable. Was there a question you wanted me to get over here? Oh, I saw Sarah raising her hand and now she's waving her hand. I'll get you in a moment, Sarah. So I've worked in the dating space a bit, which comes up with a user-driven reason for narrowing these down. Given that a lot of the users will be gender normative and expecting that for matching. If you do open up the gender field, how would you address sort of gender seeking questions in a dating or people matching field? Your voice was a little quiet, so I hope that I have just said all that. In the dating space where you have to deal with gender seeking, how would you address the more open input field for 90% of the users, say, expecting more gender normative answers? I think that auto suggest is really useful there and the people who are not gender normative are actually gonna be really excited to be able to search for people who sound more like them or share some of their sense of self or values. That's a real opportunity. On the seeking? Well, if you're making a free form of collecting the data and then a select of searching for it, yeah, you do have a conflict there. You really have to think about how would that work and you really need to have those line up. But maybe it is something like if you're using auto suggest, then you know it's pretty predictable that a lot of those values are gonna be male and female and you do something like having the option to select on those or do something like, say, a wild card search or being able to spit out basically a list of what the other values are and let people kind of use those as tags to do some surfing around for people who sound interesting. Okay, up here. Hi. So I'm the programmer who made the change in Diaspora to move it from a select box to a text field. And, thank you. And we did get a lot, there were a couple of questions about whether people give you a pushback and whether it's a worse user experience for people that fall into the more gender normative categories and what I can tell you from our users is that even the people that do fall into the gender normative categories feel better about being able to add something else in there, right? It's, and a lot of people who identify in the gender normative categories told me that what they loved about it was like, it doesn't matter, you can put whatever you want in there. They felt free to put whatever they felt like. And one of my friends put, Ada Lovelace is her gender, right? And I think that when you do this, you're not reducing anyone's user experience. You're enriching everybody's user experience. At least that's been the experience with the Diaspora user base. I think this time we can go get lunch. This is clearly a rich topic. Maybe we can talk to Bosco about having a meetup evening to discuss it. That would be fantastic. Okay, great. Thank you very much. Thank you.