 Thank you guys for the difficulties here. All right. All right. Yep. OK, cool. 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. OK, good. OK. And then I want to know how many of you have a concern about privacy online? Like, OK, 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? OK, 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. OK. 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 open source, it's bad UX. You're doing a bad job. This is sort of like the elephant in the room any time we talk about UX and open source. Hold on. This is an instinct here. Yeah. 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 instinct here. OK. So we could talk about IRC. How many people in here use IRC? OK. How many people in here use Slack? OK. You guys see kind of very the similarities between the two. Right. So in 1988 the first IRC server and client were written at in Finland by Jarco O'Connor in. And by 1989 the next year there were 40 servers worldwide and actually have a handy dandy timeline here. OK. 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. OK. 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. OK. So this is a lot of lost potential. Again. Sorry. OK. I just lost it. But this is a lot of lost potential because you know it's 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. OK. Well I'll try to I'll try to wing it without my notes. This is 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 and sort of government and academia. Right. There was a lot of sharing between different organizations. We used open standards. And there was like 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 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. Well that's the next slide. This is how this is how it happens sometimes is 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, Orbit which I don't think ever 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. I'm a UX designer and it was aimed at UX designers. It 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 something happens to that you should 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 and two or three clicks. Mailman too, yep. But you know there's an advantage here right? Like this is what digital transformation was supposed to give us. If you go back to 1998 and read conversations or you know since today we have AI and ML is so accessible I could maybe go to say the company mailing list where everybody kind of has flame wars on a routine basis and do some ML to figure out what are the cycles? Because you know these cycles it always comes back around people arguing about I don't know I'll throw out 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 right now at 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 they 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 of big companies that well you know it's just not this software's 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 anytime like you know they go away or they're doing things to your data to be R and OK? 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 to 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 just that information makes 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 gonna 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 and 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 what 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 gonna 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 I'm not 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 anytime 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 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 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 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 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 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 at a company that's a proprietary software you have control across the 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 in the back is GIMP these two tools are sort of amazingly in sync in that they at least both use the same tool kit which you know not all the creative tools in open source actually do 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 and this is sort of part of the same conversation thread here when you have different tools that work together as a part of the 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 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 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 like 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 know is it really nice for the developer to pass that kind of hard decision making on to 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 you really need to make those hard decisions so the user isn't faced with them because every little thing like that you know what I mean like 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 can just walk in the room and do what I meant to do which is open the window or you know grab something from the shelf when you make all these decisions when you avoid making all these so 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 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 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 is more important to talk about than what is UX it's not just a code 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 in the outside to 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 it'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 you know 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 look 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 you know 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 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 ten 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 ten lane bridge what if people don't really drive cars around there what if they prefer to bike a little heavy environment you didn't really need ten lanes 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 so to be able to do that you have to understand the user's context you have to understand 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 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 for 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's a possibility that your IP could be changing oh ok 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 they can help to just step back and figure out why and that's what UX people do we figured out what do they want to do why do they want to do it and then we worked 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 we do QA and code and see did the design actually solve 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 we 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 we have different reasons so the things we looked at was figuring out resource finding that was the topic we decided to focus on 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 the design process is similar you start with something that is 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 you can make a decision and that's how you design it that's what you design 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 alright 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 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 you know 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 ads well if you block the ads I would say political arguments from everything to like what cherry pick story post cherry pick story post 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 that keep coming up and of course they're always the most controversial setting ones 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 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 or alphanumerical in mailman 2 which makes sense logically but if you look at this 389 announce 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 is 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 a 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 controls to that we'll 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 need something very much like it's not it is critical for them to be able to access the thing progressive disclosure is a great technique you could think of it 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 and 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 keyboards 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 and 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 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 and they'd say ooh, they're colorful there's a lot of them that's about all I get 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 I got multiplied by the number of users because that's a lot of effort if you had 50 people pouring over this spending 2 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 you can 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 can tell I'm not a developer but I do a lot of community I do a lot of content a nice summary curation it's important contextual hints the closer to the action a piece of information is the more useful it is systems have done this you could write this pdf white paper and 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 this is an 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 this is the installer system for fedora on the left is a graphical based interface that it's kind of a wizard it 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 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 back end it's not a problem 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 users 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 can't realize 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 can create a task list based on that you probably, five is a good number and think about each one you know, when people are running through your tests, it's not taking them forever. Then you run the test. I think 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 like 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 down the hallway 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 test, 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 higher priority. 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 SpinachCon, which is an open source usability testing sort of hackfest kind of environment. We did it at Lieberplanet. This one is from like three or four years ago, but 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 some of the things we found out is the users liked the aesthetics. They wanted better tagging functionality. Some of the filters, they just couldn't find them. They didn't see them. So we got a nice list of these or 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 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, okay? That's my big, because there's a lot of people who say, oh, well, you know, 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 gonna agree with us. These are the free software users out there today. These are the people who contribute to free software. 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 wanna extend that to as many people as possible. But if we kinda 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 locations 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 use a 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. The 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 gonna 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 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 kinda can cause battles, especially in open source communities where you have the old timers, we'll call them, that 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 10 years, why are you throwing everything out? There are definitely cases 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 10 different versions of your software for your cloud users just to keep everyone happy because they like the way it worked back 10 years ago. But again, today's architectures allow us to provide different experiences on the same backend. So think about that as something you could do. You can augment as well. So having different front ends I almost think of as 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 wanna 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. It was an augmentation 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 like, I think a good analogy that I have on the slide here is city planning, right? Like if you wanna modernize your city, you can't 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. I'm not gonna say open source is unprofessional, but certainly it's more fluid. You can't just rely on sort of norms, 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 wanna 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. 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 to sort of, it's just a nice way to set the stage to lay out the table so that people are productive and not 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 website's a great way to get started right away. What are things I can do? 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 there. Avoid conflict with transparency and 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, raise your hand if you've seen this too. You tend to get 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 pulling the tablecloth out and everything flies everywhere and it's like, oh my goodness, we're not gonna make our deadlines and we have to re-architect this and we have to throw this out. It's the right thing to do, but we don't wanna do it, right? I don't know if anybody's experienced that. But because you kind of, there's this weird dynamic where sometimes designers mess everything up, they just throw everything or they re-architect everything. 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 wanna 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 wanna 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 or you will add this going on, but in an open source community, especially because the code can have a very long lifetime, you wanna avoid putting things in unless you're really really sure that they belong there, because getting them out is gonna be really difficult. Okay, design culture is different. So how do you relate to designers in an open source project, right? 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. How can 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 wanna do, the tasks they wanna achieve with your software, the context in which they're performing them. Developers focus on the technology. They're gonna make decisions about what language are we using, what platform are we using, what architecture setup we're gonna 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 is no long tail in UX. This is actually a abstracted version of the kernel. Who contributes to the kernel report that the Linux Foundation 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, right? 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, it's very systemic to be able 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, 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, but designers just want money. So they're not gonna contribute. They don't get it. They don't get open source. They don't get the 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 and I'm gone kind of 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 the Fedora project which is a global project that 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 were in a proprietary format, we're automatically locking people out of participating just based on economics alone, right? 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, right? 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 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 ticked 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. And 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 gonna hurt their reputation to release a work in progress that's not quite right. And one of the challenges of working with a designer an 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 a 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 gonna say that's not the case, but in terms of 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, 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 a community, this is a project that backs up their designers that goes with their decisions that lets them have a chance. So that's something important to think about. Another thing, yeah, is shared vision, especially when people in your project don't always use tools that you agree with, maybe you'd 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, okay, 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 gonna 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 gonna go super into depth on this. You can Google search it. If you look up Fedora design bounties, you'll find all the details. But it's basically like a common thing in a lot of bug tracking systems is the 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 wanna 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. 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 projects. So these are ways you can get designers into open source. Okay, so greater good. It's a better motive than profit. Just all of the things equal. Open source has a much better potential of a good user experience than proprietary software ever can. And let's help people 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 markups 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, 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, yeah, 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. Honestly, for me, the main thing missing from that workflow is just the easy ability to annotate, like collaborative annotation of a mockup. 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, because I don't see people 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 is always shined in the, 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 designing the command line. Right. So you end up with engineers putting in a prompt that says, dash, dash, dash, dash, you know, TLS, dash, dash, ignore, and you know. So what do you, 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 Red Hat, 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, a 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 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 system D 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 system D 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 system D, 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 fully answer your question, but we can totally do usability tasks of cryo and build in 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 don't know if you wanted to talk at all about how besides 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 multiple toolkits that could be running and there could be consistency issues across those, et cetera. I know sometimes because I'll be using, I don't know, XFCE or something, it hasn't quite caught up with GTK3. So I'll see a few different widget styles just within using one desktop environment. 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 Scribes. 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 GNOME environment works, it doesn't go all the way. So okay and cancel are flipped. And I can't, the amount of work I have lost, because okay and cancel are flipped in that piece of software, it kind of, but I mean, 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 say 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 that being said, people who use 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 gonna dictate my choice. So, there's not a problem with things being different necessarily, but it is where those apps have to work across different platforms 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, so 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. Should I have my water on? Wait. Hello. Thanks for being here. So, we're gonna talk about the mystifying accessibility today. Sarah Chizari, I'm UX researcher, and we have Jen here. She's a senior interaction designer. We're gonna talk about how to build UI component for screen reader users. So, I want you to close your eyes for a few seconds. I promise I'm not gonna play any magic or anything, but close your eyes for a few seconds and imagine that you are going to browse the web while your eyes are closed. It might sound terrifying, but you will have a torch. The torch will light up a small piece of this face for you as you are browsing the web. So, imagine that situation, and that situation that I'm describing is how blind users are actually using the web. So, now you can open your eyes and imagine you are developing the content of the web for those types of people. The context is a dark space. No one can see the screen that you are developing. They can't actually see the whole page or anything, and they're only able to see a small piece of your screen at a time if they're using screen readers. So, how would you design or develop something for that context? So, we're gonna walk you through how we did it, with the pattern fly team at Red Hat, the UXD design team. So, the analogy here is that the web for blind users is a huge, dark, massive space, and that has huge amount of information. For people who are blinds to use it, they have to have this torch called the screen readers that will allow them to light up a small piece of this face at a time. So, again, we will walk you through to tell you how we did it. So, another activity for you guys. So, can you guys, by show of hand, can you tell me who in the audience can read the information on the screen? Is there anyone? No one. So, honestly, you guys all see this on the screen. You know there's information up there, but it's still not accessible to you. And the point I'm trying to make here is that accessibility is more than designing for disability, because at this point, you guys are 100% able to see the information. You know the information's up there, but it's not accessible. So, the only reason you can't actually access it is because you're not familiar with the language. So, accessibility and designing for accessibility is a lot more than designing for disability. We have to think about usability and understanding users' needs and their capabilities. So, this is the actual definition of accessibility. Accessibility is designing for usability for the people with the widest range of capabilities. So, why should you care? Actually, it's the law out there that if you are dealing with government, education and non-profit organization, there is a standard level of accessibility that you have to meet. So, if those customers are important to you, you definitely have to meet some levels of accessibility. And also, good accessibility is good usability. So, usability and accessibility, they are not synonyms. There are different words that have different meanings. But in order for you to have a great usability of product, you definitely have to include great accessibility. And if you are including accessibility in your design, it's not gonna be targeting a small portion of users out there, because if you have a good accessibility of product, it's gonna benefit a large population out there. For example, in this picture, if you have a Ramp 4 wheelchair, this guy didn't have to carry the bicycle with him. So, again, accessibility is good usability. And when you're designing products or applications, you have to bear in mind that you're gonna use this product in the future. Your abilities, your needs, your capabilities gonna change over the time. So, definitely have this in your mind when you're designing. You're designing for the future of you. And the more you wait to address accessibility of your product, it's gonna be tougher and harder for you to do it, because accessibility is gonna affect all aspects of your design. So, the earlier you plan to include accessibility, the easier to build. And if you test early in the process, it's much easier to build. And it's gonna be much nicer at the end. So, when you're designing for accessibility, try not to prioritize one group of users over the other ones. And try not to de-prioritize one small group of users, because when it comes to accessibility, really doesn't matter how big those population group is. So, imagine your own company. If there is 100,000 employees in your company and there's only one wheelchair user, you definitely have to have a ramp for that one user. So, think about that when you're designing a web accessibility. Because, well, if there's only one user out there that needs accessibility, web technology, you definitely have to give them that chance. So, accessibility and inclusive design always go hand in hand. And you definitely wanna make sure you design something that meets everyone's needs and capabilities. And you come up with one common solution that works for everyone. I love this quote. It says, we are all just temporarily abled. So, basically, when you're designing for accessibility, you're not, again, designing for one small population because at some point in life, we will have some sort of disabilities that will benefit from the accessibility features that we have developed. So, talking about different users, we already talked about different types of users we have out there. But on top of that, we have different devices and those different devices require different inputs and they have different types of outputs. So, there is a huge combination of preferences and users out there. We have large different users and different preferences to use those products. And, again, to be honest, it's not easy and it's not gonna be doable to design, personalize, or customize experience for each of those preferences. So, at the end of the day, we have to come up with one solution that works for everyone. Well, as I said, when it comes to accessibility, number doesn't really matter. If there's only one person who needs accessibility technology, we have to provide it. But just to put you in the context and say how significant that requirement is, we have one 5.1 billion users out there that have some sort of disabilities. And that is 20% of the world's population. Today's presentation is gonna be about users who have some sort of visual impairments and developing things that is usable for them. So, just to put you in the context, there are 256 million visually impaired people out there who are using the internet. And out of those 200 something million, there are 36 million people that are 100% blind and sightless, meaning that they don't, they can't even see anything that you develop on the web. So, let me talk about who are these people? So, Norwegian people, they rely on text, audio and haptic data, and they benefit so much from this manic HTML, information architecture, and all contents and controls available as text. They have this superpower that many sighted people don't have. They're able to listen and understand screen readers in very high speed. And just to show you an example of how like this superpower sounds like, I'm gonna play something from the screen reader. I'm just, I want you to listen and try to understand what it means and what it says. So, go ahead and give it a listen. Is there anyone in the room who understood a word more than a word? So, yes, this is the superpower they have. They have this incredible talent of understanding this audio. There was nothing wrong about the quality of this audio. It was 100% high quality of the recorded screen reader, so they're able to understand this in even higher speed. So, when you're designing for accessibility, you have to bear in mind that, although they don't have the visual abilities, but they're able to do something else that we are not familiar with it. Also, when talking about low vision people, and they rely on contrast, font size, and audio a lot. And this group of participants or users are in a broader range than the low vision people. They have the ability to use the screen readers and also a whole sort of other assistive technologies such as this one that you see on the screen. So, at Alred had with pattern fly team, we started accessibility effort and to understand if the components and whatever we are developing is usable for these users. We decided to go to the actual users and see things from their perspectives. We wanted to observe how they interact without products and whatever we developed. So, we decided to work with the school that there's a school called Governor Moore Head School down in Raleigh. It's actually a flagship school for blinds and we started working with them to make sure, to test our products and see how they're perceived, how they interact with the products. This is a picture of the students that we've worked with. We started working, there are like 10 to 12 students. They're junior high school students. And we started working with them since November 2017. We did a couple of activities with them. The one that we wanna talk about is the co-design and development and testings that we did with them every week. So, we went to school to work with two Norwegian students and we had one designer, one developer and one researcher in the sessions. And what we did was to test various implementation of the components that we had. We gave them the components, we gave them tasks and we observed how they interact with the system and we heard them out as they were working with the system to see the expectation and the preferences. We went for the preferences using the device and the screen readers. There was one student who was very comfortable with JAWS which is one of the screen readers that is out there and she used Windows laptop and we had another student who used iPad and she has voice over there. So, as they were working with the system, we observed them how they interact, what they hear from the screen readers, how they react, what they expect and what they prefer. So, these were the questions that we were trying to figure out as we were working with them. So, what we learned from them. I'm gonna just tell you high level findings of what we learned and Jen gonna talk you through the technical finding of their interaction with the web components. So, one thing we learned is that cited keyword only users are not equal to Norwegian screen reader users which is misunderstanding out there. Keyboard accessibility does not equal a screen reader accessibility. So again, if you are testing your product for accessibility, you can't actually just rely on keyword accessibility. You have to definitely test it with the people who actually use a screen reader. And then, complying with the accessibility standard is not enough. I know there are accessibility guidelines out there. It's good to follow them but you definitely still have to test it because complying with them wouldn't give you the best experience out there. We observed some situations that whatever presented to the students wasn't something that we expected to get from. So, definitely we have to test to make sure everything is working just fine. And then the components that we developed is gonna be affected and influenced by various technical issues. Such as devices, browsers, screen readers and the modes of the screen readers that the users actually using. And in a design workshop that we did with the students, we observed something very interesting. The students, there were mostly no vision. There were some of them who had some low vision but still they did have some understanding of the visual aspects of the web which was very interesting to us just to figure out. And I'm gonna leave you to read that quote from one of the participants when she was designing a web page for us. And I will ask Jen to take over and talk about the technical findings. Thank you, Sarah. And then can you guys hear me okay? Is my microphone on? Close enough. The first session we had with our screen reader participants was to have them teach us how they use a screen reader to navigate a web page. As part of this activity, we learned that the same general methods are available in most of the screen readers. They are different in terms of the exact key commands you would use and the results that get announced by each screen reader. But we also noticed that JAWS provides the most full-featured, robust experience of all the screen readers. So for all the examples we show on this page and all the remaining slides, it's based on the JAWS inputs and outputs. So the first method they shared with us is how they go from the item that they're currently on and shift focus to the next item using the up-down arrow keys. So it'll shift focus from the current element to the next element in the DOM when they hit the down arrow key. Another way of navigating through the web page is by using a specific key command to navigate to a specific type of element. So in JAWS, the user can hit the H key and it'll go to the next heading on the page or tab for links, B for buttons or F for form elements. Buttons are also considered form elements and in JAWS there's so many different types of elements that you can navigate by that this is just one of the common sets of elements that these users would navigate by. Also, most screen readers provide the ability to open a dialogue that will list a specific type of elements. So similar to the previous method, the user can enter a key command to open a dialogue that lists all the headings on the page, for example. So without changing their focus on the page, they can easily scan all of the headings that are on the page to get a sense of the structure of the page and figure out where they need to go in that page to figure out what they're trying to do. So if it's the first time that they're visiting a site, the heading structure is very important. They will scan the headings as shown here to understand where they need to go to complete their task and to get familiar with that page the same way that you would visually scan a page layout to understand the organization of that page. But if it's a site that they're already familiar with and they know what type of element they're looking for, whether it's a form element or a button, and so they will pull up a dialogue that lists that type of element or use the specific key commands to navigate to that type of element. So to illustrate these methods, I'm gonna share with you what JAWS announces for the sample HTML shown here. So this HTML would show as this example on the left on the screen. You can see that there are a couple of headings. There's a bullet list of links and a paragraph. When the JAWS user hits the down arrow key, JAWS will announce heading level one accessibility guide. Then hitting down arrow again would announce list two items because the next item in the DOM is the unordered list. Then when they hit the down arrow up key again, it announces both the list and the link as bullet, same page link, understanding user's needs. And then the next bullet, same page link checklist, and then hitting down again would announce list N because they've come to the end of that list. If the user is using the H key to navigate by headings, it reverses the order, so now it announces the name of that heading, first accessibility guide because they know that they're on a heading and then it announces heading level one. And then the second time they hit the H key, it'll say understanding user's needs, heading level two. So these users, as Sarah demonstrated, they can listen pretty fast, so they'll run through pretty quickly using the keys to scan the contents of the page the same way that you just visually glance at it to understand the structure. And then here, again, is an example of the heading list dialogue showing the headings that are in the sample HTML. So as I mentioned before, there's so many key commands available for almost any type of element that you can think of. I'm just gonna take you through the links as an example. You would hit the tab key and it would take you to the first link on the page. In this case, the context that it is a list item is no longer provided because it's just skipping straight to the links. And then here's an example of the links list dialogue for those links as they would display on the page. So hopefully these methods illustrate the importance of providing a name that is meaningful because often when the screen reader user is navigating a page, these elements are pulled out of context. So you've always heard that using a link name that says click here is really bad. And this is why, because when they pull up that list of links dialogue, having a bunch of links that say click here, they have no way of knowing what those links actually do. Another thing to point out though is that even if you provide a meaningful name, it's important to check that if all of these links show up somewhere on the page, they should also have the same URL. If they happen to have different URLs, but the same name, then that's gonna be a major usability issue for your screen reader user. Another thing that these methods illustrate is the importance of having a heading outline that proper clarifies the structure of your page contents. So in the same example on the right, you can see that it's pretty easy to glance at those contents and understand the structure of the page. You can easily find the title, you can see the sections in the page. But if you remove those styles so that everything looks the same, it's much harder to glance at this example on the left and understand where you would need to go to find the contents you're looking for. And so providing the heading outline in a way that's semantic and properly identifies the heading levels and also using things like list to properly define list items makes it much easier for the screen reader users to understand where to go to find the contents that they're looking for. The remaining sessions we had with participants was to review components that we were implementing for pattern fly. Two of the components we reviewed with them were a button menu and a navigation menu. We decided to start off with the button menu because we wanted to start with something that was fairly simple and basic because this was the first time we were doing any kind of activity like this with a participant so we weren't really sure how it would go. And we also decided to use what we call the kebab menu because that icon looks like meat chunks on a stick. So with the button menu, we were interested in understanding how the screen reader user interacts with the toggle and the menu. But we were also interested in understanding how the screen reader perceives the label on that button when we use an icon instead of text for the button. So our implementation consisted of a button that included an SVG icon and then a div that had links for the menu items. We instead of testing two variations of this menu because in our first test, we noticed an issue with a voiceover. So our first variation had both Aria has pop-up set to true and then also included Aria expanded set to false when the menu is hidden and then set to true when the menu is visible. We later realized that the issue with Aria has pop-up was more of an issue with the participant having an older version of the iOS on her iPad and that version of voiceover did not support Aria has pop-up. But we had also learned with that first variation that using just displayed none to hide the menu from screen readers resulted in some weird behavior with Jaws. So in our second variation, we ended up using the hidden attribute to hide the menu both visually and from the screen reader. And we removed Aria has pop-up because we wanted to test if there were different results when we only had Aria expanded. And so again, when the menu is visible, we remove that hidden attribute and Aria expanded changes to true. Both variations had Aria hidden set to true for the SVG icon to hide that element from the screen reader because in our case, we were providing that meaningful name in the form of Aria label on the button element itself and we labeled it more actions. So we noticed when we were testing this that the variation that had both Aria has pop-up and Aria expanded in Jaws gets announced as more actions button menu and this is regardless of what state the menu is in. The Aria expanded attribute gets completely ignored in this case. But in our variation that had just Aria expanded, Jaws would announce it as more actions button collapsed when the menu is hidden and more actions button expanded when the menu is visible. When we reviewed these variations with our participants the feedback we got from them was that either variation provided them with the information they needed to know that there was something they could do on that toggle to get something else. They both provided cues to the user that they could toggle to get more. And also in further reviewing the W3C recommendations for Aria has pop-up, we learned that there is an expectation on what role you assign to the pop-up that displays for the element that has that attribute. So it expects one of these five roles, menu, list box, tree, grid or dialogue. So in our example with Aria has pop-up we should have used role menu for the menu, the div that was the menu and the role menu item for the children links in that menu. Another thing we learned was how to properly hide elements. So we already know that display none will visually hide elements on a screen but we learned that you should not rely on that to hide elements from a screen reader. We also knew that Aria hidden would hide elements from a screen reader and does not hide elements on a screen but we realized that hidden is the most effective way if you want to hide elements both from a screen reader and on the screen. So essentially using the hidden attribute is the equivalent of using both display none and Aria hidden sets a true. If you are going to use display none you should couple it with Aria hidden or you can just use the hidden attribute instead. And then cases where you would use the Aria hidden attribute are cases like where we had the SVG icon we wanted to hide that from the screen reader because we were applying the label to the parent element instead. Also decorative elements you can visually hide you can hide them from the screen reader using Aria hidden. The next component we tested was navigation, similar interaction pattern to our button menu you have toggles in this menu that can show and hide a sub menu. Those toggles are also mixed up with elements that are just links on a page. So in this case you can see the lore is a link to another page but Ibsum is a toggle that displays another menu. The first question we had was what button, what role should we use for those menu items in our navigation menu? Should it be a button, a link or a menu item? We had learned during our first session with participants how they used the links list dialog to pull up elements on the page and we decided that it was important to have all of those elements in the navigation menu to be listed together in the same dialog. And so that meant if we were to use a button role on the toggle then it would not be listed along with the other links in the navigation menu. Also if we were to use menu for the sub menu then we would have to use the role menu item for those links instead of the link role and those items also would not be listed in the links list dialog. Only the items with the role link would show up in the links list dialog. We knew in using a link role for those toggles that we are breaking with standard practice where you should only use links for the elements that are actually links and have a URL value but in this case we decided it would provide a better user experience for our users to use a link to toggle the sub menu instead of a button. And then the other question we had to decide when we were implementing a test page for this was do we use aria has pop up or aria expanded? We had learned in our previous session that either attribute will communicate to the user that they can click to get something more but we had also learned that aria has pop up has expectations about what role you apply to that thing that displays. In our case we would be using menu and if we were using a menu we would have to use menu item for the links and we'd already decided that we wanted to use the role link so that meant we were using aria expanded in our case. So in our test page for navigation we had a nav element with an unordered list of links and then the sub menu also was an unordered list of links inside of a section element inside of the list item that includes the toggle that displays that sub menu. We also included a heading inside the sub menu that had the same text as the toggle that displayed that sub menu. And then like with the one variation I shared of the button menu we used aria expanded and the hidden attribute on the menu. So our participants had no issues with using the role link on those toggles. They understood that when that element received focus and it announced that it was expanded or collapsed they knew that there was a sub menu and whether it was visible or not. So in this case you can see the menu is visible and aria expanded is set to true. The other thing that we learned during previous conversations with them and reviewing the button menu was that when they toggle the element to display the menu they expected focus to automatically shift to the first menu item. So when we built our test page we had focus automatically shift to the first menu item and that sub menu. And our participants didn't experience any issues with this when our JAWS user toggled that link for science JAWS announced that it was the environmental science link and it also announced the label that we gave the section element that contains that sub menu. But we also noticed when the participant used the links list dialogue instead to activate that toggle it would still shift focus to that first menu item but nothing was announced. Our participant overcame this issue by shifting focus forward and shifting focus backward the same way that you would kind of feel around when you're in a dark room to figure out where you are to get a sense of the context of where she was on the screen. But there is a web content accessibility guideline that states that there should be no changes in focus that are not controlled by the user. So if we were to provide, if we were to follow this principle that means that focus should stay on the toggle itself and not automatically shift focus to the first menu item. And this is in line with inclusive design because if we were to automatically shift focus for the user thinking that we're optimizing that experience for the user we run the risk of potentially making it very challenging for other users. So we decided it was better to be conservative and keep focus on the toggle rather than automatically shift focus and run the risk of some users being really confused and disoriented by that. Another question we had though was what should happen when the user moves forward? They're in the sub menu, they exit the sub menu and does it stay open? Does it automatically collapse? Adobe has an example of an accessible mega menu where they handle this flow very nicely and I highly recommend that you Google this example and just play around with it and see how they show and hide the sub menus as you just use your tab key, tab through the elements, the links in that menu. So we had headings in our sub menu. The feedback that we received from one of our participants was that it was helpful to have the heading. As I had shared with you before, there are key commands that let you navigate to specific types of elements. So when she was in a sub menu, if she forgot what sub menu she was in, she would just use the shift H key commands to shift focus to the heading in that sub menu because she had learned in using that menu that there was a heading. ARIA Current, its purpose is to announce which link is the current page. So in this example, if you navigate to the home page and then you shift focus to that link, Giles will say home, current link and our participants understood what that meant. They knew that that meant that that was the page they were currently on. And then there are many examples that use ARIA controls for this type of interaction pattern, but we found in our tests that this attribute is really verbose and pointless for this use case. So with ARIA controls, you provided the ID value of the element being controlled. In this case, the section with the ID not bar sub menu three is being controlled by the link that is a toggle. And so when this link receives focus, the section is hidden. So Giles completely ignores that attribute because as far as Giles knows that element doesn't exist on the page. And then once the menu is visible, if you were to place focus on that toggle, it'll announce the element that it controls and then it provides a key command that the user can use to jump to that menu item. But in our implementation, the menu is the very next item in the DOM. That first menu item is gonna be the next element to receive focus by the user. And that is the interaction pattern that these users expect, that when they, if they have focus on the science toggle link and they move down, they expect focus to immediately go to the science menu. And that down arrow key is much easier and simpler for them to use than the key command that Giles provides for jumping to the element being controlled. And also in previous tests, we had noticed when participants would indicate that there's too much information being provided to them. So they just want the information, they need to know where they are and they don't wanna hear any extra information that's just added noise. So this is a case where Aria Control seems to just provide more noise, provides no benefit to the user for this specific case. But there are RUI patterns where Aria Controls would be beneficial. So if you have a toolbar component, for example, and that toolbar has a sort button or a filter button, those sort and filter controls control the list below the toolbar. So that will be a case where you would wanna provide them with a way of jumping to that element that's being controlled, because the next item from that filter control or that sort control is gonna be another item in the toolbar. So having an easy way to jump to that list that's being controlled is a case where you would wanna use Aria Controls. So that's the end of our presentation. If you're interested in seeing our final implementations, please visit our pattern fly workspace, pf-next.com and take a look. Thank you, any questions? Oh, we figured that out, yeah. Low talking does nothing on this thing. All right, so recording going already? We good? All right, start the timer. All right, all right. Good afternoon, thank you guys for joining me today. My name's Phillip Bailey. I've been working for Red Hat for about two and a half years now on the Overeard project. As the primary, you can read that as the only front end developer for the SLA team, which handles the maintenance of the host engine feature for Overeard. This presentation is gonna focus on the rewrite of the hosted engine cockpit wizard. And don't worry if you don't know anything about the project or have no idea what I'm talking about. I'm gonna go over all that in just a moment. I wanna point out, I don't consider myself a UX expert at this point. I don't really know that many that could because it's still a very new field. I consider myself an avid proponent who's lucky enough to get to work with it for a living. I learned a lot in the midst of this project. I'm not pretty much sure of this by myself. And when you do that, you have no choice but to put yourself up by the bootstraps. So learned a lot and I just wanted to share a little bit of what I learned during that period. Hopefully you can get something out of it. If not, enjoy your post-launch nap. But first, we'll take a quick look at what we're gonna cover in this presentation. So we'll just take a quick look first at all the projects that the wizard touches. It touches a lot of different things. And then we'll look at the definition of user experience in the context of this presentation and a few guiding principles that to help guide the decision-making throughout the overhaul process. Following that, we'll look at a few of the important tools that we use and then we'll finally get to the meat of the presentation and look at some of the drawbacks of the old wizard and then how we fix those in the new. My main goal for this presentation is just to demonstrate that providing a good user experience comes down to details and making a bunch of small decisions and that there's a lot of solid open source tools out there to help us in achieving that goal. So let's go ahead and jump right in. I know we don't have a lot here. How many here have used Ovirte in any capacity? Okay, good. I'm actually gonna teach something. Oh, we got two. Sweet. All right. How many have you actually installed Ovirte using the command line? All right. And how many have installed it using the Cockpit Wizard? None. All right. Great. Okay. So for now, we'll go and go through all this and most of you don't know what any of these things are and I'll get you up to speed. You hear a lot of names of different projects throughout this talk and I just wanna make sure that you don't get lost on me. So we'll start with Ovirte. Ovirte is in the upstream version of Red Hat Virtualization. It's an open source, enterprise-grade virtualization solution. In other words, it allows for the management of the major aspects of a data center environment which include your physical host, your storage, your network, all that jazz. But most importantly, it manages virtual machines. And the Ovirte engine is the brain that keeps all of that working in harmony. It's responsible for scheduling your virtual machines, migrating them when they need to be migrated, restarting them on a new host if their existing host fails for some reason. So now if you wonder what happens if the host that your engine is on fails, everything comes to a screeching halt. So that's where your hosted engine comes into play. It's the critical component in assuring the high availability of your resources and it's the result of placing that engine into a virtual machine of its own. And then if that host goes down, that virtual machine starts up on another device or another host. And this is a gross oversimplification of a very sophisticated problem. If anybody cares, there's a older talk by Daron Fedeuk about the chicken and egg problem the host that engine presents. I recommend checking it out. It's on YouTube. So next up is Gluster. It's a powerful open source and scalable network file system that allows you to set up a distributed network solution using off the shelf components. And it is of course the upstream version of Red Hat Gluster Storage. Now when you put together a hosted engine installation and a Gluster storage base, you get a hyperconverged infrastructure that relationship plays into some of the work that I needed to do in the wizard. So just keep that in mind going forward. Now Cockpit is an open source, browser based server management platform. It's aimed specifically at system administrators. It simplifies server management by allowing you to handle common management tasks all in one place with a nice interface and nice dashboard to keep you up to date with what's going on in that machine. Additionally, it provides a plugin infrastructure that lets you make custom modules and that's what we use for the hosted engine wizard. All right, so that injured crash course. So let's talk a little bit about what you're here for UX. The term user experience is a humongous buzzword right now. It sounds fairly self-explanatory, but the UX world is already very big and it is growing quickly. And so the exact definition and interpretation you get of the term user experience differs depending on who you're talking to. So we'll go ahead and nail it down a little bit for the context of this presentation. So I'm going to use the basic definition by the International Organization for Standards. It seems very simple at first. It just tells you that the user's experience is defined by the perceptions and responses that come about from not only using the product, but also from its anticipated use. And the first time I read that I had to stop and think about it. And then I started thinking about all the things I hate to use. Everybody has some app or product that they just absolutely hate to pull up and have to use. And it became much clearer to me why that's a piece of user experience. Now to emphasize how deceptively simple this definition is, I want you to check out the additional clauses that the ISO tax onto their base definition is extremely daunting when you consider the scope of what goes into making the user experience. And on top of that, to further complicate it, there's no singular checklist of items or best practices that we can follow that will guarantee a foolproof user experience. It's just not that simple. As much as we love a definitive source of truth in the development world, it just doesn't exist at this point. But just because there's no guaranteed path for US success, it doesn't mean that we have to stumble about in the dark and do trial and error to figure out what works. A lot can be accomplished by following a few guiding principles. So let's talk about a few of the principles that even though they weren't explicitly stated in the process of developing the wizard, they developed organically throughout the development process and they were distilled from things that were continually repeated in one form or another. You just keep hearing the same things over and over during meetings. So the first principle emphasizes consistency, which is a critical factor in providing a positive user experience. If elements look the same and they behave the same, it helps the user to know what to expect when they see that same element reappear in other parts of the application or other applications if you have a suite of them that share the same type of interface. The human brain just excels at pattern recognition. Whether you're aware of it or not, your brain's always looking for common patterns to provide information about the state of the world around you and then how you should react to that state. So consider, for example, a stop light. You're driving down the road, you see a stop light, your brain automatically considers what the state is and what you need to do. What color is it and where is it placed? Where has that light lit up? So if I took that color away, you'd still know what to do because you know which light is illuminated and because it's always consistent, it's always the same, you know what to do and your brain will know what to do and you don't have to think about it. But if you went to a different country and they had different colored lights or different orientation of lights and nobody told you what to expect, you're gonna have no idea what to do. Your brain will automatically start trying to figure out what it means and watching other people and seeing how they respond to it but until that happens, you're gonna be a little bit lost. The second kind of principle is around assumptions and we all know the old phrase, okay, well maybe don't, because that's an assumption. So there might be somebody here from another country and they don't know what that idiom means and I'm not gonna go through it here because I'm gonna keep this clean. But they could, excuse me, I wanted to call this label or this principle, never assume anything but that's impossible. You always have to make base assumptions at some point. It's not feasible to cater to every possible user situation. There are a few common assumptions that cause trouble but have you ever been discussing a feature of your project and heard someone say something like, oh, the user should just know what that label means or they'll be able to figure out what it is. They just typically come about when you're trying to be lazy, you don't wanna fix it. You know, the little thing would make it that much better but you just don't wanna do it. So when you hear those types of things, those are red flags. It should caution you to stop and take a look at what exactly we're talking about and what can we do to make that foolproof and concrete so that user always knows what to do. The final guiding principle focuses on simplicity. At times it's appropriate to have a cluttered and busy user interface. You know, if you have a dashboard that's displaying information, it's just meant to be taken in at a glance. That's fine, that's one thing. You know, you don't wanna overdo it but it's okay to have a high density there but when you have a user conducting a task such as filling out a form or selecting settings, it's typically better to just reduce the clutter where you can and make it a lot easier to see what's important because this will achieve two goals that often creep up in UX design. It reduces the cognitive load on the user by removing all the distractions that would take additional time and brain power to filter through and it highlights the steps that you want the user to perform and the path that you want them to take through your application. All right, so you may have heard the old adage before a good craftsman never blames his tools. Right? But I've never heard a craftsman turn down a good tool when it's offered to them. The tools we use have the ability to either increase our capabilities and productivity or to diminish them which makes choosing the right tools an important step. And I didn't have much choice in the tools I used for the wizard but I have zero complaints about the ones that were chosen for me and we're gonna take a look at those now. The first tool is what I consider a complete game changer in terms of UX design. A design language system. Some of you may be familiar with the term, others may not but you've probably all seen components of one at some point in time or another. A design language system provides an established set of principles and patterns that guide the design and development of an interface. It's a toolbox in and of itself that can help drive consistency across a single product or all products in an ecosystem. Additionally, it benefits individual designers and developers by answering questions such as what type of button or font or notification should I be using here or what should I use or what should I show if there's no data to populate this given dialogue. But don't get locked into the idea that a design language system has to be the be all end all of this being used. I've seen that happen multiple times in the course of this project and the others that I've been working on and that's just not the case. When it comes to user experience it's next impossible to account for every possible situation and every context in a system. But in my opinion, it's better to consider the design language system as a strongly preferred guideline and then deviate from it when necessary. Just make sure that the conditions for deviating are given strong consideration and that the deviation provides an observable increase in the end experience. In other words, don't just change the color of a secondary button just because your favorite color is orange and you think it looks cooler that way. So the existing design language systems can be adopted that are out of there. Several companies have made them for themselves and open source them. Use it as a base, extend it, modify it to fit your project. Just make sure that whatever changes you make or being given sufficient consideration and being made for the right reasons. So as design language systems go, pattern flies is the one of choice for a lot of open source projects. It is itself an open source system sponsored by Red Hat. It provides all of the previously mentioned benefits and more. It provides a style guide that explains when to use certain patterns and why to use them, which is extremely helpful. It links to research when it's available. It also provides code for most if not all the elements in their pattern library, which is very helpful for the developers. It offers CSS files for styling, libraries for both Angular and React. And I highly recommend checking out the Pattern Fly React library if you are reactive. They have a storybook available for those that know what storybook is. It's a great way to get an idea of what's possible with a collection of components. The library URL is here. It's not very memorable, so you can find it either on the Pattern Fly React GitHub page or just use Google. Now it's a good testament to how a design language system can promote consistency between products. I wanna show a change that was made recently to Ovir. But first, take a look at the images here. From left to right, we have OpenShift, Manage IQ, and Cockpit. They're not exactly the same, but they're consistent enough that you know they belong together. And if you've used one, you'd fill it home in any of the others. Well, not too long ago, this is what the Ovir UI looked like. It obviously stood out among its siblings. But luckily, in version 4.2, a guy named Alice Wells redesigned it and recoded it to be Pattern Fly compliant. So look at her now. Fits right in. It's that simple. Just follow the guide. The other major tool that helped us really was the UI library, which is React. The plug-in infrastructure dictated the choice. I definitely didn't mind it though. For those who don't know, React is library developed by Facebook for creating user interfaces due to its component-based nature. One of the many benefits it provides is easy reuse of existing code, which was very beneficial for me in this project. And now with all the preliminaries out of the way, let's take a look at what we started with, what once was. So in Ovir version 4.1, there were two primary ways to install it over and host it in and set up. There was the command line installer, and then there was a wizard, which was also provided as a cockpit plug-in. The problem, however, was that the plug-in was essentially the command line interface wrapped in the cockpit GUI. I'm sure there's at least one person out there thinking, oh, what's wrong with that? Yeah, we all have our command line, but what's the point if we're gonna put it into a GUI? We can always go back to the command line. So from the user's perspective, there was really no advantage to using it. You answer the same exact questions in the same exact order using a text box for every single input. And I wanna point out this wasn't anybody's dream or vision of what this thing should look like. This was obviously the result of prioritization and constraint on resources. But it's okay, because it gave me the opportunity to breathe some new life into it, so. Now from the US perspective, there are a number of drawbacks to the approach of wrapping a command line in a GUI. I've listed a handful of the more significant offenses here. And we'll look at these one by one in a moment. But in the end, the major takeaway for me was that if the user wanted a command line experience, they'll use the command line. Little nothing's gained from emulating that experience in a graphical environment. Now one of the most troubling problems with the old wizard was the poor transition between the Gluster wizard and the Hosted Engine wizard. Remember that hyper-converged infrastructure thing I told you about? We wanna push it, get available to the user. So this occurred when the user installed a hyper-converged setup. They would first go through the Gluster wizard, set up their storage, and then it would push them into the Hosted Engine wizard, which is on the right. Now imagine for a moment, the user's reaction going from this on the left to this on the right. I'll take a moment, but this is what I figured it was like. And as I said before, a good user experience is all about the details. Each of the items on the list doesn't seem like it would make that much of a difference on its own, but you put them all together and you have a pretty miserable experience. So let's take a look at the new design and how it solved each of the problems that were on that list. So here's a couple of screenshots of the new wizard. At the time, the pattern fly rat library did not have a wizard component available for me. Luckily the original author of the Gluster wizard had created one based on the style guide and using pattern fly CSS. I was able to use it, which heavily accelerated the starting phase of the project and the pattern fly rat library has since been updated. So they do now have a wizard component available for you to just plug in and go and they have a lot more available as well. So let's look at how this design solved the problems. One of the drawbacks of the old wizard was that it appeared as a never ending stream of questions. The user had no idea how many questions they needed to answer before they reached the end unless they had used the wizard before, but even then due to the state machine nature, the back end that was driving that wizard, if they answered any question differently, that may end up with a completely different set of questions. So it still didn't give them a good gauge. And the new wizard solved that problem by splitting the fields into distinct steps that are clearly marked on a status indicator bar visible at the top of the modal at all times. They always know where they're at and where they're going. The next drawback on the list was that the related fields weren't clearly grouped. Grouping like items is a natural behavior and our brains like the order that it brings. So it just made more sense to group the like fields and place them into steps whose title indicates what type of information can be found there. So it's easy to go back and change something if you need to. It just makes it easier to scan the information for errors as there's less context switching for the brain to do. In the old wizard each item had to be explicitly confirmed one at a time, which became tedious. The new wizard presents the fields in a given step pre-filled with all the default values upfront. So the user only has to enter any desire changes or fill in any empty fields. But aside from that, they can just review all the inputs in one scan and then just move on to the next step. After they complete all the fields in the old wizard, the user was presented with a review of the information that they had entered. But if the user discovered an error, they couldn't just go back and edit that piece of information and continue on in the process. They had to completely close out and then start back over again or feed in an answer file. And it's miserable. So in the new wizard, the user is still presented a preview of all the information that they entered but they can go back and edit the fields as many times as they want before continuing on to the next step. Now, as I mentioned before, the previous wizard used a text box element for every input, regardless of the type of data being entered. There are definitely situations where a text box just doesn't make sense as the input element of choice. I mean, imagine a huge list of things that you can't remember all the different times on codes and all that kind of stuff. So why would you give somebody a text box to enter that information? In the new wizard, various element types were used based on the data being collected, making it easier on the user to enter the information. But more importantly, it reduces the likelihood of errors. The old wizard was limited in the way it could validate information talking about errors. The user would first have to enter information and then they would submit it and then it would tell them if there were any errors. But the new wizard, they would validate certain types of data such as email addresses, IP addresses on the fly. It can also prevent the user from entering numerical values such as support numbers outside of specified ranges. The ability gives the user more actionable feedback more quickly, providing more robust validation experience in the process. The new wizard also allows validation of all the fields on that page when the next button is clicked, we've all come to expect this type of behavior from a form. So again, we're giving them some consistency. All right, so we've got a couple more of additional changes that were made that just overall held the experience. On the left is the original landing page for the plugin. It's not terrible. But a couple of small changes made it that much better. Just falls under the assumptions guideline. Don't assume what your user knows. Just assume the least common denominator if you're assuming anything. So in this case, we added some distributive text under the buttons to tell them exactly what to do I know is small and it's kind of hard to read. But it just kind of gives the user a better indication of what's gonna happen when I click this button. What am I gonna do? And that's always important. We also added an exit confirmation dialog to prevent the user from exiting the wizard prematurely which again was an assumption issue. I didn't think that that would be a problem. When the button says close, you expect that they know if they click the close button that it's gonna close. But it's just something that actually I found in use works for myself as well. We also found out that if you hit the escape button it would accidentally close on you. So imagine the little process could make you pretty angry if you hit the escape button by mistake and it just disappears. So this was a very small change again but it made a big difference in the overall experience. Now shortly after I started development on the wizard I found out that the back end that was driving it was being rewritten from a Python script based back end to one this Ansible based. And the most important thing was that it was gonna go from being able to handle everything in one shot. If I just gave it a list of all the values just run it in one swing to I had to do phases and that completely changed the look and feel of what this thing needed to do. Patternfly saved me because they actually have a pattern specifically for this situation. So I was able to go in there, look at their styling and their code and retrofit the existing React module or component to handle that. And then they changed your mind again and made it a two phase approach. So this is not the wizard we have now but this was a nice interim stop in the middle. But just goes to show that having that library there saved me a lot of time without having to worry about figuring out how to do it myself because I probably would not have ended up having anything this clean and nice. The plugin still has a lot of room for improvement. There's a whole list of changes yet to be made but that's okay. As with other areas of development UX is iterative. You're always gonna find areas that could be better. If you don't, your users will find them for you. So don't worry if you don't see them yourself but what's important is that you're actively trying to improve the user experience of your projects. Second major takeaway from this is the small things do matter. If you neglect those small nitpicky issues it's going to affect your user's overall experience. And we should all know this one by now. Do not recreate the wheel when you don't have to especially if your experience isn't in designing wheels. And I'll leave you with that. Thank you very much. Any questions? Sorry, oh thank you. No? All right, awesome. Let you take over. Ready? Good afternoon. It's 1.40. Let's go ahead and get started. Welcome to my session. It's called What Coding Taught Me About Documentation. My name is Petra Sargent and I am a former software developer and now I am a technical writer with Red Hat. In my talk I will discuss how user driven documentation provides the best user experience. I'll give best practices for writing with the user in mind and writing for a wider audience. And I'll walk through changing content to a user driven approach. In this session I'll cover several topics. I'll first give an introduction. Give a little bit background about me so you get to know me and who I am. I'll also talk about the developer's perspective and their viewpoint. Next I'll describe the user driven documentation and what that means and we'll go over some examples of content that's written for the user in mind. And then we'll look at some content and we'll move from the developer's perspective to a user driven documentation. Okay so first I'll just give an introduction. This picture was taken over 20 years ago and it always makes me cringe because I look at the hairstyle I had 20 years ago. And then also what's funny is if you look on the desk there's a dummy terminal. Does anybody remember a dummy terminal back in the day? And some of you may not even be familiar with it or you've only seen it in movies but this picture is dated and I remember taking this picture because I was so excited. I had just graduated from the university with computer science and I landed a job with a company called Northen Telecom. They had several different name changes and I was hired to develop carrier switch software. So my background is in developing software and for a telephone switch and a switch is something that it provides local connections and local service for your public telephone network. And now I'm a technical writer in the developer teams tools group. Developer tools team we write documentation, customer documentation for Red Hat developer tools and some examples of the tools are Red Hat Container Development Kit which is it provides a pre-built container development based on Red Hacks Linux. And another example is JBoss Developer Studio or Dev Studio which is an IDE. And then another example of a tool is Dev Suites which is an installer. And you can get all of these tools if you join, you can get them for free if you join the Red Hat developer program you just go to developers.redhat.com and you can download these tools and these tools help you, it gives you an environment so that you can write applications quickly. And I wanna spend some time on the tool that I write customer documentation for because I use this as an example in my presentation. This is Dev Suite, this is the GUI for it and Dev Suite is an installer which means that if you are a developer and you're ready to write application you would download Dev Suite and it will provide all the tools you need to write applications. So it'll set up all of the tools you need along with the dependencies and also some third-party software. So this is the installer and I'm gonna, I'll be using this and the examples Dev Suite soler so I wanna make sure that you knew what Dev Suite, what Dev Suite, what it does. And this is part of Dev Suite as well. This is called the selection window. This is where user selects which tools he or she wants to download on their laptop. And for this GUI we use something called Channels or Channels UI and a channel is like a group of tools that are related. And in this example, what's highlighted is the container developer channel and it contains tools that relate to container development such as you have CDK, you have developer studio, you have Oracle Java as well and compose. So that's all in a channel. If you, for example, if you were a Java developer you could click on Java development and then that will have a list of tools dealing with Java development and you could select that and you get to have it all installed on your computer. What I wanna focus on is how do you jump from a developer's viewpoint to a user's perspective? And so that is my focus today and what I'm gonna do first is talk about the developer's perspective or developer's viewpoint. How many of you consider yourselves a developer or have written code in the past? Okay, so it's quite a few. And what I really, really enjoyed about building software is I get to build something and I really enjoyed when it was built and the customer was actually using it. And I felt a sense of pride. It's like, wow, I did that, they're using it and it was not too many, too many bugs but the customer is using it. And so with the developer I was really, really focused on the software. I was focused on the features as a developer and a developer, I did write documentation and you may have, you may the same. I wrote a design document where I described the features and I wrote the data, about the data structures that I'll use in this project. I also wrote code comments and this was all, this is my perspective. It was, my perspective was based on the feature on the project. And I also wrote comments and I also wrote, for example, if there was a bug with the project I would have to write a how to solve this problem. I'd have to also write a description of the problem. So my perspective was from the software and the features. My perspective is this is my product and here are its features. Now let's look at some content. This is actually written from a developer who wrote Dev Suite and he was describing the channel UI and his description, he writes, these are tabs to navigate and every tabs contains a channel description. It also contains a number of available components and components could be considered a tool, a number of components selected for installation and components assigned to this channel and this is a great description of the user interface. And here is another example and this example is describing a problem that was found with Dev Suite and it says, uninstaller detection for locked subdirectories in Dev Suite target install. It's very specific and it says, these are the steps that, this is the steps. This is how you reproduce this problem first. You install using Dev Suite, then you launch Dev Studio, you close Dev Studio and then you go to the uninstaller folder, you right click and then you run with the PowerShell and you get lots of errors. And so this is a very functional description from a developer and this is great. But with user driven documentation, you kind of have to shift with user driven documentation because with that, you describe features from the perspective of the person who's using this feature. And for example, for Dev Suite, uninstaller, a user would be an application developer or could be a plugin developer. These are all users for Dev Suite. With user driven documentation, you've used the situation from the perspective of the user. You focus on the outcome or the goal that's perceived by the user. Now I like to use this analogy. This is a cockpit and suppose you're our pilot and you have two sets of documentation. You have a set of documentation that describes the switches. It gives details about the switches. And then you have another set of documentation that tells you how to fly the plane. Better yet, what's the best way to fly the plane to the destination? Now, which documentation would you wanna use? Your pilot, which one would you wanna use? The second one, yes, how do you fly this plane? So it speaks to the goal of the user. So let's look at an example of user driven documentation. So with this documentation, we're describing the channel UI that I talked about earlier. With the channel UI, let's read it together. It says, you can select components for installation by channel in the navigation bar. And in this example, the channel navigation bar is actually shown in the top right with the number one. And it's actually pointed to it. And it says that the following channels are available on the selection window. And it lists all the channels, container development, Java development, fuse development, red hat products. These are the list of the channels. You click a channel to view the channel description, the number of components. And in the actual content, you actually see the number two, which points to the channel description and number three points to the number of components in the channel. And then you can also select, select all to select all components in the channel for installation or click clear all button to clear all components. So it's really talking about the goal of the user, which is to use the channels in order to install software on their computer. So it's more written towards the user versus actually describing the function of the GUI. Now, here's another example of user-driven documentation. And this is example of a problem and a solution. And with this example, the title is actually, there's a message for a locked folder. And the description is, you may get a folder that is locked in this scenario. And then it lists the scenario. It says, first you install the Dev Suite, then you install the Dev Studio. And while after you install the Dev Studio, you start it up. Then after that, you install Dev Suite from the Windows Control Panel before closing Dev Studio. And now what happens that it's a message that shows the locked folder. So it's more in terms of what the user would see with this problem. Okay, so now how do you move from a content that's more written as a functional description to one that focuses on a user? Two things, you have to really understand the user and then ask questions. So how do you understand the user? One technique that you can use is called personas. I don't know if anybody has used personas before. Yes, personas. Okay, so persona, what that is, it's a fictional user based on real user data that explain how users behave, think, what they wish to accomplish and why. And let's see an example of a persona. Now this is fictional, it's all fictional, but it's based on user data. Now here's the example and you can really have fun with a persona and you can have a picture. This is all fictional, but Diane, it says this is persona, she is a open stack developer working on extending the API and writing applications that run on top of an open stack cloud. And then you can provide a biography with that explains the skills that she has. She's familiar with Linux, several years of programming. You can also go into the behavior patterns that she would have. She, Diane is a developer working for a major player in IT. And then also you can talk about her goals to develop useful applications to interface with open stack and possibly contribute upstream to open stack. And you can take this even further, the persona and add more detail. Now this is a lot of detail. It talk about her needs and it's an exercise to do as you're writing content, really knowing, get to know who your user, who your user. And you can also talk about the attitudes of the user, the beliefs and also the workflow. So it's a lot of detail. And as you write content, you can ask these questions. What is the user trying to accomplish here? What does the user need to do? And what concept does the user need to know to do this? These are the questions that you can use as you're writing your content to make it more user driven. So now let's walk through an example where we're changing content that's written as a functional description to a more user driven approach. Okay, so now let's go back to DevSuite. And this feature, this feature checks for installer updates. Now for example, if you were a developer and you wanted to get the latest tools, you would download DevSuite and DevSuite could provide the latest tool only if you're using the latest versions. And so with this feature, this is a description that a developer wrote. They said the new feature checks for installer updates availability. And as you see, I don't know if you can see at the very bottom, it says checking for DevSuite installer updates. And it says if a newer version is available, at the very bottom, it's highlighted in red. It says DevSuite installer two point is available. And then the next page says if the version is up to date, then it's highlighted and I probably can't see it from the back, but it's in green and it says, oh now the DevSuite is up to date. And so that was content that was written by a developer. It was very functional and it was describing the feature. So now let's change that functional description to one that is user driven. So the first thing we're gonna do is we're gonna understand the user and then we'll ask the questions. So here's the persona of the user, DevSuite. Her name is Allison. She's a junior developer who wants to build applications really fast. She's familiar with Linux. We talk about her goals to develop useful applications and possibly contribute upstream. And her needs are to document methodologies or tips on producing Java applications. She needs clear, accessible information on component dependencies, requirements and versioning. So as we write our content, we have this user in mind and we ask these questions, well what is Allison and what is she trying to accomplish? She wants to install software tools from DevSuite. And what does she need to do with the DevSuite? She wants to update the DevSuite to the latest version and what concept does she really need to understand? She really needs to understand the software download versions. And so as we write our content, we have all those things in mind. And here is how we could rewrite this to be more user driven. This is just one way. We can title this, welcome window allows a download of the latest development suite. To get the latest software tools, you need to have the latest version of DevSuite. The welcome window shows if a newer version of DevSuite is available or if it's up to date. If a newer version of DevSuite is available, you can now download it from the welcome window. And then we have point outs here too where we're actually pointing to the GUI. We're pointing to here where it says a new installer version is available, is in red. And then we point to this button here that says download here. This is where you can download the latest DevSuite installer instead of downloading it from developer.redhat.com. So this is more written with the user in mind at this point. Okay. So what coding taught me about documentation is that as a developer I wrote for other developers and I wrote for other subject matter experts. But what I learned as a technical writer is that documentation should be written to address a larger audience, including the user with them in mind. If the document is really, if it's too complicated then no one will use the product. If it's too complicated, but if the user understands the document, they're more inclined to use the product if they understand the documents. Documentation written with the user in mind really provides the best user experience because you're writing for the goals of the user. So the, I'll leave with this quote, the desire to write grows with writing. Are there any questions? The tech writer would actually, so you're asking about the change. If there was a change in DevSuite installer to the GUI how would you handle that? Okay, so with, at Red Hat we have like release notes that talks about the differences in the GUI and with there you would explain how it would change from one version of DevSuite to the next one and you'd describe it in the release notes and it would be in the, you would write it in terms of the user, like the differences that they would see and point out all the differences in the GUI so that they would know. That's correct. Yes, yes, yes, that's correct. I wouldn't, yep, that's correct. Yep, are there any other questions? Yes, yeah, it's challenging to convert from developer style documentation to user driven documentation and I find out the best way to understand what the developer is, is to actually set up some time to talk to him where I can ask them questions. The questions that I had in the presentation, like what is your goal here? What does the user see? And once I ask a developer, like what does the user see in this case? That really helps with getting the information I need to write the content. That is key to ask them, what does the user see? What's the goal of the user here? And then once I have asked those questions it provides a lot of ground and we can really have a discussion and it helps me to convert it to user driven. But I think that's key though, to really talk technical writers and developers yet really should talk. Yep, most definitely. Are there any other questions? All right, well I thank you, thank you. Thank you very much. Test, test, test, sorry. Lower everyone out of the room. How's that? Can you hear me in the back there? Yeah, all right. Okay, thank you for sticking around so long. This is it, we'll try to make this as painless as possible and hopefully maybe you can get excited about the subject as I am. So we're gonna talk about containers and your web application or something I like to call a micro spa, which is not a little place where you can get really relaxed but a nice way of deploying a web application. My name's Dana Guthrite, I work for Red Hat as a front end developer slash architect, lately focusing mostly on the pattern fly project with the UXD which is our user experience and design team within Red Hat. So we're gonna talk about how a pattern library can match up with a container infrastructure and what this means, how this can really help to build a large scale enterprise application. So we'll cover why use containers, why do they make sense for web applications and not just Java or other sort of applications. So why they make sense in that area but what problems exist today? What sort of challenges do we have building single page applications and with the frameworks in the ecosystem and then what can be done about those problems? We're gonna talk about pattern fly, it's already been talked about a bit today but this is a subject that we have a lot of strong feelings about and we hope to have other people feel strongly about it that they can be excited about the prospects of it, what it can add as a value to implementation and then what does this mean when we pull them together, pattern fly along with containers and Kubernetes, is there a way to really make those all work in the same environment? So first off, containers, why are they helpful? Why do they make sense? It's good to talk about why are containers different than the way we used to host web applications and you see the left side, the old way, with applications running on the host that the libraries and the kernel, everything has to be the same across your deployment and that would mean if you were targeting different versions of Node or you had different libraries you were depending on, it became very difficult to separate those out. So containers in a Node ecosystem, when you're thinking about a web application, allow for different versions of Node.js to run. Maybe you have an older version, you're running something in Node 6 and then you have another one running in 8 or 10 and you wanna have some variability there and because they're small and fast and portable, you don't care about where they're living and you can just bundle the libraries along with the application. Containers really help in that sort of environment. Why use containers? I'm not gonna read all of these, I've got this from kubernetes.io talking about what is Kubernetes and they just list point after point. It's worth looking at that because it's really fascinating. You start to think about all of the benefits to moving to a containerized infrastructure and ecosystem, not only does it really turn into an agile environment which matches our development systems, but we see how quickly we can turn around code and get it deployed, continuous development, integration, deployment and that makes a big difference for our developers, our turnaround, being able to get things back in front of designers so they can see it and we have a real fast turnaround cycle because of that. Another nice thing that happens is that I'll point out that third point about the separation of concerns from developers to operations. Maybe we used to say, okay, I'm gonna build this application, we get all the code already and then we have to go and find someone who can get it somewhere for us and that became difficult because depending on where those people were a lot of times they're very hard to locate in a system because maybe we only hire one or two for a really big team and they're managing all of this server infrastructure but now when developers have more control over it it allows us to scale that out, our deployment in a much more meaningful way. I like that third to last point too at the bottom that they're loosely coupled, distributed, elastic, liberated microservices and it makes me laugh a little every time I read that but when we think about that idea of our services and single page applications being liberated they can go wherever they need to to work but that mindset then translates to the way developers feel about what they're building. They say, okay, I'm not locked in to these environments and these old rules and they have a lot more flexibility with what they're doing. So there's a lot and I'd again recommend just that site is great. Kubernetes.io and we think of OpenShift as an open source version of Kubernetes so learning Kubernetes is a really good basis to understanding what OpenShift is doing. So containerizing a single page application what does that look like? Is that difficult? So I went through that entire process for this and I wanted to walk through it here live because I like the challenge of that but what I'm gonna do is show a video of it being done because it takes about 13 and a half minutes end to end to be able to create a containerized application deployed on OpenShift that's ready for development and we'll show that and talk about it a bit in this video here. So to sort of set up what's about to happen we have a GitHub repo which probably all familiar with that and what's inside of the repo is a project that's been bootstrapped with create react app. So this is the welcome to react application you run it and it runs through three or four minutes of pulling dependencies and then you end up with this output which is the starting point for many react applications. So then how would you containerize this? Let's watch that process and we'll talk through it. So showing the repo here and the first step is going into OpenShift and OpenShift has a catalog that includes a template when we're in here I already pre-created a project to host it and there's a new template that we've created and we hope to introduce to OpenShift too and that's specific to single page applications and you'll notice we called it pattern flight demo app and it's really simple the wizard here there's only gonna be two pieces of information we absolutely have to provide. One of them is a name which is already given as an option and then the source URL so this uses source to image functionality within OpenShift and it's gonna take this GitHub repo and we're gonna see we're gonna provide the URL. Look at a few other things, it's on the right branch and we're gonna click create and off it goes. So really simple, only only really need to know one piece of information if you have a react application that you wanna run on OpenShift. Now this next part takes, oh boy let's see three or four minutes so I fast forward it a bit through it and you'll see that it creates in OpenShift a target URL. So this is a public URL that's now where the application's gonna live and you saw it's not there yet. So we're gonna wait for a build to finish as we see this happening and then hopefully we'll get to a deployment which is a pod that's running an instance of the image that's been built for us. And as we watch the build running we see the build happening here, the service has already been set up targeting and now we're gonna see the pod get created and it'll scale up to one pod and we see the deployment happening and that's way faster than it happens but it's still pretty quick. This may be what three or four minutes generally to see this and now we're gonna see the react application come to life. So we've sped that into about a minute, two minutes here. So I'm gonna pause here, just talk about what just happened. So as a developer that's amazing to me because I was like oh great now I can do something with this application and I don't have to go and find a person to help me deploy it somewhere. And the other thing that helps in a design team is I can deploy what I have and ask designers to give immediate feedback, say okay this is what it looks like live and instead of having to send them screenshots of what I've done or to basically set up an environment somewhere else for them manually and then it goes down and there's all this difficulty they have an easy way to connect to things. So that feedback cycle just for development can be very quick and it's not a large overhead for developers to work this way. But there's one more step that I love using this environment for and that's I wanna make sure every time I push a change to OpenShift or to GitHub that I have an immediate update in my application. So what's that look like? That's the second part of this video. So within the build you'll see it's looking at GitHub for the source but I can get something from OpenShift called a webhook URL and that's going to be a way that you can connect GitHub back to OpenShift. So back in GitHub I go into my settings and I'll go into webhooks in here and I'm just gonna add once I find it. I'll add the webhook and I turn it to a JSON content type and that's it, one, two clicks and now I have a connection from my code back to my deployment. You see it's ready to go and this next step I'm gonna go and just prove that this is actually connected. So I'm gonna go into my React application locally. I'm gonna change the title text here so that it says something different and you'll see once it's saved there's a, it's running locally. You see it on localhost 3000 and you'll see it's updated. So after this we're gonna just push this code back right up to GitHub and this would have been fun to do live but you never know what a conference do. So as it's gonna commit and then I'll push, get my push command correct and then this is where the magic happens. So we're gonna watch another build get kicked off in OpenShift and it runs through, recreates the image, pulls the code and this is pretty neat because once this build is done you see how the scaling of pods happens? It's keeping our old deployment live until the new one is ready and that's what you see happen and I just switched over to show it. Okay, it still shows welcome to react but it scales it over and now this is the new pod that's ready to go and as we go back to the application we're gonna refresh and it takes a second to kinda recache and rebuild internally and now it's available live. So that's something that personally I think is amazing that a containerized infrastructure can give you that so quickly. Start to finish 12, 13 minutes and just as a sort of an example of why this is so neat this is just this last week we started another project within our team and part of their goals is to have the application deployed on OpenShift within the first 24 hours so that they could do an immediate feedback cycle and we showed them this template and said just set up a react application, point it here and within a few minutes you're gonna have a template that's ready for development teams to work collaboratively and have immediate feedback for your designers. So that works really well when you're trying to say let's iterate quickly get this in front of people and you lose all of that setup time it's just dropped down to a point where you don't really even have to think about it because it happens so quickly. So that's a react application running on OpenShift but the next thing is okay so how does that solve enterprise problems? We said we were gonna talk about pattern fly a bit but before we do that what sort of real world problems exist with front end development? We're gonna talk about a few that I've seen and maybe if you're in that space and maybe I'll ask how many people are do front end development or JavaScript development on a day to day basis? Okay and then any that are like focused just on HTML, CSS? Okay cool and that's so some of these problems are probably gonna be very familiar depending on the size of your team and the discussions you have on a regular basis. So that's have you ever seen an image that looks like this and what this is doing is comparing JavaScript frameworks which is the bane of my existence. We talk about this all the time so which one's better or any of them better or which one's worse or maybe this one and say okay well how many downloads does it have and we start going through these exercises where we look at search engine statistics for JavaScript frameworks and depending on how you ask the question of the search engine is going to largely bias the results. So knowing what the answer is is really tough to say which one's better which one's worse this one's obviously skews it one way or the other this is probably not even accurate if I had to this is probably just because someone asked a question in a certain way and it came back focused on Angular because they made it broad enough that it captured all of the Angular versions if I had to guess. So we waste a lot of time discussing which framework is best and this is what it feels like a lot of times like we're just going around in circles we have no idea how to get off the rotary and figure out what direction and the other part is there's a lot of fear and uncertainty that comes with that because even when we choose a path we know that someone else is writing a framework right now that is going to be better than React and View and Angular and jQuery and all of these other things that have come before it because they're learning as we go and this ecosystem is evolving so quickly that people in three months you can make a great decision today but three months from now you throw it all out the window and you have no idea like when something else may come along and all of a sudden you can't hire anyone that knows that language that you picked just a few months before and this is sort of what it feels like when I think about it in my mind like okay this is the one that's bubbling to the top right now React is pretty popular but what about web components? What's happening in Angular? Is that kind of shifting back? What about View? People are talking about that so there's all of this conversation and it's just noise that's in reality a distraction for development teams and I'll tell you it's even worse when you get outside of the development organization up to management and then executives in a large company because for them this is a business problem because it's distracting development teams from moving forward effectively. The other thing that happens is with legacy sites maybe you've seen a site that was built on Ruby, it's 10 years old and they don't want to touch the code and rightfully so because it's been working and it's been tested and it's deployed in hundreds or thousands or tens of thousands of customer sites and modifying code has a huge cost to it but you come along and someone says well we need to add this section to that code base so what do you do with it? And then maybe it feels like this to you where you're like well maybe you start with a house and you know you need to put on a massive building or maybe you start the other way and you're like well I just need to put on this little shed that can take care of some of my utilities but you're left feeling like this and the reason I love this picture is because if you're an architect or a builder or someone with a design aesthetic and you look at this, how does it feel? Not great, right? Because you walk away saying well this kind of destroys the neighborhood because the entire neighborhood is supposed to be small wooden sheds and now we have a factory attached to one of them or the other way around. So it's not a great feeling and developers feel the same way about their code as builders do about the houses they put in. And the other challenge is sometimes we just don't have anyone left that knows that old technology that can even work with it. So it creates some difficulty that way. The other thing that happens on teams is sometimes the same things get built over and over again, copy and paste is happens but then people start changing little tiny pieces of what that, they start with this list view and then they put it over there and like but I need a column header and then someone puts it over there and I need alternating colors in my rows. So you end up with 50 different versions of the same list or a hundred types of buttons and they're inconsistent throughout. There's a common exercise that happens where people will go through a site and they'll do a component cut up and they'll pick out different pages and cut the components out and then they lay them all out next to each other and they try to figure out, which one's the base component and it's really difficult to do. The other thing that sometimes happens is developers and designers ask the same questions over and over again. How is this supposed to look? What's this behavior supposed to be? And if there's not a way for them to get that answer, that generally becomes lost time and effort. So this is where design systems come into play and I found a quote that I liked, a design system acts as the connective tissue that holds together your entire platform and we've seen that and I'll show some examples of how when you introduce a design system to an enterprise across multiple applications, it starts to create a similar look and feel to many different products so it becomes easier for that cognitive load for our users so that they can benefit from that. So we introduced pattern fly and maybe you've heard of it before and just out of curiosity, how many people here have heard of pattern fly? I have a few, okay. So we'll give a little overview. This is an open source project that was started by the Red Hat UXD team and our first release was back in 2014. So it's been around for a little while. What is pattern fly? Pattern fly is a community project that promotes design, commonality and improved user experience and it's not just documentation, it also includes styles, code and a community. So that's an area that we really work hard to foster and try to introduce new people to the community and work with them to understand what problems are they trying to solve with pattern fly or what is painful to them when they're using it or questions we like to ask on a regular basis. So this is what some of our Red Hat products look like back before pattern fly came along. And we see they all have, they all obviously look like Red Hat. We see some red throughout most of them and there's Shadow Man here and there but they don't look like the same family of products. So after pattern fly was introduced, this is the look and feel of these products now and we see some differences but again, much more consistency. A user's not gonna have so much difficulty moving between applications. So then what does this all have to do with containers, right? It feels like we just took a left turn in Albuquerque and how are we gonna get back? Talking about OpenShift and Kubernetes but does a design system make sense in this area? So when put together, it can help quite a bit with using containers and pattern fly at the same point. We're gonna show how can that help. So this is something that we've been doing a little more internally. Within OpenShift, adding a proxy allows you to redirect users to different portions of the application and you can even have different containers that respond to those requests. So a lot of times what may happen in OpenShift or other web applications is you'll see a proxy layer welcoming people that is accepting requests and it just sends them to one application. But when you're using a design system, you can have multiple applications that are all styled the same way behind your proxy and they will look and feel like they're part of the same application. So let me show you what that actually looks like. So here in OpenShift, you see I have two applications. One of them is a React demo and one of them is an Angular demo. So this is an Angular application, Angular 6 and React and they're both styled using pattern flies. So this is what they look like when together. So this is our normal pattern fly three look and feel. And then this is obviously a React application. But say I want this portion of the application to be written by an entirely different team. They're in a different location. They don't know React. They only know Angular or they only know View and you've just brought them in you say but you need to be able to work quickly. Do we force them to learn React or do we say let's just have them use the same pattern library? So when you click on this part of the application, you notice at this point now we have a pattern fly style page but everything else looks the same. Even though every single one of these components on this page, if you were to inspect them is all Angular now, there's no React on this page. And they can move back and forth between those parts of the application without any challenge. Now this also lets additional things happen. So these are behind the same URL. And the reason I highlight that is in terms of browsers that's significant. That gives them the exact same security context for their website. And what that means is you can store things in local storage that the other application has access to without any problems because it's at the same host. So you start to say okay well what can we do with that? There's plenty because even though they're separate applications they're running in the same context both in the browser and in your host environment on OpenShift. That lets you take OpenShift to another level as well because you say well maybe I wanna have state serialized in something like Redux. You could host Redux in another node container and keep that outside of these applications and start to have a centralized state management. And you can think about now you have all these possibilities are endless where you can scale out your container infrastructure to do whatever these applications need. And maybe there's a Rails application that sits here and you start extending it with React containers. And you can think about the possibilities in this sort of environment with distributed teams that have to work at different schedules and their own pace. You can deploy individual containers at different release cycles. It allows for quite a bit but the key thread is because they're containerized and styled with the same look and feel you have a great deal of possibilities there. So I wanted to show that as a demo. You get a feel now that this application here could be made up of a dozen different containers with a dozen different library choices or versions of things. And you're not forcing the business to have to make a decision about when to release things. Sometimes framework choices end up holding business like tying the business hands of they're saying well I don't wanna be forced to have to make that decision, I wanna release next month. And if developers are pushing something that can really cause some problems that way. But it gives a lot more flexibility in this sort of architecture. So I wanted to show that demo and then that brings us to our end. So thanks to the pattern fly team. And also we showed use of a new image that's still in beta that the Bucharest gold is under that community if you're interested. This is the node team at Red Hat that we've been working closely with. And it's still up and coming but that gives you access to be able to deploy single page applications to open shift very quickly. And that hasn't existed up until very recently. So if you're interested in that I would look under the Bucharest gold project as well as on patternfly.org and on our GitHub project we have an example of this in our React demo app. So that brings us to the end. I don't know if anyone has any questions. Silence, golden, yes. So that's a great question. So pattern fly three, the one that's been around for a while was based on bootstrap. And the theming is it in abilities within pattern fly three are limited mostly to colors. So you don't have a great deal of variability with that. We were working on pattern fly four which you'll see on the pattern fly next repo soon to be merged back. But that one allows a great deal more theming options and it's a more modular approach to CSS. So it's meant to provide a lot more opportunities like that. We've also decoupled from bootstrap so that we're not tied to their release schedules and their decisions as we move forward. And then the other reason that we're really looking forward is everything in here with style with pattern fly three but moving forward to pattern fly four it's an updated look and feel and accessibility and responsiveness were viewed as first class citizens in the design process there. They're not afterthoughts. So those are things that we've put a great deal of emphasis on. And then you mentioned as far as the frameworks go we've provided a react implementation an angular one and an angular six implementation pattern fly also exists out there. I think there's also a community contribution of a view a version of that as well as a jQuery set of widgets with pattern fly four we're focusing on react to start because that is it does appear that that's where things are coalescing right now but depending on what the community does we generally we start with CSS and HTML because that is the common that's our common language react is just our primary implementation we don't view that as the common platform for everything. Any other questions? Nope. All right. Thank you very much everyone.