 We're going to be talking about where UX and Dev can meet. Just to talk really briefly about what we're going to go over. We're going to introduce ourselves and talk about what kind of we're all doing here at this talk. We're going to go through the three principles that we think unite UX and Dev, understanding performance and support. We're going to talk very quickly about how to test for usability, and then we'll have some time for questions and a bunch of resources that we're going to share out. So I'm Katie Ryker. I'm a senior UX designer at the Red Hat. I'm Christopher Lee. I'm a technical manager at TripAdvisor. We're out in Needham in case you guys are curious. And we care about UX as a UX designer and a developer, but we're really interested in telling you what you care. So I'm a developer. This is a developer conference, and we talk about UX. I work on consumer product or come back in product, and we always talk about it from a consumer product standpoint, like users and end users, right? But UX goes way beyond that. And this being an open source conference, we wanted to talk about how the UX on the back end or the UX as an open source contributor is also just as important as the UX for the end user. Open source software is collaborative. There's not necessarily someone steering a ship all the time. Unless a big company like Red Hat is the one mostly sponsoring the project. So if we do a better job thinking about UX up front, we can make our open source projects better, more usable, and hopefully get more contributors and more adoption. Being here and coming to a UX talk at the Dev conference, we're actually making a couple assumptions about you. And I want to address these right up front so you guys know where we're coming from and hopefully you've got something right about you. So our first assumption is that you've got at least a basic working knowledge of development best practices. If we throw out some basic development best practices, you're not going to look at us like super confused. And if you are, we assume that you're interested enough to look it up. We're also assuming that you are people that care about your final product, you care about user experience, and you're willing to put in a little bit of extra effort to take things from bad to good or just okay to good. And we're also assuming that since you are an open source Dev conference, you are a user of and or contributor to open source projects. It takes us to introduce the two different users of open source. So the first one is the end user. Generally when people talk about user experience, they'll be really focused on this end user. Who is the person that's going to use your product, your project, your application at the end. And this is hugely widely varied. This could be anyone on earth, this could be any different set, but we can kind of generalize this down just for the point of this presentation to any user or someone who's focused on their own goals. They only care about what they're trying to do. They don't have context to any of your development choices that remain. And they're using an interface. This could be a command line interface or graphically user interface. Either way, it's an interface. And then on the other side, you have the contributor side, right? So, you know, being a Dev, it's nice because you can give back to these projects and you can see the internals, but our goals are very different. So, you know, we use a lot of open source software work. And my favorite thing about it is I can go right in the code and I can read what's happening and figure out why the performance is weird. I can figure out why a certain bug is happening. We can suggest extensions to functionality. We can fix bugs. And often we just need to know, like I said, how something works. I mean, when you're triaging, like, you know, Byzantine failures and your large microservices cluster in production and you're using some open source framework to manage all that, it's nice to be able to look at the nuts and bolts. But the quality of the code there and that sort of thing is important. So, that user experience is also something to consider. And this is what makes open source really unique. Because you have these two users, you have the end user and the contributor. And the contributor can be your end user, and very frequently is. And your end users can become contributors. You have an example of this. Yeah. So, TripAdvisor, you know, we use a lot of open source software but we're not publishing our server code out for open source because you don't even want to see it. It's not actually usable. But I have worked, you know, in my spare time on open source projects and one is Mail on the Box. And Mail on the Box is one bash-stripped solution for running a mail server full stack configured for, you know, relatively good security. And I used it for a couple of years and then it was stuck because it was pinned to Ubuntu 14.04. It was a reaching end of life and the maintainers were like, we're busy people, we don't have time to do this. This isn't a full-time job. So, I got to become a contributor and I got to open a port request. And I went and did all the things, like working on the forex kernels with Ubuntu 18.08 or whatever it is. And then that was great. I got accepted and a month later, you know, I was able to use the software without having to do a bunch of hacks to make it work. It's supposed to be just, you know, one-stop-shop. So, you can, you know, a lot of people get in that journey. They start off as a user of open source software and end user and then they find themselves contributing. And that's why I want to keep UX in mind, even on the Dev side, because these roles are very fluid and people can be from one to the other. And we need to give UX for both. You actually have the meat of our presentation here and what you came here to talk about, which is good development and good UX and how they overlap. So, yeah, I mean, if you're a developer, you might be familiar with Code Complete by Steve McConnell. It's like 10 years out of date at this point. I don't know if they're going to make a new version. There's a whole bunch of good Dev practices up here. I mean, a lot of buzzwords, testable, consistent, reusable, separation of concerns, lots of things to consider when writing good code. There's so many most practices there, too. None of which could be really boiled down to just one word like a lot of Dev ones do, so maybe we need a better book. But there's quite a few things. But what you see in common of these is a couple of principles. That is understanding performance and support. And if you have these three things and you keep them in mind, this will help you make a better UX for the end user or the developer. How about each of these separately? I'm going to start with understanding. So understanding how we're defining it here is the implicit and explicit information the user gets in context of their workflow. So when they're actively doing something, they don't have to go anywhere else. This is the information they get just from the actual workflow. It is a command line. We're putting together this presentation. We're at a developer conference. What never really gets talked about, that would be command line UX. We've made a big effort to do a lot of these examples. But I'm going to go ahead and say that I primarily am a user interface designer when I work with stuff. So anything command line, if I'm wrong, just keep it to yourself. Unless it's really bad. You could be right. Job script, package manager, download. It's good because it's all normal English words. You probably know how to spell. But this is really long. You're going to have to remember how all this was. So let's say it's going to make it shorter. We can shorten it to this. JS package manager, downloader. Which is a pretty legitimate way of shortening things. But how on earth are you going to remember which letters are in, which letters are out, what's the exact shortening you want to do. So in this particular example, this could be shortened and rewritten in a very much more simple way. Which is this. How much easier to remember makes sense to an actual human brain. It's descriptive of what you're doing without having to have a lot of words. And this is where keeping it simple is really important. And that also leads into the most important thing to remember that if you take one thing out of this presentation, we think you should take this. Which is you want everything to work the same as it does for other places. Which means people don't spend most of their time in their application. They spend most of their time in other applications, on other websites, doing other things. So the more consistent you can be with their overall knowledge and experience, the better you're going to be. And this is called Jacob's principle. And this is Jacob with the best forehead I've ever seen in my life. So I really had to include his photo. But I think the principle doesn't necessarily need any. So Puppet actually did a bunch of work in figuring out what commands to use in this question. And I'm not going to try to explain this question because I don't think it actually matters for what we're going to do, but your result will be created. What they did is they took a bunch of Puppet users. I think they took over 90 users and asked them, what would you expect the command to be? And they did come out with one and they generally kind of had like 40% here, 40% here and then 20% on a different one. And out of the three that they proposed, Puppet status and Puppet infrastructure status were their most popular. Puppet status because it's simple, short and Puppet infrastructure status because it's specific. They did not like Puppet enterprise status, which was made up by their team and no one ever used. It's not something that people use in other applications. It was calling an actually Puppet infrastructure status where in-breath is an alias for infrastructure so you could just do both. And this is great because it's specific, it's shorter and it's clear. So that was a lot of talking by Katie. So let's get back to me. We're looking at some code. And in this case I wanted to talk about using readable code over clever code. So I had a great example actually of code that's horrible. That uses streams that really shouldn't use streams. Hopefully you guys are familiar with streams. It's just functional syntax and Java. And I lifted this from some guy who was like, modified it a little bit. But you can see here, look it's doing stuff and it's functional and I love Scala and I love Kotlin and it's great. But if you come into my code base and you start doing this, then you're going to get another job because this is the worst. So we can see, I can't really tell what it's doing. But look, we've actually just got two for loops and we're done. It's all it's doing, there's no streams. And some of you might say, oh, well who really cares? You know, I don't understand that. Everybody in my company understands it well. When you have a problem with production in a web server, the top one is the stack trace you get for that function and the bottom one is the stack trace you get for the two for loops. Now again, you're like, oh it says divide by zero, it has the location, no big deal. Well, and that's strapped in the patchy and coyote stack traces and there's nested lambdas and all this other stuff. You're going to really wish that you'd done it the simple way. Use the constructs appropriately. Use them to extend functionality to make things easier. Don't just use syntactic sugar. So that's an example of like keeping good UX practices on the dev side. Someone comes in your code base, it's easier to understand. It's easier to fix bugs. That's going to improve your end user experience. It's going to make it easier for you to like solve problems that users are reporting in real time to stop losing money, stop bleeding. And that's really valuable at crunch time. So let's get into our second riff fall, which is performance. So performance is the actual and perceived speed of your application. It's a little bit of both. Because what people notice really hold up. What people notice is when the computer is coming back slower than you expected to. So there is this another principle don't mind me, the dirty threshold. Which means that when computer and user interact under 400 milliseconds people perceive that is pretty decent. Now this was set in the 70s. So even though I don't have a new number I'm going to assume that people are expecting faster responses now. And this ties into how fast people expect things to work what they're actually interacting. So this is latency that people can actually notice. So when you click if there is a latency of more than 34 milliseconds people will notice. When you type around 100 milliseconds where people are dragging some UI around the screen people will notice latencies as low as 2 milliseconds. And this is what that's surprising. Humans evolve to interact with a physical world where you can pick something up and it picks up immediately not a couple milliseconds later. This performance is so crucial because if you are showing if you're doing speeds that are more than this your users are going to perceive this as slow. Even if it is, you know, 70 milliseconds. So how do you deal with this? So a couple ways you can deal with this one is to avoid complicated UI elements things that will really bog down your code. If you don't need a lot of stuff why put it at the key to very simple. You really clearly communicate wait times whenever a user needs to wait on something make sure they know what's happening. The other thing you can do if you are set up for it is to use an optimistic UI pattern. So optimistic UI is basically pretending that things have gone through faster than they have so you can do the processing of the scenes. So here on the left we have non-optimistic UI where someone is typing out hello world and sending and then it processes and then posts. And you see this seems really slow. There's a big gap, you're not allowed to move on, you're kind of blocked versus on the right someone writes hello world and it gets posted right away. But the processing is just happening behind the scenes. So the processing time on both of these is identical but one of them feels a lot snappier and is much higher perceived performance. So yeah her example actually is a great example of how we talk about client side performance and time interaction and contentful first paint and all these other terms that we can use from metrics but performing back ends actually matter a lot and her example, I wish we could go back but this is Linux and when you hit the back button it doesn't actually work. The thing is just posting a string and storing in a database somewhere. So all of that time is just network latency hopefully network latency from you to the back end server which you can obviously optimize using CDNs or other edge upload pipelines like Amazon has one now but it could also be inter say you're in a colo or you're in a cloud somewhere if you're not configuring your services properly it could be latency between those services, it could be a very overloaded database that's taking a long time to return. If you want to have applications snappiness if you want to have people be like man this thing really works focus on the client side you do have to have performance back end and you have to have them configured properly. So yeah another aspect of user experience is sort of the DevOps experience right and that's something got super buzzwordy like I don't know two or three years ago it's still pretty buzzwordy now but for your developers you can talk about how we get so much productivity out of microservices right it's so easy to pull requests and deploying all those things well if your build takes a long time or your CI pipeline takes a long time then it's not actually that fast because you're running these things for every commit and this is actually a problem we have we have a huge legacy code base this giant Gradle build dot Gradle is all over the place and takes a long time to build and we have up until recently we weren't really doing much to improve that build time and it was killing us from a productivity perspective when you consider like 500 developers waiting 15 minutes for like a full build so focus on it devote resources to it it might not be full bottom line it might not be it's always going to be a cost center but in my opinion it's one of the things that you can use to accelerate your development process and it's going to be the better code too because people aren't going to want to take shortcuts they're not going to want to do things to try to bypass the normal workflows and you're going to result in a more performing bug free application plus your contributors will like you look to our last principle which is support so support is the explicit details about how something works and this can be in a lot of ways so just as a random assortment of things that could classify a support there's your tool tips in your UI that people will hover over or click over and get more information and use your health documentation on the contributor side and figuring out your bugs writing good comments writing good commit notes documenting your command line your face with health also that can be part of your support is utilizing frameworks and tools that already have a lot of support so if you something establish that has a big community that has a lot of support that's less that you personally have to do or your project has to do and the same with growing a community of users and another way you can really communicate support is through product and security updates communicating those and producing those I want to talk about because you know I have a principle for all of these is knowledge bias so as a person who designs or builds or works on something or is engaged with it in any sort of deep way you have far more domain knowledge than your user and you cannot help that because you look in the code you thought about how it's going to work you're really in and that means you're really prone to design things that make sense to you but are not clear to others missing information stuff that's very implied in your head but like is not implied to the rest of the world and this is incredibly human and normal to do so you're going to fix this with one addressing your assumptions you see that we did that at the top of our presentation we talked about what we're assuming about you and assuming about your knowledge so we could better construct this talk to account for what we're assuming about you and the other thing you can do to really combat knowledge bias is to give a lot more information than you think you need to don't assume people know anything just give a lot of information and if you're writing documentation try not to skip any steps that seem obvious but instead say them explicitly and one way that you can really improve the experience for people right away is to write really good error messages like these ones right? so these are awful error messages they're being they're not really connected to anything they're very developer focused but not actually that useful to developers either so how do you write a good one? so a good error message has a couple things in common it's clear, it's concise it's specific it's relevant to whatever the user is doing at that moment it tells them how to solve the problem and just as a psychology thing for more positive and say don't you say do and stay away from really negative words and people respond better to that so let's take actually one of the examples that I grabbed a moment ago and I took it from the really great screenshot into just like the pattern fly styles which if you're more interested in more fly there's a big bell sign and you see here that it's got a really bad error error message how do you state I mean anyone know what that means right there well awesome because it took me actually a long time to figure out what it meant when I was trying to clear it up and what I did was I rewrote this error message to be more specific state is a required field and also tell the user what they can do to fix it which is choose a state and search again I also highlighted the state with a red border that's a little thicker so you can see it even if you're colorblind to really pull out that error and this is a lot better we can actually go one step further in this design to make it better and that is to prevent them from making the mistake in the first place so by moving the field underneath when you read people read top to bottom left to right so things that are over not in the flow of how you're reading are easy to miss so by moving state right underneath we're not only providing more context about the error but we're making it a little bit easier for people to not make that error in the future I also added required asterisk stars which go an awful long way in communicating what users need to do so it's not just the client side though so the examples that Katie put out for error messages are garbage and they're not just garbage to clients as she said they're also garbage to devs if I saw something something value state in the log file and that was the error message I saw and it was something that somebody wrote out of the box web driver gs so until and unless there is Selenium in it it won't open the browser and manipulate the DOM does that answer your question? okay any other questions? yeah I do functionality testing on the set dashboard so methodically for code coverage standpoint how would you be calculating anything of that sort see code coverage with frontend test is a tricky thing so there is one tool called jacoco java code coverage so there is a plugin which you put in your repo and then you run your frontend test so based on which path you are taking while running your frontend test it gives you some sort of code coverage but that's not something to be very that's not something which is very reliable and promising to be honest so code coverage thing is mostly done on the unit test or an integration test level alright then thank you everyone and just to let you know that these both is app as well as these libraries so if anyone of you is using reactor chosen I know most of the redhead apps use reactor as well as chosen the redhead customer portal uses chosen drop downs so if you are using any of these so these things are on github feel free to use them I'll probably paste this link in my presentation for you to check alright thank you it's dealing with the actual wizard so I don't know if you guys are familiar with this movie it's kind of indie but you've got a wizard of odds he's just a normal guy but he is totally a smoke machine and it looks awesome and it looks like everything works but it doesn't and this method of testing is called wizard of odds testing because what you're doing essentially is you're pretending it works by instead of coding it up so the computer will respond to different commands different interactions you just have a person sitting there in a different room copy pasting your results in so let me show you a quick demo that I put together just to play co-share and it starts off with users typing in what does this work you brought up a great point about keeping the design consistent for behavior not introducing new stuff that users are unfamiliar with so how do you balance that with trying to come up with new ideas and being innovative in the user interface and things like that mine's pretty bad do you want to speak it to? is that better? yeah okay so we brought up a great point earlier about keeping the user interface and UX components familiar so that users don't have to think about what they're doing how do we balance that with trying to introduce new ideas and being innovative when you're working with an existing code base that has a lot of smart people contributing to it how do you strike the balance of not commenting every line of code for new or junior engineers coming in to understand it versus not commenting every line of code basically I'm interested in your guys take let's say you have an existing code base and you bring on a designer to help with something and what the designer is suggesting is brilliant and that's what you should do obviously but the code base maybe isn't up to the task like maybe it's architected in such a way that what the designer is asking to do is impossible yes literally my whole life so I managed a consumer product team and I also managed a platform so the consumer product team and yeah the designers come in and they're like it's better now because the browsers are mostly here in the standards but imagine six years ago when they weren't the vectors and we wanted to do CSS animations we wanted to do stuff that's like sorry these sort of things that's just not going to happen so rather than going to your designer being like straight out of no you know patients and then your corporate product goes a long way and also they can really value their company let them challenge you you know we you know sometimes it doesn't make sense to strike there we just decided to support 96 forever and we're just going to not embrace these technologies and we wouldn't be trying to do this like the influence thing now that's all that stuff it's great it enables all the school interaction and all the school data that we can do for but we would have never got there if the designers had pushed us on the design side it's like people like you know treated the designer and maintained the experience and you know just two weeks ago designers specified a CSS animation and they were going to use the link to save on your site there's about a million Chrome and CPU went up to 45% of the browser well on the machine and it was a lot of money we decided to do a GIF instead we got the designer what they wanted we got what we wanted this personally as a designer sometimes I'll ask back but I don't have all of the background because the person who's answering for me knows that and they assume I know that and this is where giving more information than you think is necessary can really help get you to a better place because it can also help your collaboration so that's a great example of that if you do what I meant by the thing went to 45% CPU and you also do that it's not all of you it's actually not a lot of you so that's a great example of like domain knowledge right if your designer is probably also don't know why that's been you have to over explain it you have to make it clear that everything's going to come to the grinding halt if they're running anything else in the computer that's valuable contextual information thing to hear comments about knowledge bias and that's don't assume that people won't do things that are obvious to you not to do in technical writing and support and I've repeatedly sat in meetings and said what about this the key developer says well no one would think to do that and six months later someone on the forum has done exactly that so don't assume that because you know not to do it everyone else knows not to do it could you talk a little bit about the effort I know at Red Hat we are trying to make all of our apps look and feel the same across the different apps across different domains it seems like a difficult problem and we're certainly still struggling with it could you just talk a little bit about how these like UX studies inform across different products even Red Hat we have a design system called Patternfly that is an open source design system you may have heard me mention a moment ago and that's helping us make things consistent because we're doing a lot of research on how people actually expect all these inputs to work and then keeping it consistent across our apps and our entire app portfolio so the way that the UX studies work