 So welcome to the next talk with the title, Top 10 Usability Obstacles. I was told there would be roughly around 10. We'll see. We're going to be surprised. Our speaker today is Bob Marvin. He's a user experience designer from Czech Republic. And he's talking about the problem that a lot of the times the people who are developing applications don't think enough about the users who are ultimately going to use these applications. So he's going to tell you a little bit about the very common design mistakes and how you can avoid them. So please give Bob a huge round of applause and welcome him. Thank you very much. Good morning, everybody. First, I have to say that this is first time when I'm here in this Congress. And I'm pretty much excited from this place. And I'm much more excited that I can talk here. And so let me introduce a little bit more. My nickname is Bob Marvin. And as was mentioned, I'm UX designer at avg.com, the online security company, last two years. And before I used to work in Cessna and CZ, I don't know how familiar you are with this company, but it's something like Czech Yahoo. And it's still competing with Google in Czech Republic. So it's pretty much a big online company. And as was promised, I like today to show you and explain you my top approximately 10 usability obstacles. And I'd like to make it through some story. And why I like to do it this way, it's simple. Everybody talk a lot of holistic approach to design, like end-to-end journeys, user experience, and so on. But I'd like to take your back to the roots, take you back to the basics, and show you still quite common mistakes which happen in user interfaces. And why? Because I think it can help you to produce better software devices, gadgets, and stuff like this. And if I said that I'd like to tell you a story, it will be a story about Captain Nemo and Treasure Hunt. Are you curious? I hope so. So let's do the story back on. Oops. Actually, this is first quite common mistake which really happened to almost every of you. It's some meaningless life screen. Please. Forgot about something like this. And actually, can somebody help me with the buttons at the bottom? Which one I should pick? I'll retry. No, OK. Why retry? Why not OK? OK, so this was something like first try. Now we can start. Imagine that you are somewhere in the deep ocean where it's only some iceberg. And I'd like to introduce you Captain Nemo. This is our hero. So what's wrong with him? Actually, he's on the iceberg and he got two big questions in his mind. Where the hell I am and where I should go? And we can a little bit help him with it. So he's on North Pole. And obviously, he can go to the South because from this place, there isn't any other option. And let's move to the practice. I'd like to start with nothing smaller than Apple. This is screenshot from Apple support. OK, the title itself, it's quite fine. But I totally missed the orientation on the left side. There is no mark here. And actually, these bullet points are my navigation. Those are our links. Those words are active links. And I cannot recognize them. So I got big troubles with my orientation and navigation. This is first big mistake, which repeats often and again and again. OK, because I promised you the treasure hunt, our Captain Nemo would like to find some treasure. But at first, he need to find his submarine, famous Nautilus. So he dive and start looking for the submarine. But again, he don't knows what to do here. Why? Because again, there is missing navigation and also some interaction elements. How can Captain Nemo knows that this ancient bridge, or what is it, can move without any significant mark on it? And if I'm talking about navigation, I mean really the navigation, not the menu. What's the difference between menu and navigation? The menu is the list of anything. There is too many items. But the navigation is the device in your car which lets you to your goal. And try to imagine how big is the difference when you are in some restaurant and try to find something in big menu and how you feel in your car when the navigation lets you directly to the target. So the navigation is that helpful thing, not the menu. So we need to navigate people to their goals. But back to the interaction elements. Now Captain Nemo knows that he can move the bridge. And I get another example from Apple. I'm sorry, this is in Czech because I don't like to switch my whole iPhone into English. But you can probably recognize that this is alarm clock. And I know one girl whose alarm clock looks exactly like this. And there is one simple reason why it looks like this. Because she simply don't know that she has to swipe over the alarm to delete it. It's pretty much easy, but without any visual clue, you simply don't know that you have to swipe over it. But we know it. So we can swipe. And that's the second mistake, I guess. Stop hiding features. Please stop hiding features and content. It's a pretty, pretty big mistake. But now we can swipe and move forward. Maybe you recognize that now you can see this element here on the left side. So we can click on it. Ta-da! Some icons. Could anybody from you tell me what does this icon mean? Fresh fish, fish. OK, OK. Sorry? OK, so jellyfish, fish. Another fish? An anchor. So what I'd like to explain here is that the icon needs labels. I know that then it's not so sexy, but please add to all your icons some, I have to say, meaningful labels. Because if you add labels like this, nothing will help. So please change it to something like this. And again, some practical example. Please recognize usability.gov. Actually, on the left side, there are three icons. I can guess that these are some documents, but I'm not sure. But I'm definitely sure that you have to hover over it to see what's inside. From my perspective, this is a terrible mistake, like hiding information, hiding labels. Please add meaningful labels everywhere. That really helps people. And actually, you can, sorry, this was about microcopy, as I said, add labels everywhere. And actually, you can also try to warn people before danger. But please be sure that they never listen to the warnings, and they will fall down and be trapped somewhere in the deep hole. And the point of this situation is that every time when users are in some deep hole, troubles, deep whatever, you should provide them some underfunction to recover from it, to make one step backwards, to try the action again. And probably the best example of this is the famous underfunction inside of Gmail. You can only imagine what happens if you send email to wrong people. And if you use Gmail and got this function turned off, I suggest you to turn it on. But other way, the first point is underfunction. It's also pretty much important. Not only undo, but any possible option to recover from everything. So our captain Nemo now can recover from this deep hole. And finally, he found his famous submarine, Nautilus. And he's staring on something. What's this? Two circles. Again, you can only guess at this moment. Again, let's a little bit help you. Some ideas? Windows, Windows, maybe Windows? Or? Buttons, fine. Those are two buttons. And now I think it's pretty much clear that those are the buttons. And because Nautilus is under the sea, and captain Nemo would like to simply go up to sea level, he have to push the left button. But what about this help to him? Is it better? I hope so. Like, your UI should really help people, again, navigate them, or help them to understand what's going on. If I go one step back, those buttons are fine. You can recognize that those are buttons. One is for up and down. But the shape and layout is the thing will make the difference here. Flat example. On the screen are three buttons. But actually, only this one look like button. Those are some boxes. It's really difficult to recognize them. If I made this improvement, it's almost the same. It's a little bit scoomorphism, but it's definitely better to perception. Visible perception of those buttons is much better than of the flat. At this moment, I have to say I'm not against the flat design. But I think it's simple too much. The material design, as was introduced by Google, is slightly better, because all the shadows and layers got some meanings. And you can much better recognize what is able to click on, or touch, move, and everything. So this fifth point is guiding UI. Let's keep in mind that your user interface should guide people forward, not confuse them. And if we are guiding UI, like this big button, then the big word is important, because you may be heard about mobile-first design, but my personal approach is touch-first. Everything is touchable now. And if you produce such tiny, maybe nice, but tiny UI elements, which are too close together and too small to touch, then it sucks. So please use big buttons. And once user click on it, provide them some reaction, light them up, play some sound, or something like that. So all buttons, or not only buttons, elements of UI should represent the state that they were pressed. And not only pressed, but we can also inform people that something is happening, like some progress bar, and maybe also that five meters left to the surface. OK, we are almost there. This part was about the reactions. But let's move back to Captain Nemo. Yes, he's still going up. And you probably think that this is link, and you are wrong. This title was designed by some crazy designer, and he simply used the blue color and underline to highlight the headline. And again, it's wrong. When you start designing misleading UI, that's something that's not active, looks active, and in the opposite way, it's the best way how to confuse people. So please don't do it this way. But that's not the main point of this slide. The main point is here. Treasure this way. It looks almost like an advert, doesn't it? Sometimes I saw examples when people tried to attract their users so much that they overthink the whole elements, or whole design, and produce important buttons like this. And then it looks like this. Actually, this whole box is the most important button on the page, but because it looks like banner, it's probably over viewed. Those are links. It's quite clear. They are, in this case, red. They get underlined. But this looks like an advert. So let's skip it. So please keep in your mind that there is something that we call banner blindness, and don't produce elements of UI as banners. Keep them in this distance. And now we are back on the sea level. And it's not so visible, but there is some fog here. And inside of that fog, something is coming to us. And it's simple statement that contrast and size matters. If you don't design or don't use the letters big enough and this sufficient contrast, then it will look like this. Actually, on this screen is not so bad, because we got here quite high contrast ratio. But all these tags on ordinary screen are pretty much small. And they are on gray background. And trust me, also for me, I am not so blind as it looks like. It's difficult for me to read those texts. So please avoid to use gray on gray or small letters. We are still older and older. And our eyes are still weaker and weaker. And once we will be old, we like to read all interfaces. So please keep in mind that there are already some old people which like to use your interfaces. And this can really help them. This point was about contrast and size. We can call it also accessibility. This is not only one rule for accessibility, but this is the important one because this is about the information perception. And on the right side there, it looks like some mountain. Our captain Nemo is here on the top and see this incredible scene, some fish in the air, some bird under the sea. Terrible. I'd like to organize it. It's another important thing. It's grouping. Related things should be together, like same birds with same birds, fish together. When there is some border, it's visible. But between, for example, birds, there is no border. And also, the visual hierarchy, it's important. This is a nice example. On the left side, there is some app. And here is some button. Like, the screenshot is so small because the distance is so big. And this is a nice example how don't connect things together because if, really, this button is related to this app, then why it's so far? Back to the hierarchy. I'd like to keep in your minds or put in your minds that the visual hierarchy is another important thing which you have to follow in your web designs or apps. Why? Because, for example, this small rearrangement means more than 30% difference. This version is better because the logical order of text and call to action button is simple in one flow. So people are able to read the headline first, then observe the picture, read the rest. And finally, take an action. This is not logical order. This is the logical one. And yes, obviously, you can always test it. But when you design something, please follow the hierarchy, linearity, and then the overall performance will be definitely better. So this was about the hierarchy and some clustering. And we are moving forward. Captain Nemo died again. And he received some alert. You reached five meters. OK. He continues. Any other 10 meters? Fine. 20 meters. OK. Oh. This is what's happening when you overuse alerts and notification. Probably everybody of us got a lot of apps in our smartphones. And all of these apps try to somehow notify us, push something on us, spam us with emails. And if you produce something similar, you will end up with something like this. Nobody cares about it. So this point is about notification overload. And it's pretty much important because people became real blind to notifications. And the ultimate result of some overall notification or simple overuse notification could be uninstalled. So if you'd like not to make people angry, please don't overuse the notification. And finally, we are almost at the end. And we reached the treasure here. It's quite a verse that it could be open. Or it should be open because it's button on it. Should I open it? OK. So congratulations. You just found the treasure. And actually, you can download the full-scale presentation on this link. And why? Because without the big picture, you cannot build the user story well. And the user story contains all the small pieces. So from the small pieces, from the details, we build the whole user journey. So as I mentioned at the beginning, that I don't like to speak about some holistic approach or some end-to-end journey, I was kidding. As you can see, we made it together, and we are at the end. So thank you. Thank you very much for showing us where the treasure is. We now have around half an hour for Q&A. So if you have questions, please move to the microphones that are dispersed through the room. If you are already leaving the talk, please be silent and do it quietly so you don't disturb the other people who want to ask questions. We are going to start with a question from the internet. So one user asks that you said that a button could make a sound. But isn't that rather annoying for the user and for other people around him? OK, if sounds aren't right. Actually, at this moment, I was sort of talking about user interfaces in general. So in cases of some sounds which are produced by, for example, an apps, it could be annoying. But on the other hand, imagine that, for example, not imagine, like another example is simple, the Mercedes, the automotive company, which one of the interests of this company is the sound of the closing door. It has to sound expensive because you spent a lot of money on your Mercedes. That's the first thing. The second thing is that the sound of the door is that thing which ensures you that the doors are closed. The technology is so far that it's possible to produce completely silent door. It's really possible to close the door of the car without any noise. But at that moment, you simply don't know that the doors are closed. So it depends. Sometimes the sound could be annoying. But in case of other actions and interactions with your devices, it could be really helpful. All right. Thank you. Please let me remind you again to please be quiet if you want to chat about how awesome the treasure is or if you're already leaving the room, please remind quiet. Next question from Mike, number two. OK, thank you. On sixth reaction, why has the progress bar how up or down I am not on a vertical in a horizontal way? You presented that he's 30% up. And you said to the right and not to the top. My mistake. And you're right. And actually, we can all look at it here. Actually, if you see the space, which left there for me, that's the mistake. I didn't left enough space for the progress bar on the right side. So I put it under. And yes, you're right that the better solution could be the vertical progress bar. Thanks. Yeah. Thank you, Mike, number four. Really good point. So you mentioned about labeling icons. Now, I personally strongly disagree. Here's the point. If you compare the traffic signs in Europe against the traffic signs in the USA, you will find that the traffic signs in the USA are mostly text labels. And the problem with that is you have to actively parse them. So you have two kinds of symbol recognition going on at the same time. You have your visual symbol recognition, which translates shapes, letters, into some semantics into words. And then you have a second parsing step, which parses these words into the actual meaning. The problem is you have two parsing steps. And part of this parsing step is a very conscious process. So if you compare it to traffic signs in Europe, in USA, you have no parking, no halting, two times text. You would say this is very clear what it intends. But if you're in an intense driving situation with very time constraints, this is a problem. On the other hand, if you drive around in Europe, you have two very distinct signs. They are of similar shape. But they are different enough that you can see them in a glimpse, mostly from a peripheral vision. And this makes it much easier and far quicker to read. Now, when it comes to icons, the problem I see is that most designers go forward and try to make it artsy and not very clear. So when the World Fair in New York was started, the Department of Transportation of the US, they initiated a project to create a universal symbolic language that would be immediately recognizable by everyone around, these are stairs, these are restrooms. And these don't have text. The point here is these are readable, no matter which cultural background you have. If you label something, then you assume that the person is reading English or German. Now, if you have, say, an ATM machine and it's configured to say English and a Chinese user or a Japanese user wants to use, he has to be able to read English in the same way. If I'm going to an ATM in, say, Japanese, I don't speak Japanese and I can't read it, I would be lost. So if there's an icon which directly gives me a hint, oh, here I can't select the language, then I don't have to be able to read this. So labeling icons, not a good idea. Make the icons meaningful and universal or possible. Thank you, thank you for this point. I agree, I only like to add this. There were some researchers run on this topic and the result was that this, like universal and meaningful icons exists, there exists, definitely, but in only very few amount, like there is only something like seven really universal icons, seven pieces. And we got much more actions which we need to represent. And actually I put it there because of quite common mistake of wrong usage of icons. If I can choose, for example, in the case of that example from usability.gov, I prefer only text label in this case. So I'm showing you common mistake, which you described. And the additional point is that, yes, we can use universal icons, but please, please, really carefully, there is only a few of them which are really universal for perception. All right, let's move to mic number three. Well, my question is linked to the previous one. Now, if we have different languages, even for symbol languages in UX design, why don't we have like different version of apps or websites for different symbolic understanding? Like technical users look out for quite other UI designs than normal user or my older model or someone else. If I understand you properly, you ask for different kind of designs of one thing, one application, for example. Yes. Like we have different language versions of a website, but we usually don't have different graphical interfaces for the same website. Is this a topic? Do you know anything about that? Yeah, actually, in case of websites, it isn't worth it. This is applied in much, much more complex systems, not on websites, but this what you are talking about is applied, for example, I know it from CAT systems, CAD, computer, edit design, like AutoCAD, KCR, and so on. Those softwares are really set up that way that you can choose different settings if you are a beginner, for example, or advanced user. So based on your knowledge, you receive really different UI because it's worth it in that case, because you spend much more time, you spend with CAD systems, you spend hours per day on some web page, you spend maybe 50 seconds, that's the difference. So that's the reason why on websites we don't get different designs, but in other software applications, we get it. All right, next question from Mike, number two. Could you talk a little bit about the difference between graphic design, i.e., making things pretty and beautiful and usability, because I feel like often these get conflated and they're kind of different. Yeah. I want to say, it's a really, really big topic how to combine the visual design or aesthetics with usability, accessibility, and so on. I believe that if people are trying enough, they are able to produce usable and accessible websites which are nice. So it's only question about effort, how much time you spend on it and how deep is your knowledge in the field of accessibility, usability, UX, and so on. Because this topic which you touch is quite related to, for example, that situation when some graphic designer which got plenty of work on paper and produce really nice designs, visual designs, is asked for producing some websites, then it's totally disaster, like in almost 100% because those guys know pretty much a lot about the visual design itself, but they don't know anything about the UI interactions and so on. So please avoid this situation, ask friends from, for example, DTP Studio to produce something interactive, but on the other hand, if somebody spent enough time on a project, then it's definitely possible to produce nice pages which are also easy to use. It's only time effort. What was this answer to your question? Thank you. I totally disagree with you about bringing right brain people into projects. I think every user, every open source project that's oriented towards consumers should have a designer or a usability expert as part of that team. I think it's a learned set of skills. Of course, your first attempt at doing a website if your print designer is gonna suck. I mean, how many hello world? Where do you go? There's a learning curve, but designers absolutely can and will learn the rules of the game if they're given a supportive environment. What I think is more important though is the end result. Visual beauty is important because it's a signal. It tells you that time and thought has gone into this application. It tells you this is a friendly place. This is a walled garden. This is somewhere you can spend time. Usability is important because it actually lets you get your job done. So in the hierarchy, I feel like usability is what has to come first, but I don't feel like that needs to be the domain of programmers only. And I think that's actually really dangerous because programmers think in a way that is very different than users. Sorry guys, I don't want to interrupt, but maybe you can take this one discussion to after the talk. Because we have a bunch, sorry, sorry to interrupt you, but we have a bunch of other questions from the internet, from people who cannot be present here and who cannot ask the speaker and discuss with them after the talk. So sorry to cut you off, really sorry, but can you discuss this afterwards? I would like to go on with the questions. I'm going to talk at 2.10 p.m. I'm doing a lightning talk then. All righty, just catch them later. All right, sorry. Thank you. Sorry. Please go on with the next question from the internet, please. So a user from the internet asked, what do you think about infinite scrolling, for example, with websites? Okay, infinite scrolling, it's nice thing, or nice question, sorry, nice question. And actually, maybe it's also a nice thing, but again, it has to be handled carefully because if you don't care enough about your layout and you produce on the page something, what we call false folder or false footer, simple to visual break in the flow, then the user probably should stop scrolling. So the infinite scrolling is good in the cases when the content on the page build something or what we can call like continuous stream, like imagine the Twitter, that's probably the best example, like there is always obvious that there is something more of content under the fault. And my experience said that once people start scrolling, they are able to continue scrolling almost without the end or like until you say stop simply. It's your fault when you cut them off from the stream. It's design fault. So infinite scrolling is possible, but has to be handled carefully. That's my point of view. All right, next question from mic number one, please. Hello, thank you for your talk. I watch myself often choose commercial software products over open source software when I really see a huge difference in usability. So yes, to ask from a positive perspective, GitHub is a great tool for programmers to collaboratively work on code. And my question is, do you know of any tool that is like a GitHub for UI designers so you can, yeah, work better on the UI and maybe attract more UI designers to your open source software? What? A resource, a resource space, it's... But actually I don't have any experience with this. That's what I have to say because my work is much more closely connected to, for example, mapping the flows and organizing them. And pretty much a lot of this work is surprisingly on paper and posted. Yeah, and it's not... I know that at this moment I didn't help you too much, but the design collaboration works as far as I know, different way than programmers' collaboration. So then we use different set of tools how to collaborate, workshops and so on. I imagine something like where you could compare two flows and then discuss over it or something. Nothing. We use meetings for this. And actually not only in-person meetings, but we discuss this via Skype, sharing the screens and so on, we always take pictures of our notes or drawings and show it to each other. And this is how we collaborate. Not by some platform, but by meetings. Okay, thank you. Talking, talking, talking, talking. All right, next question from Mike, number four, please. So I have a question with regard to evolution of GUI design. Is there anything which, so to say, is completed at one point of time? So there is no improvement anymore. For example, if you have a temperature regulator, there are a multitude of things. But I think that the turn kind of switch is the most important or best one here. And the second thing is I'm missing a point about the environment where it is used. I'm sorry at this moment. I'm not sure if I understand your question. Like what, so again, with regard to revolution. So is there an GUI design which at one point of time is finished? So with the given technologies, there is no further improvement. Would you think in that way or not? And I believe that there is always some space for improvement. It only depends if you like to face it. I imagine, I heard a nice example of the work which looks like finished, or the design which looks like finished. And it's simple, the fork. Like, or, no, it wasn't for, it was a spoon. Sorry, spoon, it was spoon. Like imagine that you get spoon in your hand and it's up to you if you'd like to improve it or not. And maybe you will find that there is some other better solution than this. So the improvements are always possible. That's definitely the ultimate truth. Or. All right, next question from Mike, number three please. Thank you very much for your talk, Bob. You mentioned accessibility a couple of times and that's a topic that's close to me because I've worked with university students in the past who have had disabilities who've been partially or totally deaf, blind, have motor impairment. And whether software is usable and accessible for them isn't always often not the difference between being more or less frustrated. It's the difference between actually being able to do something at all or not. With regards to the principles that you mentioned as your top 10 here, with the usability or with an accessibility perspective for people who have disabilities, temporary or permanent, is there anything that you would add to say that this is what you need to do to make sure that you cover accessibility or is it just the same sort of thing but looked at it in a different direction? Nice question, thank you. I used to work in the field of accessibility also like last 10 years and I quite hate the approach that the accessibility is something different. And if I can suggest something to everybody here, don't separate accessibility from the usability or neither, for example, CEO. They are quite overlapping and the best possible approach is to start with the accessibility since the beginning, study at least some basic points and simple incorporate accessibility principles in each project since beginning and simply don't think about it as something special or extra. That's the best possible approach. So at this moment, I don't like to add any other important points because there is something like at least another 10 of them but I'd like to encourage you to study at least the basics of accessibility and simply use them because it really can help to many people and not only to somehow somehow disabled people but the impact of accessibility is really huge also on ordinary people, on us because everything what's accessible is automatically or like in intention also better from perspective of the usability. So that's the main point which you please try to keep in your mind. All right, next question from Mike number seven up there. Hi, I just wanted to add something about the idea of different styles of UIs for different levels of users. You know, like say an expert UI and a standard UI. I think the problem there might be that most normal users can't judge their own level of understanding of the app and might think they're an expert and go into the expert UI and then get totally overwhelmed which is another problem with things like this. Think that's a real problem or just might never occur in the real world. I again try to answer from only my point of view not something like ultimate true. My personal preferences if I understand correctly to your answer to your question is that I prefer only one and as much as possible simple interface for everybody and don't make any like extra versions or branches for expert users, disabled users, German users or whatever like as I mentioned earlier the accessibility is integrated part of UI design then this topic of like how to call it level expertise maybe is another point which I really don't like to see in UIs. Is it was this answer? I agree, I just wanted to add. Okay, okay, thanks. All right, thank you. We have another question from the internet and as we're running out of time, this might be the last. Do you have any advice about user interfaces for systems with dedicated controllers like video game consoles? I'm sorry, no because this is too far from my field so I'm really sorry that the last question wasn't answered. Well, as this was a very quick answer we can take the last question from mic number two. Two points, one is about sound. I think there are almost no good reasons to play sound as a feedback but lots of reasons against it and I see the Mercedes example is not a cartridge example because normally you won't open close your door several times a minute and if you close your Mercedes door you're not sitting in your office with your colleagues next desk, you're not sitting in the train, you're not sitting in a restaurant. So just, no sounds, just imagine people would have sounds as feedback on their gadgets in here and the sound would be terrible. The second is about icons and text. I would underline that there should be text in any case, not just in icon and traffic signs are not a counter example for me because they didn't change much in last over decades. Okay, pedestrians depicted don't have hats nowadays but a stop sign looks like the stop sign 50 years ago and people are trained to these signs. So if once you know them, you know them and icons and software are just different, they change every year, every version just to change to say, hi, I'm the new version and so you just can't rely, people understand them and at least I appreciate every application that gives me the opportunity to switch to a text only version of menus and buttons because I can much better go through menus with text items and read them than trying to read those tiny icons maybe with slightly modifications to make a difference between them. No, away with that. Okay, thank you for this note because it's nice wrap up to this session. The true is there is nothing like ultimate and the universe of true. It always depends with sounds, with icons. It is always a case of context and please keep in your minds that in all cases in all of designs, the actual context of usage of the design is the most important thing. So for example, yes, I completely agree with you that it could be really annoying if every tiny notification got on sound and actually this is really related to this point number 10 notification overall for example, but it depends if for example, airplanes doesn't have audio warning about to near or to close approach to another airplane, it's also UI, it's interface of the airplane and if it doesn't really loudly scream like danger, danger there is another airplane, then there will be much more death, so it depends. It depends, it depends. Always keep in mind the context and the same is the same I can say or add to the topic of icons. Sometimes you can use them, cannot use them, this takes, this out takes, it's really, really, really important to observe the current situation, current environment, current state of mind of the user and so on and based on them make your decisions. This could be maybe my next talk here because it's completely different, like different topic or different point of view to the UI, okay? Well, thank you very much for wrapping up this talk. Thank you everybody for coming and for your questions. Let's thank Bob for taking us on the treasure hunt. Thank you so much for your talk. Thank you.