So hi, my name is Joe Masti. This is bringing UX to your code. These are my various things you can find me around.

What I do as a day job, I help companies to build awesome internal education programs. Basically try to keep your employees happy and doing things. That has nothing to do with this talk, but I figured you should know what I do. I've been working at Rails for five years. So about five years ago, I got sick of consulting, and I ended up joining a company,

and I felt a little too qualified for the back-end job, even though I actually come from a back-end history. And so I applied for a UI job. No real history in UI. And they gave it to me. It's cool. I just want to reinforce that I'm coming not from a designer perspective. I'm not a UX designer.

I'm not a UX developer. My heart really lays way closer to the metal. Our show of hands, who here is like a UI front-end person? Small number of people. You can raise both hands if you're super UI. Who's like really back-end type of person?

That's the majority of you. That's awesome because you are actually the target of this talk. So when I joined this company as a UI developer, I got a bunch of materials, you know, obviously learning Rails, a new framework.

Also gave me a couple books to read, and one of the books was by this guy, Don Norman. This guy started the user-centered design movement. He released a book in the mid-1980s called The Design of Everyday Things. Anybody read this book? Yeah, surprisingly good number of hands. So it's like maybe like quarter-ish.

If you've read this book, you know that you learn a lot about doors in this book. I'm not the only one who thinks this. Actually on Wikipedia when I was looking things up, it's authoritatively about doors. But it's actually a really cool book.

What it teaches you is that this door, if you look at it, the handles are totally identical on both sides, right? And so they had to put a push label on there because everybody kept getting it wrong. And I have this thing, and I'm assuming that you probably do too, where you've been doing this your entire life and you assume that you're really stupid. And the book taught me that you're not really stupid. It's not your fault that that door sucks. It's actually the guy who designed the door.

So that was a really important lesson for me. And if you take nothing else away from this talk, you can take away that somebody in the mid-1980s told you that it was not your fault that doors suck. So there's that. But there's a lot of other good stuff in the book.

There are a lot of great lessons about usability. It changes a lot about the way that I do software, but mostly in the context of doing websites. This is the first result that came up when I searched for really hard to use websites. Apparently only like 20% of this is clickable, and you can't tell which 20% and the rest of it like moves around.

It's pretty bad. But as soon as we switch over to code, there's really no mention of this usability stuff. This is not something that we pay attention to as back-end developers. And I think that I know why that this is.

Yeah. I've been doing this a while. I've been an engineer for a fair amount of time, and I believe in how wonderful and exceptional we are, and clearly we're saving the world. But I've noticed in that time that there are two things that we really tend to ignore as engineers. Anything that was invented a long time ago, where that's a sliding scale.

Those of you who are fairly young, this is probably like, you know, like five years ago, seven years ago. And then things were invented by non-engineers. We pretty much just remake everyone else's fields. And so

designers, like this usability stuff is designer stuff. It's not like engineer stuff. This was, I Googled a designer stereotype, and this was like the nicest thing that I found. And this guy is not one of us, right? Like he seems, he's definitely not an engineer. And he seems like he was probably invented a long time ago. And so,

and when you, and when you read the book, he's talking about, you know, it's literally, it's long enough ago that he's talking about like doing spreadsheets on like a green and black screen, and he's talking about all these, you know, like faucets and things. And so I think we tend to dismiss that experience, and to prefer the things that we kind of just come up with on the spot, because

we're engineers, and you know, we can, we can invent stuff. And I think we're missing out. And this is my contention, is that the decades of work that they've done in usability has given them, them, us,

has given them a vocabulary that they can use to describe these concepts. And this vocabulary is very rich, and it helps us to think about these concepts. There's a big power in having these words, and having these things defined. And I think that our code is an interface.

We may feel like the code itself is some like magical, majestical thing, but the words that you write are really almost tangential to what the computer executes, right? The words that you write are there for you. The computer has to translate them to do anything. And so I think that these principles actually do apply,

and I want to take a look at them. I'm done ranting. It's all happy from here on out. And so let's try it. I want to talk about a couple of the principles in Don Norman's book, and I want to talk about how they can apply to code. So first, Gulf of Execution. In the book, The Design of Everyday Things, he talks about the Gulf of Execution, and the Gulf of Evaluation.

