Video details

Yuval Bar Levi - Building UI in an ever-changing world | AngularUP 2021

Angular
01.18.2022
English

Building UI in an ever-changing world "Design systems help us write components that look and feel consistent across our app, and easy to maintain. However, many agile dev-teams start coding before the design system has been completed. Others are working with a very rapidly changing design, making it difficult to keep every aspect of it in sync. This usually leads to spending lots of hours solving bugs that could have been avoided.
Wouldn't it be wonderful if you could write your code like you already have a completed, up-to-date design system?
Well, you can, and it’s easier to achieve than you may think.
We'll show how Atomic Design can help us create components that are easy to write and maintain, even if your design is changing or unfinished, making your components consistent, and your dev team happy." Yuval Bar Levi -
Web developer and consultant, Haiku (Founder) / Web developer and consultant.

Transcript

So hello, everybody. Please welcome Yovalbar Levi. Hello, everyone. Well, I'm excited to be here. A bit nervous and mostly happy because it's so fun to see real people and not Zoom screens. So thank you for being here. Actually, can we have a round of applause for you being here? Yeah, real conference. Okay. And I know you had a long day and you have lunch, so we're going to do something to energize you. Raise your hands. Up, up, up. Come on. Up, up. Now stretch your fingers. Stretch. Now stretch to the right. To the left. Raise your hand if you feel energized. Yeah, everybody feel energized. Great. Thank you. Okay, before we begin, I want to share something with you. I have accent issues. I either have kind of American accent or a veritic Israeli accent like you hear right now. There is no in between. Sometimes it change while I talk. Nothing I can do about it. Bear with me. It's going to be fun. Okay. So my name is Yuval Baulevy. I'm a web developer for the last decade or so, and in the last few years, I've been a freelance consultant. I study philosophy, and I love cats. Yeah. Okay. Why not? So we're here to talk about the problem with UI in a world that changes all the time. And we're going to focus on the most visual aspect of the application. That's the buttons, the navigation bars, dialogues, colors, fonts, and so on. And it's supposed to be easy, right? But as application grow, we might find ourselves spending more and more time keeping those different aspects consistent. And why is that? And I think it's because of the way we work. We work agile, and it means we work on one page at a time or feature by feature. And when we work like that, it's kind of hard to see the big picture, seeing the entire application as a whole. And I want to demonstrate that that's a small application with two pages. We have the application bar and below the header with the sales component and the list of tasks. And if we press the down button, we Mark the task as completed, and then it will appear on the down page, which look kind of the same. And we have a couple of issues in this application. I call it the Agile Symptoms, and the first one is Duplication of Values. If you look at the homepage, you will see there is an application bar which is blue, and there is a down button which is blue, and also the username is blue. But in fact, these are three different colors. And that happened in real application as they grow. And why is that? It's because we work on one component and then we create another component, and usually we copy the stats from this one to the next one. And sometime down the road, we change one of the values. And if we are not careful, we end up with lots of different colors and lots of different values. Please raise your hand if you know what I'm talking about. That's practically everybody. Yeah. Mostly with colors, sometimes with other stuff, but we know this stuff. So next, in terms of duplicate components, if you look at the home page code, you will see that the search component is not really a component. It's embedded into the homepage code. And the same thing happened to me when I built this app in the down page. That happened also in real applications. And why is that? Because we work on one page and we see only that. And when we do that, we're not always sure which of the parts we will need to refactor for reuse. And third, unintentional variants, we have the primary button. And then in one instance, I've added another local class, new task, and this class overrides some of the styles. So I've ended up having two different kinds of buttons. And in the large application, that can be dozens of different buttons. And once again, we have lots of buttons and we're not sure which of them are correct and which of them should be refactored. So I looked at these three symptoms and I asked myself, okay, what are we missing here? What can help us solve these issues? There is a term in Sanskrit called Manas. Manas relates to the mind, a specific aspect of the mind that can see the reality as it is. That means seeing the big picture, but seeing also the details. In the same time, think about standing on top of a mountain and you see all the things around you, but at the same time, you have a powerful telescope and you can see all the details of the things around you. And if we can cultivate this kind of vision, we can solve these issues. And actually, we have a tool that do exactly that. And that's design systems. That's the design system of GitHub. It's called Premier. And we can see all the components we already know from the GitHub page. We can see the stars Tags, the user avatars. And also, if we drill down and pick a specific component, we can see all the details, the different variants and the use cases. In which case should I use each button? So we already have that, but we have a problem. And you probably know that when we start coding in most of the time, we won't have the design system completed, but we know how design system works. So we can co like we have the design system even if we don't have the design system. And we're going to talk about different guidelines to implement that in practice. Before that, I'm going to say that I'm going to talk mostly about buttons and colors, but these guidelines can be applied to any kind of visual aspect, any kind of components, navigation, bars, dialogs, animations. And it can work well. Also with third party UI libraries. So let's talk about the first one. Duplicate values. We have design tokens and we can set a place for them. We can set a color file for the colors and the typography file for the font sizes. And then we can use these in our components. And that's nice, because if we change the value of the light blue, we can change it in one place and it affects the entire application. Cool. But what happens if we need to change the value of the light blue to something which is completely different, like red? Should we keep this variable name? That's going to be confusing. We can change it, but that might be required to change hundreds of places. So we can add another layer on top of that primary color variable and then we set the value to light blue and we use the primary color variable instead. That way, if we need to change the primary color from light blue to purple, we change it in one place and everything is fine. And I was thinking to myself, when I see that, first of all, this can be applied to any kind of design tokens or border shadow animations. And that seems pretty basic, right? Everybody who sits here knows how to put a value into a variable. So why does this happen so often in so many applications? So I think it's not about the technique, it's about our habits. And we have habits. As developers think about what is the first thing you do when you work on a new feature in a large application or any application? You look at the exist code, right? So we have habits. We just need to use that. And it means that the default is the key here. If we set a place for design tokens from the first day of the day, one that we start working on duplication, we can solve that. It will be easier to maintain on the road. Duplicate Components So what we usually do is when we get a new page design, we create the page, and later down the road, we refactor the reusable parts or not. But what we can do instead is get a new page design, create the reusable parts first and use them to build our pages. So how do we do it? In practice, we have methodology that's called atomic design methodology. It splits the application into five different layers. Atoms is the most basic ones. Atoms are the small parts like links, buttons, labels, text boxes, icon buttons, and so on. We can assemble these into more complex components, like molecules. That would be taking two links and create a navigation bar from that, taking a label, a text box and an icon button and create a search component for that, getting couple of buttons and create a button group and create more complex molecules. Of these molecules, organisms are more complex part of the application usually stand by their own that's the application bar or the entire page content templates are layouts for a complete page and they are the pages themselves. Now, if it's the first time you hear about atomic design, you might find these different words confusing. Different the way to divide the application. But that's not the important thing. The important thing is that atomic design is more of a mental model more than anything else. The main idea is to divide application into different layers by complexity. And if you look at these two layers and we implement them completely, it basically means we have the entire UI kit and we can use this to build our entire application. And how can we do that? When we get a wire frame, we get a wireframe and at first we can spot the large parts like the organisms, the application bar, the header, the card, and then we can break it down more. We'll see the navigation bar stuff like the search component, large molecule like the button group. And if we break it down a bit more, we spot the atoms, links buttons, and then we'll implement these components in our application and use that to build our pages. And lastly, unintentional variants. Remember this issue? We have the button and we have the class that overrides some of the styles. So I look at this problem and I ask myself, what's the actual problem here? And I think it's that we have too much flexibility. And as developers, we love flexibility, right? We want all our code to be generic and you can use it anywhere and life will be great. But in practice it's not always work. Think about TypeScript. For example, we use TypeScript because JavaScript is too flexible, right? We want to reduce this flexibility. And the same thing is we can apply that to the UIKit. How can we do that? The first thing we can do is drop the button. This is a template of a button component. We take a button and we use primary input to set the class and then we can pass an Ng content. And the problem with this approach is that it's still too easy to abuse it. It's still too flexible because if we use it like that, that's going to be fine. But if instead we pass this kind of content, we can still pass a class as an Ng content and then we can affect the button, we still have the flexibility problem. So lately I started to build my components as minimal API components. It means that I try to build the API of the component so it will allow the minimal number of possible variants for that component and we can measure the number of possible variants. We can do it like this. We have this at button component and we have his primary input, which is boolean. So it's two possible values. We Mark that as two tax also can get two possible values. That's another two so in total that's four different variants, right but that's probably too extreme. It's not very practical to build this kind of button so we probably end up with having more flexible button like this. We have a primary button which has a default of primary but can get any kind of class so that's infinite number of possibilities same with text infinite number of possibilities. So together explore two variants if you look at that we can reduce that we can reduce the button class possibilities into two so that's going to be two and the text is still infinite so that's X and we reduce this into two X total number of variants so let's wrap it up. We talked about keeping the big picture the Manas point of view and we talked about the default is the key. If we set a place for our design token from day one it will be easier to maintain down the road. We talked about the UI kit first approach using atomic design to break the application into smaller components. First reusable components and we can assemble the pages from these components and lastly the minimal API components reduce the flexibility of the UI components to keep our UI consistent. So eventually change is part of life we can't avoid it if we truly able to accept it, take it into account into our decisions, into our actions we can do better we can do better in our work and we can do better in our life. Thank you.