 I've never actually done the presentation with my notes on the phone before, so I apologize if things get a little hairy. So just by show of hands, just so I understand my audience here. How many here raise your hand if you feel comfortable, like you understand what UX is, you understand what UX people do all day? Okay, good. Okay. And then I want to know how many of you have a concern about privacy online? Like, okay, good. And how many of you would like more designers in your open source project or a project that you're following and you're not really sure how to get more designers? Okay, cool. All right, so you're going to probably like this talk. It'll hopefully be interesting and useful for you. So my name is Maureen Duffy. I've been around open source as a user since I was in high school, which I'll vaguely say was around the year 2000. And I started contributing as a college student, so it's been a while. And I have come to open source from the perspective of design, which is maybe hopefully like these days is increasing, but traditionally maybe wasn't how people approached open source. And I work in the products and technologies group at Red Hat as a designer. So I just want to tell you a little bit about what I do. Okay, so one of the things that might be a little bit embarrassing about being a designer who works in open source is something that people will say is, you know, open source, it's bad UX. Why are you doing a bad job? This is sort of like the elephant in the room anytime we talk about UX and open source. Hold on, this is in sync here. So I don't want this to be a gloom and doom talk and talk about how bad UX is in open source or anything like that. There's a lot of positive actionable things that anybody could do to improve the UX of open source. There's things that are happening right now, so I don't want you leaving here depressed. I also will be talking about why I think fundamentally open source has a bigger potential for a good user experience than proprietary software just by the nature of open source software. So we'll go into that. So let's step back a little bit. Why is it so important that open source not have a bad UX? So, sorry, I'm just trying to get it in sync here. Okay, so we can talk about IRC. How many people in here use IRC? Okay, how many people in here use Slack? Okay, you guys see kind of the similarities between the two, right? So, in 1988, the first IRC server and client were written in Finland by Djarko Okunren. And by 1989, the next year, there were 40 servers worldwide. Actually, I have a handy dandy timeline here. Okay, and then in 1993, there was an RFC that described the basic protocol. By about 2005, by several different accounts, is about when IRC's population peaked. Daily active users at that point across all the major IRC networks was about half a million people. Then, you know, Slack came along. And within two years, so Slack came along in 2013, within two years, Slack had a million daily users. And why did this happen, right? Like IRC was there at the start. It was an open standard. It was an open protocol. The software to run it was open. Why did it sort of stagnate and then they came in? A lot changed about technology in this period, okay? Like, one of the things, you know, if you remember the 90s, if you're alive then, not everybody had a computer. If you had one computer per user, you were pretty lucky. Today, this is a computer, that's a computer. I mean, everybody has multiple devices. IRC wasn't built for that world. IRC assumed a different environment people were operating in. And it became good enough, right? We sort of just kept using it and never went back and revised it. I'll also point out that this is an issue with email, too, right? IMAP has issues. And what's happened is proprietary companies have just put extensions on that, not in an open way, and now we're kind of stuck in this place where big proprietary email provider are going on your own and there's dragons. Okay, so this is a lot of lost potential. Again? Sorry. Okay, I just lost it. But this is a lot of lost potential because, you know, we had a nice beginning there. We had a nice open system. And then a proprietary company kind of swooped in and ate our lunch, right? I'm just trying to figure out why this isn't going. This is like hell for a speaker, right? Okay, well, I'll try to wing it without my nose. So this is lost potential. And I want to talk a little bit about... I saw an evolution in software, maybe you've seen it, too, where things started in sort of government and academia, right? There was a lot of sharing between different organizations. We used open standards. And there was a bit of a shift probably around the dot-com boom, maybe, where proprietary companies kind of came on the Internet and things changed a little bit. These days, you know, as Chris and Sarah said in the keynote session that just finished up, open source has won, right? So now we have companies that are proprietary companies trying to get into open source, but it's a little bit of a different flavor than the early days. So this is sort of like my plot summary of a proprietary company today getting into open source, right? Oh, well, that's the next slide. This is how it happens sometimes. It's like another startup. They take some open source technology. They make that technology shiny and convenient. Slack makes IRC shiny and convenient, but there's no open standard and gone in a few months. And gone can mean the company is gone, or it can mean, you know, they're not the new thing that everybody's using anymore, you know, like social media, Friendster, MySpace, Orchid, which I don't think anybody really ever used, and then Facebook. You know, there's trends and things just kind of fall out of favor. This is moxup.com, which no longer exists. This is one of those systems that it was sort of like a cool thing people were using on the UX designer, and it was aimed at UX designers that would let you manage mock-ups on this, you know, website. And actually two weeks after I signed up for it, they announced that they were closing up, and, you know, oh, you can download your files, except your files are in a format that you needed this proprietary app to use. So once they went out of business, what were you going to do with that data? I don't really know. But it was one of those things where, you know, thank goodness I didn't rely on this tool because what am I going to do? There's a lot of tools these days. I won't mention names, but they've gone cloud, which means you don't actually have the software in your physical system, nor do you have your actual data or files. So if you don't keep up with your subscription or if something happens to that company, you could lose a lot of work. This, in terms of longevity, it's not pretty. This is sort of a snippet of a screenshot from Red Hat's internal mail server. It runs Mailman. This is an open-source system. I can get company emails from July 1998 in two or three clicks. Mailman 2, yep. But, you know, there's an advantage here, right? Like, this is what digital transformation was supposed to give us. If we could go back to 1998 and read conversations or, you know, since today we have, you know, AI and ML are so accessible, I could maybe go to, say, the company mailing list where everybody kind of has flamemores on a routine basis and do some ML to figure out what are these cycles? Because, you know, these cycles, it always comes back around people arguing about, I don't know, throughout a Red Hat reference paper towels or, you know, proprietary software. Why are we using this? You could sort of trace back. But the thing is the data is there and it's all in one place. It's easily accessible. It's in an open format. Even if this Mailman server went away, all of this is available in plain text tar balls. It's glorious, right? This is what moving to digital is supposed to give you. But, you know, the problem is when the platforms you rely on turn over so quickly, every two or three years, there's some new thing, you know, maybe right now it's Slack. I hear Slack is falling out of favor and people are going to other things. I mean, how can you rely on that as a repository for your data when you know it's going to go out of style in three years and you're going to have to switch again? So this is where, this is sort of how I like to classify these companies kind of coming in and saying, all right, we want to hop aboard the open source chain. Our API is open, right? But your API also is controlled by you. I don't know if anybody here has written an application, relied on a specific API call, and then suddenly, you know, they decided, oh, we're going to drop that call from the next version and it's a cloud, you know, piece of software, so it's not like you could even stay on the old version that had the call you needed. Suddenly you're in firefighting mode. Oh my god, my app is going to break as soon as they turn off this API method. Ah, is anybody even in that situation? Yeah, not fun. Our client is free software, but the server isn't free software, so just because the client is free doesn't mean I have ownership of my data that's sitting on your server. We use free software and we contribute back. Just not this software. I think towards the end of the discussion that we just had during the keynote session, you know, that kind of came out a little bit. There's a lot of big companies that, you know, well, you know, it's just not this software is open source, but we contribute back. It is really important that companies contribute back to open source. That is most obviously welcome and a good thing. But, you know, if it's an important critical thing that people rely on, right, is that a good user experience that you're relying on a piece of software and then any time, like, you know, they go away or they're doing things to your data that maybe aren't okay, that's not a good user experience. So, yeah, and some of these things, these four bullet points here, this is sort of the fundamental reason why I think all other things even, open source versus proprietary software, open source has a better potential of providing a good user experience because we don't have to do these things. We're not beholden to shareholders. Like, okay, if we work for a company, we are. But the open source community as a mass of people, irrespective of what individual companies, individuals might work for, there's no profit motive. Like Chris said in the session before this, like, there's no deadline, a requirement of delivering something by specific date. That's not something that the open source community necessarily has in mind. So, for these proprietary companies developing the software, they can hold your data, they can control your data, they can hold it indefinitely. If they go away, your data can go away, there's no one to answer to you. They can do all sorts of things with your data, sell it to other people, harvest it for information, use it to sell advertisements to you. And that goes into the surveilling users, right? They can monitor and analyze your activity. They can look at, oh, well what time of day do you typically log into my system? How long does your session last? And they can, based on just that information, make some pretty big, you know, revelations about your behavior as a human being in the world, which maybe is not okay for them to do. Stealing users' time and attention and selling it for profit. What are the things that you spend the most time looking at? What are the things you click on? All right, I'm going to turn that into an ad and sell stuff to you. The other thing, and I'll talk about this a little bit later, but there's this thing called dark patterns in user experience. I don't frequently and pretty much never see UX design in open source using dark patterns to make users do things like, you know, how can I design the software so it's addictive so I can keep your eyes on it so you spend more time on it so you click on things intentionally in it. Those don't really, I mean, I'm not going to say they don't exist at all in open source, but they're not common in open source. Whereas in proprietary software, I could rattle off a list of 12 things right now and I'm sure you could too. It's software that's addictive that tries to keep your eyes glued to it, that tries to make you click on certain things to go certain places that isn't in your best interest as a user and then could go out of business or get bought any time. I think I belabored that point already. Okay, so let's talk about purpose, right? So this is what makes open source and proprietary software just different fundamentally and it's not necessarily bad, right? It's not bad to want to make money. You need to be sustainable, right? You can't just rely on people having the privilege of having time and resources to work on open source software for free. So that's, you know, that aside, there's sort of different drives behind these two different types of developing software. And open source I see is more like the academic model. I don't know if anybody else kind of thought about it in that way, but it's more you're building on each other's work, you're sharing in the open, and it's for the greater good. You're developing software to help people. Because of the free license, that's sort of a platform through which you can enable that collaboration. You allow it to be customizable so that people with different scenarios can tweak it so it meets their needs. You know, try doing that on, say, Facebook. So I just want to see things my family are posting in the timeline order that they posted it, not in some random order where that one post that, you know, Aunt Sally made about Donald Trump shows up over and over and over, like they're beating me in the head with it, right? Like you could customize it if it was open source. And then versus the profit mode, where there's a, because you're trying to make money, there's this natural, you know, thought towards we need to keep this closed for a while just to see if we have secret sauce that we can make money from, or, you know, it's more one size fits all. You're at the mercy of whoever's developing that software. You can't go customize it for your own needs. Benefits few is, I mean, the main drive, especially if it's a publicly traded company, is your shareholders, right? It's not when you develop proprietary software, you might be thinking about, I want to make the world a better place, who doesn't? But it's not at the same level as when you're developing open source code. Okay. So I'm going to go into some UX issues that tend to be specific to open source. I'll go through this quickly because most, you're all open source users in here. You're at dev comp, so, you know, I'm not going to belabor points that you probably already know. Consistency is one of the critical things. It's easy to get right if you're a company that's a proprietary software company because you have control across a suite of tools your company develops. You have control over decisions that, across different open source communities, it's harder to get in cadence with each other. So this example shows you in the front is Inkscape and the back is GIMP. These two tools are sort of amazingly in sync in that they at least both use the same toolkit, which, you know, not all the creative tools in open source actually do, but just simple things like the main selector tool that you use to click on things on Canvas. The icons are different. They're in different colors. They're in different positions. This is an easy fix. This is not difficult to do. The difficulty in this is getting people on track, getting them to agree, well, what should that icon be? Well, where should it be? What should it actually do? What should the keyboard shortcut be? We don't tend to do that final level of fit and finish in open source tools. Integration, and this is sort of part of the same conversation thread here. When you have different tools that work together as part of a larger workflow, proprietary companies tend to get that better. They tend to do that well. Whereas open source tools, I mean, again, they're not always talking at a level where that's really possible. 3D printing is something in open source that you could kind of see where this has evolved. In the early days, there were different tools that did very specific functions that you had to sort of link together. Now there's tools that exist and are being worked on that make it one consistent workflow, but traditionally it was kind of hairy. Okay, UX debt. This is sort of an email on a mailing list in the Fedora community that people refer to a lot, but this is sort of... The chain of logic from Linux is about choice to ship everything and let the user choose how they want their sound to not work. It starts with fallacy and ends with disaster. The job of a UX designer, the job of designing UX for software is making those choices for the user. It's kind of like if you've ever faced, say, moving or maybe a relative is downsizing and they have all this clutter and they kind of just, hey, do you want a bicycle or hey, do you want another twin size bed or hey, here's like a whole pile of comforters that you want. You're cluttering their interface. The hard thing to do is to figure out, well, should I really throw out these perfectly good comforters? I'm never going to use them, but I feel bad throwing them out. That's a hard decision, right? My house is pretty cluttered. I don't know if any of you guys here have a cluttered house and have trouble making this decision, but it's hard. So is it really nice for the developer to pass that kind of hard decision-making onto the user? Because at least the developer is making that decision. It's made once clean, nice, right? But when you're passing it on to your users, you're kind of multiplying the ickiness of having to make that decision by the number of users you have. That's not good, right? It's not right. You really need to make those hard decisions so the user isn't faced with them because every little decision like that, you know what I mean? I just want to walk into my children's toy room and not trip over stuff, right? But now, since there's stuff everywhere, I have to make the decision, okay, well, which toy should I throw out and which toy should I put away, whatever? If somebody had, say, put those toys away for me, I could just walk in the room and do what I meant to do, which is open the window or grab something from the shelf. When you make all these decisions, when you avoid making all these decisions, you're forcing your users out of their workflow. You're distracting them from the tasks they're trying to do and instead you're sort of putting these distractions in their way that they have to deal with. So don't do that. Okay, and then itches. A lot of open source software, I think, starts with an itch to scratch where it's someone, they're coding it mainly for themselves, right? Like, they have their own need, they understand their use case, and the software perfectly suits their needs. Where this is different than proprietary software is because proprietary software is focused on, like, we want to make money, so we need people to buy it, so we need to meet a lot of people's needs. Open source has that different, I'm just doing it for myself. So that's where open source tends to maybe traditionally not have a good UX as well, is it was a very focused, singular use case, and the person developing it wasn't really thinking about, how can other people make use of this? What might they try to be doing? It's not really made for other people all the time. Okay, so what is UX? I'll go through this, I'll try to go through this pretty quickly, because it seems like you guys are pretty UX savvy in here. So what UX is not, I think it's more important to talk about than what is UX, it's not just a coat of finish on the end, right? It's not, I just built a house, everything's all done, I just need to hire the painters to just paint different colors in the rooms and the outside and make it look pretty. That is not what it is. It's not just on the surface, it's not just the walls, it's the systems of the house, it's the plumbing, although I'm mixing metaphors here because that's a plant, but you get what I'm saying. It's the plumbing, it's the electricity, it's the layout, how do rooms, one room flow into the other, how does that work? It's also a system, right? How does this house sit on the plot of land? How does it interface with the houses around it? You're building a contemporary style square house in a neighborhood of Victorians that looks a little bit different than a house that is built to look like the houses around it or even a lot of famous architects think about well how does the house relate to nature? Is it facing the rising sun or is it facing the setting sun? How is it perspective to different, you know? With software, when you're thinking about it being systemic, you're thinking about, well I have this IRC system, right? Bringing that back. Well I have people in mobile phones so when they're on their phone away from work, how are they going to access IRC messages from back at the office? That's part of the system. People have mobile computers in their pocket. That's part of the system. Or how does it interact with other systems? Say I have a friend who's on Matrix. Can I connect to them? Or am I completely barricaded from them? How compatible is this with other systems? Do the file formats, are they able to be opened in other pieces of software that a person might want to use? So UX is not something you can just paint on at the end to make things pretty. You have to be thinking about things from bottom to up. And I guess the best way to relate it to the house metaphor is say, you know, you buy a house, it's a great house, it works for you, and then you have children and you have to carry car seats and maybe that three-story, you know, brownstone walk-up house where your kitchen is in the basement and the bedrooms are on the third floor. Maybe that's not the best idea now, right? Like, the house wasn't designed for today's living if you're disabled, if you have small children, it's not the right house. You can't just paint the house blue and then make it, oh, okay, well, now I can walk up and down the stairs. Fine. You have to completely redesign the house. Maybe one floor living is better for you or maybe two floor living or maybe having an elevator or a ramp. So these are things you have to think about. You can't just paint and fix it. Okay. So the other thing that's important to know to think about maybe food for thought with UX and open source is with open source software now there's a lot of libraries and components and tools that everyone has access to because we have so many years of open source now, open source one, anybody can go out and download jQuery and use it. So jQuery as a piece of, you know, engineering is a piece of technical achievement. You can't differentiate your software based on the fact you use jQuery because anybody can use jQuery, right? So if you think about, well, if we're competing in the software marketplace where different applications have access to the same platforms, to the same components, to the same libraries, how can you stand out? And I believe design is how you can stand out. How you assemble those free components together to make a compelling use case, to make a compelling workflow for users, that's how you can make a difference. So that's, I think, design is what will bring open source to the next level. And this is sort of just a quick metaphor. You can build a bridge with the best quality concrete, you can make it 10 lanes wide, it could look beautiful designed by famous architects, so it's a piece of art. But if people don't want to go from point A to B and it connects point A to B, nobody's going to use it. If people, maybe where you built this bridge, you know, it's a 10 lane bridge, what if people don't really drive cars around there? What if they prefer to bike? What if it's a bicycle heavy environment? You don't really need 10 lanes, right? So you have to think about how people are actually going to use this thing on a daily basis, not just building it with the best technology or building it to be the most elegant, the cleanest code, the best architecture, the coolest, latest stuff. It doesn't matter if people aren't going to use it. All right, so to be able to do that, you have to understand the user's context. You have to understand, people don't go from point A to B, they actually prefer to go to point A to C. But how do you learn that? You have to observe users, you have to talk to them. So one little story I have here is, I have cute animations I'm just going to go through. Users ask for things. They might ask for what the implementation should be. I want you to do this. But you have to always make them take a step back. Why do you want that? And the story that I'd like to tell for this is internally at Red Hat, people used to be able to get static IPs, which is useful if you're working on an operating system because if you can reboot and get the same IP every time, then when you're working on something like, say, this installer system, you can always access that system, even if it reboots, even if something goes wrong, you know where that system is. They took that away from most engineers at a certain point and they put in a dynamic DNS system. And the IT department was still getting complaints. Like, no, no, we want to have the same IP. It has to be the same IP. I need a static IP and they didn't really understand it. But once they kind of got together and dug into it, they figured out, oh, you're developing the OS. Oh, you don't have access to the dynamic DNS client when the operating system isn't even installed yet, so you're not going to have that same host name and there is a possibility that your IP could be changing. Oh, okay. And then they were able to change different aspects. I don't actually remember the exact solution they worked out for this team, but they were able to change different aspects like the IP lease period. They were able to change that. I think they were... I don't know if they made exceptions for certain machines. But, I mean, the thing is, users ask for things. It can be a point of contention in open source where people are filing these bugs and they're asking for these things and they're getting upset. Sometimes it can help to just step back and figure out why, why. And that's what UX people do. We figure it out. What do they want to do? Why do they want to do it? And then we work together with the developers to figure out, well, let's solve that problem. So how do we do that? User research, figuring out what context is the user operating in. Design implementation, working with the developers and figuring out, well, what should this look like? How should it be architected? How should it work? And then validating. Similar to, you know, we do QA and code. We can do usability testing on design since the design actually solved the problems we're trying to do. Both the design process, well, the user research process and the actual design process look very similar. You start from a single question or a single problem. You gather as much data as possible. You kind of make sense of it. You can see, like, there's some clusters here. And then once you've made some sense of the data, you make a decision on what you're going to work on and then you move forward. That's how the user research works. You might talk to 20 people. You might find patterns of usage within that group of 20. Decide which block within those groups of people you want to address the problems of and then you come up with a solution. Yes. So this is, like, just a real-life example. This is a project I worked on with an intern a couple summers ago. She went out and talked to all different people in the Fedora Ambassadors Group, which is not important for the purpose of the story, but she was trying to figure out what are the problems facing this group of people, what should we be actually working on to try to make things better. And these are some of the clusters. We just went through the notes she had from talking to people. We clustered them together. This note seems like this note. Gave them categories. And then we used another tool, and there's all sorts of cool tools. I'll tell you where to find them. This tool is the many few affected versus impact. This is how many people have an issue versus how big the impact is. So the upper left corner here, the most people are affected by this issue, and it has a really severe impact. By organizing the categories into these different blocks, we're able to figure out these two things are the highest priority things we need to be working on if we want to have the biggest impact for the most number of people. And we decided budget was an issue for people, and we didn't want to focus on that for a lot of different reasons. So the things that we looked at was figuring out resource finding. That was the topic that we decided to focus on. So UX designer is someone who could come in and lead a process like this for your open source project, for your product, to figure out what should you be working on right now to make the biggest impact to help the most amount of users. And the design process is similar. You start with something, you decide from the last exercise exactly what you want to work on. You talk about that topic. You brainstorm tons of ideas. Crazy ideas. The last session we were in talked about diversity. That is what you want here. Things that sound kind of nuts. Things that sound silly. Things from people. As many people as you can think of, you can get involved from all different angles. You just want a lot of crazy different ideas here. Then you cluster the ideas in a similar way. You prioritize them, make a decision, and that's how you design it. That's what you design. So, does anybody want to go into nitty gritty of how you actually do the design work or do you want me to skip that? Raise hands if you want to hear about some nitty gritty low level design details. All right, all right. So these are just random principles that I think are useful to know about. Visual hierarchy. You would be surprised how many pieces of software fail this little test, right? What's the most important in this software versus what stands out the most visually? I'll take Facebook as a scapegoat here because I'm in that mood. Maybe it's not fair, but Facebook talks about we want to bring people together. We want people who are friends and families and community members to be interacting with each other and good times, good karma. But what stands out the most visually on Facebook? Anybody have something you want to throw out there? What stands out to you when you log into Facebook? Memes. Memes? Memes? We want to say ads. Ads? Oh, yeah. Well, if you block the ads, I would say political arguments from everything to, like, what? Cherry-picked story posts. Cherry-picked story posts, yeah. And then, like, the ones that, like, somebody comments on it and it was, like, three months old and it comes back, the zombie things coming up and, of course, they're always the most controversial and upsetting ones. Even, like, stupid things. Like, there was a big argument on a local Facebook group. People having arguments about raccoons and whether or not they could have rabies and it got very intense. So that's what stands out the most visually. That's what gets the most real estate on the screen. Think about, for any piece of software you care about or you work on right now, what is the most important thing you want users to be able to do in that piece of software? And then take a look at it. Just try to, like, squint your eyes. What has the most real estate on the screen? What stands out the most? You want those two things to be in sync. You'd be very surprised how often they are not. Ordering. This is a screenshot of Mailman 2 and it's a particular Mailman server, the Fedora Mailman server, and it's annotated. One of the things that might stand out is the ordering, right? They decided to do alphabetical and also numerical ordering by default in Mailman 2, which makes sense logically, but if you look at this, 389 Announce is the most, it's the top billing mailing list on this server. The most popular mailing list on this server is actually down here. It's not even in the screenshot. That would be Develop List. 389 Announce is an Announcement List. It's low traffic by design. It's an Announce List. So why is that the first thing people see every time they log into this system? That's like ordering. It's kind of important. So we redesigned that in Mailman 3 and the list by default are grouped by the number of conversations and the number of subscribers. So you'll see here, Develop is properly at the top of the stack. 389 Announce, in fact, no Announce List appear on this list. So just ordering. It's simple, but we don't do it right. So do it right. Progressive disclosure. This is something where, you know, I'm sure everybody has a situation where reality is it'd be nice if we had a nice, clean minimalist interface, but there's a certain group of users that have to do this thing that's complicated and I have to give them the controls to that. Well, think about it this way. Remember that grid I had up earlier where it was like number of users, severity, that kind of thing? If you have a very small population of users that needs something very much, like it's not a trivial thing, it is critical for them to be able to access the thing. Progressive disclosure is a great technique. You could think of it as like onion skinning, peeling back the layers of the onion. So the initial layer of the onion here is what applies to all users. All users, and this is an example from Nome, they get this right a lot. Every user uses a language and has a default language in the interface. Every user has to work with formats, time formats, currency, and every user has to input text. So by default, that's what every user in this dialogue sees. Now, if you're a user that has to work in a specific type of input system that requires additional configuration, then that's another... that's a smaller population, but it's very critical. If I speak a specific language and my keyboard's laid out a certain way and there's one specific formatting that I need to set so I can actually talk, like so I can write things on the computer, that's super critical. So it's just in another layer. It's just another dialogue. It's nested one deeper for those people. So you don't hit everyone in the world in the head with it, but the people who need it can access it. Curation, this is very critical too, right? So this is from the Fedora badges system. On the left was the original widget that users could display that showed all the badges they'd earned in the system. Here I see, ooh, they're colorful. There's a lot of them. That's about all I get. So I'm sure there may be some person out there somewhere who would pour over these and add them up. We did put a system in place so based on the color of the outline, it meant different things. So you could maybe tally them manually, but I don't have time for that. So curation, going through that data and making some sense of it for the user so they don't have to do all that work. Is not multiplied by the number of users, because that's a lot of effort. If you had 50 people pouring over this spending two hours figuring out this is my badge system, figuring out who I am and what I do, that's a lot of wasted time. You could watch a whole season of Breaking Bad or something in that amount of time. So here, it's just at a glance. You can look, oh, I've been awarded 84 badges. I've gotten 25% of them, right? And then you could see my most recent badge. You can see the categories. So this is a lot of community participation, but not too much development. So you could tell I'm not a developer, but I do a lot of community. I do a lot of content. A nice summary, right? Curation, it's important. Okay, and then contextual hints. The closer to the action a piece of information is, the more useful it is. You could write, and systems have done this, you could write this PDF white paper on how to choose the best, most optimal password. It could be 12 pages long. It could be cross-reference. It could be beautiful with diagrams and visualizations. The problem is I need to set my password now, and I'm not going to go download a PDF and spend 10 minutes reading it. It doesn't matter how wonderful and great it is, I'm not going to do that. I'm just going to pick God or dog or something as my password and get on with my life. So this is a great example of giving a little bit of hint. What does a good password look like right where the action is taking place, right where you're actually typing the password in. That's where it's most useful. So just think about contextual hinting. It's better than documentation. It is, and it's a form of documentation. But it's a little bit of words that are more powerful than a full document. And then different tools for different audiences. This is an example of Anaconda, which is the installer system for Fedora. On the left is a graphical-based interface that's kind of a wizard that walks you through the system. On the right is a kickstart file. If you're installing a single system, this guided interface is great. It walks you through everything. Writing out a kickstart file when you're trying to install one system is not something people want to do. But if I have to install 10,000 systems, it's great. I can repeat the same install across a number of systems. So just think about a lot of times I think conflict in design decisions and conflict in software in general comes from divergent needs. Like, how do we meet these users' needs, but also these users' needs, even though they're so different? And one way to think about it is, well, if they're so divergent, just come up with two different interfaces for them. A lot of people follow an architectural model now that you could have different clients using the same backend. It's not a problem. It used to be difficult to do that old time ago, but not anymore. So why not think about that? Consider that rather than compromising and having a design that doesn't really fully meet any user's needs. Okay, so I'll talk a little bit. Has anybody in here had experience with usability testing? Okay, so I'll talk a little bit about how it works. It sounds fancy and hard and expensive and it's not. This is all it is. You create a task list and you can do that prioritized based on what you think people should be doing with the software. If it's a mailing list software like Mailman, people want to read the mail. They want to find topics of interest to them. They want to see what people are talking about. They want to be able to send messages. They want to be able to search and find information about topics they're interested in. So you could create a task list based on that. You probably, five is a good number. And think about each one maybe taking five to ten minutes so you're not, when people are running through your test it's not taking them forever. Then you run the test. It's Yakov Nielsen who's like one of the big usability experts out there who's been writing about usability for a very long time. I think he said there was sort of a law of diminishing returns here. The optimum number of users to test just in a basic usability test is about five. That's doable. You could find five people today or here at DevConf to sit down and try your software. So it's not intimidating. And then once you get the results of the tasks, you basically watch these people go through the task list you came up with take notes on what happened, where did they get stuck, then you analyze the results. You might find, well three of the five users all hit this one problem. One person hit this one problem but nobody else did. And just based on this simple kind of analysis well everybody hit this problem so that's already. Then you could figure out what you need to work on. All these bugs incoming to your project this can help give you some guidance on how it's affecting people and what you should focus on. And this is just a picture super informal. This was an event we did here in Cambridge close to Boston called Spinach Con which is an open source usability testing sort of hack fest kind of environment. We did it at Leaper Planet. This one is from like three or four years ago they did one this past year too. Where you just show up with your task list there's willing volunteers they will run through your software and you can get usability results right there. This was the summary we had we did a mailman hyperkitty test there and you could see some of the things it's probably hard to read but we some of the things we found out is like the users like the aesthetics they wanted better tagging functionality others they just couldn't find them they didn't see them. So we got like a nice list of these are things that we can work on in the software to make it better. Usability tests are absolutely useless if you can't commit to doing anything about them because it's no good to have like this list of all the ways you suck but then having no power or no time or energy to actually fix the ways you suck. Just don't think about the ways you suck if you can't commit to that. Because there's a lot of people who say well we don't really need to get UX involvement in this project we'll just do a usability test and it'll be fine. If you don't actually do anything with the results of the usability test how is that making your software better? So how do you make this all work in a free software context? This might be a little bit of reality but I'm pretty sure if you're involved in open source free software you're going to agree with this. These are the free software users out there today. These are the people who contribute these are the people that we need using it that we haven't reached yet because the thing about it like and I know today now that open source and free software is a bit more mainstream this may be less the case but I think a lot of people are involved in open source and free software because they really believe it makes the world a better place. It helps people and we see it as like software freedom that's something people say because it's a freedom you enjoy it's a privilege and we want to extend that as much as possible. But if we kind of stick to the little echo chamber out there how are we spreading software freedom making it accessible to more people right we really need to be thinking about these folks. So to do that and this was sort of the main topic of the keynote session previous to this one we need to be inclusive we need to figure out not just how do we get more people able to use free software from all different backgrounds a diverse set of applications and abilities and identities but we also need to figure out how do we get them involved too how do we get their ideas because one of the things I talked about earlier when I talked about how do you how do you do user research how do you do design work part of it is you start with a problem and then you get as much data as you can as many ideas and you can get better ideas if you have a more diverse pool of people generating those ideas more chances you'll have some crazy awesome innovative idea that would really solve the problem I mean if you have three people who live on the same street giving suggestions about a thing it's going to be limited what ideas they could have versus three people from three different continents right I mean it's simple but people tend to dig in and like argue against this but it really is obvious to me I guess don't displace your existing users this is another one of those things that kind of can cause battles especially in open source communities where you have the old timers we'll call them that you know things work the way I like it it's always been this way we can't change things to a certain extent I don't always agree with that sentiment but absolutely it doesn't make sense to displace people like you've been using this it's been working for you for ten years why are you throwing everything out this is where you can't avoid that for example if it's a cloud based piece of software you have to upgrade it you can't just run ten different versions of your software for your cloud users just to keep everyone happy because they like the way it worked back ten years ago but again today's architectures allow us to provide different experiences on the same back end so think about that as you know something you could do as well so having different front ends I almost think of is like federating I know it's probably not the exact correct usage of the term but for example when we did hyperkitty which is the list archiver for mailman we didn't want to disrupt existing users the mail delivery system still worked if you had your mud RC configured exactly how you wanted and you didn't want anybody to pry it from your cold dead hands fine this was just a layer on top of the presentation of the same stuff so it was an online forum style way that someone could participate in a mailing list not get 100 emails in their inbox or more per day but they could still access and participate in that open source community if they use this front end system and not disturb the mud RC people at all and you have to think about I think a good analogy that I have on the slide here is city planning if you want to modernize your city you can just go in and demolish five blocks it just doesn't happen you have to figure out how to do it in a way that doesn't displace the people you have but still enables people that you want to bring in establishing boundaries I think this applies to all design not just open source design but I think it's especially true in open source because in open source we don't always necessarily have things like corporate org chart or hierarchy or professional standards but certainly it's more fluid you can't just rely on professional norms of a particular company to guide how people behave so one of the ways that you can kind of set up a framework for productive interactions a conversation when you're talking about design in an open source context is sort of setting out at the start who's the decision maker what's the thing we're talking about where are the boundaries so then if somebody kind of steps out of line maybe they're not even intending to they're just really passionate and they're kind of ranting because they want to be helpful but they don't realize how upsetting it is you can kind of point back to those guidelines you can point back to that framework you set up well today we're talking about this I get that you're passionate about that we'll talk about that another time and you can kind of keep the conversation going and kind of break up that stop energy the open decision framework which is something I will say is put out by my employer Red Hat is a really good methodology and that came out of Flame Wars internally about different corporate decisions you know oh man we didn't think about this oh we didn't talk to these people oh how could we avoid doing this in the future they came up with this great it's Creative Commons licensed I believe framework that anybody can use it's just a nice way to set the stage to lay out the table so that people are productive and getting stuck in raffles oh also game storming this is something I mentioned earlier there's all these little games and like techniques that you can use when you're going through all this data and you're going through all this feedback that you're getting to make sense of it I love game storming it's actually a book but the website has a lot of the games and some additional ones too I do recommend getting the book but the game storming websites how can I run this meeting or how can I go through this data and be productive with it I don't even know where to start avoid conflict with transparency and this is sort of this is sort of a big guiding principle I think of the open decision framework too but a lot of times you'll find yourself in some contention because I will say designers and you know raise your hand if you've seen this too they get like a group of developers and they're working on a project and they've been working together for a while you bring a designer into the equation and it's like you brought someone in who's like pulling the tablecloth out and everything flies everywhere and it's like oh my goodness we're not going to make our deadlines and we have to rearchitect this and we have to throw this out it's the right thing to do but we don't want to do it I don't know if anybody's experienced that when decisions tend to be made that maybe not everybody agree with especially people who are like old timers who've been around for a while that they want to maintain the status quo they don't understand why you're upsetting things if you're clear and transparent from the very start as early as you can be don't just have like these closed meetings with the developers for months and then the public community gets to find out oh this decision has been made that is the way to piss people off and get people really mad if you are public and give regular updates about your decision process and why, the core why of what you're doing even if people don't agree with you if it seems like you have a good rationale if it seems like you were open and you gave ample opportunity for anybody to participate you see these kinds of things totally diffuse like the big flame war that you're waiting for never actually rains down on you so it's a good thing to think about especially for designers trying to get involved in open source it's easier to add harder to remove it's very tempting to add especially if we're in technology and we have that engineering background we want to make solutions but it's better to hold off because it is so difficult to remove them so and this is one of those things where again if you're at a company you can kind of have that top down you will remove this but in an open source community especially because the code can have a very long lifetime you want to avoid putting things in unless you're really really sure that they belong there because getting them out is going to be really difficult design culture is different so how do you relate to designers in an open source project because they're kind of coming from a different background there's a bit of a culture shock for a designer trying to get involved in an open source project and then you make things a little bit easier for them make them feel more welcome and included so this will seem very obvious right but designers focus on people their needs, their workflows what they want to do the tasks they want to achieve with your software the context in which they're performing them developers focus on the technology they're going to make decisions about what language are we using what platform are we using what we're going to use designers get some input into that and developers get some input into what designers focus on but you really need to divide the work up this way it seems obvious but I see a lot of conflicts between designers and developers that if you just go back to this it really helps there's no long tail in UX this is actually an abstracted version of the kernel who contributes to the kernel report that he puts out every year it's about 50% very prolific paid development and 50% a whole ton of people who each commit like one line of code or two line of codes or something like that it's the long tail you can do that in code you can write one line of code and that's a contribution you can't really do that in design there is no long tail in design like we talked earlier how to decide how the design of a thing should be how it should look how it should feel how it should interact with other things it's not something you can do drive by and if somebody tells you you can they're probably not a good designer so it's really hard to get design contributions at this level and I've heard people say things like well you know developers are cool and they'll do code and they won't want any money and they'll do it for the good of their hearts so they're not going to contribute they don't get it, they don't get open source they don't get the free software free software philosophy but it's not that at all like how do you commit a UX patch UX isn't something you can just do this small atomic finely scope thing so just think about that when designers come to your open source project it's a long term relationship you're trying to build it's not like a one and done patch submitting or pull requests type of relationship so you need to set the relationship up to be a longer term one designers do use closed source proprietary tools they do, they don't need to they don't need to, but they do and it's okay be nice about it, I've definitely seen people get screamed at in the past I've done some of the screaming myself you can start with standard open formats it's a good way to be inclusive because especially in a project like a Fedora project which is a global project that it has diversity in some senses there are people who can't afford some of the standardized UX design tools that professional UX designers use, like they just can't afford those tools so if all the files for the design work we do in Fedora we're in a proprietary format we're automatically locking people out participating just based on economics alone so if you set a standard of listen use whatever tools you want but use these open formats so that anybody can participate you're kind of starting the gateway job and then this is sort of a nice set, these are the tools I use all the time, they're all open source summer, paper and pencil whiteboards and sticky notes but this is a great set of tools, the standard formats for all of these are compatible with the industry standard for proprietary tools as well so you can kind of use the standards as a gateway drug and then try to get the designers in your project on these the big reveal this is like one way designers kind of think about things that I think is very different than open source development culture designers tend to like things that are very curated and polished I've known designers who have been working on a thing for like two months and nobody knows about it, nobody's seen it and they won't release it to the world until it's just perfect, they feel like it's going to hurt their reputation to release a work in progress that's not quite right and one of the challenges of working with a designer in open source project is making them comfortable being open with their things in progress so helping them feel comfortable just giving them sort of the okay talking them through that can be a really useful way to help them be productive and open source okay and this is something it's more like a right like a privilege kind of thing to think about early on in my career I got in this sort of back and forth with the developer where the argument was one based on who had commit privileges I was the designer so I didn't have commit privileges and so when the argument got to head the developer was the one who won the argument designers don't have that final say that developers do in terms of being able to commit something some designers are able to commit codes some designers are coders I'm not going to say that's not the case but in terms of like having the authority having the permission they don't always have that so you really need to be able to back up your designers to be able to say you know I'm a developer I have commit privileges in this project I'm one of the high ranking people in this community I back this person up because they can't do that for themselves so you have to be willing to do it and when you do that over time if it shows that you back up your designers in their decisions number one your project starts looking better you're supporting designers it becomes a better climate for designers they feel supported they feel like it's a good place to be you will attract more designers because on the outside it'll start becoming obvious this is this is a community this is a project that backs up the designers that goes with their decisions that lets them have a chance so that's something important to think about another thing is shared vision especially when people in your project don't always use tools that you agree with maybe you wish they'd use an open source tool and they're not designers are really inspired by the vision and the mission of open source software I think that whenever whenever people get into sort of a tiff over different things it helps to come back to this common purpose this common goal so it's something to think about too I'm going to go through this really quick because I wanted some time for questions where will the designers come from these are some strategies that I've followed that I think could work for most projects training you can take a UX designer and train them sort of in the ways that I just enumerated to be more effective at open source but you can also take your average open source contributor who maybe doesn't have design background and train them to be a UX person it can go both ways and I've seen both directions work design bounties I'm not going to go super into depth on this you can google search it if you look up for our design bounties you'll you'll find all the details but it's basically like you know a common thing in a lot of bug tracking systems is easy fix bug so you mark a bug easy fix if it's something that a beginning developer could do this is sort of the equivalent to easy fix for design work there's specific things that you want to lay out and do we had a very good rate I don't actually do these anymore because I don't have the time I need to do more but we had a really good success rate for these we had one person just randomly came out of the community did one of these became a red hat employee another person became an intern another person stuck around with the project for a few years and then moved on to another open source project and that was out of five or six people so I would say 50% is a pretty good rate for a program like this so it's something to think about the open source design community a community we have a community at opensourcedesign.net it's kind of a loose association a lot of open source projects have designers affiliated with them and this is where they get together and just talk about things it's a good place to find people who are like-minded who are design who could recommend people to your project or even you could recruit them internships is a great way Outreachy is one I've had a lot of success with Google Summer of Code does not accept UX design you have to be a coder Outreachy, UX design is okay so it's a good program if you're looking to mentor UX designer in your project University partnerships, I've done a couple I did one with Cornell University where you have like a class it's a class in UX design or a class in information design you can make a relationship with the professor teaching the class where a group in that project can pick your open source project as sort of the client for their they're usually practical types of courses where they solve a problem for your open source project I've done that pretty successfully and I know other people have too and then your company I've gotten interns through my company program that I mentored in UX for open source project so these are ways you can get designers into open source okay so greater good is a better motive than profit just all the things equal open source has a much better potential of a good user experience than proprietary software ever can and let's solve problems without becoming a product themselves with open source does anybody have questions I've noticed that there's very few tools that do UX and mock-ups in the open source world and a lot of open source UX and design people are using proprietary tools I wonder if you could speak to that yeah it's something it's um I know of a few projects I've been involved in one that sort of tried to solve that and kind of petered out it's hard because you have to figure out a way to make money but keep it open source I mean it's a problem that we don't have more UX centered projects I mean I use Inkscape myself I use the symbol libraries to have widgets um honestly for me the main thing missing from that workflow is just the easy ability to annotate like collaborative annotation of a mock-up I don't have that so I have to manage that manually and then being able to easily upload them somewhere like if I could press a button from Inkscape's interface like export this PNG to whatever web server service that would be ideal I'm actually really out of touch with what people are using in the proprietary realm for UX design tools so I don't really know I've noticed that over time there's like different tools come and go so I don't know that there really is a good answer generally not just for open source but just sticking with one tool for a long time I don't know if you've seen the same yeah one of the interesting things about Linux is sort of it's always shined in the as my kids used to say the little black box I type into but one of the things I think UX design is never fully plugged into is design in the command line so you end up with engineers putting in a prompt that says dash dash dash you know TLS dash dash ignore and you know so what do you have any thoughts on you know command line UX yeah how to do UX in the command line yeah oh I think well first I will say that at least at RedHack we have done a little bit of UX work on command line tools I remember I ran usability tests for system D back in the day and like we actually sat users down with system D that had never used it before gave them like a brief primer and then asked them to do some basic tasks it actually went over well like you would see the kind of the commentary in the community and think it would be awful but people actually really liked it I think one of the most important things in the command line is consistency and cross tool consistency which is a problem right like certain tools there's like one format where it's like the command sub command and then a set of flags and then in others there's no sub commands Git is just a mix of everything there's like sub commands and then Git dash blah and changes over time and I think consistency and internal consistency and consistency with other common tools is probably the most important there it's definitely dicey if you're making a new tool it's a lot easier than if you're trying to take an existing tool and change it where I've seen some projects do this well is for example the transition from YUM to DNF there was an alias and even systemD is a good example because you can still and I still do and I need to stop Espin service to start a service it's like linked so that it just calls I think systemD does a really good job in that not only does it run the command you meant to run but it instructs you on how to do it that's one of those things where it's in context right when I want to know how to start Apache it's telling me this is exactly how you do that in systemD please try to do that next time I don't I should but getting people when they're in the moment of doing the task you want them to learn is when to do it so it's definitely a sticky wicket but I've seen examples of where it was done well I don't know if that doesn't really answer your question but we can totally do usability tasks of cryo and build and other tools I'm on board for that if you want to do that do you have a question oh okay hi yeah so I I don't know if you wanted to talk at all about how besides the the fracturing of user environments now where we're running the same applications from smartphones and from desktop environments and from who knows what else do you feel that the open source environment has a little bit more of a challenge in the terms of like we have as you alluded to like multiple toolkits that could be running and there could be consistency issues across those etc like I know sometimes because you know I'll be using I don't know XFCE or something like it hasn't quite caught up with GTK 3 so like you know I'll see a few different widget styles just within like using one desktop environment like do you feel that's going to pose a challenge even still now going forward I do my canonical example I give people on that front is Scribus it's a great document layout tool it's like the premier open source document layout tool but it's written in QT and it's apparently written in QT in such a way that when you try to make the QT compatible with how the known environment works it it doesn't go all the way so OK and cancel are flipped and I can't the amount of work I have lost because OK and cancel are flipped in that piece of software it kind of but I mean you know there's different ways like there is a framework to sort of move the buttons and do different things to make this toolkit look like that toolkit but it just doesn't fully function I do think it's they're different they're not consistent they're not integrated those are absolute issues that being said I mean there's Android and there's iPhone and they do things differently and there's applications that run on both that have to deal with those differences or even like cross browser so I don't know that it's necessarily something that's a specific to desktops or is even specific to open source I think I suspect I've actually never used an iPhone I suspect Apple is probably the best at dealing with that because they're very strict with their guidelines and how you have to adhere to guidelines and I imagine that they do something to your listening in the app store if you didn't get on board in time but you know that being said like there's KDE people who use GNOME people use FCE or LXDE or whatever people are using now I'm maybe out of touch with that they have different needs I mean if I have only so much RAM and it's like a 10 year old system that's going to dictate my choice so you know there's not a problem with things being different necessarily but it is where those apps have to work across and provide a coherent experience is where you run into that but I think that's a problem for proprietary software too I don't think there's anything like the long-term example for me is as a child really wanted to play Super Mario Brothers had an Atari couldn't do it so it's not like it's a new problem either sure okay so that's it thank you for coming I really appreciate I know that this was a double time slot so you had to miss out on two other talks I hope you got what you were looking for and if you have any other questions you could reach me by any of these methods I'm happy to talk about whatever thanks