Gulf of Execution, in a nutshell, is a way of describing what we do when we have an intention, and we want to actually act on it. And in short, the part that's most interesting is, is there any action that corresponds to my intentions? When you have a door, you look for a handle, right?

So think about this in a code perspective. Let's say hypothetically that I am new to Rails, as some of us have been in the past. And let's say that I have an active record model, and let's say that I wish to remove it from a database, right? I don't know the action for this, and so I'm going to look.

Because I have done a couple of Ruby tutorials, I am very clever. I am going to take a look at the methods, and I'm going to sort them. I'm going to see if there's an action that corresponds to what I want to do. This is less than successful. I did put a red box on it, if you can see that far.

And so obviously I have no idea what I want to do. And so I get clever, though, because again, I have taken the tutorial, and so I am going to grep, and so I will find the method I want. But what do I grep? Don Orman's contention is that the model that is in my head is the one that I'm going to use to try to find

an action. And so in my head, as somebody who has done the web before, HTTP verb, delete, SQL statement, delete, arrays, delete, delete, delete, delete. Obviously, I do delete. And so I get the method. Yay, right? Awesome? All good? Yeah, fantastic. No problems.

Only, except clearly, that's not right. For those of you who have done Rails a little bit longer, you know that delete, despite being the thing that clearly I would find, causes data inconsistency in my model. Fantastic. Destroy is the thing that I want. But destroy doesn't map really naturally to any convention that I'm aware of. And so

for those, I can't see whether there are Rails core committers in here that I'm offending, there's a good reason why there's a destroy and a delete, and it's bullshit. Because every new person as they come to the framework gets confused in the exact same way. And we didn't have to name the thing delete, right?

We could have named it any number of things. We could have named it destroy without callbacks. But so by putting this thing in the way, of course, now I get tricked. Problems. Gulf of evaluation. Once I've taken an action, I perceive feedback from the system, and I want to see if I've succeeded the action. Did it work?

So in our code, this is actually, is reasonably straightforward. Everything in Ruby has a return type, right? And so you have to give feedback. And so if you're giving even some like minimal amount of thought to what kind of feedback you give, this should be pretty straightforward.

And delete, it kind of does something reasonable, right? Like I don't think this is an unreasonable return type for delete. It didn't throw an error. It didn't return falsy or nil or, you know, anything like that. So it's probably reasonable. It also happens to be virtually identical. There is actually a difference between the two of them. But it's almost identical to destroy. And so in one sense, we did give good feedback, interestingly.

Like it succeeded in deleting. And in another sense, it failed to warn me entirely that I've corrupted my data model. This is less than optimal. Right? It gets even worse when your code's not in an execution context. This, if you do

return types, if you think about other things like destroy all, this is actually a useful return type. I don't think that that would work for destroy or delete, but it's useful to know this kind of thing. In a non-code context, have any of you done this before? First of all, do you see why this is a problem?

All of my new people, when they learn they have this problem. We declare private, and then we start to declare static methods. This does not work. There is no return or anything on that private modifier, and so there's really no indication that you have done anything wrong. The way that they typically catch this is either in code review, or if they run like RuboCop, it'll tell you that you've got useless private statements in here.

And so with the Gulf of evaluation, the question is, how can I provide feedback such that I can catch this kind of mistake? I'm gonna tell you, I don't have a great answer for this one. I, you know, maybe you throw a warning.

I'm not really sure precisely how you fix this, but we should be aware in these places where we create a system that leads somebody down a path where they have no way to evaluate their success as to whether they've succeeded. So another one, natural mappings. This one's cool. The explanation for it is so cool. I'm not even gonna like use an analogy.

Stove top, right? Everyone has stove top. It's got four dials on the bottom. They're laid out in a row, and so if you want to turn on one of the dials, you read it, and you decide which one it is, and you turn it on. Not a big deal, right? What if we do this instead?

The labels aren't even necessary anymore, and is it a huge difference? No, I have turned on my stove top like 90% correctly since the beginning of time, and it's the confusing one, not this one. But these things add up, and if you think about that in a code context, how much time and effort

