 Hello everybody. Thanks for being here. I'm very honored to start this session in Yatic today. I think we're almost all there. Almost. So I'll start in one minute. It keeps coming all the time. So it will be very crowded after. Okay, let's start. So my name is Julien Blavac and I'm a tools technical director. I'm also a UX UI designer. I work in production. And my job is to do the bridge between the developers and users. And I try to provide them to ensure that they get not only the features they need to work, but also they get something that is very comfortable to use, that is reliable. So I try to provide our user a great journey with the tools, basically. So that's what we call user experience. And that's what we're going to talk about today. How you can have the user experience in mind when you design your add-on, so that you provide your user, well, something that is comfortable, something that is great for them, that will they like. We'll go through some definitions, some benefits. Why? You'll see that there's a lot of work to do with the UX and good UI, but we'll see why. There's great benefits from that. So I'll also provide some overall guidelines. And then we'll see Storyliner. Storyliner is an add-on I've been working on it for several years now. It should be released next month with Blender 4. Well, at the same time as Blender 4. And I will use it as an example for several things I will show you during the presentation. Then we'll go into some practical things in UI, in UX also, and we'll see some aspects of UX. We may not see everything that you will need to know in UX because there's a lot of things in UX. And then we'll have some consideration for managing the development. So what is UI? UI, UX that you may have heard about, because I've been in the air for the last 10 years now, something like that. So it stands for user interface. So basically it's graphic components, layout, structure, colors, typography. It's also transition animation, but it's also user inputs. So it's everything that happens between the user and the screen and the interaction that goes with it. So what is UX now? Well, it stands for user interface. It includes user interface, but it's wider than that. You have information. And by information, I mean not just the display information, but all the information you need to take decision and to go through your workflow. You have the workflow or the workflows, depending on the complexity of your add-on. You have the tooling. So when I say tooling, I don't mean features, because features is more the functional part of your add-on. I mean, are you able to do what you want to do? For example, if you want to scale some keys, you're on the workflow in an animation workflow, for example. You want to scale some keys. You don't have the scaling tool. That's a break in the user experience. That's a break in the workflow, basically. So in that sense, tooling is part of the user experience. And you have accessibility, which is the ability to open your add-on to a wide audience. But all that are considerations that you have when your user is in front of your add-on. They have opened the add-on. They are in Blender. They are playing with it. That's all the kind of things you have to take care of in that context. But user experience is far more than that. User experience is also the testing you may have with your user. It's the feedback you get from your users. It's also learning and documentation. You will have to provide them so that they understand your tool. It's the support you will provide. It's the overall communication, starting from the website, starting from the installation. So basically, the user experiences all the relationship, all the travel your user can have with your add-on from the very beginning well to late. So basically, it's a journey. It starts in the browser and it never really ends. That's the benefits of having an optimized user experience. So for the user, well, it's clear that if they understand the concept you introduced in your add-on, well, they are more in control. It's easier on-boarding. If your add-on is easy to use, is intuitive. You have a kind of a self-documentation already. So it's faster for a user to understand and to be autonomous with your tools. If, well, they can predict how it will work just by knowing if it's consistent or not, for example, it will allow them to work faster and so to concentrate on creation and not to concentrate on how the tool works. And at the end, it makes your user happy. And that's what we all want as a developer after all. But there's also some advantages of having happy users. For example, if you have a break in your add-on for some reason, they are more tolerant, they are more eager to accept that sometimes there is an issue or whatever. If they are happy, you have a great communication with them. And that makes a lot of force and back and that really improves at the end your add-on, your features. You're really going somewhere with it. For your add-on itself, the benefits are if you have good UI, good UX, it's more robust. It's more long-lasting. By long-lasting, I mean, let's say you have your add-on, you play with it for a while and then you put it aside and you come to it in one year, for example. If it's poorly documented, not very intuitive, you will take, it will take you some time to go into it to go, maybe you have to go into the code to understand how it works. But if it's well self-documented and treated, etc., it will be easier for you to get into it once again. So in that term, it may last in time. Minimize support time. I'll come back to that also later in the presentation. It means that if it's self-centred, you have less force and back with the user, because they may ask some questions, how do I do that? Do I do that? Well, if it's documented, you have some tooltips, for example, or whatever, user is more autonomous. So you don't have to spend too much time with them. You can concentrate on the development. And at the end, you get good press, which is kind of good. So here are some overall guidelines, I would say. To start with, you have to have a clear vision of where you want to go with your add-on. What is its purpose? What is the scope of it? Meaning that you will be in charge of the development of your add-on. You will have a lot of requests from every direction and people wanting to push that in one other direction or another. You have to keep in control and to always know which direction you want to provide to your tool so that you maintain an overall consistency to your add-on. Then you have to know your audience, which is very important. Do you do this add-on for newcomers, for experts? Will they use that all the time in Blender or only for modeling, texturing? That's kind of your target. And once you know that, you're able to start designing the journey with your user. Let's see some guidelines that will help you to keep the scope of your add-on. The first thing is that the user should be able to do what they aim at. That's a functional part of it. They want to do something, your add-on, as a purpose. So it has to work for that. But if you stay at that level, it will be laborious. But it will work. So it's functional in an efficient and pleasant way. It means that if you can provide some entreativity, usability, robustness, that's always better for the user. That the user to be a part. And with the feeling of always being in control. And that is very important. That means that when you have, for example, a big add-on, sometimes you have complex workflow or complex, a lot of controls, a lot of parameters that are exposed. And you want your user to always understand what they're doing, understand what they can do, what they cannot, and come back to that later on. So when you have that in mind, you will be able to better integrate all the requests you have and to have a clear understanding of where you're going. Now I'm going to do a quick presentation of an add-on I've been working on. So it all started in 2020. I was in production of an animated TV series. And the director wanted to have something, a tool that would be very efficient for him to do the cuts from the very beginning of the production. So something very flexible. He wanted to be able to iterate, see the staging of the 3D, see the edit. So I came with this idea of introducing a nonlinear real-time editing environment directly into the 3D view of Blender. So that's what I will show you. It has been used successfully on the production. And then we open sourced it. It was, we open sourced it in more than two years ago. And last year I wanted to come back on that to explore more of the narrative opportunities of the tool. So I forked it, I worked all the last year on it. I transitioned to Blender 4 and then it will be released the next month. So let's see a quick presentation of it. So basically you're in Blender and you're able to create shots. So a shot is a camera plus a timing plus the ability to put shot together to create a sequence. There are three levels to use it. Three incorporated workflow. First one is storyboarding. So for every shot you create you're able to do a drawing that is based on increased pencil of course, plus additional tools like the ability to fully control the layers like in Photoshop, hide, lock, etc. You can play that in a nonlinear way to create an animatics. And then for every shot when you have a drawing on it, you can smoothly transition to an hybrid 2D 3D workflow where you put the content of your shot, your drawing, you put that into a 3D scene. So now there's a big transition and you're fully 3D. That's also perfectly suitable for previs. Let's say you have a continuous action like this one. And with the tool you can very, very quickly introduce new shots. So I just place a camera here. I change the timing. I move again. I'm later in time. I place another camera. I move again. I place another camera. And in just a few clicks like that, no longer than that, you have an edit. And it plays in real time. That's incredible. That's really changing the way you can direct your sequence. So here is the result of it. So we used that in production a few years ago and that was very successful. Let's dive into some practical consideration. So we are on the UI side of things now, meaning that we are more concentrating on the look and the interaction. We will start with some design principles. If you go on the web and you're looking for UI and UI design, you'll find a lot of principles between 6 to 12 principles overall. Some are very similar one to each other. Some are taken care by the API of Blender. You don't have to concentrate on responsiveness, for example, if you develop directly in Python with Blender. One that I like very much because you have it all the time whether it is for the visuals, whether it is for the interactions or behaviors, it's called consistency. It's probably the most important thing you have to take care of when you're doing any development that is integrated in a larger environment. So your aim should be to make the experience very transparent for your user. Exactly as if your add-on was natively integrated in Blender. They don't have to feel that they switch to another environment or having some custom tools, etc. They have to feel that it's part of their working inside Blender. So in practice, how does it work? We have a property. Let's say it's called transparency. Simple property. We want to integrate that to have the same look and feel that any other properties that you already have in Blender, for example. So the first thing is you find a reference. So properties that is equivalent. So I find this one which is opacity. It's in the responsible layers. Transparency, opacity, not exactly the same. One is the opposite of the other. You have to maintain the concepts that are exposed and used in Blender. So you have to switch from transparency to opacity to avoid the user to kind of have a mind switch, what kind of concept I'm manipulating. So first thing, we'll switch to opacity. Then you match the terminology. That's what we've done. Terminology, concept, etc. You have to match the way it is presented in the UI. So capital letters, punctuation, there's no punctuation in Blender overall. So don't use commas or... Then you present the property as it is in Blender. You separate the label and the control. Then you use a slider which is not by default, but slider are not used everywhere. So just try to match your reference. Then you match the range and then the precision. And here you are. So you got to have to go through all that to get the same results. So it seems to be a lot of work. Yes, but that's really worth it because at the end you have the same experience. Also, I wanted to mention that those last two steps are not just UI. It's not just matching the similarity with the slider. It's really kind of UX in the way that if you already have a clamped range for your property between 0 and 1, you don't have to take care of all the extra values that could break your add-on. So it's part of the user experience also to control the range and the possibilities that your user may face with your control. Icons. I don't know if you know that tool. It's really, really wonderful, really helpful. It's called the icon viewer. It's integrated in Blender and you see all the icons that are provided with Blender and that you can use in your scripts. What you can see also is that they are very consistent. There's no colors or very few and that's the same in Blender overall, meaning that some things that are colored in Blender are more highlighted somehow so are supposed to be more important. So you have to maintain that consistency when you use the icons. Those icons are very, very interesting. You can do a lot of things with them and here is the main panel of storyliner and here is where I use the default icons. So you'll see that there are a lot of places, but not everywhere. Example. It's a true example. Two weeks ago, I wanted to introduce a scaling functionality in my add-on. So basically, you go in the UI of Blender. You see that on the left tool bar, you have that scaling icon. So you want to use it. Unfortunately, it's not in the available icons. So you cannot use it. So I said, well, maybe I can use this one. So you may know what is this one. You may have seen it in other context. So I said, can I use it? I will try. So I put it in my interface. Okay, it worked. Today afterwards, I came back to the add-on and I tried to play with it and I said, why do I have a maximize screen tool in the middle of my add-on? What is that? So it doesn't work. But if you put that, as soon as you come back to your UI, it's okay. It's predictable. So there are some icons that are really generic and some that are really designed for a specific purpose. And sometimes that purpose is used in other contexts like, for example, in YouTube or whatever, you have that maximize screen. Basically, you have it on every player. So use the icon wisely. Component layouts. There's what we call the Gestup theory, which is a theory that has been developed in the last centuries to basically define what is your perception of elements that are put together, how brain is interpreting. Well, what are the expectations we have from the association of various elements? So it can be because of their shape, because of their color, respective placement, et cetera. So those theories are very much used in illustration, in the graphic design, and also in UI design. One that I like a lot is called a principle of proximity. It means that when objects are placed together, they are perceived as belonging to the same group. So in terms of UI design, it means that those objects are supposed to have the same fate or become part of the same category somehow. So in practice, if you have that kind of panel and you put all your properties like in a row, it's kind of difficult to understand what they're doing. But if you organize them, I didn't change anything. I even didn't change the order. I just put some spaces. It could be spaces. It could be separators. It could be titles. It could be boxes. It can also be that which are rollouts if you want to hide some information so that you kind of group them or categorize them. And you see that when you have that, you have some more examples of the ability to make your user understand that this, for example, is related to the world group just because you have a frame around your properties. And I take the opportunity to have this panel into the eyes to highlight also one thing. When you organize your properties, try to have kind of a flow in mind, starting to have a logical approach. For example, here it's in the preference properties. I put all the things that you don't use at the bottom of it. But what you have to avoid is to have some properties that should be used together at the same time by the user. And one will be there, one there, one there, et cetera. So you have to try to avoid traveling, basically. Similar components are expected to behave in a similar fashion. That means that when they look the same, users expect them to behave the same. So what do we have here? We are in the render panel of a story liner. And we have those six buttons or association of buttons. Each one of them is controlling one kind of export you can do with the tool. One is for still images, one is for a shot, single shot, play blast, snapshots, storyboard as a PDF, and everything. Everything needs every shot plus a shot for the video for the whole sequence, plus ideal export, plus audio, et cetera. So every time you have one button that is doing the export, and then you have the other one that is displaying all the properties related to that kind of export below. If you just do things too straight, you will have six different experiences, six different way of presenting things below. So that makes a lot of memory load for your user. What you want to do is to have something that is predictable. And every time the user goes to one of the other panels, they want to find the kind of same layout, some properties, some similarities, even if there's some difference because of the specific cities of the export. So here are the six panels. And here are the similarities. All that are exactly the same plus what is not highlighted is the specificities of each export. So it's very predictable, even if you've never used one of those exports. In Storyliner, there are two, I would say, particular widgets. So here is the panel. It's made with a standard API. And it is one of the widgets, which is integrated to the dope sheet or the timeline, depending on your workspace, that is made to display all the shots as a stack, called the shot stack. And the other one is this one. This one is a timeline. It's made for doing an edit. You have an edit track, which is there. But the difference is that the timing of that timeline is the time of the edit. It's not the time of the 3D. So you need to have a completely different tool that basically you are hacking the time. You have a local time that is different from the time of your scene. So they were developed in GPU. So they are very specific. Well, it's kind of a lot of work to do that in GPU. But at the end, well, you're starting from scratch in GPU. There's no components. So you have to design all the components and at the end, you have to make choice for the colors, for the feelings. And there's some things you have to match. You want them to be integrated. So you have to match the same look and at the end, the same way you interact with it for the timeline, for example. And there's some consideration you have to have. One of them is that in Blender, you can change the overall scale of your UI. But you have to do that on your widgets, too. Otherwise, it breaks everything. And when it breaks everything, it's a break in usability also. Which is that here, when you have the keys, if those clips don't match the size of the lines, it's a mess. And it used to be a mess because it took me, well, I had to go to the source code of Blender to find the right properties to see how it scales. It's very complicated. So at the end, I got it. And at the end, it really helps the overall experience for the user. And plus the fact that it's very consistent. It goes beyond that in the way that you also have too much the theme. Particularly if the user changes the color, you also have to do that. So at some point, while we're talking about UI, changing UI, but you also have to adapt the architecture of your add-on so that you can do those kind of things. So here we see that the theme is exactly the same. So I got the properties. I'm able to change the color. If I weren't able to do that, we'll add something like that. So not only it doesn't fit, visually speaking, but here, since this layout is made for printing, you have a usability break. So it's not just about UI. It's about the way things are used afterwards. So this theme has a purpose. You have to also be able to support that kind of purpose. Now we'll see what a component may look like when it's not finished, in that case, or not fully integrated. So this is the zoom part of the timeline. It's not finished yet. So I didn't match what you usually have. Well, you know the kind of timelines you have everywhere. So I will, at the end, change the look of that. But at the moment, it's working. It's functional, but it's not usable because it doesn't match the look and doesn't match exactly the feeling in the events. So back to that. Users should be able to do what they aim at in an efficient and present way. Feeling of always being in control. So we're switching to UX now. We'll see that in detail. Golden rule that I use all the time. Anytime, the user should know the state of the system and what they can do and what they cannot. Golden rule. And if, well, you have for that to provide some more information, you can do that. We'll see how. So in practice, when I design the interface of my add-on, for example, when I play with it, I'm in the middle of the workflow. And what I do is I let the mouse on the table. I do one step back. I look at the screen and I'm wondering, am I understanding everything there? Do I have all the information I need to understand what is happening, to understand the state of the system, and to understand what I can do next? That's very important. And you'll see, sometimes you will be surprised with that. Just you'll see that you're missing an information, for example, or its place somewhere that is not really the right place for it at the moment when you need it. So golden rule, keep that in mind. And how do you do that? Here we can look at the UI and see that there are different colors and different states. So basically, well, a state is a convention somehow. So a button that is disabled is the same in any application. A button that is toggled is the same. The only difference is here in Blender, it's blue by default. It's red when it's an alert and it's grayed out when it's disabled. Same forever. So just looking at that, you have an understanding that you have several modes that are activated, because some are blue. So if you didn't have that, if you had just one button that is doing a toggle but don't reflect it, somehow, in the workflow, you will do something and you said, it's not supposed to work like that at that moment. But thanks to the highlight, you know, that, oh, that's because I've toggled that. That's because I am in shop play mode, for example. You can, well, go further in that by doing highlights. If your user has a doped, doesn't really know if they can use the button, for example, they can move the mouse over it. So that's very conventional. You have that on web, et cetera. There's the highlight part of things. So even as a component I developed, well, you can change the mouse cursor also, which is an interesting way to show that you can interact with something. Well, you see that for the clips, for example, I added some highlights, because I wanted to show that you can interact with it. And now you have to provide some feedback when you have done an interaction with that. Meaning that when you click on something and nothing happens, you start wondering, have I done something? Did I change something? And what? But if you provide a way to have a visual feedback, every time the user clicks on something, whether it is a menu, it is a color change, it is a display, users expect to have something that happens when they interact with the system. So you might say all the things we've just seen are related to UI. Yes, because it's a look, the field, but it's also related to UX, because it's part of the information, the overall information that you need to work. Now, big point, tooltips. There's one thing you have to do in your items, it's tooltips. You may know that tooltips are everywhere in Blender. So first of all, if you don't do tooltips, it's a consistency breakthrough. Tooltips will save you a lot of time as a developer, because they are the first kind of documentation that is available for a user. If they don't have tooltips, they start wondering what is this doing? So they start to explore, but it's dark, etc. Or they try to look at the documentation that may not be there. So they turn back to you and say, what is this thing? So if it's one user coming back to you as a developer, it's okay. If it's 20, it takes a lot of time. It's 300. Wow. Just because you miss a tooltip, that's unfortunate. So tooltips. Tooltips, as I said, you have them everywhere in Blender. So in your items, you have to introduce them to. In Blender, there are also these things that when you have a shortcut that is associated to the control, it's displayed in the tooltip, which is really great, great information. Sometimes tooltips are not enough. So I developed what I called a quick help. It starts with a tooltip, and you can have far more information on that. That's also because tooltips are limited in the number of characters. So I also added an hyperlink. You can go directly to the documentation, and I answered a button that allows you to hide the button when you got it. So I placed those kind of components almost everywhere in the add-on. That really helps for onboarding. And when people know about the feature, they just hide the window. And so it makes the wall panel lighter at the end. Of course, for you as a backend, it's more work because you have to keep the state of those buttons and stuff like that. So there is a wall seam that I won't dive into, but it's called preference, where you put your preference, how you manage to use the preference. So the topic to have in mind when you're doing UX, and I'll go quick on that. Errors, error handling, capacity to recover, to inform when something is going wrong, because you may do a lot of testing, you won't be able to cover everything. So what happens when something goes wrong? So you have to avoid crashes because users tend not to like that. Plus, after a crash, you don't know the state of the system. You don't know if your data are corrupted or you can still continue doing your work. So handling the error is a very important aspect of UX. Feedback, when something goes wrong, you have to inform the user. Decision, meaning that you have to provide him options. You may restart the computer. Step back. Just undo things and that will be okay. Preferences, there's different kind of preferences. Those that you want to have in the add-on level, because you want to have them at every session, for example. Those that are part of the session, like I just unchecked that button, and every time I add a new shot, for example, I want that button to be unchecked. But next time I will start a new scene, a new blender file, I want that option to be back as it was at the beginning because the context had changed, so I may use that add shot in another way. So where do you store those preferences? You may also want to store that in the scene. As a TD, I find it very convenient to be able to open a scene from a user where I find all the layout they are using, all the preferences they have customized, so that I really understand their context and I'm more able to see the problem or to help them with that. Installation, update, patches, support, contact, everything that is beyond the simple use of your add-on inside Blender. Documentation and tutorial, it's a whole world, it's a lot of work, but that's really worth it. Another aspect of UX, how do you manage your development? Because we've seen that there's a lot of things, a lot of work, you may think it's a lot of common sense, which is true, but at the end you feel like it's common sense because the add-on has been made and treated, but if you don't do that, you'll just feel that it's rough to use, for example. So it's common sense plus a lot of work, a lot of good practices, and you easily feel that there is a break in the workflow, but for example, an add-on that has a great experience all the time and there's a break somewhere, you will focus on the break. So it has to be overpolished and that kind of common sense has to be applied everywhere. Question, when you do an add-on, when do we stop improving, doing the usability and stuff? So the question is more what is acceptable for a release? When do you release? You may have seen something like that. It's called the hierarchy of needs that's based on a mass load. Mass load is something for the human hierarchy of needs and you have a similar hierarchy that has been proposed by a university on the principle of design. So basically it says that to go to the next step, you have to be sure that the step before has been completely satisfied. To be successful, designers meet people's perfect needs before you can even attempt to do how your level needs and sounds obvious somehow because you may think that something is very well-streamed. At some point, you may have a break in functionality, for example, so you really see the delta. Functionality means that it works in some condition on the thin red line. If you don't have the right data, for example, just may crash. Next step, reliability means it's stable, good, but it's very laborious to use. You have many clicks, workflow is not clear, you lack information, but it works. Usability, that's what we talked about and that in that one there's a lot of work. Consistency, logic, easy to use, all the information we talked about, that as good tips, progress bar, confirmation, all kinds, et cetera. Accessibility, forgiving, so that's error handling, documentation, tutorial, all those kind of things is what you have to concentrate on. But there is a graduation, you don't have to do everything. That will be the next point. Proficiency is the ability to empower the user or to make him use efficiently. So you can have, for example, additional tools that are not part of the basic workflow and that are the kind of nice thing. It may have happened to you that sometimes you're using an application and you say, oh, this thing is cool. I love that, this one. That's usually occurs at the point where your whole project is already very usable, very mature. User customization comes here too. Well, you can provide a way for your user to have his own environment with your add-on. And creativity, this one is kind of hard to reach. That's when your tool is so mature that it can be used in context that it was not made for. For example, that tool I presented could be used in architecture, for example. That would be great. That would mean that it's an achievement. So the question is how do you balance your development and your development time versus your release? So you can go from functional to proficient. And here is the timeline. You can release here. It's fast to deliver. It's great. Your user can use it, can do what they need to do very quickly. Great. But it's unstable. You provide a low trust on your tool, which takes a lot of time to recover. And it's hard to maintain after all. So if you go too much on proficiency, it means that you spend a lot of time doing all that, so you don't release. So your users are waiting for you. And in the meantime, they may find other tools or other ways or etc. So basically your tool is not out. That's not very good either. But you have great usability and you have less support when you release it. Afterwards. So it's a truth. So as I said, it takes longer to develop. And you may find that you take a lot of time to develop something. And at the end, it's not the right thing to do. But it's too late. You've developed it. And your user told you that, well, we don't want it to work that way at the end. Okay. But if you had delivered earlier, you would have seen that. So you have to find a balance. And the balance is you form the very early design, you talk to your users, and you get their feedback. And then you implement on that. And then you do a first release. It's not complete. It's functional, kind of robust, etc. You get the feedback. You implement. You do a release version 1.2, 1.3, you get the feedback, etc. So at the end, it's called user-centric design. It's a whole approach of UX, basically. And that's very, very efficient. It's a way to integrate your user into your development and to have a smart release. So back to that, when do we stop? Well, we never stop. We iterate. What is acceptable for a release? Well, it depends on the respect of the time and the budget constraints, satisfies the user needs, have a good balance between all the features. Because what we've seen can be applied to a feature, but it can be applied overall and you will add on managing the development. So how to be sure your design is great. That's also a question you have to ask yourself. First of all, test. Test your add-on yourself. Sounds obvious, but still you have to test it. You have to test it all the time to go through your test scenes, for example, and a small warning on that. Your test scenes may not be representative enough of what happens in production. So always use new cases or plausible projects or true projects, if you can. You are your first user. So if you're not satisfied with something or if there's a break and that you kind of take on that, well, you should be able to see it. And then test with your users. So get their feedback every time, as we said, that's part of the user-centric design. There's something, there's that book. I don't know if you've read it, but I really recommend it. It's called Don't Make Me Think. It has been around for 15 years, three editions already by Steve Craig, really, really great. And one of the statements is if you have like three users, you can already have a very representative feedback on the main issues you have with your application. As a conclusion, some takes take a ways, add a clear vision of where you go all the time, keep the scope of your item. At the same time, maintain consistency, do iterations all the time, take your time, talk to your users, take time to explore and then integrate, and tooltips, tooltips all the time everywhere. Create great items, and Storyliner will be out next month. Questions?