 My name is Serena Nichols and I'm the UX design lead at Red Hat for the developer tool area. Thanks for joining me today. I'm going to tell you a little bit about myself first. I was an, I have an undergrad in computer science and was a UI developer for about 15 years. And then I, I had that kind of, it was a long time ago. So I had that hybrid role when they didn't have UX where I was always designing and developing at the same time. And then I formally kind of transferred out of that hybrid role into the UX field just about 15 years ago. And then I went back and got my masters in human factors. So I've been studying and practicing UX for quite a long time. So now I'm, I'm leading, I've been at Red Hat for about five years and I'm leading the dev tools area. Specifically what I'm going to be talking about today is the OpenShift developer experience that was introduced in OpenShift 4.2. So curious by a show of hands, are any of you UI developers? All right. Yeah. Okay. Are anybody, is anybody a designer? And does anybody use OpenShift? Okay. Cool. Awesome. Just have to figure out how to move the slide. Sorry. All right. So today we're going to talk about designing a user experience that developers love. I'm going to discuss the process around what, how that process might look and then dive a little bit into developer experience as a case study. So that first half is kind of going to be around the UX process and the second half will be around OpenShift itself as a case study. So anybody who works on software in general likely already knows this. It's pretty hard to develop, to develop something that users love, right? It takes a lot of time and dedication. And in an ideal world, kind of three groups work together to get this stuff done. It's product management, user experience and development. So let's talk about the three headed monster. Product managers usually set the product vision and set the project goals and they have intimate knowledge around the competition in the market and they prioritize the backlog whereas UX leads the user experience. This includes end-to-end flows, visual design, research and feedback loops. And then we usually have a UI dev lead who determines how the user experience is implemented and of course other projects, I mean other developers behind the scenes doing a lot of the technical work, but I'm just going to be talking about those three spots for the most part. So with these three, when these three leads are, and teams collaborate, the outcomes are a lot more positive, right? So I'm just showing here and the overlap of some of the work between or the roles between product management and UX. It's a great visualization of how those interact. So I think I had, was there one designer here? I'm curious if whoever the designer was has, works with a PM. You don't? PM. Okay, yeah, which makes, I think it makes it a lot more difficult. Typically, like the product manager also has product knowledge, they know about the market and all that kind of stuff as well. So what's nice about a role definition between three areas is it helps to articulate why the roles or how the PM and UX need to communicate. So now I'm going to now take a few minutes to discuss some design stuff. So from a really high level perspective, it's pretty easy to generalize the different UX maturity levels by if you're engaging in proactive or reactive design, right? So this image is really associated with reactive management styles, but it's kind of the same thing. When you do reactive design, usually the developer's just developing and hasn't thought of the end-to-end flows or hasn't necessarily thought about the users or maybe they have, but they're more thinking of, they haven't spoken to the users. So essentially what happens with reactive design is development team implements something, designers, they come and ask the developers, hey, can you help us out? And it's like, or they're finding out from their users that there's issues and we have to fix them. But does that mean reactive design is bad? Definitely not, because at least you're going back and fixing things, right? And oftentimes when you're in a fast-moving market, you don't necessarily have time to do the upfront design either. So sometimes that happens and it works out well. But the proactive design approach is a lot better, in my opinion. You're informed by actual user needs, not by guesses, and this is a quote by Jared Spool, right? You promote what an ideal user experience could be. So in my mind, I call this design-led, but being proactive definitely requires a process change and also takes time and patience. So does it mean that people should always be proactive? It depends on the product you're working on. If it's a brand new product and you have enough time to do it, it's the best thing to do, but we don't always have time. And also companies don't always have money, nor does open source, right? So now to dive a little bit more into once you decide if you're going to do proactive design, which process should you use. There's two main processes in my mind, user-centered design and design thinking. But as I mentioned in the beginning, I've been in the field a long time, and in my mind, these are just kind of buzzwords around the same process. There's not much difference between them, and if you do some searching on the internet, read books, go to classes, you often find different visualizations for the same processes. So I'm just going to go quickly through four. This is UCD depiction, which puts it super simple, right? You're going to do analysis where you research your users, then you do your design where you're designing for the users, evaluate where you test, and then implement. So this one's fairly easy, and this one's a lot more complex. But it's also got a lot of nice detail in it. It calls out some of the specifics, so the different methodologies to use the different discoveries. So competitor analysis, audience definition, user scenarios, content surveys, all part of discovery, and then you have your concept section, and then your prototyping and user testing. So this diagram doesn't actually include the development piece itself. And then if I switch over to design thinking, this one's pretty neat in my opinion, because it starts with the line that says awareness. So you're doing research so that you can empathize with your users, then you define what you want to do, then you ideate and prototype, and then you validate. And it shows that it's all iterative. And the really cool thing at the end to me is that it shows that you've made an impact at the end right if you're following these methods. The other thing that this is not showing is kind of like the diverge and converge, so come up with a ton of ideas or a ton of designs, and then come back with the best. And then here's the final one that just showing again, this is a little bit more detailed around design thinking, where it's kind of putting it in three major areas, understand, explore, and materialize. But again, it's all pretty much the same type of steps throughout the process. So since we only have an hour, I'm going to dive into one piece of this part of the research, which is around the research and analysis phase, which is who's going to use it, right? So in order to design meaningful experiences, you have to understand and empathize. So there's two major methods that I've used in the past. One is personas. I think people are probably very familiar with these. It's part of your audience research. It includes demographics, details like age and gender, what motivates you, what your responsibilities are, frustrations, et cetera. But it's usually, if you're talking about personas, it's like who is a person using your software? And how do they feel or what's their background? Which can be very helpful. We also have something now that are called behavioral archetypes. So they're more focused on user behavior. They contain details from user interviews around the group's needs. What their motivations are and what their pain points are. So they focus more on who does what when they do it and why. So the interesting thing about this is that you can have multiple archetypes. No, a person can have multiple archetypes as they're going throughout the journey of your product, depending on their goals. So that was the initial portion around design. And now I'm going to switch over to the OpenShift case study. Here, if anybody has any questions as I'm going through, please let me know. I'm not doing live demos. I have some screenshots and animated gifs because the connection here as well as going back home is not fast enough for me to do it. So I apologize about that. So again, designing a developer experience that works for everyone is really interesting challenge. Developer goals vary. And as they come from different organizations with different levels of proficiency, it's pretty hard to create an ideal interface that makes everybody super happy. And then there's a lot of design challenges, not to mention additional complexities of working with open source projects. And when I mean that, it's that OpenShift is working with a lot of different projects. Not only that, we're working with a lot of operators, right? And a lot of operators are coming in at various times. And we're trying to create UI and UI interface for things that we don't necessarily know when they're coming. So it's been an interesting but fun challenge, I would say. So I mentioned the three-headed monster before. Today I'm going to discuss how our three-headed monster kind of approaches the problem. So here you have a fun picture showing the UI dev lead, the UX lead, and the PM leads. Actually, our PM lead, the guy on the right-hand side, Steve Spiker, was supposed to co-present with me, but I'm here alone. So it would have been a lot more fun if he was here to have his head face shown in person. And this actually, it's not really an accurate description kind of of our monster heads, because we really have additional PMs representing other things. So Steve is the PM associated with dev tools, the developer experience. But then we also have PMs for K-native, tecton pipelines, code ready workspaces, Helm charts, GitOps that we're constantly working with and getting their stuff into the UI. So the UX and UI teams, it's a large collaborative team. And as I mentioned before, the more we collaborate, the more the product works, the better the product comes out. For the developer experience of OpenShift 4, we just started the process last February. So we had a face-to-face in Bangalore with our team, and we had a few small ground rules, which makes sense, but it was great that they were written down and everybody agreed that PM has a final say on features, right? And what the timeline is or what's kind of focused for a release. UX has a final say on user experience. And then UI Dev has a final say on how things are developed. But that doesn't mean, and first of all, it's not just the leads, it's the entire team. But that doesn't mean people don't, you know, impact the other areas. So developers are always talking about, oh, I'm not sure that makes sense. What, you know, could be changed user experience, as well as, you know, sometimes, often, we're all doing the same thing. But in the end, we all know the roles we play, and it really helps. It helps to set expectations and have healthy conversations and better outcomes. So I know a couple of you said that you knew a little bit about OpenShift or knew some about OpenShift. But for those who don't, OpenShift's been around since 2011. And the decision to standardize on Kubernetes in 2014 changed the game plan for OpenShift. So in 2015, OpenShift 3 was launched. A lot of people knew about that. For a long time, it had its own console. They had a web console that was not as focused on cluster administration as it is today in 4.0. And then at the end of 2018, CoreOS was acquired, and CoreOS had a lot of great, had a lot of great technology that we were able to now use in OpenShift, including operators, integration with Prometheus and Grafana, being able to provide some really cool monitoring capabilities. So after the acquisition, it was pretty interesting, because the OpenShift console at that time was written in AngularJS. And there was a discussion around upgrading from Angular to either NG or to React. And CoreOS had their product was Tectonic, which was already written in React. So it was actually really kind of cool because they had originally decided to go to React. Then when CoreOS was acquired, it kind of finalized it. Since CoreOS's product called Tectonic was already written in React, we used that as our code base and then started to bring in some of the features from OpenShift over to the React code base. So if those of you who know OpenShift in 4.0, it was predominantly cluster administration. So we lost a lot of the end-to-end flows that we had in OpenShift 3.0 because we didn't have time to bring everything over in React. So that's what this whole developer experience was around, is now creating a new developer experience which is more focused on the end-to-end goals. So our main design goals were to provide a higher level of abstraction of Kubernetes. This is just on the developer side. So there's two perspectives in OpenShift today. There is an admin perspective and a developer perspective. As a user, you can go into both of them. It doesn't matter, but as a developer, you're going to have limited functionality just because of role-based access. So as I said, the design goals is to provide a higher level of abstraction of Kubernetes. So we don't want to force people to have to know about Kubernetes. It's okay if they want to learn more, they can. If they know about it, we still allow them to access things, but we're not forcing them to have to know that. We provide an application-centric focus, give developers an optimized experience with the features that they're most likely need to be productive. So what we're talking about here is like efficiency. A lot of the things that we're doing is kind of like, can we do something in one or two clicks? Or rather than having to enter all kinds of data. We allow users to access advanced options and edge cases, but again, it just takes a little bit more, and sometimes we hide some of that stuff. And we treat workloads as first-class citizens. So I talked about personas and architects before, archetypes before, and so these are the behavioral archetypes we created for our initial release. We talked about the fact that there's an OpenShift Explorer, and we're going to come in and discover and quickly learn about OpenShift. We have an application builder who needs to quickly assemble an application. We also have a code locator, so this one was an interesting one. It was like somebody needs to locate a service that has a problem, and they see a service that has a problem in OpenShift, and they need to quickly be able to identify where that code is so that they can edit it in their IDE. We have the application deployer who might sit inside of their IDE all day writing code, but they deploy to OpenShift, and then they come into OpenShift to monitor it or see how their application is assembled. And then we have the application monitor, and that is, you know, I want to view the components of my application, see how they're connected, see what the health of my app is, and what the connectivity is between them. Now, although we started with these five archetypes, we have continued to kind of add a few more, and in addition to that, we didn't necessarily implement all the functionality associated with all of these in the first couple of releases, right? So OpenShift is released every three months, and 4.3, so our second version of the developer perspective was just released on Friday. So we're currently working on that third iteration, but like I said, three-month iterations are pretty quick, I'm going to kind of talk a little bit about all of those now. So the developer perspective has simplified navigation, so if you can see that top item there, it's actually a way to switch between developer and admin, and when you switch, entire navigation changes. But when you're in the developer perspective, we really only have five main areas. Topology, we think, is our main area where people will spend the most time. From there, you can add things to the project, you can build your application from within Topology, and you can also monitor from within there as well. But we have specific areas, like add is an area where we add things from, build you can see your builds, and build configs, pipelines is where we see tecton pipelines, and then we hide a bunch of stuff under advanced. Things like project access, project dashboards, search capability, and eventing. So the user experience is enhanced as additional operators are installed. So as you saw, a pipelines element inside of the navigation area, that was because the openshift, the pipelines operator was installed. We also support OpenShift serverless, so that means we bring in Knative services, we bring in event sources when that operator is there. We also have a service binding operator, which is pretty cool. So this operator supports the binding capabilities, so if you have an operator backed service, which is a database, and you want to connect objects, that service binding is the way to go. And then EclipseChay is our upstream of code-ready workspaces, which is our downstream, which is the IDE. So if you have that integration, it allows you to do more things, and I'll show you a couple examples of that. So now I'll talk about the progression of our topology view, and really one of the reasons I talked about the history of OpenShift is Steve, the PM, and myself were both the leads for admin console for about a year and a half before we switched over here. So we had a lot of knowledge on what users wanted from the developer perspective already, but it was just a different UI. So we had already been talking about topology, and how would developers want to see their topology. So about a year before our group assembled on the developer side, we had already started, or one of our designers, Christian, had already started doing a lot of discovery. So this was an exercise where people at Summit had actually drawn out what their applications looked like. And then did some brainstorming around how that might look, how pods would be displayed, how workloads would be shown, what kind of details were there, health, build status, all kinds of things like that. And through design iterations, these things were just continued to be iterated on, and came up with new ideas. So this, like I said, this stuff all happened before last February when we started on the project, so it was really good because by the time the project started, we were able to create an initial prototype with a lot of background and data, which actually ends up looking very similar to what we built. Based upon a lot of research. So this is just kind of showing you have a front end and a back end. You have a side panel when you select a node, you see all kinds of details on the right hand side. It just had shown this is showing it scaling up. So in our initial prototype, you could actually see when this finishes or when it starts, let's see. We used to show, like, the number of pods as portions or segments around the circle. Now we're not doing that anymore. We also used to have, like, the way that we navigated differently. So we've done quite a bit of work since our initial prototypes with that. So this is what our topology looks like in 4.2. So topology represents the application-centric view of a project. It displays the different components in the project. So each workload, so each one of those elements, the circular elements, kind of represent a deployment or a deployment config for those of you guys who know OpenShift. We have badges beforehand that is representing the resource type. If you hover over that badge, you can see the resource type if you don't recognize it. And then if you select on the left-hand side, you get the side panel on the right that shows you all your resources. We also kind of have this grouping which is the shape changes based on your elements. But what that is, is you're able to use the Kubernetes-recommended labels for applications. And then based on how you label things, we visualize an application. So now let's look at some of the other features that did ship. We have an application access to things. We have a number of decorators. We call them decorators. I don't know that that's what's going to be in the documentation. But the four things on quadrants, the little circles are Mickey ears. And what those things are, sometimes are visual indicators of status and other times they're indicating that there's an action can occur. So the top right one allows you to open up the URL. So if a route is there, one click access to open up your application. The bottom right hand one, that's that code decorator that I was talking about. So if you do not have the Che or code ready workspaces operator installed, what it does is it brings you right to your repository. If you have Che or code ready workspaces installed, it will bring it right into our workspace with your code in context. The bottom left hand corner, this one's showing its build indicator. You sometimes can either have a build or a pipeline, a tecton pipeline associated with it. So that's showing the status of whichever you have. And then what's not shown here, what's coming in 4.4, is we're going to have a fourth indicator on the top left which kind of shows you. Do you have warnings with any of your associated workloads or is there a problem with any of your health checks that you might have set up for you? And now this is showing the route decorator. So you saw the route decorator was up there on the top right hand corner. I click it, it just brings up a new tab. There's my app. So pretty simple. And these are the kind of things that we've heard from customers wanting to be able to have these flows be super efficient. Another one here is the code decorator. So this is the example of I don't have Che installed or code ready workspaces but when I click on that icon it brings me right to my code repo which is pretty cool. And that again goes back to that archetype that I had discussed. And here this is showing that with the build decorator we have one click access to build logs which again was something that was really important for users when we spoke to them. Also that indicator on the top bottom left hand corner will change whether it's successful or error and that would if it was an error or even running for a long time that might necessitate you to go to the logs. So filtering by applications we also have this ability to filter by application. So by default if you have multiple applications inside your project you see it all but there is that secondary selector that allows you to kind of flip back and forth and have more of a zone, kind of zone in onto a specific application. And what's going to be really cool about that is in coming up soon once we have monitoring inside of the developer perspective you'll be able to have application specific metrics as well. We're going to be adding a tab on our right hand side of the side panel. That will be a monitoring tab and it's going to show you some graphs as well as alerts associated with object and context whether it's an application or a workload. So building your application I talked about this before like this is the page that you either see when you go into a new project that's empty and no workloads exist or when you go to the ad section. So we have kind of end-to-end flows where where you can import from Git deploy an image from an internal or external registry access our developer catalog import from a Docker file import YAML or add a database. And our developer catalog is interesting as well because we have operator back services in there. We have templates we have builder images. We also in 4.4 what's coming is help charts as well which is kind of cool. So there's a lot of different types of items that you can go into the catalog for to help build your application. And this is just showing you the import from Git flow so doesn't look super exciting but the reason I like to show it is this is showing first you create your application I'm sorry your project but what we've done is we've had most of our forms only make you give the really necessary information so you can see here I put in the Git repo it auto detects the builder image type it automatically sets the name of my application sets the name of my workload I could then if I want to create a deployment or deployment config or make it Knative and serverless but all I really have to do is put the name of my Git repo in and then hit go and I'm done but again if you want more advanced options be able to change things you can do so. So this is another piece talked about the service binding operator and so we're taking advantage of that in I think it's in 4.4 we're releasing this so it enables applications to use external services by automatically collecting and sharing the binding information so the credentials connection details secrets config maps all you really do and I didn't I couldn't do this again I'm sorry because I couldn't get it live essentially when you hover over one of the elements in the in the graph you see a little arrow and you can just kind of pull that arrow over and try to drop it onto another target so you see the one that shows the OpenShift logo I just kind of drag that over to the one that's got the PGO icon let it go and it created my binding swarmy automatically so again if anybody was here in the OpenShift three time frame when we had the service catalog and they were talking about the ability to bind things this is kind of doing the same thing it's doing that work for you so the user doesn't have to go and manually create and and share that information the service binding operator helps you do that so again it makes things much more efficient this is showing some of the functionality that we have in 4.4 so Tecton Pipelines again if you have the operator installed we have a tech preview version of this this is a version this is just showing you all of the pipelines the most interesting piece in my mind is the last task status piece so that's saying the last time I had a pipeline run what are the statuses of all of the tasks that are comprised of my in my pipeline you can hover over and get a lot more details but it gives you a really nice bird's eye view there and then if you wanted to drill in you can go into that pipeline run and it shows a visualization of your pipeline so not sure if people know much about pipelines but at a really high level there's serial tasks and non-serial tasks so you have to run code compile first once that's complete you can go to compile and test once that's complete you can start unit test and security check at the same time and then once they're both complete you can go back to image build so each one of those bubbles represents a task and in a pipeline task you can also have multiple steps so if you see the underlines inside of the bubbles that's representing the actual the individual steps of the task so this is something that we definitely need to improve on because of a scalability issue but as you can see like code compile just has a single task and it succeeded if you look over at unit test it had two tasks that were successful security check I see they're all green if you count there's six there's going to be more it's going to be pretty difficult to see an image build has two ones in progress and one is pending and that's what the two different colors of blue are if I had the product running you would see that if I hover over that it gives you all that information in an easier format to view and read so it's something that we're going to have to continually improve going forward in 4.4 well I should say we are targeting 4.4 to support Knative Services as well we had them in 4.3 but we represented them differently in 4.3 we showed does anybody know anything about Knative Services so Knative Services made up of a bunch of revisions those revisions have workloads associated with them so the way we are going to be visualizing this post 4.3 is we kind of have a grouping mechanism so that blue box it's only blue because I have it selected it's typically gray but what we're showing there is all of the revisions that are inside of the traffic block this is a really cool demo when it works but I tried doing it since I got here and I wasn't able to so here you see three decorators on the rectangle you see one up on the top right-hand corner you can see that there's two lines that are 50-50 so that's saying I have two revisions I'm getting 50% of my traffic typically for Knative Serverless what's happening is it's auto-scaled to zero right so you would see both of those node JS elements would really have like white circles because no pods are running and as soon as you hit the route decorator on the top right-hand corner it starts spinning up one of those serverless it starts scaling up one of those servers one of those revisions actually when the system is working quickly it's really cool because you can see the app is loading or waiting to load you see the pod come up and then you see the app start running really quickly so that's it's a pretty cool demo when you can run it we also have the ability to set traffic distribution which I guess I didn't show here so if you have multiple revisions you can change you can go from 5050 to 9010 you can add additional revisions if there exist and that kind of thing again for scalability reasons we're only showing revisions that are associated with the traffic block so now we're going to talk about some feedback here so feedback that we've methods that we've used to date we've used quite a few walkthroughs with customers well we just have one customer that we're really integrated with right now but we meet with them quarterly so we had a lot more luck being able to interact with customers when we were working on the admin console it's really easy to find cluster administrators it's really hard to find the developers who are using OpenShift or developing on OpenShift that aren't Red Haters or that aren't OpenShifters right so it's taken us some time to start creating those relationships so this first one I can talk about them because they tweet about meeting with us so we have a really good relationship with UNC back in the United States and we've been able to do a lot of good work with them and so we meet with them quarterly around the developer perspective and have gotten a lot of great information with them we've done usability testing at conferences so at Red Hat Summit last year we've done it at DevConf here we did it in the US at DevConf and in India actually we've also gone to Code 1 and do testing we have regular feedback sessions with our SA Tiger team so our solution architects as well as with some of our developer and evangelists so you know if we can't necessarily get our developers we're looking for developer advocates who are talking to our developers daily we've done a lot of surveys and gotten a lot of great information we've started our on-site customer visits well just one visit in person but it was six customers in December which was great we'd gone to London and met with a bunch of the people in the FSI sector and it was really enlightening too because you know what we're realizing we know this but what you see is the differentiation between how cluster admins set up their clusters what they allow their developers to access and what they don't so it was really interesting we learned that a lot of times they just shut the developer catalog right off and don't allow access for their customers to that which is interesting for us to know when we're exposing a lot of our the ways that we allow people to develop or build apps through the catalog we are piloted in OpenShift developer user's office hour and it's still going so this is open to Red Haters customers and the community and it's open feedback we demo and get feedback and then we put those those recordings back up onto YouTube so people can go take a look at them and we just started a database to try to collect all the feedback so it can be analyzed and we can share metrics on like the you asked we acted type of thing so I'll show you some of the specific examples around what we heard during some of our feedback sessions and how we responded to those so again like when we do a rolling update or a recreate rollout in 3.11 what they used to do was they had the visualization that's on the right hand side right so they're showing that initial pod spinning up the new pod when it scaled up then they get rid of the old pod but it was shown on the right hand side of or the details page of the deployment config the problem with that was that if you're inside a topology and you didn't have the item selected you never knew what was going on so we ended up changing so now as you just saw you kind of see that visualization internally inside of the node or the element that's on the left hand side so that was one big change that we made based on feedback another one was easy way to scale up and down so in 4.2 we had a dialogue that said I want to say it said edit count or something like that it wasn't very easy to understand that it was associated with pods or anything so we ended up putting this pod donut on the side panel and it's one click access if you want to scale up or down or however many clicks it takes to get to the number of pods you want and then this was another great one I thought we had a lot of feedback both from developer evangelist as well as UNC and that summit that people wanted to be able to see the number of pods so what we're doing right now by default is we're showing like the one time or the builder image associated with things inside of those deployments and deployment configs and post 4.3 we introduce or are introducing a pod count filter that allows you to switch back and forth so if you always want to see pods configure it that way once and you never have to change it again or you can keep it using the image we also now allow you to switch between graph and a list view of topology in 3.x we had something called a project overview which a lot of customers really liked and when we improved the so we've recently just improved the topology view now to allow you to switch back and forth between the graphical view and the more list view list like view that was very similar to what we had in project overview I think this is great a lot of people you know some people are visual others don't want to are interested in looking at the pictures and really want to see the data so this gives the user the option to switch back and forth and again this is something that we consistently heard when we started doing our interviews and I think I mentioned this so we started the project last February and March that March we started doing collecting some information back and getting feedback sessions and we've got a lot of really great data another thing that we had heard about is an open shift today in order to provide access to projects the way that you do it in the admin area is you have to go through role blindings and it's pretty difficult so you know they asked is there a way for me to just say hey if I have access to my project can I just say I want to share it so this is an easy really easy way and it's hidden inside of the advanced navigation item but it's a really easy way to add access for another person and then allow them to either have admin view or edit access if they themselves don't have that role binding capability it won't even be that navigation item won't even be shown in the nav so now I'm going to do a lesson learned so the key to success is in my mind is to be collaborative and iterative at every stage you know feedback is really important so get it early and often if you can't find developers connect with their advocates developers in different verticals really have different constraints and that's kind of what I was talking about where the cluster administrator might set up that cluster differently for open shift but I mean the same thing applies to all different products right different users use it differently and might have different configuration another thing is you can't satisfy everyone because the last probably month or so every feedback session we've had has been super positive and on Thursday I met with somebody and they were like oh my god wait, who leads the developer experience and I was like me and they had some really negative stuff to say and I was like oh darn it but it was going so well but that's good because the more you can continually improve things if everybody always says it's awesome you can't get any better right you want to hear that constructive criticism constantly working with the latest and greatest tech isn't easy and this goes back I'm not sure that it's probably not just open source but if we're working with one of these operators and or something that's going into open shift that's a new API and code freezes almost around the same time you really have to time things really well it's probably software in general but it was always fun when we just had a code freeze on Friday so it was really fun to see what actually got in and working with upstream technologies is also interesting because based on your team and your company how much effect you have in that upstream technology things don't necessarily go the way that you might plan it at the beginning of a release at the end of the release it might not be exactly what you wanted and like I said sometimes even the template plans don't work so what's coming next we have a lot of exciting things we've got Helm chart support we have project metrics we have a pipeline builder coming out when I say pipeline builder I mean through the UI event source creation that's again with Knative and we're going to be introducing a cloud terminal this stuff is all coming post 4.3 not sure if it's 4.4 4.5 but they're all things that we have designs for and implementation already started so for OpenShift developers I think it's going to be great we're going to continually be adding more functionality and of course more collaboration and feedback with customers developer advocates community and Red Hatters so with that that is actually the end of my presentation love to see let us know what you think try out the OpenShift developer perspective we have a Google group which if you join that Google group but just essentially right now it's telling you the time and date of our office hour so join our office hour or feedback sessions you also get a a link to the YouTube videos so you can watch it offline and as always we want to hear feedback so we have an email address so feel free to send us an email with any or all feedback on that user experience so I'm also happy to open it up for questions discussions yeah so actually what we did I'm going to go back to that slide oh sure he said that he wanted me to go back and explain a little bit more about the archetypes so let me see if I can go back here super quickly so what we did was when we first had our face to face we talked about all the functionality and what the initial goals of the product were and then we tried so then we were looking at all the documentation around archetypes and how you build them and so they're supposed to be right around who does what when so we took those user flows and started to try to figure out okay if the goal is for OpenShift to be kind of like an onboarding tool and somebody's going to come in and want to be able to explore and you want them to come in very quickly and easily to do things that's how we created the OpenShift Explorer right so we kind of we kind of tried to take some of those main end-to-end flows that we needed to support and then started talking to developer advocates and a few customers that we were able to talk to and these were our five main groupings since then like we now have a pipeline admin administrator which again so like some of these things the pipeline administrator for example you don't set up pipelines very frequently so it's definitely a distinctive a distinctive behavior like archetype because you're doing a specific activity and have a specific goal in mind but you're not necessarily doing that all the time does that help the answer? okay yeah no problem has anybody used archetypes? no I mean I think personas are really like the biggest thing going but I personally really liked the activity and it also helped like the designer and the developer kind of focus in on for this flow who's actually what are they trying to do I'm not sure that people always know that yeah so I'm going to go back so personas are typically like it's talking about a specific person who uses the interface and you know like these are like a typical format where it talks about motivations goals how much experience you have what are your age that kind of thing and whereas the archetypes are more around behavior so it's who does what when they do it and why so it's more around a specific user flow so you might have the same persona that is is mapped to multiple archetypes does that make sense okay any other questions right okay so I'll let me go back to the specific instance so the question was how do you go about removing features so I had referenced the fact that in our topology view at one point actually you can see it here right at one point we had multiple segments here it is the one that says front end node like you could see there was four segments there so to me that one's not necessarily removing a feature that was more around the usability feedback we got and because of scalability it didn't make sense because when you scaled that up to 10 you get super overloaded right so that's why we changed that was more not a removal of functionality but more about changing the experience because it just didn't seem to work and and then when we switched thank you when we switched from segments to a single arc per type or per status we then got the feedback well now I don't know how many pods I have so that's why we went to the option where we have this note the viewing the pod count that's why we gave this option right because we originally allowed you to see it through the arc removing functionality is a big thing that UX doesn't typically have you know it's PM usually it has the final say on that one that's a difficult thing to do I yeah I don't have an answer on that one I'm sorry anybody else have questions alright thanks for your time oh one more sure yes so right so it's really interesting we had our OpenShift UX team we actually have three kind of mini teams within our OpenShift UX side people focusing on developers people focusing on admin and then there's a multi cluster CNV and storage section as well and we had a face to face last September last fall and the research team is actually doing a lot of interviews like one on one interviews and they're doing something like this creating a database for the nuggets that they get right and that's what they're focused on but this past like a month ago we started doing it inside the developer perspective for our own utilization so it's a pilot for us we're really right now what we're doing is we're using a Google Sheet it's not the greatest but we're trying to pilot all of the information that we got since last March by the end of this month and see where it takes us we want to be able to have some really nice visualizations that show like the value of what we've been doing and how we've responded and how that feedback has worked not only for you know for multiple reasons for you know to show the value of what our UX team is doing but also to show the users that we're really listening so we heard this five times and this is how we responded that kind of stuff so we really want to utilize that to help start creating blogs and sharing the information out that way yeah anything else? thanks everybody have a great day