 I think we're good, so I'm going to hand over to Catty, who's got a great talk about tips and tricks of design for developers. Lower the bar please. Okay, so hi, my name is Catty Namoraro, you can find me on Twitter at Tevalica. I don't know if you've been to Amit's talk, he talked about patterns in architecture, but similar to architecture we also have patterns for interface design, and I provided a link there if the slides are available on Twitter, so you can go if you're interested in more, because some of you asked about patterns, but in this talk we're going to go even lower, even at the core principle. So there will be like the basics, so patterns are more advanced, maybe we can talk about that in the future, but now we'll go even lower. So principles are fundamental rules, and if you were to apply just one principle in your day-to-day interfaces, that would be consistency. So what consistency means? If the user learns your interface once, he will know how to use it in subsequent uses, and that is very important because it's much faster for him to react. But if we're saying that we're designing a consistent interface, this doesn't mean that all the buttons needs to be the same. There are several types of buttons, and it's very important to have a primary action on your screen, so the user needs to know what is the main thing you want him to do. And primary actions are usually designed with more contrast and color, so he gets the point on what you want him to do, and they should be like only one per screen. And these primary buttons needs to be very clear, so we should avoid things like yes or no or read more or stuff like that. Users think in actions they want to delete something or they want to add or to edit, so we should use verbs. We should not have long buttons. We could give context, but verbs are more efficient in terms of directing the action. And also, when we ask the questions, we should avoid double negatives or very abstract things. We should use a common language and make it very clear what we want them to do. There has been a very big debate on where the buttons should be placed, should be placed on the left side or on the right side, and if we are developing a native application it's much more easy because the operating systems have guidelines and style guides and they have a preference, but if you're designing for the web, on the web the rules are not that strict, so I just want to show you some points on why you should pick one or another. For example, on the left line it's very easy for the user to vertical scan. He can read the title or he can read the labels, and if he finds the button at the end he can just jump from the title to the action. But if you want the user to actually read the description text, he will make like a z-shape, so he will read the description, and then he will need to press the button, so in this case the position matters, because for example, if you're using left-align he will read the text, he will go to the primary, he will see the secondary, and he will need to go back. So it's a bit longer to react, like a millisecond or something, but can add up or at least compare to the other right-aligned. Now, it also matters if you're designing for large interfaces or small interfaces. If you're doing a mobile application, it doesn't really matter if it's on the left side or on the right side, because the width is very tight. There are some interfaces that even put the buttons in the middle, or the buttons are full width, but when we are designing for web now as developers we like to have 8K monitors if we can afford them. If you don't have columns, if you are applying a right-align layout, the buttons can get separated from the context, so the user might feel lost or not see the connection between the actions. So here, again, he will do like a nail shape. Now, I've talked about primary and secondary action. The thing is that regarding patterns, there are some patterns like wizards where you have multiple steps and you need to go like next and previous. If you're designing for someone from Western culture, when we read books we kind of go from right to left and we're switching pages, so that's why next button, feel more natural to be placed on the right side. But even when you're placing them, just make sure that the primary action is on the edge. Edges are much more accessible because they're coming, so don't place the primary action in the middle of the screen. So again, you need to decide, do I have wizards in the interface, you need to place them on the right, but if you place them on the right, place them everywhere. Don't switch the position depending on what interface pattern you're applying. Okay, buttons and colors in general. It's very nice that we can attribute some color meaning to the actions and, again, be very sensitive of your target. In Western culture, red means danger and errors, but in Asia, red means abundance and luck, etc. So they have reversed the green and red. But even if we can give all the cultures, try to limit the palette in order to be more pleasing and we can convey, in other ways, things like warnings and infos. And why it's important, at least to have one color for dangerous action is that if you are sure consistency across the interface and all your buttons are, let's say, gray and blue, when the user will see a red button, he will understand that that is a very important, or it's something with that action. And for destructive states, it's really important to ask for confirmation. So if you're doing something that will affect the user, ask him to see if he didn't accidentally press that. And I know it's harder to implement the undoes and measure controls, but they could be very helpful for the user to feel in control and safe and know that he can come back to that. Okay. And I know we talked a lot about buttons. We still have. But there's another principle which is called affordance. And affordance, the metaphor is like when you see a door and if the door has a circular handle, you might know that you might need to switch the handle. Again, if the door has like a pull, you know that maybe you can pull it or you can push it. And that's why sometimes when the door does the reverse thing of what you're expecting, you might be a bit confused. You don't know what's the direction. The same for this principle can be applied to links. So for the people that have been for a long time on the web, when they see something that is blue and that is underlined, they might think that, okay, that's a link. Or at least I know that's a link. So be very careful when applying blue to headers or things that are not linked. In the past year, the designers wanted to leave the old habits and maybe try to express themselves with colors. So it's okay to have links of other colors according to your color theme. But the most affordance based on your prior experience are blue and underlined. Same for buttons. When you see a button, buttons usually have the click state and you know that you need to be pressed. They have multiple states. So in order to increase usability, they should be represented at 3D objects that have some shadows or that have some borders or that have some gradients. So the flat trend for the past years have lowered the bid usability of the things because you don't know if that's just a container or it's actually a button. So ideally, they should have these affordances that can help the user know what type of entity it's in the page. One of the questions is, okay, when we have an action, what do we use? Do we use buttons or do we use links? And if maybe it's more clear that you should not have buttons inside the text because maybe you'll have some alignment things that the line height will get increased because the button doesn't have the same 12 pixels or 16 pixels. This is not actually the way we should rational about them. Buttons and links have been created for very specific purposes. So you should use buttons when you would like to have an action. It's something that changes inside the interface. You're adding an element or you're producing changes on the database or something like that, so actions. While if you're just navigating to other places, you should use links. Okay. Another principle is the proximity principle. So objects that are closer together are perceived to be related and this is a very strong visual principle that we could use inside the interfaces. So for example, if you would have a menu, if you just put some entries more closely together, people will perceive them as related. But it's very important to actually be related. Not just place them because they visually look nicer and this is an example of how it was used to be done in Gmail for an older version. Okay. Another related principle is the similarity. So similarity states that object sharing attributes are perceived to be related and we can force that using colors or shape or orientation. So if you would want to try to read this, let's say per lines, your brains will be harder for your brain because he will naturally try to put them in groups. And having this similarity and proximity principle in mind, there is an even stronger principle that is called the law of unity, which can override cues from this principle. And actually the thing is that if we are linking consecutive objects by lines or by borders or by background color, we can suggest somehow that they are related. And here is an example. So for example, if you are in an activity stream, if you just separate with lines, people will perceive this as an entry or that could be a logging form. Just a note here is that we might be very tempted to use these borders and lines, but the more borders we use, the interface would look more crowded. So in the past years we've seen a fallback instead of law of unity on the proximity. So the designs are more airy and they're using more white space and they're more relaxed and just rely on the proximity, not just on these cues. Okay, choice paralysis. It's a principle that states that if you give the user lots of choices, you might not know which one is best for them. And there's another law which is called Hicks law that states that the time to make a decision increases with the number and complexity of choices. And what we can do about this is to try to limit the choices we are offering to the user. To clearly mark what are the differences, we can apply this for example, in North software there are multiple download versions, so we should not represent them all the same. Be very clear. Actually if we can limit just the two and maybe if there are some advanced things just put them aside. I know we want to show all the options we have, but it's better for them to get a recommendation and know exactly what we should expect them to pick from that. And a similar rule to this is the seven plus minus two rule. So a century ago Miller did some experiments. I thought you were making pictures, so that's why I ignored you for a long time. So Miller's rule, he was having a lot of people and did research. He was giving them like lots of words and tried to see for the short term and long term memory how many of those words users remembered. And the average at that time was like seven plus minus two words. In theory designers use this rule to always say that we should not never have more items in the menus and all the websites should have this limit. But researchers have redone the research more recently and the value changed from four plus minus one. There's no clear conclusion on how many items there should be. The point is to have as few in order to be as easy to be used. Okay, and there's a principle that is called zero-position effect. If you think, let's say, at the alphabet, you know that it starts with A and then ends with the Z, but you don't actually, I mean maybe you do, but some of us have trouble remembering exactly what's inside the sequence. And this principle can be correlated with chunking. So for example, if you would need to have like nine items in a navigation bar, you could split them in groups of three. And this way you will have a first and a last for each of the groups and they will be easier to scan and easier to remember. And also they should be correlated, related not just placed there. And chunking is actually very useful also for form elements. I don't know if you have a card number, you should chunk them. People when they are trying to remember their phone number, they are usually splitting in sequences of two or three. So it's much easier for the user to know exactly what information they should enter. And regarding the easiness, for example, here it's an example with the zip code, but the most classical example, when you enter the card details, when you do a payment, and if a user sees an input of three digits, he might know that that's the CVS that he needs to take from the back of the card. So it will be much easier for them to fill the form. Here, if you place the labels on top, again it will help with visual vertical scanning. Highlight and explain the error in the context. Some applications have a generic zone where they place the error message, and it's much easier to implement like that or with alerts or with toasts. But for the user, it's much more clear exactly where he did the mistakes and also provide a hint of what he should fix. And if we are using some white inputs on something that has a light background, like it's here, the user will have to trigger he will want to fill in the blank. So if he sees something white, he will like to fill it, and that's how you can increase maybe some forms that have some optional fields. Okay. I've seen a lot of times when we have numbers that they are left aligned or centered, and the rule is to have them right aligned because if you have decimals and hundreds, it's much easier to compare from one to another. And this exclusively, not exclusively, but it's even more important on tables when you have quantitative data. So you can then apply them to currency or even to date and make sure the dates have the same format so it's easy to scan months and the days. And here I've also used easy to digest the date format because we don't want to see those long formats that we usually see in our interfaces. Icons are very important because I can't remember that Icons are not universal. People might look at this icon and think that it's a search, but it could also be a zoom because maps used it too or they could think it's a ping-pong paddle and they have tested the survey research on this. So it depends on your privacy, previous knowledge with Icons. You might understand them differently. But Icons help the names. The first time you will see them you will not know what exactly that icon means, but on subsequent users you will understand that that means I don't know recent tabs or downloads and you will just jump at it recognizing the Icons and not needing to read the text. Okay. I know I've went very fast and there are two books I can recommend learn more principles of design and the refactoring it's more of tips and tricks from a designer point of view. Okay. The slides are on Twitter. So if you have any questions, we have 30 seconds. We have time for a couple of questions because there's lots of people outside and we need to do the full turnover. Okay. That's a very unusual question. So I use Sphinx documentation for my open source project. So I'm using the default template. I'm pretty sure a lot of people put some effort in doing it the most generic nice template but I feel something is definitely wrong with it. As a developer I cannot say what's wrong with it but I would like to get it fixed somehow because a big team is using the same template for documentation. So in general open source projects tend to do generic things and things that are scalable and the base for theming so this is not necessarily wrong but you can do customizations on top, right? And my suggestion is identify what's the problem. You can do that by asking a designer or actually asking other people what they think it's wrong with it because I don't know what is wrong. You can try to fix it or just do a theming for it and theming can be diverse because we all have different purposes so it might work I don't know for not dark mode but theming should be supported mostly because there are people that are colorblind and ideally I don't know. Yes? Somewhere down there if you can project a set of patterns in medical industry application or a specific type of pattern in games is there a difference between those categories or is just that using it because it can create a habit and everyone will use it but that doesn't raise the risk with the threat of malicious participants exploiting these human habits. So the question is that there are different patterns for different industries and this is kind of hard to respond. The thing is that there are common things that all humans will understand and will perceive in psychological principles. It's very important to know your target. I mean if your target are children or people under 10 years old you will apply some patterns compared to someone in pharmaceutical industry I don't know. Industry come with some patterns but you will not find a website that will list them on domains. On the web we will have patterns like wizards and how the search results should look like but I don't know any of them but I would be very interesting to know if they are So like we have the good patterns there is this other category that are called dark patterns there are a lot of research and people that are trying to combat this they are usually taking advantage of in advertising and making people sell or buy things that they don't want or book things but that's not that good designer would not want to apply those patterns but you cannot force somebody to apply them or not but they shouldn't it's not recommended yet. Hicks law being abused so badly Hicks law being abused like to sell me service providers hosting companies but designers take an ethical standpoint like oh I've got four options I'm going to highlight this Ideally you should highlight it because you will have the user but depends on your purposes if you know how to manipulate these rules you can propose something that is not beneficial to the user but this depends on the moral values of the designer so I don't know how to answer that thank you so much for coming