 And good afternoon. We have got Kevur over here. Kevur Ken Vermette, a member of our visual design group. If you don't like our wallpapers, our default wallpapers, this is the guy you'd want to kill. OK, and he's got to talk on iterative UI design. And I'll stage yours. Stay here forward. Hello, everyone. My name is Ken Vermette. I'm a web developer and graphic artist from Canada. I've been with the KDE Visual Design Group for a couple of years now. And you can thank Yens for roping me into it and me making a bunch of horrible wallpapers early on. And I've been trying to make up for that ever since. So anyways, there's this big misconception, I need to say about Canadians, that we apologize all the time. I just want to say that's flat out untrue. And we need to get on with it. OK, another thing. Sorry. I'm probably going to pronounce cute at least 17 different ways, because I'm horrible. So getting right into it, the goals of this talk. Normally with iterative design, you're talking about prototyping, testing, doing analysis, and then refinement. I'm not going to be talking specifically about how to go through this process. The methodology and the resources we have available will vary. We have an incredibly diverse crowd here from large companies to open source hackers. So instead, I'll just be talking about iteration very literally. We have an application. We're going to change it. We have some very practical things we can do to make those changes effective, not to cough our users and just go more smoothly. So we're going to learn about iteration, cadence, and how it affects user expectations. We're going to quickly talk about personas and how they affect decisions on a step-by-step level. And we're going to cover some strategies and pitfalls when iterating on our designs. And it occurs to me, flip those around, because I did that at work. First, some definitions, so we're all on the same page. Visual design, that's how your application looks. That's the colors. That's the imagery, animations. It can be lines. Anything visual which doesn't actually affect how it's used. Visual design does affect how people think it will be used and what they think the workflow will be. So this is an example of just same application, same everything. You can see that the one on the top left is the oxygen style from Plasma 4 Days. And one thing you can see in there is the pane on the left has the extra frame around it. So what this tells users is that that is isolated in some way, you can actually rip it off. You should probably use this. Roger that. So now this is going to be awkward. So with the frame, what you can do is, as a user, you can see that things are isolated here. You can actually pull that off. It will become a window. So that's a visual indicator from the oxygen style. Meanwhile, Breeze lacks that frame. And it actually provides less visual separation between the pane and the contents. So users may actually have more indicators that when you interact with that left side pane, it'll interact with the right side pane. That's just an example of how a very minor visual tweak will affect how users see design. Another note is with the Breeze style, it's less obvious that that can be torn out into a window. Workflow, workflow is the placement of the components, how they interact with one another, how they're accessed, and the optimal way to use them. Workflow affects how people use the functionality of your application. A big example of a change in workflow is with Microsoft and the introduction of their ribbon interface. Compared to menus, it's actually fairly similar. At first glance, you have your row of options going across the top, and then it drops down into the various subcategories of options. The big difference with the ribbon is that it's organized in a way that you see everything more upfront, it's persistent, and some things have more focus than others. But just that little tweak changes the workflow significantly. Functionality, what our software can actually do? You can have the most powerful software on Earth, it doesn't count for anything if users can't access that potential. For example, I won't say what project specifically, but I was having a brilliant tech demonstration with somebody some sprints ago. I was absolutely amazed by the things the software was doing. There was no way to actually access any of that power. And this is just a call graph because I couldn't think of another way to represent functionality. So functions, cadence, the last thing. The TikTok click cycle of releases where we release large overhauls, smaller updates and fixes to our interfaces. Now, a note about cadence is that visual design, workflow, and the functionality all do follow different cadences, at least if they're not deliberately synced up. So for example, with the modern design introduced in Windows 8, that exists into Windows 10, but they have completely different workflows. One uses the start menu, the other uses the tile menu, unless you go and install a bunch of third-party applications. We can exploit the offset of these cadences to better prepare and transition our users by setting expectations. And what I mean by this is that if we, for example, do a large visual overhaul to an application, users will expect that the application will function differently or have a different workflow. So if we wanna start introducing these changes, then what we can do is just simply start by adding these minor visual changes and then users will build that expectation up themselves. So getting on with it, out of definitions. These major iterations, they tend to use code names. We all know and love them, Metro, Astralis, Breeze, Material. These are ones that tend to be provided for us to use. Minor iterations for our applications should hopefully just refine and reinforce what that major iteration or revision aim to do. So if material aims to have a nice flow to it, we should try to reinforce that instead of moving away from it. When working with well-defined platforms, the overall design is usually given to us, meaning that the major iterations stick around as long as the specs do. So we get one nice big stab at getting the user interface rate and then from there, we're refining. So the first thing we should do, if we're given a set of specifications, we should try to iterate closer to them as we can. If you dislike the specification, because I know we have some people here that hate the material design in the animations, if you don't like the specs, then usually there's ways to bend. Usually there's a few avenues to present buttons. So there's ways that we can kind of try to make the interfaces that we like while still following the specs, but we shouldn't try to deliberately just break away from specs. That's what they're there for. That's what users know. And by breaking away from the spec, even though it works for us, it'll be broken for literally everyone else. When we're working without specs, web designer is what I am by trade. We work without specifications. We have HTML and we wing the UI every time. Try to use fewer unique workflows in whatever you're making. If you see a chance to consolidate your workflows, take those chances every time you can. See what two parts of your application are similar and see if you can just combine them into one single component. Codify these refined workflows into components and classes and more thoroughly reintegrate and recycle each round that might include making your own specs and saying, okay, this is how this application is gonna run so that way you can pass off your own specifications to the next person taking over your project. If you're using QWidget still, I am so sorry, but look at porting components or Windows to QML. QML is amazing, iteration is better. I was going to show some QML stuff in this presentation, but I think we're all getting pretty familiar with it and in a design talk, I'm not exactly gonna teach you a whole language. If you're getting slammed by the design process, consider using an existing design framework such as Kirigami UI. That's one you might have seen in some of the KDE plasma related talks. It's brilliant. Go ahead, use it. It'll give you everything you need. Setting the user expectations and behaviors. As I mentioned before, when people see a major design change, they often expect the workflow or feature set to change. Confident users, when they see these changes, will re-explore the application. They'll inspect you wise. These are everybody in the audience, everybody who knows how to use a computer. They see something new and be like, what can I do with this? If without instruction, uncertain or novice users, these are a lot of office people who don't necessarily know how to use a computer. They're just kind of trained and they do what they know. They're gonna recheck to know if their stuff still works. They're gonna go with what's safe. They might even reduce what they use until they can easily re-identify or re-discover whatever might have changed. And this will happen, even if the workflow has not changed at all. If you just change the visual look, sometimes they will do that. They'll go, oh, that's different. And then they'll panic and shut down. So we have to be very careful about how we do this and we can very gradually introduce design changes if we want to make sure that if we're doing a large enterprise piece of software, something a lot of people in cubicles are gonna have to do, we can be more gradual with our changes. Major iteration strategies. If prepping a major workflow change, refresh the design, it's probably gonna happen anyways by the nature of the work. If, say for example, you're moving from just something generic on Android, say from hollow to material, everything is going to change anyway, so just simply be prepared that that's gonna happen. When changing the workflow, it affects multiple aspects of the application. So what you wanna do is you want to front load the biggest changes. So if you have a feature bulletin change like Microsoft had the Rebin there, you wanna put that in first, let people see it, know it, possibly have an opportunity to toggle it off. And over time, fold in smaller changes, maybe look at reducing to the core feature set you want to provide. So if you wanna kill your menus for any reason and go with a Rebin, then that's when you would do that. And of course, pair of visual refreshes with transitional changes to your workflow. So that's just saying, don't change the look and then in a completely separate release, change the workflow. Try to do them roughly at the same time and that sets the expectation that when a user sees it they go, whoa, something's changed, that we are not tripping them up twice. Pitfalls, polishing early designs, don't do it. Get your designs good enough when you're transitioning to something new but don't try to put too much polish into it. Get it good enough, get it looking nice, worry about the polish later. The reason being every time you iterate on something, if it's highly polished, if you put a lot of work into it we all know things tend to fall apart slightly every time and kind of skipping to the last point we don't want users sensing that degradation that a polished design is gradually falling apart. Instead, it's better to introduce with something good enough and then to gradually improve it over time so that users think, oh hey, this is getting better. The problems that I have are getting solved as opposed to them seeing your designs slowly fall apart before you repolish it thinking, oh no, it's falling apart, it's getting worse, get me out of here. Not respecting your platform. If it's worth reporting to a platform, it's worth doing well. That being said, do assess your user base. If you're expecting 90% Android users and 10% iOS users, do one platform right first. And when you think you're confident enough to move on to something like iOS or a different platform, then at that point try to do a good job there or reuse what you have. Just at least keep it on the docket that the further you stray away from your platform guidelines the more you're hurting your users. We're gonna talk about this. Completely discarding existing designs. Every design has a lifetime. Windows 8 was a reaction to the touch screen generation of devices. Input methods change, computers get faster, we can do fancy things, the focus changes. At first, always try if you can to allow users to restore older workflows or at least something similar to them. Don't change the intention of the user interface. One of the things about Windows 8, it tried to shift from productivity to consumption and of course that's when businesses said we need to actually do real work here. If the goal is different, you're designing a different product. Treat it like a different product. Even if you can share 90% of the code base and just the interface is changing, I'm not really sure how, skip ahead, how you want to do that, but just know that if you're gonna change everything, at least treat it like something else so that you don't trip everyone. Designing for corner cases. When we're iterating or at least getting started before iterating, we can over design things. This is one of my biggest problems myself. When you tend to use pen and paper, you start thinking, oh, well, what if this happens? What if that happens? A great example of this is the floating action button from the material design spec. When you look at that button, you think, oh, that's covering my content. Oh, that's floating in a weird place. It's gonna make things crowded. It's gonna make things, you're never gonna see what's on the bottom right. Don't worry about it. Seriously, just when you see things like that pop up, usually intuitive solutions will also come up. Some applications have figured out if you just add a little bit of spacing to the bottom of your lists, then when you scroll down, the floating action button is just in the void. Other applications, when you start scrolling down, they all slide down the button away. It's a little bit weird. It's a little bit overanimated, but both of them work, both technically fit the spec. That's actually a really good time. Rigidly defining the aspects of our specs. If you're working on an application, you've started nailing things down. That's an order. See, this is what happens when you iterate too many times on your slides. It's good to define how things should work, but if it's not working out, if you have an idea and you're just trying to hammer in a screw, just stop. You can use something more traditional. It doesn't always have to be so unique. Your design will evolve over time anyways. Just look at what you may be changing. Possibly update your own internal specs. Don't try to keep going on something that's not working. Personas, iterating with people in mind. For those of you who don't know, persona is basically an imaginary user, somebody you make up. This user has goals, backgrounds, a requirement. For example, let's see. I have an example here on my notes, which I have not used once. Two mics. And the wrong notes. You might have, oh wait. Here we are, this is where my notes were. A persona can be just somebody simple. This is Alice. She wants to organize her music on the go, so this is going to be for a mobile application. This is Greg. He's a very basic user with thousands of songs, but he wants to listen to the same three tracks over and over and over again. If you're designing a music application, you might have these two personas in. So one idea that you might have to appease both of these users is possibly having quick favorites that you can quickly favorite and unfavorite songs. When you're changing or modifying the design, just go over your personas. Occasionally put yourself in the seat of the user before you actually do the get push and see if it will actually benefit those users. Ideally, every change that you do will be good for some users, at worst, neutral for others. You don't ever want to impact other personas that you have negatively. Always try to find a solution that fits everybody. If you have too many personas and you can't satisfy them all, then you might be making your application too broad. Yes. Wow, I really blew through those slides. Does anybody have any questions? What is your recommendation on information architecture? So how to design information architecture before you pull the design on top of the graphics? My apologies. I tend to like the model view controller approach, especially when using QML, that essentially solves 90% of your problems because your user interface is in one very malleable format and is well depending on how you actually assemble your program and how you actually load your QML. You can also very easily split out the code path so that you use, say for example, one QML file for iOS and another one for Android if you're having to redesign the interfaces for different platforms. Did I answer your question, let's say? No? No, I didn't. I asked for information architecture. So designing the workflow, like Bazamic is doing, XU is doing, so without doing graphics, that's kind of the flow through the applications. Okay. Yeah, I apologize. Yeah, sorry, I'm... Yeah, the way the user moves for an application as sort of how the user would preferably move through the application. Where do you want them to look, et cetera? Oh, okay. So yeah, in terms of that, it depends on your application. Generally speaking, what you want is users to have an entry point. So say for example, and again, this really varies depending on the application that you're working on. So I'm just gonna fall back to the music example. You'd have an entry point that might list, say for example, your categories, like your songs, things like that. I tend to like the drill down approach where you have your categories and then you can go in, in, in, in. But if you have something simple, you can just present it all at once. Do you use pen? Do I use pen and paper? I tend to use pen and paper when initially designing things. You can be very rough with it. You can just quickly draw your boxes, get things where you want. After that, I tend to graduate either to HTML or QML, depending on what I'm working on. I don't do any images, images are always dead last. If I have anything that I can recycle, that kind of looks like it might work there. One thing that I do personally is if I have a placeholder image, I might just throw a big orange background on it, something that'll really stand out so that I know what's placeholder and what's not. But do you think about intentionally unpairing the design and workflow changes? So that you have a real TikTok release. I think Microsoft is doing it in this way, small or not a big change at all at once. Yeah, I think that's a good way to go about it. I think pulling them apart, it can brace users for changes really well when you're not doing everything at once. So if you think everything is going to change, sure it might throw off users a bit when they go from Arrow to Modern, but at least they'll know, like they'll quickly rediscover their workflows in that case. But if you do something like that, you also want to be very careful with your iterations in the future. You don't want to, say, transition somebody to a different look, and then six months later, completely change their workflow. Ideally, what I like doing is I like putting whatever big banner change in with the visual design change, and then slowly introducing components after that. But if you can't get it to sync up that way, then that shouldn't be too, too much of a problem, but it can be a little more stressing to users who aren't necessarily 100% confident with how to interact with the computer. Any other questions? We have another. But I understood just like now, you are a designer, but you also feel comfortable in developing HTML and QML. Yeah. From your perspective, what is kind of the biggest missing point from you as a designer standpoint? In QML, walk it quick. Just, sorry, if I reiterate the, if I restate the question, just myself as a designer, what do I kind of see potentially lacking in QML? Yeah, lacking. One thing that I tend to find a little bit lacking, and it's something that every company kind of builds up over time, is that initial stock of components, just you know, Kirigami kind of solves this because it gives you a nice treasure chest that you can work with, but you know, you're usually using with the same basic parts over and over and over again. You're gonna use some lists, you're going to use certain types of controls, certain types of forms. One thing that I really kind of miss is that there's no real specific form component that just comes with QML, and I know that I'm gonna have labels on one side and certain controls on the other. That's one thing I kind of missed, and it's solved with GridView, but there were some niceties of the actual QWidgets form implementation that I kind of miss. In that case, I have a question. Sure. Right. Okay, so I am a programmer. I have never used anything other than Inkscape to mock up simple lines, but as a programmer, if I'm working on a project that's small enough that I don't really need to go to another guy who's a pro at designing interfaces to do it for me, but yet I don't actually have the requisite skills or the experience with tooling to mock things up. Do you have any tips on where I should start? Yeah, so if you're just looking to start with mocking things up, what you can start with is start looking at what other people are doing. Imitation can be the sincerest form of flattery, so just look at what other applications have done. So if you're looking at designing the way your controls are gonna be laid out, and I do this too. I just top onto Google. I do an image search and I just see what other interface layouts people have going. And from there, you can be like, oh, I like that, I like that. If you have a pencil and paper, it doesn't have to be pretty. You can even just put boxes and the name of what you were looking at. And then you can just kind of, it's just for your own reference. It doesn't have to be anything super professional. But yeah, I would say if you're not really super keen on design work, but you don't feel like you need to pull in a designer, just look at other people's designs and you can even pull up an application like Color Paint or something like that or the GIMP and just literally copy, drop it into a file and slap it all together. Okay, so we have around three minutes. If anybody wants to ask another question. Yeah, we have one more. Right. I keep saying one more. I'd like an abundance, really. Just a quick side note. You said that when you make a big iteration and you give it to the users, they might be at first put up by the fact how many new things, new features there are and they might be overwhelmed by this kind of thing. And you actually believe that they are going to overcome these obstacles that they're gonna learn, they're gonna find out and everything. And you should probably tell that to my mom. No, because it ends up like this. People see new things, new stuff and they get so much overwhelmed over this that they just gonna, okay, I'm not gonna use it. Yeah, no, that was what I was kind of mentioning with the users who are unsure or were novice. Often you'll also have a lot of like office or cubicle workers and they'll be trained on the application that they're working with. I recall when I started working at this one call center, the computer test was knowing that you can hit the close button on the window. So like a lot of novice users, they will shut down and that's why I say, introduce changes very gradually if you can over time or if you're gonna drop a new big interface design, don't also drop everything in at once. Ideally there will be somebody to kind of show them if they're just going to stop but we also do have to be aware that when there is a significant change that some users will shut down in that respect and there's just not a whole lot we can do about it. We can either keep everybody on Windows 98 or we can try to inch everything else forward. It's just one of those things where there's no real solution for it. The best is to just try to hope that they can kind of keep up and that we can kind of get them the breadcrumbs to bring them to the end of the path. Okay, so I think we're out of time here. Thank you, Ken. You're very welcome.