 OK, y'all, we're going to get this party started. So hi, my name is Maurice Hayward. I'm a UI developer at Ferguson Enterprise in the United States. I think here in Canada, it's called Wozly Canada. And I work on internal applications, internal web applications. And so I would like to talk to y'all about how I learned about user experience and what happened when I started talking to my teammates about it. So while I was creating this slide deck, I was watching Beyonce Homecoming. So that's going to jump out, oh, no. So user experience is about the experience a product creates for the people who use it. So let's say, for example, a product is slow, cumbersome, or unreliable. Then most likely, it will create a bad experience. On the other hand, if a product is reliable, if it's usable and very intuitive, it can most likely create a good experience for the people who use it. So before Revolution Conference, so this is a conference last year, 2018, I had no idea what that term meant, user experience. So I would like to first talk about my experience at that conference. And before I do that, I'm just going to just talk a little bit about RevCom. So it is a language-agnostic conference in Virginia Beach, Virginia, in the United States. And it was my very first conference I went to in 2017. And I try to go to it every year. I call it my home conference. So I really love it. So let's talk about that conference. So the very first talk I went to was by Chris DeMar. And it was called Focusing on Focus. And this quote right here that he mentioned during the talk floored me, y'all. So it says, 20% of people have a disability. So accessibility is a must, even for internal applications. So after this was said, I actually felt personally attacked. Reason being is I worked on, again, internal web applications. And I believe at one point, I reasoned within myself that I didn't really have to think about accessibility because my project wasn't customer-facing. And by the end of this talk, I realized my wicked reasoning was incorrect. So side note, did y'all hear about that Beyonce.com debacle? You don't hear about that? OK, so a fan couldn't use Beyonce.com using their screen reader. And this led to a lawsuit. And so I'm going to spill some tea and read an excerpt here. So it says, defendants are denying blind and visually impaired persons throughout the United States with equal access to the goods and services Park would provide to their nondisabled customers through www.Beyoncé.com. So this is just one example of how not thinking about accessibility can be quite costly. And personally, I don't want everything I own to be on the box to the left. The next talk I really appreciated was by John. And it was called UX for Developers. And I really appreciated this quote. It says, UX, user experience, the debt is technical debt. And this is very true. So let's say we don't make user experience a priority on our team. We can slowly be introducing small usability user experience issues. And all these small issues together can make our whole product really unintuitive or hard to use. It can create a bad experience. On the other hand, if we decide to tackle some low hanging fruit, some really easy usability issues, we try to go ahead and fix those really easy ones, then it can greatly improve the usability of our product. And another quote from this talk, UX is everyone's problem. So everyone on the team, whether you're a BA, a quality assurance analyst, a developer, which we are here, and or a designer, you have a responsibility to think about the experience your product creates. And the last talk I really appreciated from that conference was by Aisha. It was on web accessibility. And this talk was full of gems. So she went over some practical guidelines and checklist to follow in order to improve the accessibility health of your website. But what I also really appreciated was this quote. Accessibility make life better for everyone. So this is very true. So let's kind of illish grade this. So do y'all remember this dress? Like, it was a media frenzy. Like, no one knew what the colors were of this dress. And you can imagine, like, if we had this dress in an article, and it would be, if we just had the image, it would be very hard to understand the author's intent for this image. So let's say in that same article, we just simply add a caption to that image. The caption reads, the actual colors of this dress are blue and black, but many people see it as white and gold. Just by simply adding a caption, everyone, including those who use screen readers and those who don't, will be able to understand the author's intent for this image, which was hard before because of the optical illusion. So this is just like one of the many examples of how just thinking about accessibility helps everyone. So after this talk, I was super inspired, y'all. I was very inspired. I felt like Beyonce. I may be young, but I'm ready to continue digging deeper into UX and tell my teammates about it. So let's just see how that went. So before I do that, I'm just gonna talk about the makeup of my team at that time. So again, we work on internal web applications for our organization. We had a BA. His job is to take business goals and turn them into requirements. He also created our project mockups and he did them in Microsoft Paint. And they looked awesome. So yeah. We also had a quality assurance analyst, QA. So she takes those requirements and then creates test cases. And then she ran through them using a combination of automated and manual testing. And at that time, we had three developers, including myself. We take those requirements and we implement them using web technology. So HTML, CS, CC, CSS. And JavaScript, AngularJS, and so on. So these are my teammates. So after the conference, I told my team pretty much everything I learned about UX and accessibility. But I also mentioned this, that I think user UX and accessibility should be a priority on our team moving forward. And we should allow time for it. So surprisingly, they were actually really excited and they agreed. And I got to hear about so many different experiences that they had. For example, one of the other developers, he used to work at a bank and he was a developer for them. He had to make sure that the website followed the government web accessibility guidelines. So just right on my team, there were already a wealth of knowledge on this subject. So the next thing I needed to do was talk to my manager. So again, shared my thoughts, what I learned at the conference, and I said, I, sorry, y'all. And I mentioned how I think accessibility in UX should be a priority. And she agreed. So I was like, hey, cool. But notice what she mentioned next. She was like, hey, Maurice, you know, you already been doing some user experience work, right? You already been doing that. And I was like, wait, what? What do you mean by that? I was already doing some UX. And she mentioned, yeah. When you were working on making sure that the application was responsive, you were thinking about the users. You were doing UX. And I was mind blown. So that was very true. So when I first started working on the project, I noticed that the application worked really well on desktop. But when I switched to my laptop, everything didn't look as good. So later, another front end developer and I took the initiative and convinced the business owners to allow us more time to refactor the UI into components and update the styles to allow for responsive design. So by doing this, we were letting the users be able to use the application in all screen sizes, desktop, laptop, tablet, and even on mobile screen sizes. Another use case was just be able to take the application and put it in half screen mode. So we were improving the user experience of the application. We were doing UX without even realizing what we were doing. So now, oh, so this goes on to the main point of this talk. When you, yes, you make decisions based on the need, feedback, or analytics of your users, you are doing UX. So now that our team was more conscious of why usability and accessibility was important, we needed to go ahead and just be more intentional about it moving forward. So I tried to take the lead in that. I read some resources on UX and design, and I will talk a little later about some of those resources that I really appreciated. But just reading a couple of books did not turn me into an expert. So I wanted to get some expert advice on this. So I'm on the IT side of my organization, and I found out on the business side, they have designers and UX professionals over there. I was like, I didn't know that. So I was able to schedule a meeting with them and invite my whole team and a whole bunch of people from their team, and they just went through our whole application and just gave us a whole bunch of tips and tricks and actionable advice. And everyone took something from that on my team. So I'm gonna go through what we learned. So first, let's talk about the BA. So again, the advice that we got about usability and UX was very helpful for him, because again, if you all remember, he creates our mockups. So now he's more conscious of making sure interactions on that site are consistent. So what's the interaction? This is probably a bad definition, but anytime a user interacts with your website, so some common interactions, clicking things, clicking buttons, typing in an input form, those are some common interactions we have on a website. So let's go over an example of this. So let's say, for example, you have a eCommerce site and you have the user submit their product to the cart. And so they look at the product, they click the submit button and it adds it to the cart. Let's say on one part of the website, it is a blue button. And on the other part of the website is a red button. They do the same thing, they have the same functionality and they use for the same purpose, but they have two different colors for some reason. Well, in this case, the style isn't consistent. So unless you have a really special reason for it, I would definitely look into making those one style. Because we don't want the users to think, we just want them to add the product to the cart and buy it. The next thing he worked on was making our wording more user-friendly, especially when it came to our error messages and tool tips. So this is very embarrassing, y'all. So this was an error that we showed to some of our users. So this is, again, a very embarrassing. That's scary, y'all. We didn't know no better. So or.apache.solar.common.solarexception, colon, error during request authentication. So, again, if you're a user, this is not helpful. It's really scary. So we were able to change it from something like this to this, unable to retrieve product info, colon, solar server error. So again, the user is able to see, okay, we're not able to get the product information and there's some type of error with the server. And as a developer, if we need more information, well, we log everything. And we can also use the developer console in our browser to dig deeper if we need to. And this was just actually the first iteration of it. We later found out that we can improve on it even more. So these were pop-ups. Later on, we decided to make them in-page messages and be more useful for the user. So like, oh, you see this error? Maybe you can do this or do this. Or you can contact this person if you need some more assistance. So it just goes to show how user experience, it's a process, it's a continuous process. We're always making improvements. Okay, now I'm gonna talk about the other developer on my team. The first thing he worked on was making sure we only show important information on the screen. So in our application, we had a whole bunch of tables, like a lot of tables. And all those tables had a lot of columns. So one thing he worked on, if the column is not important in this scenario, or if the element is not important in this scenario, don't show it. And this is very key when you're working with different screen sizes. That's another reason why a lot of people like the mobile-first approach, because it forces you to think about what's really important. Another thing he worked on was making sure that everything was concise. So for example, we had a shopping cart. So this is very easy to understand if you see it at the top of your screen. It has a shopping cart. It has the word cart, and it says two items. So your shopping cart has two items in it. So this is fine when you have bigger screen sizes, but if you're moving smaller to a mobile device, this takes up a lot of real estate that we can use for other things. So he was able to change this to that. So it's just a shopping cart icon with a badge above it that has the number of items in the cart. And so at first, what we did was in bigger screen sizes, we showed this version. And in smaller screen sizes, we showed this. But later, we were like, you know, it does the same thing. Why maintain both of them? We're just gonna show this icon for all screen sizes. And let's talk about me. What did I do? So the first thing I worked on was making sure we only show relevant information, well, we show relevant information as soon as possible. So one thing I noticed with the application is that we waited for all the data that we got from different APIs to load successfully, then in order to render the page correctly. And that made the application be perceived as slower than it really was. So let me just visualize how it kinda looked. So we called the product API. If that data load successfully, then we called the inventory API. If that load successfully, then we called the pricing API. And if that render successfully, I mean, if that is loaded successfully, then we actually rendered the page correctly. So I'm just gonna show y'all a little code. This is not exactly how it was, but it just, it'll give y'all the idea. So again, we call the product API. That returns a promise. So then we can chain it with the then function. We call the inventory API, that returns a promise. We can chain it with the then function, and then we call the pricing API. But we can also see another problem with this. So let's say, for example, the inventory API just decided not to work today. The server is down. Well, if the server is down, then we're gonna get an error in the inventory API promise. And that's gonna go all, next is gonna go to the catch statement. And we're not gonna call the pricing API. So the page is not gonna render correctly, and we're not gonna get any pricing information on the page. So this is pretty unnecessary. So I was able to switch it from this kind of configuration to this. So what's happening here? So all the elements on the page that don't rely on the product information, let's go ahead, if it's important, let's go ahead and show them as soon as possible. Then once that's shown, we're gonna go ahead and call the product API. And since the pricing API and the inventory API relies on data from the product API, we're just gonna call them when the product API is successful. But instead of chaining them, we're just gonna go ahead and call them independently. So let's see how that kind of looks code-wise. So again, not exact code, but just a representation. So we call the product API, if that's successful, then we call the inventory API and the pricing API separately. And it solves our problem with the error problem that we had before. So let's say, for example, the inventory API fails. Well, we have a catch statement associated with it already, so it's not gonna stop the pricing API from being called. And you can also see that I set the promises equal to variables. With that, I can check to see if these promises are still pending. If they are, where that data will be, I can just have a loading icon there. Just to, again, just tell the user it's still loading. So I really like this project. I had to get up close and personal with the event loop in JavaScript and learn about promises. I didn't know you can do that before. So next I'm gonna talk about the quality assurance analyst. What does she do? So one thing she did was logging any UX issues we saw inside of the QA record so we can keep track of them. Another thing she did was actually test the usability of our product. So she noticed that based on our users, we needed to be able to tab through our whole application. So because it was essential, she created automated testing for it. So it's now part of the regression testing. So if we break tab in, we're not passing QA. So sum everything up. As you can see, everyone on the team has a responsibility to shape the user experience of their product, regardless of your title. If you make decisions based on your users, you are doing user experience work. So let's everyone put on your reading glasses because I have some greatest of all time resources on design and UX and accessibility that I really appreciate it. So I appreciate this book Don't Make Me Think by Steve Krug. It really gets to the meat of accessibility and usability. It has sections that talk about buttons, like for example, how to style a button to make it look clickable and what text you should put in your button to make the action clear. So if that's interesting you, this is a good resource. Also the Mozilla Developer Network WebDocs. It's free and I think it's a really good resource if you're trying to learn or review web technologies, JavaScript, HTML, CSS. And it teaches those technologies with accessibility in mind. So for example, on the page that talks about the image tag, the HTML image tag, it also talks about why using an alt tag is important. And then it talks about how you can write meaningful alt tags and then goes over a scenario where you will want to have an alt tag with an empty screen. So really good resource. And one last resource y'all was the non-designer design book by Robin Williams. Again, I'm a developer. Didn't know much about design fonts or colors. And I really like how this book broke down those principles. So that's it y'all. Thank you.