it takes to add up to get these mappings right. When they're a little bit wrong, and you knock the person out of their flow, when they have to go look it up, when it does unexpected things, it becomes really evident how important getting these mappings right are. So what does that look like in code? Because we don't have you know, there's no ovens, there's no dials.

So I think Array and Ruby is a really cool example. If you didn't know how to sort an array in Ruby, you'd probably guess .sort, right? If you didn't know how to get the first element, you might guess .first. If you want to delete something, which you know, back to delete, you kind of guess the delete, and then it works. It just kind of works the right way, and I think that that's a really cool example of an API where it

really doesn't pull you out to think about it, because all these things are mapped to the ideas in your head. A counter example, I screw this up every single time. Every, twice in a row, it doesn't matter. I screw it up every time, because these two ideas have kind of like jumped on top of each other, and the one that

I want when I want to update my software is very clearly, unfortunately, not the update one. So this is, it's a mess. Again, I'm not entirely sure what you do about this one, but I think maybe we need to think about how we can define other words, how we can take advantage of not

overloading these meanings. This is another really good one. These are in the file class in Ruby, in the standard library. These are all the path-related methods. There's two interesting things here. One, this is a mess. There's no, there's no like mental mapping for the majority of this. The difference between like path-real-path, real-dir-path,

big mess. As a counter example, really interestingly, if you've used Unix for a while, the idea of relative path and absolute path very much are natural mappings. And so absolute path can be natural for some people, can be for some context, isn't for others.

So all this stuff is very, very situational, which makes it difficult to design for everyone, so not sure what to do with that. Design for errors. I don't know about you, for me, if I'm coding for say eight hours, about five of them, my software's broken.

Software's screwed up all the time, all the time. And so we need to design in such a way that we can recover from that, and that we don't get pissed off by that. This is my daughter. Her name is Lane. She is 10. She's learning JavaScript.

And so maybe a month ago, I'm in the kitchen making dinner, and she's off on my computer programming. I start to hear annoyed noises. You can tell when a kid starts to get frustrated, like, you know, first she goes, right, and then a couple seconds later she goes, and so, you know, and she's kind of like building up this amount of anger.

And so I finally say, what's wrong? And she says, it doesn't work. We're working on bug reports with her. It's, you know, not a very clear report. I say, okay, what does it say? It says, undefined is not a function. Right?

This sucks. It doesn't tell you where it is. It's really like, what does that even mean? It's, in JavaScript, even better, like, it's like, forget it. I'm just going to stop executing. It's like, not only am I not going to tell you anything, I'm going to stop doing everything else I was doing, you know, take my toys and go home. And especially in JavaScript,

we have this, you know, spooky nulls at a distance kind of thing. I don't know what the name of this term is, but, you know, we're like, the thing that became null was, was three methods ago, but you never quite got around to throwing an error. And so she has this issue where she's futzing around with the code where it says, oh, it's on line 17, it's on line 17. No, it's not on line 17.

It's in some other place entirely. We can do better than that. Undefined is not a function, is, is lazy. It's easy to write that response, but it's lazy, and so the people, the, the 10-year-old child, has an impossible time with it. One more from Don Norman.

Exploit the power of constraint. I love this one. It's basically, if it's the right thing to do, make it very easy. If it's the wrong thing to do, make it very hard. I saw somebody tweeting like literally 20 minutes ago that people just blame the library, but I think that there's still a lot of space in this

to support it. So make it hard to do the wrong way. I, I am not a heathen. I don't use MySQL anymore, but when I did, this was the coolest flag in the world. MySQL dash dash, I am a dummy. It means that you cannot run, like, delete from users, period. You have to add a, like, where, you know, ID equals two. It would refuse to do these things for you,

and I set this up as my default because like many people, I once fucked up the production database, and so I thought that it was very important to not do that again on account of wanting to be employed, and so this is a wonderful thing because once this is in place, it's very hard to do the wrong thing.

Ruby, is this console in production, development, or test? Yes. Right? And so if you leave a console open, as I often do, and

