 Oh, we figured that out. Yeah. Low talking does nothing on this thing. 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 Ogret 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 Ogret. This presentation is going to 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 going to go over all that in just a moment. I want to point out I don't consider myself a UX expert at this point. I don't really know that many of 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 pretty much drove this by myself. And when you do that, you have no choice but to put yourself up by the bootstraps. So I 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, let's take a quick look at what we're going to cover in this presentation. So let's 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 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 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. We don't have a lot here. How many here have used OVIRT in any capacity? OK, good. I'm actually going to teach something. Oh, we've got two. Sweet. How many have actually installed OVIRT using the command line? And how many have installed it using the Cockpit Wizard? None. All right, great. OK, 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 get you up to speed. You're going to hear a lot of names of different projects throughout this talk. And I just want to make sure that you don't get lost on me. So we'll start with OVIRT. OVIRT 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 OVIRT 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 an older talk by Daron Fedeuk about the chicken and egg problem the host that the 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 hyper-converged 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 plug-in 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 for 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 tap 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. It's 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 just 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 stoplight. You're driving down the road, you see a stoplight, 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 a different orientation of lights and nobody told you what to expect, you're going to 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 going to be a little bit lost. The second kind of principle is around assumptions. And we all know the old phrase, OK, 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 going to go through it here because I'm going to keep this clean. But 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 simply come about when you're trying to be lazy. You don't want to fix it. You know, the little thing would make it that much better, but you just don't want to 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 kind of principle focuses on simplicity. It's time just appropriate to have a cluttered and busy user interface. If you have a dashboard that's displaying information, it's just meant to be taken in in a glance. That's fine. That's one thing. You don't want to overdo it, but it's OK 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 brainpower 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. You may have heard the old adage before, a good craftsman never blames his tools. 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'll 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 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 if it's 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 there. There are several companies have made them for themselves and open sourced 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 fly 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 URL's here. It's not very memorable, so you can find it either on the pattern fly react GitHub page or just use Google. That was a good testament to how a design language system can promote consistency between products. I want to 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 a 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 considerably 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 plaminaries out of the way, let's take a look at what we started with. What once was. So in Ovir at version 4.1, there were two primary ways to install it over at hosted-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 going to 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 want to 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 OK, because it gave me the opportunity to breathe some new life into it. 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 or 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 cluster wizard and the hosted engine wizard. Remember that hyper-converged infrastructure thing I told you about? We want to push it. We want to make it available to the user. So this occurred when the user installed a hyper-converged setup. They would first go through the cluster 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 cluster 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, they 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 up front. So the user only has to enter any desired 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 time zone 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, 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 port 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 helped the experience. On the left is the original landing page for the plug-in. It's not terrible. But a couple of small changes made it that much better. It 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 it's small and it's kind of hard to read. But it just kind of gives the user a better indication of what's going to happen when I click this button. What am I going to 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 going to 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 other 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 going to go from being able to handle everything in one shot if I just gave it a list of all the values, just running 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 their mind again and made a two phase approach. So this is not the wizard we have now, but this was a nice interim stop in the middle. But it 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 with anything this clean and nice. The plugin sells a lot of room for improvement. There's a whole list of changes yet to be made, but that's OK. As with other areas of development, UX is iterative. You're always going to 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 will when you don't have to, especially if your experience isn't in designing wills. 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. Hello, hello. Can you hear me? How low is it? Is that low? I can kind of hear. It's not sensitive. What's that? Put it really high on the collar and then just speak loud, but that should be OK. Hello. Can you hear? Not really. It's not captured. Where'd you put it on? I didn't see it, so. You put it right here. I buttoned my, yeah. You had to bite it. I buttoned the top button, but I forgot about it. Oh, OK. I really want to hear your presentation, but I have to take him to eat something because we didn't get much, and he's going to kill me if I don't feed him. I'm not the catchers on YouTube, so I really wanted to hear it. I love good technical documentation. I hate when people write crappy documentation. Yes, oh my gosh. And now I'm trying to teach developers how to write. Hello, kind of sorter. Hello, hello. Yeah, that's good. OK, so here, you can take this, and I don't want to risk HR, but I like to just put down your belt, or your pocket, and you got everything up there. Yep, everything is good. I think it's good. This is Libra. This I'm using well. Yeah, Libra. Yeah, yeah, I like it. I do like it a lot. That's why I wanted to use my computer. Yeah, the speaker notes. I know you're like, OK, I carry it, yes, yes. I put my glasses on. I was like, oh man, I really Yeah, yeah, yeah, so this is good. All right, thank you. Yeah, after this, I can relax. You're on rail, you gotta be. Who said? I know, that was me. I was like, can I go home? I hate to hate to I can relax. I know, I know, I know, I know, I know, I know. Last time I've been stressing it, because I'm the type of person I'm going to keep working on something. Yes. To make me turn to the end. Yes, yes. And then you're pulling up my fingers, but, you know. Right. I'm just going to do it on Friday morning and then I can just go to my house. Yes, that's what I was saying. I know. So the next time you expose day one, because we got stuck. That's right. All right, I think we're in your timeframe. Yeah, okay, nice meeting you. Nice meeting you, Phillip. Sure, long time. Yes. Where are you at? Where are you based out of? In Raleigh. Okay, me too. Okay, yes, yep, on the tower. Yep, the 11th floor. I don't have a problem, but I need excuses to go to the tower. Yeah, that's right, we do the tower. Yep, that's right.