 My name is Jacob Kozo and I will be presenting on a streamlined UI UX for building operating system images. Now let me share my slides. So I'm a software engineer at Red Hat and I primarily work on web development. And I will be talking about this streamlined UI UX for building operating systems, which is primarily a talk about switching from multi page to one page design. Now to begin, I'd like to talk about the projects I work on. I'm a member of the image builder team. Image builder is both a surface as well as an ecosystem. And this ecosystem begins with OS build. OS build is a pipeline based build system for operating system artifacts and images. So basically OS build works in that you pass it a JSON manifest, and it will create an operating system imagery. On top of that, we have OS build composer. OS build composer is a set of services for composing operating system images with OS build. It has a set of predefined image types and has several API's that we can access. This allows us to call OS build composer through its API. Select an image type, define customizations, select how we want to deploy it, and it will generate this manifest and use OS build to build us the image. Now since OS build composer exposes several API's, we also can access it. And one of the ways we do it is through image builder, which is a hosted service within the console.redhat.com platform. Now image builder will access OS build composer and use its image types and features to create the images. In this ecosystem, we also have two web based user interfaces. And these are what I'll primarily be talking about today. The traditional UI that we have is cockpit composer. Cockpit composer has been around for several years and directly accesses OS build composer. It is focused around on premise installations as a cockpit module. For those of you who don't know, cockpit is a web based graphical interface for servers. I like to think about it as if you had SSH, but it's a website. This is a really wonderful tool and allows you to have a server and you can install cockpit into it. And then inside of cockpit, you can install cockpit composer as a module and allows you to install the UI. Now cockpit composer is a multi page UI and is therefore very feature rich. It contains a lot of content. On the other hand, and more recently we've created the image builder front end. The image builder front end was created as the UI for our hosted service image builder and is a more recent project. It's actually currently still in beta. Image builder front end uses a one page design with a model wizard and provides the user with a more streamlined process to building images. I'm going to use the term multi page and one page websites quite bad. I've already said them, so I'd like to define what these terms mean to me. A multi page UI consists of many different pages and provides lots of content and information on all of these pages. This makes it great for complicated services and websites. You can have many different views, many different features, and you're not limited by showing these all in a single page because if you want to add a new feature, you can create a new page. The issue with multi page websites is that with all of the complexity, a user must navigate around. And sometimes, especially for new users, this can be confusing and it can hide features if they aren't sure where they need to navigate to access the content they want or access the feature they want. A one page site simplifies this. It's a single page and it will provide less content and information because it has to condense everything, but this makes it simpler for a user. They navigate to the page and anything that they would want to see or interact with is already there in front of them. This is especially good for new users who aren't familiar with the site because they don't need to navigate around to become comfortable with it. Everything they might want to do or might be able to do is right there in front of them. I'm now going to go and give an overview of what both of these UIs look like. I'll start with Cockpit Composer. When a user navigates to Cockpit Composer, the first screen they see is our list of blueprints. A blueprint in Cockpit Composer and Osbel Composer is a user defined set of customizations for an image. These customizations can be packages or users, hostname, a lot of the customizations you'd want to set for an operating system image. These are defined in the blueprint. Then from a blueprint, a user could create an image. For a Cockpit Composer, you start with your list of blueprints that you've created. Right now we have two of them. If you select a blueprint, you'll then be brought to this blueprint page. We have information on the blueprint. You see a tab here for customizations. A user can enter certain customizations for their blueprint and therefore their image, a list of packages that they've selected, and a list of images that they've already created. Furthermore, there's another page for package selection. If a user wants to add packages or remove packages from their blueprint and images, they can do it here. And finally, Cockpit Composer has a modal-based wizard. This wizard is a create image process and allows the user to select which type of images, which type of image, and where they would like to upload this image for certain image types, and brings them through the process of entering image-specific customizations. The image builder front-end focuses on more of a one-page design, and therefore the user navigates to it and sees this page, which is their list of images. The list of images contains all of the images the user has created and provides information about the image and details, where it's been uploaded, the status of it. It also has this button to create an image. This opens up our modal-based wizard. Now, I'd like to add a copy out here. I define the image builder front-end as being a one-page site, and I said that one-page sites don't have this navigation experience that multi-page sites do, but as you can see in this wizard, we do have a side nav bar. But I would still say that this is a one-page site because this wizard is, each step is fairly small, and we could have them in one long scroll, but we decided that it's better to have it broken into steps, so we can verify and validate each individual step in the process, and it is a guided process with next and back, so it isn't quite the same as navigating around different pages, but that's why I call the image builder front-end a one-page site with a modal-based wizard. Inside of this wizard, you have all of the customizations and image type settings that you would want when you're creating an image. There's a lot of simplification of features and content going into the image builder front-end, but the image builder front-end wasn't specifically designed to simplify Cockpit Composer. It was created to provide a UI for our new hosted service, but it was created after we had already worked on Cockpit Composer for several years and therefore contains many of the features and content that Cockpit Composer has, but in a more simplified visual manner. Now, this follows in several different ways, and the first of which is that the pages have been simplified. One of the main ways this happened is that the image lists have been consolidated. In Cockpit Composer, we use blueprints, and each blueprint, here we have two, each of these blueprints will contain its own list of images. This means that for however many blueprints a user has, they will also have that many different lists of images they've built. Image builder front-end removes this blueprint concept and instead provides the user with the list of all of the images that they have created immediately you navigate to image builder, and you see your list of images. Another way that we have simplified is we've consolidated a lot of our features. This means that we've migrated many features to this modal-based wizard. Customizations now occur in a single workflow, and we have removed the package selection and customization pages because they've been moved to the wizard. Here in Cockpit Composer, you can see three places to enter customizations. First, the Customizations tab. Second, the Edit Packages page. And third, the Create Image Wizard, where you would enter the image type specific customizations. In the Image Builder front-end, these all occur within the wizard. You select your image types, enter your image type specific customizations. You also enter your packages here. And this process has been simplified quite a bit. It does limit some of the information shown. For instance, here you see your packages selected, but you don't see all of the depth solved information for that package. Now thirdly, we have improved the user workflow in multiple ways. By the way, it's the simplification of customizations, and one of those is a clear image type selection. With Cockpit Composer, I mentioned that we have this blueprint concept where inside of your blueprint, you have your customizations stored and saved, and it can be applied to each image you create. So Cockpit Composer, you only create one image at a time. You enter this Create Image Wizard, and you create one image. But Image Builder front-end allows you to create multiple images in one process. Here we've selected AWS, Google Cloud Platform. We're also going to build a VMware image and a bare metal installer image all in the same workflow. Next, the Image Builder front-end has consolidated how we review customizations into a single view. In Cockpit Composer, there are several places to review your customizations, the Customizations tab, the Packages tab, and inside of the Create Image Wizard. In the Image Builder front-end, in order to reduce different pages, we have these all located within tabs within the wizard. You can view your image type specific customizations, your package selection, and other image type and release type specific customizations. And finally, all customizations are now uniformly validated, which is a big improvement to the user flow inside of Image Builder's front-end. In Cockpit Composer, since customizations occur in multiple places, it is difficult to validate and prompt a user when a customization isn't quite accurate. Here, when you get to the end of the Create Image Wizard, we do notify a user that certain fields are missing or are invalid, but we don't provide direct feedback as to where they need to go to remedy this and provide the user to understand the customizations they're entering a little bit better. In the Image Builder front-end, we validate on each step, and this is part of the benefits of having all of our customizations occur within a single wizard and a single workflow, is that on each step of the process, we validate. So here, we're going to upload to Amazon Web Services. This means we need an AWS account ID, and the user here has entered a four-digit account ID, which we know is not quite long enough since currently, they should be 12 characters long. We prompt the user and tell them why it's incorrect, and we also block the process from continuing until the account ID matches what we can guess is a correct account ID. This allows us to have a better sense that when we actually create the final image, when the user gets to the review page and clicks Create Image, the image they create will be both valid to create and also valid to be uploaded so that way the users won't get many image failures, and if they do, they would have a better sense of why. Now, in conclusion, there are many benefits to the existing multi-page design for Cockpit Composer and the new more streamlined design for the Image Builder front-end. Cockpit Composer has a lot more features. It shows packages and their dependencies. It shows a lot more content on those packages, and the Image Builder front-end can't display quite as much information, but because of its simplicity, the Image Builder front-end simplifies the image creation process and allows a user to rapidly go and create an image, which is really nice for a new user. And Cockpit Composer is a little bit better freezer that already is familiar with the OSBuild OSBuild Composer ecosystem and knows the process already and therefore has more control over the process. Now, I'd like to give quite a few thanks out. I am a primarily developer. Most of the design and user research that went into Cockpit Composer in the Image Builder front-end was done by Jen Giardino, Andreas Nielsen, and Katie Ryker. They are the primary researchers and designers for these products, and I just sat in on many meetings with them and implemented their designs. And today I've been talking about my perspective as the developer who is working with all of these designs in rewrite. I'd also like to thank our collaborative projects. We use pattern fly components throughout the Image Builder front-end and Cockpit Composer, which is wonderful because it allows us to quickly implement new features, as well as having a uniform view on the project. Both Cockpit Composer and Image Builder look very similar, which is really nice. I'd also like to thank data-driven forms. This is how we add our input fields and allows us to quickly add new steps to the wizard and validate each input we have. Furthermore, Cockpit Composer exists within the Cockpit ecosystem. The Cockpit team has been extremely important in allowing Cockpit Composer to exist and is a wonderful project. And also Red Hat Insights is that for Image Builder's front-end. We exist within Red Hat Insights on console.redhat.com. I'd like to thank both of these projects. Finally, of course, I'd like to thank my wonderful Image Builder team. And if you have any feedback or want to get in touch with us, please reach out to me at jcosol at redhat.com or check out our GitHub, github.com, slash osbuild. Now I'd like to open it up for any questions that people might have. Thanks, Jacob. I don't see any Q&A questions right now or in the chat. So I think you're okay on that. And you already told people how to get a hold of you. And will you be on a work adventure after this? Yes, I will hop on the work adventure. So if anyone wants to interact or ask more specific questions. Right on. Right on. Cool. Well, thanks a lot again, Jacob. And we've got our next speakers coming up here at 1230. So if you want to stick around or mingle somewhere else or go to work adventure, go ahead. Okay. All right. Well, thank you very much. And thank you everyone for attending today.