you come back to it, and you have many windows, as most of you do, you don't really know what this is, and so when you start doing user last, and you like hop back into this thing, and you're doing debug statements, this is how you delete production data. Fantastic.

And you may be thinking to yourself, like, oh no, I would never do that. That would be dumb. And I have to ask you, have you ever programmed while really tired? Have you ever programmed while really angry? Or even better, have you ever programmed while really drunk? Yes.

This is the thing that happens, and it's just as easy as, you know, falling off a wall. I don't even know what the, there's an idiom there I don't remember. It's really easy to do. It's terrible to do to your users. I saw this quote yesterday. It's like a retweet of a retweet of a retweet. You can write code that drunk children would understand.

Now, what I learned is that Sandy Metz condones children drinking, and I just want to, I want to go on record that I don't support that. That is illegal and immoral. But we should be writing code that is, that works when you are compromised and

distracted and everything's on fire, and you have to remember that your user, in this case, the user of your code is probably always compromised in this way. So I was thinking about these things. This was, this was a couple years ago, and like everyone else, I incorporated some of this, but I certainly still don't consider myself a usability expert, but I came up on

this blog post by this lady, Whitney Hess. This blog post is called, So you want to be a user experience designer, and no, I don't. So, it was a failed blog title, but there are a lot of cool principles in there. So whereas Don Norman is writing from the 1980s to me here,

this is a lot more recent. There are some really cool articulable rules, and again I just want to walk through some of them and kind of illustrate how that can help us out. So grouping related objects. Objects that are close to each other have an implied relationship.

And when I read this, my very first thought was, if any of you have read Abdi Grimm, Confident Code, hands? I want to make you keep doing hands. Oh, we should do it by like, applause. Let's do it by applause. Who's read? That's great. It is a great book, and at the very beginning there's this like mind-blowing. It's like in the preface,

it's not even part of the book, and he looks at this code. This is actually from the talk of the same name that he did, and this code, it doesn't, don't stress too much about reading it. The idea is, is that the code is doing a lot of different things, and because they're interspersed, you have to keep changing contexts, and you have to keep going back and trying to understand what happened in the previous one, and

it's very difficult to understand as a result. This is the same thing reorganized. This was like mind-blowing. I don't know if your mind is not blown by this. This is a big deal for me. By rearranging it in this way,

it's very easy to understand, because the entire beginning is all about gathering input, and so they are all next to each other. You are thinking about gathering input when you're reading this code. There is none of it hiding at the bottom that forces you to backtrack. The relationship of these objects is clear, and it's being exploited in a way that is really good for the user who has to read this code.

Be consistent. These are not in order. I'm going to jump back and forth. If we have gulp.upcase, what do you get? Big gulp. I thought I was going to get two chuckles. You do big gulp.upcase, what do you get? You get big gulp.

You do gulp.upcase, bang. You get big gulp. What do you get when you do big gulp.upcase, bang? Somebody knows. Clearly, like, it should definitely be the same thing. No.

No, it's not. This is ridiculous. Again, there is probably a really good reason for this. I don't care. It is bullshit. People are using this code, and this is super surprising, and remember that when they use this code, it doesn't look, you can't inspect it for those title case. It's going to come from the user,

which means you have one of these bugs where, you know, one in 10,000 users ends up having an issue, right? You catch your test. No problem, right? No. Because when you write a test about this sort of thing, you don't write a test that does nothing. None of us think about writing a test that asserts that an uppercase word is still uppercased.

It feels like a waste of a test, and so of course you have this test. Test passes. No problem. That inconsistency is poisonous. There's one from Rails. Production, production, Dashie production. Same thing.

There is probably a reason why it's Dashie. I do not care, because I get it wrong every time, and the software should be working for me. Use emotion. Coolest emoji I could find. So this is an important one that was really obvious after I thought about it,

but wasn't really obvious up front. We have an emotional relationship with the software we use, and I'm not just talking about when you use Mac or, you know, whatever. I'm talking about when you integrate pieces of software, when you write code, you have an emotional relationship to that software. I'll approve it.

I'm going to say a word. I'm going to put it up on the screen, and I want you to make a noise that corresponds to your feelings about that software, and so it's like a yay or a boo. All right, this is an easy one. Rails. We're at RailsConf. Whoo! Really good. They're quiet over there. They're emotionless robots. It's all right. You can catch up.

