 And if there are any spaces between and the next person So okay, so it's 11 o'clock and I'm going to speak into David's shoulder because he has the microphone So this is David Hollis. I hope I pronounced it right And he is a software engineer working at Red Hat on the manage IQ open source Hybrid infrastructure management platform and he's going to talk to us about this so take it away David So hi everyone Hi, everyone. I hope you guess that I'm not there is a She was the original speaker of this talk together with me and it's a talk about how we cooperate How we do the cooperation between engineers and designers at Red Hat? So few words about Teresa as she isn't here She's an interaction interaction designer at Red Hat. She oversees the projects I'm working on as an engineer for example manage IQ and other projects like Foreman She lived seven years in North Carolina and she loves working with people and bringing the human aspect to the software engineering and She's a runner as you can see on the picture. So that's me. You already heard my Introduction, I really love JavaScript, but I used to maintain pattern flies SAS port and I work mostly in Ruby and I like to play the guitar We both work for Red Hat You probably know the company Red Hat has over 40 different products only some of them have a user interface We're gonna talk about those because that's where UX comes into the picture They all look different most of them came by acquisition they were developed by different teams so Here you can see how they looked like They are kind of feel disconnected. The only common thing maybe can be the Red Hat logo And let's go back to the history in 2013 when When the Red Hat UX team was formed by five brave people Their goal was to prove user experience to make the look and feel of the Red Hat portfolio more consistent To create a system that helps all so they started to work on the disconnected pieces Like this working in a solution that can help designers and engineers in an open source way Most of our developers didn't really wanted to touch the user interface part so we wanted some kind of flag owing that can they can put together and Build it up as a website or a web application So they ended up with this thought that we need a design system different products build the same things over and over again and They having consistent patterns like login screen a form or just a simple button And it took designers and engineers a lot to agree. So we wanted to standardize these steps for example Yeah, and make the things consistent Does anyone know what consistency means? so In user experience it means that the user can find similar patterns in similar places if you have a button on the left side on the right side or you have switched them off We wanted to define those standard idle dies those in a design system So the first part is already explained we wanted to improve consistency we wanted to increase the usability Reduce the time of cost to market so we don't have to build all the stuff over and over again and We wanted to share all the stuff in an open source way with the community Some of them you might ask what's the design system, right? I'm talking it about So it's basically a set of guidelines rules constraints principles implemented in the design and code Some of you a few already heard about material from Google if you are using Android or any Google application on the web it has a common user interface or Salesforce has the lightning which they use in a cross their own product portfolio Both companies Google and Salesforce have wide very wide product portfolio so it's nearly impossible to maintain consistency without such system and We needed something similar So after learning about the competition meet our design system As any other redhead project it's open source But it has a community around itself as any other redhead project, but it focuses more on designers than engineers You can check the website. It's pattern fly.org At the start it was just a custom styling over bootstrap with some jQuery It was more enterprise focused. It was more condensed We implemented a lot of extra widgets with jQuery such as date picker time picker Tree view which caused a lot of JavaScript dependencies third-party ones The first success with pattern fly was if you remember this and When we applied pattern fly on these products They started to look similar and very very consistent and you could feel that they they are from the same family let's say and This allowed us to grow the UX team So it's a success Thanks to the revolution on the front and the JavaScript the whole thing how we develop on the front and changed Yes, I'm talking about React and Angular and all those things and This is what our developers preference was they saw the shiny new stuff and they wanted to use it So they started to implement their own things in those frameworks and And for that we had to We had to implement Which caused inconsistency Because they started to implement their own stuff and not shared with the community that much as pattern fly would do But as a band-aid solution We started to port these libraries in pattern fly itself So we created the components in Angular or React or Angular 2 So When those frameworks started to develop You can see the con from the contribution graph some of them get more popular than the others So some of them got more components than the others. So you might end it up as a Software engineer you might end it up with using more libraries just to have the right set of components available Which is probably not a nice thing to have Angular and react in your application at the same time So from this we learned that we might need a universal solution Which is like something like this maybe You know the picture So it's kind of megalomaniac, but We might be okay with something suboptimal so we started to think about Componentizing the pattern fly So we can split it up to smaller pieces. So it's easier to react to changes We removed all the JavaScript from the core repo we Splitted up pattern fly into really small atomic mini libraries. Let's say components We implemented all of them in react and As they are mini libraries you can pull them in to your code base one by one So it's easy to transit easy to do a transition from your old word JavaScript to a new component based application gradually About bootstrap pattern fly used to be a bootstrap library We no longer need it. It's not really enterprise looking We didn't wanted to use jQuery anymore and we wanted to reduce the number of third-party libraries So we made our own bootstrap with CSS grids and without jQuery Yay, that's the part where Terraza is singing and woo-hoo and something like that So meet pattern fly next it has everything that I described before it's without bootstrap It's without jQuery. It has the isolated components as mini libraries I have this nice picture where you can see that the CSS part is very very thin Just the grid system on the top of it. There are the atomic components those parts are created by the uxd team all alone and on the top We are building advanced components legoing together the atomic ones together with engineering and those advanced components are tailored to the Engineering needs and then the engineers can use those components in their products as high-level stuff So basically this is how we collaborate and It's fun to work with each other So going back to pattern fly our goals is to apply pattern fly to all our products It means understanding the pattern fly patterns and knowing how they should be applied as You might already heard today. Consistency is important. I will give you some time to read it Okay Using the components over and over again illuminates confusion And we can end up building consistent look and feel in our applications weaker that leads to consistency Uh Here's a component Let's say an abstraction of a component. It doesn't really do much But if you have the right set of components and you organize them well, you can build castles You can build multiple class castles next to each other and if someone looks at them They will think that it's made by the same architect Remember our uxd team it started with five people Now we have 95 people over their years it grew exponentially Since then we are working with engineers during teams more and more to build successful products And it's fun to work with each other So we enjoy bringing ideas to life and we value the collaboration between designers and engineers To sum it up. It's about continuous involvement Evolvement about communication between designers and engineers and adjusting the right solution to the right problem For the end I don't know how much time I have Nine more minutes so if you don't have any questions I do so Who has a living design system that he or she uses do you have any experience with design system and components? how do you feel our pattern fly for as a universal solution and How could we make this concept better together? Thank you. So one of things I was curious to know Obviously we stand on the shoulders of giants So in terms of the previous design patterns in terms of ux where where did you get most of your? Well, where was the greatest source of inspiration upon which you then built your pattern fly? Okay Yeah, so as far as I understood it right From where the inspiration came for pattern fly and how we got the data to build it No, no, so obviously so my point by standing on the shoulders of giants is that you didn't just come out and bring this to the market And certainly in terms of ux patterns It's a fairly well known topic So I'm just curious to know where you got your inspiration from in terms of the body of knowledge That was already existing in order to evolve pattern fly Well, I'm a software engineer. I'm really sorry and there as well is unfortunately not here Roxanne, right? I couldn't fully hear the question The inspiration for Sure, so for for our patterns where did the inspiration come from for a lot of them so I think that's difficult that can be difficult because design can be so opinionated, right? Like I interact with I Interact with upstream communities I I interact with like direct customers and you know always get one guy who hates something and five guys who love something and So we do look at what we would consider industry standard for ux best practices And then we also look at you know to to be frank like what are we have a Desire for a certain type of functionality who else is already doing it Who do we think is doing it? Well, I mean the reality is when you have a certain type of interaction and 15 of the 17 Like you know comparative examples you looked at are doing it and they seem to be doing it well with great response I mean you do try to to emulate that does that help at all? Yeah, yeah Right Yeah, I mean that yeah, they're Sure, you can pull from academic examples you can pull but ultimately right you kind of do do your own user research And that you're looking at you're looking at a pool of what's existing and if it isn't existing that's where it gets a lot trickier Right, that's where we have to actually start user testing our designs to see if they they're actually if they work That does that happens You're talking about component-based design now a Site and building things that uses one they come up with almost unique looks for every page typically How do you break that down into components that you can then build and reuse? To make these or balance Sensible because they're gonna be a balance, but that you got get to this is I've got don't want too many components Because there's lots of maintain, but I don't want few too few because I want to be able to have enough design So how was the approach you might take to finding that balance? Okay, so Let's go back to the spiramint so The atomic components I think are kind of basic stuff. So you have a finite list of elements That's that's the thing that you we aren't really debating what's in there and what's not and By using those reusing those components On the second level those those components are more specific to that to that product product or project But because they are using those atomic components the look and feel will be Let's say consistent Go Yes, so I'm repeating the question so how we negotiate this with the end user so Redhead products or the open source projects behind them aren't like end user like they are end user products as well But they are in-house develop for multiple customers at the same time so How to say it right? It's not the same as you would build a website for someone specifically so we are negotiating so the designers are negotiating More with the engineers who are working on the project if that answers your question. I Mean we you know So as we saying we take the basic components like a button right a button is going to look like a button Where you put it on the page and how it interacts with everything is probably where I see I see more of that That's kind of delegating work happener like the negotiation happening If you adhere to like the basic Design system that you have and then you build from that it still will have that consistent look and feel despite each page Having its own unique variability And we have to do it a lot. I mean You know some of some of the products we work on are just absolutely massive 30 pages is it is nothing nothing It's more like 300 and then how do we handle a table that's like parsing like 20,000 entries at a time so but when we stick to those basic components and it gets like even down to the font weight How titles are handled on how these basic elements are handled on every single page gives us that Consistency at least from a look and feel you're always gonna have there's no perfect world where everything is always falling into an exact Spot right every now and then you're gonna have something that deviates it. It just happens So my question is a little bit more generic What I want to ask is Is there any big challenge that you faced when you put together engineers and Designers user experience designers. So yeah, can you name one? That would be really interesting The developer says no, I can't do that That's the biggest challenge and that that it's like an old married couple or you're like getting divorced all of a sudden and you know like But but we have but we have to do this I can't do that or even the worst answer is and this is not anybody's fault is I don't have that data. I Don't have the data that that's really hard And honestly, I every situation is gonna be different But it's just about understanding that you're both trying to get to a good solution and knowing that it comes from a place of good intention and how can we There's compromise just has to happen compromise will lead to inconsistency But it it's just a dance that that to me is the biggest challenge that I run into It's never about the will to do it. It's just is it possible She's stealing the show from me No, it's good When you talk about look and feel Before the the the projects before they had buttons and and and tables and things and I guess they there were