Soap! This is the best for me. Adequate record. Fantastic. CoffeeScript? Great, right? So we totally have an emotional relationship with this stuff, and it's great because

even in Ruby, this is something that we acknowledge because we have a language that was designed explicitly for developer happiness. This is something you should keep in mind when you develop your code is that when you work with code that is joyful, when you have, this is this library that just colorizes the dots on your RSpec tests.

The entire library colorizes your dots. It's this fabulous test, and you know what? I feel really good every time I have fabulous tests, and that makes a significant difference in my day. Warmth and kindness makes software a pleasure to use. This is important stuff, and when you do that, people will want to use your library.

They will want to kill you less. It's an important thing. Void Jargon. Another quiz. It's very audience participation. I was assuming you'd be asleep by now. By show of hands, no snickering, do you have CSRF's enabled on your app?

Cool. Who doesn't know? Okay. Same question. Do you use protect from forgery on your app? It's the same thing. The people who built this feature are wise enough to realize that when you're implementing your app,

to say something like protect CSRF on action would not work. This is not a an acronym that is known widely, and it's not something that you want to try to retrieve or Google, and so people will just not do it. Protect from forgery. Fantastic. It's non-jargoning. I know what it's doing, and so of course I try to apply it to everything.

It's an important distinction that the CSRF library would not be as successful without this lack of jargon. Ajax. Counterpoint. With Ajax, I think maybe it's okay to use jargon. I think that this is probably prolific enough that that's acceptable. So it's very context dependent.

Some things you can expect them to know, some things you can't. The last one, signposts and queues. Straightforward enough. Where'd you come from? Where'd you go? So when we look at this,

what can I do next with this object? If you think that the documentation is a sufficient way to tell me what to do with this object, fuck you, it's lazy thinking. When you think that you can design software poorly, but point me towards a web page somewhere

that's hopefully up-to-date on how to use this thing, you're causing me those paper cuts. You remember the oven and the natural mapping, right? When I have to read, it slows me down. When you send me to the docks, it slows me down. This does not point me towards anything that I can do, and so it's not okay.

This is an interesting one. I can kind of tell what the method is doing, but if I want to look it up, I'm not going to be able to look it up. I can't Google find by email and first name, right? And if I want to put a different parameter in there, I have to start to think about, well, can I put it before? Can I put it afterward? Is there an or?

How does that work? The newer syntax for this, way better. If I want to look up dot fine on active record, it's actually relatively simple. By being able to say email and last name, it's very easy for me to tell what this thing does. One last example, Aaron Patterson, a couple months ago, he was talking about RSpec, and I thought this was a really neat example.

If you have this code, again, don't fret too much about reading it. If you run a spec and it fails, it tells you how to rerun the spec. You can paste this command into your terminal again, and it'll run just the failed test. How cool is that? So it points you towards what you need to do next, which is rerun your one test.

It's very easy to see where you came from, very easy to see what you do next. So what do you get if you invest all the time to learn these things? So you get less suffering. There's this wonderful quote in that blog post, the world is filled with anguish. Let's not add to it. This speaks to me as somebody who's worked on production code bases. I'm not sure she wasn't writing about us because this

encapsulates my entire experience of developing, and so we should be not contributing to that anguish. And also, in this one, I'm not sure about it, but I'm thinking about it, and it seems to make more and more sense the more I think about it. I think that if you believe in self-documenting code and ferries,

I think that this is a mechanism for self-documenting code. And I'm not contending that if you do this right that you don't have to write any documentation whatsoever. What I'm contending is that self-documenting code is not about code. It is about the people who perceive it.

And so when we use these techniques, people will understand our code, the cognitive burden is lower, and I think that this is what we mean when we're talking about self-documenting code, code that humans can understand. And so as a last request, I'm just going to say please go out, the blog post is literally like 2,000 words long. Take a look at it. Think about what you do with your code.

If you maintain a library, think about how people perceive that library and what those stumbling blocks are. All right? Design of Everyday Things, amazing book. I recommend it to everybody. That's all I got.