Welcome to Agile Roots 2010, sponsored by Version 1 Rally Software, Virio, Amirisys, Agile Alliance, and X-Mission Internet. Agile User Experience Design by Dan Harrelson and Todd Wilkins. From our perspective, some things that we've learned about when you try to get Agile processes and user experience processes together, both successes and failures, I guess you might say. One thing I wanted to say before we dive into this is that we actually have a lot of slides because we wanted to go through some case studies. But in seeing some of the sessions today, there's been a lot of really good conversation. People ask a really good question, which has kind of led the conversation in a direction that seems like it might be more relevant to people in the room. So we want to encourage you guys to, if you have questions or thoughts about things, just feel free to raise your hand or step in. Because if we don't make it through all the slides, it's probably better if we talk about things that every year I'm actually hearing about. And we'll make sure that we cover the stuff that we think is the most important here if we have this kid passed away. Alright? Great. So I always start because we used to be conferences that aren't really mere designers, mostly. And so when we go places that we're not full of design folks, I always want to make sure that they kind of know who the heck we are. I don't know if there's anybody here to know who Adaptive Path is. Somebody probably knew about me. So we're a user experience consulting firm. This is our sort of mission statement, you might say. We help teams and organizations create products and services that deliver great experiences to improve people's lives. And I know it sounds like just like a marketing phrase, but it's actually something we very much drive our decisions about what we do and our practices, the projects we take. And we do a lot of different things in order to try to meet that mission. We do a lot of consulting work, which we'll talk about today, but just so that you guys sort of understand a little bit more about us. We also do a lot of events, we put on conferences, we'll be training all around the world, trying to teach people how to do user experience work. We work with developers, business analysts, marketing folks. I think I've worked with almost every kind of person that tries to make a technological artifact. Other designers. Yeah, other designers, trying to help them understand how to get good experiences out of the world. We also try really hard to share everything that we've learned. We work on conferences and write articles and that sort of thing, because we feel like everybody gets better, including ourselves, the more ideas we get out for people to try or react to. So just so you kind of know where we come from. And then the other thing, which I think is always important to us and just so you understand why we even come to conferences like this to talk to people who are generally speaking a bit different than us, is that impact is really big for us. We choose our projects based on kind of impact they can have on a world positive impact. And at the end of the year, we often sit down and do some kind of rough back of the napkin calculations about, like, these are the projects we successfully completed this last year or two. How many people do we think we helped? And they're very rough, you know. So the last couple of years, we helped about 300 million people. That's about 8.6 million people for each one of our employees. And that sort of, I mean, it's a back of the napkin measurement, but it's something that we spend a lot of time thinking about because we want the work that we do to really be impactful. So that's why we're glad to be here and share our experiences with you, because we hope that that will also help have a positive impact on the things that are getting made. But that's it after practice. So then the question might be who the heck are Todd and Dan? And this is who Todd and Dan are. Oh, I didn't switch that back before, but I'm a UX designer. I'm also the director of our studio in Austin, Texas. I always like to share something interesting because I'm the designer. I thought everybody here would be interested in knowing that I actually have a computer science degree back in the day. I actually have done things like coding the kernel of a multitasking operating system from scratch. I don't do those things anymore. I think I would be really worried if my life depended on doing something like that today. But I have done it before, so I can at least, I can understand that I have a sort of strong kinship with a sort of development mentality. And I also like to brew my own beer. So I like to mix up and just don't do the coding anymore. And then Dan, I'm going to pass it up to you. So as it says there, I'm jealous of Todd because I don't brew my own beer. I like to drink really good beer. I drink his. Some day maybe I'll get a chance to do that. I'm a design technologist. I work out of our San Francisco office. The term design technologist is pretty sort of explanatory of what it is. I've spent about half of my career in actually coding and building and working in development and architecture. I've spent about half of my career designing. New experience design, everything from research to interaction design, et cetera. Sort of my thing to tip it here is that even though I have, you know, written in JV code and, you know, schema for databases, I also just recently spent a couple of weeks tooling around all the parts of the UK, talking to small business owners about what they're looking for and doing collaging and doing some in-depth ethnographic research. So I kind of have both of those backgrounds that I bring to the table here when we're working with our clients. So with that kind of background about who that path is, who I am, who Todd is, kind of what we're bringing to the table here, let's dive into the meat of this and tell you a bit about what we're hoping to talk about today. In general, what we're trying to raise some awareness about, I think, is that through our experiences, through some research that we've done, through consulting work, et cetera, we actually think that the processes that user experience designers take and the processes that agile developers tend to take are a lot more the same than different. Hopefully we can kind of talk about some of those things. We'll also dive into a bit of the differences as well to make sure that we sort of highlight, you know, the ways that maybe people who are, you know, worried to code, those who are worried to, you know, look and feel kind of think differently and then talk about maybe some ways that we can use the tools and techniques to help bridge those gaps, help people have a shared vocabulary and have better conversations so that when, if you're in a dev team and you need to work with, say, the UX team, then you can better, you know, share ideas and end up with a better product at the end of the day. As Todd mentioned, we really want this to be very conversational, so feel free to jump in and ask questions, you know, call BS on something that you don't believe in, that kind of thing. So let's start off by kind of getting the stereotypes and that kind of thing out of the way.  Who's your classic designer? Maybe something like this comes to mind, right? You know, the Apple guys.  You know, these may be sort of two ways that in reality people are seeing each other, right, that somebody who is a designer as a developer kind of sees the other party. Often they also see each other this way. They see each other as the person whose job it is to say no, right? A developer's job is to tell a designer, no, that cannot possibly be done. A designer's job is to tell the developer, no, you can't do that because the user will hate it, right? This is it. This is reality. Some of this is actually happening out in the world and this is what we're hoping that we can maybe overcome a little bit by identifying, you know, that these are the cases that we actually do have more in common and maybe try to develop techniques to kind of get away with hurdles. Sometimes even we see developers and designers in this way, you know, they're on opposite sides of a big waterfall, right? Certainly people in this audience, you know, are not working this way, right? Everybody has a nice, pure, agile, very collaborative kind of working environment, but, you know, maybe there's some other place, you know. Unless you work before. Yes, yes. You have some friends that work places like this. You know, maybe you see each other this way, right? You see each other somewhere at the end of an email, you know, in another department, maybe on the other side of the campus, that kind of thing. So sort of knowing that we do have some of these preconceived ideas about how designers, developers, UX, agile, maybe are different, we can dive into some quick little setting about how Todd and I are looking at the world of agile, the world of design when we were more thinking about the sort of problem of how did the two groups talk.  We know that there's a lot of philosophy tied up into agile, right? We know that this is sort of bound up with the whole world and it's not done simply because everybody really thinks that it is the best way to be creating great software, right? There's a lot of, yeah, a lot of, kind of, overarching philosophical ideas that go along with it. There's also, you know, logistical ideas that come along with agile, right? It actually manifests itself in certain processes and certain techniques that take this philosophical idea about how to build software and actually execute it upon it. And then, you know, so, we didn't want to tell you about agile because you already know about agile, right? And we don't know that much about it, but what we can tell you a little bit about is that's sort of where we're coming from. Like, all we really felt like we really, what we've run into the most is an understanding of what the philosophy is, right? But what we can tell you a little bit about what we mean when we talk about design because that may be something you guys have less experience with or at least not something you maybe do on a daily basis all the time. And what I want to start off actually by talking a little bit about what we say design is not as far as what we're talking about. So, I'd like to talk about five ways of thinking about design, four of them which I think are not going to be helpful in this conversation, but I want to get them on the table so that we can ignore them explicitly. So, the first one is seeing design as aesthetics. It's about the beauty of the shape, of the form, of the color of that. We're not talking about design as aesthetics, though that aesthetic are important in design. We're not talking about design as a distinct role. We're not talking about that guy with the kind of spiky, cool tennis shoes down the hall trying to grab what he does with all of those post-it notes. That's also not what we're talking about, not that specific role. Not talking about design as a thing, people often talk about industrial design as a sort of artifact, not what we're talking about. And then we're really not talking about the idea of design as sort of the rock star designer type. That's not what we're talking about either. So, when we say what is design, it's none of those things. What is it we really want to say design is? I mean, when we talk about design, or the course of the next little bit of time, we're talking about design as an activity. Design is a verb. It's something that you can do. And it's an activity that an organization can embrace. It's something that everyone can do. And I know that all of you do design. You guys use the word design probably every day in your life. You're talking about designing software, you're talking about designing architecture, you're talking about designing a database schema. Design is an activity where we're adding some structure, creativity to create a sort of structure or a tangible artifact based on a certain set of constraints. That's what design is. And then you just do it in different contexts. And the activity of design is the thing we actually want to talk about a lot today, because it's the thing that actually has so much in common with what has kind of developed in the agile world as well. The nice thing about design, though, is that when you focus on the design as an activity and you look at design as something that everybody does, that designer, someone who might have that title or something in an organization, ends up being a facilitator. It ends up being their job to help everybody go through this process and do this activity. So they engage sort of cross-functional teams. They can design ideas out of them. Then they work for finding them and hone them. That process there, if I didn't attach designer to that, that sounds very much like the kind of thing that a lot of sort of agile development processes are doing. You get a cross-functional team. You get some ideas out and you start to refine them. And so if that's what design is, what is UX design, all of that is it's design of a specific focus on users and the overall qualities of the experience. Why do I make this case? Well, this is actually the point when you, and when I think you begin to see where there could be similarity, some points of agreement between what we have seen from agile. When I use the word agile, I think I'm going to continue to just reinforce that. We know in little A in agile development environments, or agile sort of software development environment. And so I wanted to start off by talking a little bit about what those points of agreement might mean. And there's two really big ones, I think. Iteration and a focus on the user. I think that that's a pretty well-established part of the agile development process. You want to iterate through things quickly. There's this huge focus on user stories, which is actually not the kind of thing you necessarily find in a lot of other development approaches. I think the other thing that's really interesting is that the sort of philosophical aspect of agile is actually, it comes across in the sense that people who are doing agile development spend a lot of time explicitly reflecting on the process that they're going through and why it might be the right process to go through. And user experience designers often try to do the exact same thing. They try to think about what we're doing and why we're doing it now in order to get the best results out of it. So those two kind of perspectives are things that are very much in common between the two, these two sort of fields that develop from completely different places. They just sort of ended up in a very similar place now. And one of the things that I think actually helps to make this case, and one of the reasons why I like why I believe this is true, some of you have put a slightly skeptical, but that's okay, because I think I can prove it to you. Because we actually had a really, we had this sort of advantage of actually being paid to do a really interesting study, a research study about designers and developers and how they work together. And it was actually one of the best projects I've ever done. So it was a lot of fun and so easy in the insightful and it maybe changed a lot of the way that I work, actually. And interestingly enough, this project was created for Microsoft. As you guys probably may or may not know, Microsoft has been developing tools and platforms for the work, as they call them, web designers. For a few years now, so Silverlite, WTF, they've gotten the .handwork framework. They've got this whole expression suite of tools that they've been developing. And after a couple years of working on it, they realized that they didn't understand people who were creating what they called sort of web designers, as well as they would have liked. And when they used the word web designer, what they really mean is people who were making kind of rich, networked applications that may or may not run in a browser. So while I say it's not websites, it's actually something more complex than that. They actually used, they talked about rich internet applications. I don't know if anybody feels like they know that or it's worked on in something called a rich internet application. Basically, it just means it's an application that has some media in it and has the internet connected to it, which is slowly becoming every application. So the things that we learned about these people actually should, if they don't apply to today, they will probably apply to you very soon. What they did is they came to us and asked, they had three questions. And I simple by these, but it was really quite as simple. What are designers? What do they do? What do they make? How are designers different from developers? Because Microsoft feels like they understand developers really well. Huh? Well, at least a certain kind of developer. Somebody doesn't believe that. Yes, that's fine. They believe that they understand developers really well. They actually can't deny that. They wanted to know a lot about what the differences are between the kind of work that they do and how they approach their work. And then they wanted to know about their workflows.  We talked to designers and developers and managers and people of all sorts of different roles.  And we spent a lot of time with them to understand what their process was. They showed us their artifacts that we talked to people, multiple people on the same team. So we could really just get a sense of what they were doing and why they were doing it and how they were doing it. And what came out of it was that we got four basic archetypes of people in these processes. And I think that you guys will end up feeling like you know some of these people. They may have a different name in your organization. People will have run into all of these people at some point. You probably know someone who looks kind of like this. So who are these people? I'm not going to go through the details here, but I just want to kind of point out the archetypes. They're kind of important. So here's Sean, the architect. When I use the word architect, this is not like a database architect. This is like someone you might call an information architect. Someone who, in some ways, they might be called your program manager or product manager. The person kind of makes the requirements or maybe builds the spec you're supposed to develop to. This is somebody who's really, really focused on having a vision about something and helping to kind of give that vision to somebody to make. You have people like Natalie, who we call the inventor. She tends to come from a creative background of some sort. She'll be much more wanting to get her hands dirty. So she's the person who may have a creative background and may be the kind of person who puts together specs and wireframes, but who also really likes to nail the devs. You can talk about what's possible and, like, prototype stuff. She's the one who breaks out the sketchbook every time when somebody's trying to solve a problem. So she's really, she's really, she leads the creative effort, but she's really, she wants to get her hands dirty. Sean doesn't want to get his hands dirty. And then on the other side, we have sort of two, two folks who tend to do what you might call development of some sort. We've got Greg, the designer's slash developer hybrid, which was an interesting thing we found. And I think you guys will probably all relate to some people like Greg. And we'll talk about him in a minute. Usually, this is somebody who's come from a design background, probably started developing something in, like, flash or JavaScript or something like that and then slowly started kind of beeping up development chops until he was able to actually code stuff in a fairly, like, sort of robust way. But he still kind of maintained that designer's mentality, especially with focus on users. And then James, we probably created Coder because I think actually a lot of folks who come to this conference would be this kind of person, someone who's solidly in the world of development, but it's not somebody who wants to just kind of follow the old-state process of development and use the old-state process of tools. They see themselves as creative, but they're a builder. They want to build stuff, but they want to think about those things to the kind of people who will, in the middle of a development conversation, bring out something related to Russian literature because they see that it relates in some really important way, you know. And so I think that sort of the creative aspect of that coding is actually really important, especially these people would tend to be more agile than what your classic developer would be. Do these guys sort of make sense? Have you guys met people like this before? Anybody? A couple of you? A couple of you don't know anybody at home. They might become more, make more sense to you as you start to see some of the developers. Great. Great. Somebody has worked with all four. So you can maybe give us an anecdote as we walk through until you know that. I was going to get past the details of this table. I don't think we can dive into it. Because what's interesting is actually the trend that we found amongst these archetypes. So I'll start off with them. The first is this designer developer hybrid because I think it's something that you're climbing. I think you all in turn know they exist, but people don't talk about them quite as much. Most organizations don't want somebody who doesn't need we bit into some sort of bucket. And people like the designer developer hybrid always do, always they break up the mold. So they're almost always somebody who comes from the design, from a design background. So it's like the designer who starts to sound like a developer. We talk to these people and they would, the quotes are kind of amazing, are kind of interesting. I'm pretty proficient in code. I spend 80% of my day there. This is somebody the organization thinks is a designer. He spends 80% of his day coding something. This other one was a really great example. My hope is that some of the things that we're doing, total abstraction, frameworks are going to influence the way the rest of the company works to make it pretty guys are going to determine how things are going to get built. This mentality is really common. And these people are actually taking a sort of really forward role in the development of a lot of these, a lot of these kind of rich applications. And they're also the ones who are breaking your standard processes that kind of waterfall. Because they see themselves having something to contribute all the way into the process, not just one end of it. So it was an interesting trend. I'm sure you guys, does anybody here think that this is sort of them? Anybody but this mold at all? Does anybody know somebody like this they work with? This is one that I think is, you guys might actually appreciate this one a bit more too. Does that sound like a really strange phrase as a newcomer? Anybody ever done any sculpting? So sculptors often talk about having a conversation with their materials. It's a common phrase in art. The idea is that you get a big block of granite and you kind of have an idea that you want to make something out of it.  But after you start chiseling away at it and moving into it, you start to see things about the grain. You start to see sort of see shapes or get feelings out of it. And as you start to do that, you actually change the nature of the thing you were going to make. So it's not like you start with a vision and you just make the thing. As you start to work with your materials, you begin to change the thing you were going to make in order to respond to the things that those materials bring to the table. And so for example, when you see this, you're partially through. Does anybody have any idea what this is going to be? Torso. Torso? Anybody else want to think of? Hip hump? Turbul. Turbul. Pony. It actually is going to be a turtle for what it's worth. This is a process of somebody else's eye. So it's a good eye. But if you see this, it's a big block that would have been really hard to them. Yeah, I think, have you heard the microphone? He says, I don't try to create a sculpture from a stone. I see the sculpture that's there and I move everything out of the way. The sentiment. That's what this conversation is about. And this translates really well to code. Because you start to talk to someone, especially like Greg. And what they want to do is acknowledge that something's been going on all along, right? I can't think of one time in a picture I had in my mind is what we ended up with on the screen. A lot of times, because you stumble across or evolve into something that's better. That's always been happening, although most upper processes don't acknowledge that. And many design processes actually don't acknowledge that. And many design processes actually don't acknowledge that. They want to do all the design up front without ever touching anything in the code. Another thing that Greg had, something that Greg actually said, this process is actually really good when you're trying to do something really new using new technologies that you don't totally understand the capabilities of. Because you have to learn something about them before you can really design effectively to them. And the great thing though is that like certain design type folks actually really love this process too because they realize that as things, as experiences get rich, the design can be static. It's really alive. And so transitions, state changes, the shape and movement of things on the screen actually is a huge part of the functionality. And so you need to be figuring those things out at the exact same time. So someone like Natalie really loves this idea of a conversation with materials. She's someone who wants to get her hands dirty with materials to figure out how to do the right design work with it. And the thing that I thought was awesome in this is that we actually had a couple of people who would use it would say, I'm doing some thinking in code. That's what I need to do. Like some design folks would do this in my favorite from my hip work in the whole study. Coding is the sketch. Python is my thinking. Right? This is somebody who actually works at a relatively well-known boutique firm that does kind of crazy data visualization work. And you would imagine that when somebody came to a project with them, the first thing they would do would be like open up some book about data visualization on it. Something like that where they would get up on a board and they would start figuring out what are the shapes going to be, what is color going to communicate, what is shape going to communicate. The first thing they do is they open something up and they connect to the database. And they start to figure out what data is in there and what the story of the data is going to tell. And he starts to sketch through what he's going to create, purely in the code. And it's only later that the visual comes out of it. They need to get in there and start messing with things tangibly in order to understand what the design needs to be. So this trend was a really interesting one and it sort of speaks in our mind to the place where designers and developers are actually thinking very similarly. They just are using slightly different tools to do it. So for example like previously here, Natalie were sketched something out and then started talking to a developer about what was possible and then they would start photographing something and then go back and forth. And this has an interesting implication for the way the workflow works. And what's interesting here is everybody we talk to literally every single institution we went to, they told us they use the phrase of something like this. Agile seems to be the closest to what we are doing anyway. And so none of these people were strictly formal agile developers nor had they necessarily adopted a strictly formal agile development approach. So they all had a sense of what Agile was about and they all had a sense that that basic process people used the word scrum although I wasn't really sure if they meant if they really knew quite what that meant. But they were really into sort of this iterative process and it seems to be working really well for them. And I think I put all four of these architects here to point out that three of them, Natalie Gray and James all really loved that and it made Sean really uncomfortable because he doesn't want his hands dirty. So he really likes the idea of doing like he knows he's having to do something agilely but he really wishes he could just think about all of it and then give it to somebody to thank. But they all had to acknowledge that it was the way they were working. Whether they wanted to be working that way or not. And so what we saw were things like your sort of traditional waterfall model like this where you can design and hand off. Sean was like yes. Stick with it. But everybody else in the process started telling a different story about this, right? They would sketch out the stories of projects which is why he's kind of like James. And somebody who was like James a coding person came in and said well there's this first part of this project where we decided we would do it kind of traditionally. We'd split up the design and the development and we'd have the kind of developers who would work on like what's possible and feasible and designers would work on how it's supposed to feel and then we would reach this point where the design would have the design done and we would understand the basic platform to build it. And what happened was he's like well when we came together he's like it was not so happy. And he said that they were just everybody was frustrated it was a room it was a meeting where everybody's had them yelling at each other. Because because they hadn't been working together. Like they totally split those things apart and they both had they both had a different idea about who owned what the project was going to end up being like. So what they did is they said okay well that didn't work let's try something so for the next step they as he said they started scrumming and then everything started to go smoothly. He used the word scrum but I really have this and I don't know if like I'll let my need to take not need to take but I scrum probably has some more sort of specific meaning within the answer world but he just meant we did things really quickly all together in the same room in little bits and you love it you can tell he had this huge smile on his face and the designers we talked to in this organization also did so whatever scrumming is to them which I think approximates a lot of what the formal agile process is it just totally works and the reason it works is because they were trying to do something really new and really kind of innovative and the only way to do it was to have the designers and the developers iterating quickly through ideas together and everywhere we went people would draw something that's almost exactly like this which is like sort of here's design development there's just lines shooting back and forth between both of those all the way through and the reason was because what that end up doing is kind of it just it was just like sort of iterated through and it started at a kind of fader idea and slowly it added it added fidelity until at the end you had the real thing done and it was just it was amazing how powerful this was for them to work this way and they would say things like there's no difference between back end and UI people we're all saying how we work with this information they all get in the room and they work it out together and these three folks were really really happy working that way and because more people were happy working that way more good work was getting done and and I think the other reason was working really well that we saw was that this process is iterating through things quickly and sort of collaboratively was something that actually jived really well with what both designers and developers wanted to be doing they actually just didn't realize before that they both wanted the same thing until they started doing it together and having gone through this process one of the interesting things we found was and I think this would mean something to you guys is like deliverables and artifacts what is it what are these people actually making that's helping this process go forward right like what is it actually what is the thing that comes out of a scrum look like or what is it in this process where the designers are really kind of trying to do the same and we found a few things out first one is like Photoshop comps anybody ever worked with Photoshop comp do you know what that is do you know what that phrase means it's like a static Photoshop file it's supposed to tell you what the interface looks like and possibly how it works comps definitely live on in this environment and there's two reasons one is that Photoshop is essentially ubiquitous and if everybody has it it's sort of an easy point of the realm so everybody uses it the other one is that as you get into rich applications you need a sort of high fidelity in the visual representation and Photoshop's pretty good at that it doesn't communicate function very well but at least in it can give you a high level of fidelity and so people are trying to make it work when it doesn't work people often there are some problems that is my favorite you couldn't build a Windows application like this because people mostly work in the web world where that's more common than Photoshop comps but they're like you know what is that button supposed to do nobody ever told me it just looks nice in order to deal with this issue we have this sort of wireframes anybody work with wireframes a lot? got you a person to do wireframes? wireframes are interesting wireframes seem to be mediocre at everything right? they provide more functional definition with annotations than you get in a Photoshop comp but they're still really really stacked they don't change they don't move they don't show state well and so it's really hard to have them be really move a conversation along in this process and so you get quotes like this from the developer class the UI expert makes wireframes and hand them off but he does not bring a lot of value to me the zero concepts aren't that useful it's not that the design person is not having good thoughts it's that somehow they're not being captured communicated or even sort of refined in a way that's effective for the for the process and so we found it was simply working better and we'll talk about this a little more later is something like prototypes, demos and interactive storyboards and it's because they're dynamic they're flexible and there's something that you could create so this this one I actually really love this one I'll sort of show it to you this is somebody who's actually making a quick interactive storyboard in Keynote because he could communicate the states and the changes really quickly it's a super lightweight development environment as far as he is concerned as a designer but it communicated so much more clearly in a wireframe to his developers who could quickly take it and turn it into something that was much more real and this sort of led to a sort of common refrain don't comp one of my favorite quotes from this when you make the comp and then the stuff the comp can't learn from the stuff but I think it's really true right and most of the people were leaning towards the idea of just trying to build things quickly because it just made things clearer so I think the big takeaways from this are we learn about stuff probably not stuff that's like some of the stuff was not going to be amazingly new to you but what's really I think the thing that should do is hopefully if you can see before but it also shows that it's really ubiquitous these kinds of experiences people are having because of how many different kinds of places we were able to talk to and see this this kind of this sort of sort of patterns that people are trying to deal with and all of them as you can start to see it all starts to move its way towards this kind of agile way of working especially with the iteration but before as much as they found ways that could work there's also there's also some actually sort of real points of disagreement I think also that that come up between designers and developers especially the sort of UX designer and the agile developer and Dan's going to talk about that because we we actually have some experience of our own making some mistakes on projects working in an agile way that we thought we could share that so you guys could hopefully learn from them it took us a while to learn from them but we we have hopefully so yeah you know obviously this has been a case in a case study in you know understanding that you know UX designers and engineers are actually working a lot the same ways that we're coming together that the software development world is actually like converging on to agile processes you know anyways none of the less it's probably worthwhile to point out as Todd mentioned earlier there's something missing here right somebody was not really happy with this with this way of working and that was Sean that was sort of the the architect person right there are some people that are that are outside of this and are not totally comfortable working in this world yet right there are engineers who aren't really cool with jiving with with designers quite yet they're struggling with that there's UX designers who are having a hard time sort of dealing with this fast paced iterative process that a lot of engineers are looking for so let's just kind of talk about this let's talk about sort of the ways that some of the baggage that each group is kind of bringing to the table and how that impacts the way that that they're working a lot of times you know you have your UX designers are focusing on different things than maybe an engineer would be they're worried about sort of like current concepts they're worried about things like like what is the business needs behind this design and how this project's going to work they're focused heavily heavily on sort of user-to-life on really you know countryman satisfaction things of that sort a lot of times they couldn't care less about stuff that the engineers are really focused on things like making sure it scales or making sure that it's maintainable over time or on just this this bulldog approach to like getting shipping code out there they're getting something live in front of people right these perspectives of each other you know that are tired accurate but are sort of understanding right you've got your agile guys who's sitting here and saying it needs to be quick and it needs to have you know it can't be like sort of burden with our pretty documentation and we've got our UX designer who's trying to talk about you know oh well we really need to think about a big picture of vision and they keep talking about you know they need to like have this sort of focus and this is hard I mean this is hard for these groups to sometimes talk to each other because they come with all this kind of baggage they come with these different sort of understandings about the best way to get a product in the hands of their other users a way that sometimes there's a difference in between that how the two groups are talking is in the way that they understand users a lot of times designers are really wanting to to go deep into sort of like their understanding they really don't want to sacrifice that quality of speed that they want to just take a step back they always want to take a step back and be able to really understand sort of what are people trying to do with this application how do they need this to work and sometimes that translates well into these discrete sort of user stories elements sometimes you sort of miss some of the big picture when you when you when you take sort of user understanding you chunk it into small little bits it's really really hard to do sort of a proper definition piecemeal it's sprinting through research you know and can sometimes be very very tricky you know you really sort of miss some of the big picture elements if you try in and try and do little pieces of research as you go specifically what we're talking about here is not user testing user testing actually is a tool that can be great for for doing iteratively for getting a friend of people for getting quick feedback you can get a daily weekly whatever we're talking about really more involved user studies ethnography you know really seeing how people you know live and how they will they only use the product you're building in their day to day life really kind of having that bringing some of that that understanding the way that you're going to build your product and define it Hey Dan you and I were talking just before this but I think that the one thing where I put it out is the agile development process it sort of assumes that you have a good understanding of your user and then you can break it into the user stories and you start to design to it and the issue here is actually the question of like what if you don't what do you need to do to make sure that you do have that proper understanding that's a place where you as a designer often time make sure you have that solid understanding before you move into good generations yeah yeah they're not actually going there deriving a lot of guesses based on what other people are really really big difference and you're going to get a lot of data bias that's driving design decisions if you use the user who's actually going to be the person using I think one of the concepts to get you a good user experience I need to get feedback but you make your point I mean essentially this is the case to you it's basically this there's a certain point when you need to you need to make sure your assumptions are right before you jump before you before you go into the process and that's something that but you know I think everybody just think about things before you jump into them but like there's a this is where I want to say let's step back I just wanted to make a comment from that I find it interesting but this is from if if your product means inside a team you need all this definition the team is a group of knowledge workers who have the necessary skills to reach the vision so the US designer should be inside the team so that's the definition of scrum agility so I think what you are referring to is the usual software development teams who are trying to use agility the product owner is represents so he represents the interests of all stakeholders one of them usually the customer the guy paying for it is responsible and you have users and you have all sorts of stakeholders so what are the usual states of software development teams that use agility is only showing things to customers we can just step back I was just going to push down because the next part is where we can talk about what we screwed up I always like I really want to make sure we share the part where we screwed up because it's like you can learn from our crew who is who is who is who is saying this is this something that that who is who is this is this a you are saying this are you saying this this is this is a probably a general assignment from the US design community and I think it's definitely sort of a mindset that we have right that this is a mindset for traditional you have traditional you are designed and I would say that both Todd and I probably feel this way as well that the idea that doing doing this sort of in depth ethnographic really deep understanding of users is hard to do actually that's international that's sort of a notion right and so how does that work right that's just a conflict I'm just putting it out that's a what about what about what about agile it's not hard to do iteratively the cycles have to be really long well well it it took me I did research in four countries took me seven weeks eight weeks did you deliver what all the research insights so we could understand all the users that we designed things so does that work delivering a software product yep and did you revisit any of the research constantly insights constantly what are your artifacts for that kind of thing those archetypes that you saw before were actually a really good example I didn't show you everything for them I didn't go into the details but they're personas we're going to talk about some of the artifacts in a minute but do you believe that until you had to visit a southern country that you did not have sufficient information to even start building anything because what did actually I would say that is true I would say that's true so you could begin to build a single article someone could have started building something and that would they might have had their own value that would have added value to or designed insights clearly there's a conflict that we're talking about here but I would use a chess sign and so I'm pushing back at this this to me completely flies in the base of just fundamental it's a fundamental actual yeah I think our here that the four of us said things is that you might have conducted a research study like maybe 20 years ago 15 years ago 10 years ago from local countries and also software development teams maybe they were using waterfall and they do would have said something like this you have to have like four months of analysis before and three months of design before you code they would have I mean swear by their mothers that that's a way to do it so and I think if you're doing this other design you definitely need to do that after that research before you so like the waterfall project would have done much better if they did so maybe our fear is that okay I usually do scrum trainings and I usually bring people from other professionals and they usually say no no no we can't do it this issue and then when we start talking things about it well maybe so maybe the initial mindset that's what I think there's more that it doesn't have any qualifiers yeah the problem is that this may not be the case for some project maybe this is that one edge case project where maybe you actually have to do seven weeks or whatever of research but you know in my case I've done this for 15 years plus that I've never done that I do a lot of projects where there's no research on the front because that project doesn't need it doesn't warrant it so perfectly this is not every single I mean you can do it you said you went to seven countries this was a giant project it was something that had never been built before and never been done before there was there was very little patterns and other software design we could build on this was a set of users that we had not been studying especially not in a very recent way so this was well in one sense it's an edge case it is something that proves a little bit of a rule which is that if you don't understand your users well enough you need to be able to set the time aside to do it I agree but that might be 5% of the case I think which site you get to this point in three days or a week I only worked on one project where I had to go to four countries and spend eight weeks on it and I've worked on a lot of projects you're saying understand your users in one case it got to seven weeks but how quickly can you typically do this what's that you know what it's a much longer conversation about how you approach research can I we're going off here in the other presentation you know we're building our stuff sufficiently uncoupled and using our edge of processes he can contribute greatly to what we need to do okay he may need to do a process that isn't necessarily agile yeah and we need that information though okay so let him go thanks well no no your point is actually still I don't want to shut it down let's just talk afterwards alright so just though in the interest of getting through all the slides I'll press on and we can continue talking for half an hour we got a flight eventually to catch but we can keep talking about this for a while so yeah let's talk about when you don't do some of this when you don't do a bunch of research and don't have a understanding of your users because we did it so we had a client and we started working with them and we were doing everything right we went in and we were doing we were working with all of the right stakeholders everybody was at the table we were we were coming up with concepts really fast we were iterating on them we were incredibly collaborative we were doing all of our design work very very well we the client was a was a start-up they were incredibly fast-paced they already had a really strong team that could work together and could screw around these ideas so they started instantly working on some of our concepts getting their system set up being able to take the designs that we were doing and being able to turn those into reality they were following some of the best practices they were using all of the modern coding techniques they were making sure that they were focusing on the ability for their site to scale it was ridiculous how much they were working on that nonetheless they were doing all that right I mean they were everything everything on the design everything on the development was right we were really doing doing a good job there we launched it we launched the site and they did an agile launch they got it out quickly they were listening to their users they were taking feedback you know on the blog and they were within days iterating a new launch to the site and iterating a new launch to the site they were squashing bugs they were they were fixing issues they were rolling out new features as they went everything that they were doing was right and still they had failure they were getting we were getting failure right absolutely the response from the users was really really negative they were they were features on the site that were alienating current users there were features on the site that were confusing new users who were being introduced to the system just all this buzz about a great new site launch that was getting picked up by tech crunch and things of that sort we didn't over-emphasize on sort of expert decisions on picking up sort of personal whim and desires of engineers that think things might be cool we essentially didn't do any sort of any sort of upfront research we didn't have a strong understanding of the users we did zero user testing and worse we did twice we did for the website and then we turned around and six weeks later we launched an iPhone app that had the same same problems right so what I'm saying here is we're not perfect you know we fall into these same traps and here's sort of a case study of exactly what happens if you follow you know a lot of these sort of processes to the T and yet you still end up with something that consumers are not adopting because you don't really understand them right the idea here is to make sure that you do understand that you have you've talked to them you've interviewed them you really get what it is that they're looking for out of your out of your service you're looking at your analytics you're doing what it takes to really get to really get your users and build your features around around solving problems that they have with their service or in their lives so with that in mind let's our final couple of slides here are talking about a couple of ideas that Todd and I have for possibly bridging the traditional UX design and agile engineering a couple of activities of artifacts that might work well to be able to solve some of these issues around different you know language issues between the two groups and things of that sort first one's Todd's going to talk a bit about personas yeah so somebody actually asked earlier about artifacts that you can create that can help capture the research I mean a lot of people probably heard of personas right they do them so they get a bad rap so I've seen very badly done ones but if you do a good job on a persona it can actually it can be huge because so with a persona when it's done really well it's an artifact right so it represents a set of characteristics and traits that are found in your user base so essentially you can't always have your users sitting in the office with you all the time for your scrum meetings and that sort of thing so you need something that's like a surrogate and but it's also one of the reasons why we work really hard to make our personas face very very closely on people we actually talk to we try not to give them you know we try not to have a persona named Elvis you know we try not to have a persona named like it's not making them funny and silly and kind of cool do you want something that feels very very real because the empathy is the important thing building that empathy so but personas are great in this bridging this role kind of like Leonardo DiCaprio could be Hamlet or he could be the ratio in a play a persona is sort of captures that kind of multi-fasted nature of all real people so they don't get stereotyped and then what's great is once you have these characters that's when you start to really be able to talk really well about things that are sort of really common to the edge approach which is scenarios where you're piecing these things together most of the user stories I've seen the card versions of them are not they're more like actions they're more like a plot without characters and the key to personas is that they help bring the character back into the plot so that when there's some place where you need to interpret something you can try to interpret it from that person's point of view and I've seen this prove to be hugely effective for developers and folks who are not the interaction designer and it really it meshes really quickly and very easily in with the whole user story kind of ethos of agile development so this is something I've had a lot of good luck with and something that I really like to kind of sort of push as something to explore and I've used it before in other situations and you can start to talk about where it's really good you have to develop them early when you're in the vision and they have to help you craft the vision but then they just keep topping up in really important places and you have to have a good set of personas you know who you need to recruit for any given user session right if we're working on the stuff that Donna uses all the time we're going to try to recruit a couple people that are like Donna you know or Rachel or whatever that that particular persona or person is so yeah this is a huge I found this this is one of the powerful things when it's done right we're helping to bridge that gap another tool that we find a lot of value in prototypes prototype definition from Wikipedia there's sort of two different pieces here that are that can build a prototype for this sort of definition one is engineers and one is designers I like to focus on the ones where designers are building some over prototype if it's a prototype that maybe is engineering focused maybe that might be like more proof of concept something where you're trying to prove how things will work if we talk about something like a design prototype then we're going to the way that something works and the way it feels and it's going to be something that we want to we want to use to inform sort of the the way that an application functions for a user and something that they can actually they can actually test often when I think when I talk to people about the best ways to choose what you're going to prototype something like this helps to to describe that you often have features and functionality of your application that are critical you often have ones that are really really complex tackle those tackle the ones that are sort of out in that world there of being very very different than maybe something that they're used to or something that is that is super important to your application right if you're Twitter probably being able to to get it right the way that you can craft 140 characters is like the most important thing that your site can possibly do don't project the login screen just do your login screen the way everybody else does the login screen and assume it's going to be right complex stuff figure out what's a five step process that someone's going to have to go through maybe doing their taxes or something like that focus on prototyping the parts that are really really tough so that you can put that in front of your users get their feedback and then iterate on what you need to do to make sure there's a lot of samples here talk about this one sure so this is a prototype that's actually a little IDO actually uses this as a prototype it's for an endoscopic surgical tool you know what that is like during surgery inside somebody they had the technology they understood how that was supposed to work but the thing they didn't know so you prototype the thing you don't know you don't product the thing that you do they knew stuff about materials they knew things a lot of stuff but they were like what the heck is like a wand or a stick is it like a gun is it like how do they hold it how is it supposed to feel and so when they were trying to figure it out they just they grabbed what was around like this is a white word marker I don't kind of turn a little clip and they put it together and they were just walking with it and they were like does this feel right I think they actually might have had a physician around that day for an interview and they said do you hold this in your hand and tell us a little bit about is that feel like what it's supposed to feel like and once they figured it out they could start working on all the details of it and I think this is actually a really great example kind of how you think about what to prototype and how to do it and this is like I don't know that they needed a mechanical engineer or an industrial designer to do that they could do it very quickly without a whole lot of effectible skills I'm going to show you because I was just like shut what you see here is a box of Scotch tape Scotch tape box and a tube we worked on a product for a diabetes management system and the designers were trying to figure out how to understand what it's like for someone to walk around with an insulin pump attached to them all the time and so they prototyped it and what they did is they got that box and filled it with rocks and batteries so it would be the right weight and then they attached one of the things that people who actually have insulin pumps attached them are and they attached them to a wire and they stuck it in their pocket the same way that everybody does when they have an insulin pump or they put it on their belt and they walk around with it at the opposite of home it was like what do I not know I don't know what it feels like to walk around with a device like this attached to my body and so they walked around with it for a long time and what that helped them do is they helped them know something that you really needed to know in order to design the experience for the new device they were doing also a super simple thing to do but you can see where the insight came from from that prototyping and you can see why it doesn't matter if you're a designer or a developer or an industrial designer or whoever that can help everybody get on the same page about what you need to be doing with your design process do you want to go to the airport? okay the last one is actually more software based this is a quick it's like a comic we wrote have you guys ever heard of Lulu? Lulu is a print on demand book service basically and we never worked with them but we like the concept so we use them as an example when we play around with the ideas this was the sort of idea of like Lulu was going to create some kind of concept about doing something to help encourage their authors to write more books how would that what would that service possibly be like? so rather than trying to code up email or code up the web pages or anything like that we all did a sat around and talked about what it would be like and created a little story board and we walked through how it would be what the experience would be like she took about 10 minutes because we have to have somebody who's a relatively good sketcher although even with my horrible sketching skills I could have put this together in about 15 wouldn't have looked nearly fine but the text would have probably been fine an artifact like this is actually far more functional than you might think I mean you can show this to a C level executive at your company and have them sort of understand the experience that you're designing and sort of where you can take their money you know or you can show it to a user and have them quickly understand how this might fit into life something people really understand sort of like frame based comic metaphors and they can quickly understand like oh I get how I'm going to be involved in this and the fact that this has a perspective like the only one of these blocks actually has a screen design on it the last one has a bit of a button the other one is actually show the person like at the computer with bubbles running kind of like giving an idea about oh this is what it's going to be like when I'm dealing with this piece of software right it speaks more than a thousand words it speaks 10,000 words because it really actually has a narrative and a story behind it programmers love comics too this is often our first round of user testing in other words this kind of thing is often our first round of user testing if that's helpful at all which you can do this with designers and developers and it brings folks together in the process relatively quickly and seamlessly and you can do this prototyping stuff almost everywhere we do a lot of it in the beginning but you can do a lot of it during development and like I said it rolls into testing really quickly and it gets people on the same page that's the last thing we actually had on there that's it but we would love to talk to you now is the official question time there better be at least one if you want to yell at us we're happy to be yelled at whenever you want to what's been your experience with the paper code? it's been really useful it's great it's super cheap it's really really fast when you compute crying out 10 iterations in a day people respond to it really really well yeah it's been great we've done it both in person sitting down with somebody and actually giving them physical pieces of paper and maybe five different screens and five pieces of paper it actually works pretty well remotely so setting up something like a WebEx or Adobe Connect and having people open up a PDF of a bunch of drawings and that kind of thing and having them kind of talk to you about what that means again, period prototyping I think works best when it's not just screen designs but it's sort of a story it's a narrative about the sort of tasks you're going to want to do okay how have you prepared the user or the processor for that experience are you sort of not expecting too much if you will we say we'd like to show you some concepts that we've been working on they're just sketches really you know and they literally are sketches you say that to them and most people are like I know what a comic is I don't think I've had a person yet say sort of like oh well this isn't done or anything like that I think people kind of get it they understand sort of their role there absolutely yeah kind of reconcile with the guy kind of yield that sorry the actual process you know you give us ordinary information yeah we go to work okay actual is all about change we move for it okay so you come up oh that don't work okay you make a change okay so we go to work they put in their job it works I think it's also it's about change but it's also about reducing ambiguity I mean these are great ways great methods great tools for reducing ambiguity quickly early on in the project right and as many as much as you can do that then your iterations zero and one or just one and two and three however you do it with much more accuracy not big design of front accuracy you reduce you reduce the solution space to an appropriate accurate range as opposed to frankly wasting a lot of money we have two in the back there yeah it's actually I wanted to ask a little bit on ambiguity you know as user experience designers we deal with ambiguity every day and so my question to you is kind of bridging up the conversation we had earlier dealing with ambiguity and dealing with that within a sprint user experience for you does that live within the sprint or does that live outside the sprint and why does that question make sense do you want me to try to do it it's hard to think so I'll say that we kind of come from the consulting world right so we're always sort of coming from the space of being outside right we're never in we're never inside you know in the team we're not sitting with the team that sort of thing so sort of with that perspective in our engagements it seems to work best that it works out that way that it works either sort of asynchronously you know we're like a sprint ahead maybe you know doing some design work doing some sort of level setting that feeds into follow on sprints in general that seems to be and again I put that caveat that sort of like the perspective we're coming from in-house team I would say that you could probably do it where it's actually within the sprint itself but yeah we don't have a lot of experience in that way one thing I can say that speaks to that is that our experience being able to see inside lots of organizations that's one of the great things about being able to see the way a lot of people work and my experience has been that user experience works best when as many people in the process are involved as early on as possible so like the developers go out and do field research with you kind of thing often the whole project is actually better in the end because everybody knows there's like communication overhead disappears which rapidly increases everything and then everybody can actually be involved in the conversations at an equal footing so there's actually a big potential for having it be in in the sense that like I could imagine I'm trying to feel I feel like I've actually seen this but I can't think where I've seen it before where like your earliest sprints are actually involving roughly the same team even with the developers but and I know this may sound like sacrilege but you you do a sprint or two without code but you still make things you know what I mean like you're still making the sketches you're still making the stuff and then you transition to coding something as soon as it makes sense but the idea is it's the same team iterating through the ideas towards something that is getting more fidelity and more tangible and more towards the code as soon as you can but it's not a handoff because everybody's involved I've seen that I can't for like well I have an example and actually this this maybe can turn we turn back into a question to the guy in the the corner over there who was asking 20 minutes ago about oh well you know if we're off interrupting our research can we do any code right I worked on a couple of projects I worked on one that three weeks ago we had front-end developers and the designers sitting in the same room spending two days and the artifacts were whiteboards and sketches right there's not a line of code written there was no intention to so I feel like that worked incredibly well it got it got some really good understanding it's making this work really fast the the front-end developers have a lot of buy-off on what what they're going to be ultimately building because they help to come up with the concepts so my question back to you is then is that okay so just to so I work at a lot of developing all of the first a lot of bodies are traveling all over the world and so I always say I should work on a project where we worked in we were in several we worked in four countries but we were in two countries and there was a lot of travel and different organizations and so on that project I was pairing with a developer so the developer was with me on that operation and the developer was the one who could tell me now is the time when we can start to add value by building and so the point that I'm making there is that from your perspective even though look there are a few more highly skilled UI designers US designers in the world than people have that path I mean there's more than you guys do we just grew up a lot but but the thing that is lost there is an understanding of when is the right time to start to build and when can we when are we not adding more value by just sketching to do all the things you're talking about and it's a great idea myself and we're going to add more value by not actually combing it that was the point that I was trying to make so to me that is all this stuff is spreading out there 90% of all this is good 10% is you need to have a developer be part actively participating in the desk process to say you know what we need to do a code exploration here I agree the question of when should we start coding is exactly the right question to be asking there I admit the only thing we want to say is don't assume that today is the day don't assume that's the day but everybody that's as soon as you can get to the code as soon as it makes sense it is the right time you know because there's no reason to just keep doing things with paper when it's not really getting there I think we have to do agree it just seems like you have to find the problem before you can solve it and usually you've got to you already know what roughly the problem is you've got well there's a myth for this product let's figure out to your sprint zero narrow that down enough to probably start it sounds like that research project given to you what the problem was not as well it was actually what it was it was just a really really big problem it wasn't a small thing they were trying to develop and design it was a really big thing and so the problem was really big and it was so they wanted to make sure that but it was an unusual project like I said I don't do those every every project is not like that but in fact for a second to make sure although honestly for that project if I had a design technologist I didn't have one on that project it didn't sound but I might have I would have loved to started coding stuff sooner than it did I would have loved to but I would have probably waved off those abeaks and then I would have started because the project was actually months months months months months months months months months months months months months months months months months months months months months months months months months months months months months months months months months months months months months months months Thank you very much.


Hello everyone. I hope you're having a good time with DevCon so far. I'm Ucie and I'm the second session chair for this room. I would like to introduce you to the next talk, which is What is the New in Modularity by Martin Curey. Please enjoy this talk and welcome Martin. Welcome and hello to my talk, What is New in Modularity. I'm Martin and I will be talking about what's happened in modularity space in the last year. So before we start, I want to introduce the team, which is basically working on modularity in Red Hat. It's me who is the software developer and product owner of modularity. Then we have Peter Pisci who joined our team last year in April. Before that he was the maintainer of Pearl and he had a lot of experience with modules before that. And now he's the maintainer of Live Modularity. Next is Philip. Philip is a software engineer in modularity. He works mostly on infrastructure related things. Before modularity he worked in Factory 2.0, which is a Red Hat team which created microservices in the infrastructure for building modules, containers and so on. With this I want to also thank not only I want to thank all the people who are involved in modularity and who enabled us to do the things that we did. We are very grateful for that. So let's get into it. Just like a disclaimer, this will be not very newbie friendly. Basically I assume that you know what the module is and how modularity works and so on. So let's get into it. In the last year we created a new version of the module and the package format. And this was due that we needed to fix an issue, basically a design issue in modularity, which was the broken upgrade path problem. I can make a small intro into this to segue to the next slide where I can tell you or explain what this means. So basically this is a simple example. Of course the upgrade path problem has many variations and it can be not only this but also more complicated. But just to illustrate the point I make the most simple example I could. So basically here, as you can see, we have three columns. The first two columns represent the whole table, represents a module. Each column represents a stream. Each field in the tables, as you can see, we have Perl 524, 001, 06888. And this represents basically an upgrade path. If you go up from the bottom to the up, you can see the versions are 001, 002, 003. This represents an upgrade path. The first stream, which is the 524, is okay. It works. There is no problem. Because nothing has basically changed only the version and the version defines the latest upgrade, which should be used when DNF makes its transactions. So this is fine. In the next column we have Perl 526, the stream 526, which basically is okay until the version 002, but in the version 003, in the third column, you can see the context changed. In the old way how modularity works is that every time you change your modular dependencies, your context is generated by MBS, which builds modules. This is a problem. Because actually if you change the context, DNF, when doing its transactions, has a real hard time to identify which is the next upgrade for your stream. So as you can see, 526, 001 is fine. 526, 002 is also fine. But when DNF wants to identify the next upgrade, for DNF, the 003 version is a different stream with different context. So it cannot put those two together. So you basically, DNF couldn't identify which to upgrade next and upgrade your stream wrongly or it didn't update at all because it could put together those two contexts. So basically what we did. One thing why the context is generated is due to something which is called module stream expansion. Module stream expansion basically is an automatic way how it will create modular dependency combinations for you. You don't have to spell which modular dependencies you need. In your stream, you just leave it empty and the modular dependency stream expansion, modular stream expansion will do it for you. And that's why every time those dependencies changed, also the context changed and the context was dynamic. The context changed at a real time, so the package didn't have any control over it. So what we did basically, we replaced the whole context generation with a static context. A static context basically is a configuration for that specific context. The context is defined by the package before it goes to the MBS to build the module stream. So basically you have to specify the name of the context, which is an arbitrary string. It has some restrictions, but about those you can read in the specifications of this format. So yeah, it's an arbitrary string which is defined by the package. This string should be the same for the lifetime of this context, or the module stream context. Because if you change it for the DNF, it will again be the same thing as with the old way how we do things and there will be a broken update. So another broken update, you will think of it as a new combination of module stream context. So yeah, context is now set by the package. Yes, so why we did a new version of module empty package? It was because the changes are not backward compatible, so we needed to bump up the version. Also what proliferates with this change is that now you have different metadata for input and different metadata for output. Because the module empty package, I will explain, the module empty package version free is basically affects only the input file. In the input file, you specify the configurations you need for each context so that your modules can be built. And the output which comes in the repository, in the RBM repository, in the repo data, there are still version two module empty metadata. Before this, basically you could put module empty v2 at input and then get module empty v2 at output. Now you put module empty v3 and you get v2. So yeah, v2 basically didn't change a lot. The only addition is that module v2 now has a field which is called static context and it just set the true. So DNF can identify that this is actually, the context is not generated and it's static context. Yeah, so let me check if I didn't forget anything. Yeah, so this wasn't really easy to do as modularity is really implemented in a lot of systems in a pipeline. So it took a long time to actually implement into the pipeline. So it took nine years, nine months. I mean, the most problem was that we didn't have a lot of people to do it. And additionally, we need to check if everything works as expected because this was like a big change. Yeah, so let's continue. Yes, this is the upgrade path, for example. Yeah, so additional thing what we added to modularity, one of the features which was missing at the start was removing page packages from modules, basically, or we call it demodularization. But just don't be confused, demodularization, we don't mean like removing like modules, but just removing the modular RPMs from a module. So basically, yeah, so demodularization of packages. Right now we have like a demodularization section in the metadata where you can basically put the RPMs that you don't want to be provided by your module, but you want to use the non-modular counterparts. Yeah, so this issue was, yeah. So I think there is not much to say. This is already released in Fedora and also in Rao. Yeah, but this Fedora, it is released now, but in Rao it's only for Rao 9, which is still not released, so yeah. Okay, yes, so modular absolutes. This feature was a long time in Limbo or in development that we can sell. You can say basically the implementation of support for absolutes and end-of-life metadata in Fedora or not in Fedora, but in the tools which are using it, which are DNF or KREPOC and others, was implemented, I would say, quite a long time ago. But again, the problem was to implement it into the pipeline itself. So this is, we have, all of the implementation of this feature is the work on it, the development work is done. All right, now we are actually, it was done like two weeks ago, the last page that we needed. And now we are basically testing it. So we also have a real-life data for absolutes and VR testing. So basically what absolutes are, if someone doesn't know, this feature was missing for modularity also. And this is basically that you could tell if you will add metadata into the distribution or the repository, RPM repository, which will tell which module streams can absolute which ones or when an absolute is end-of-life. So this is basically like this. In the end, how we did the user, not user interface, but how you can add your absolute metadata to Fedora or to other distribution is similar as default streams. You will just add metadata to a git repository. The link is in the presentation. And you then, it will be taken into the repo data basically during compose time. And then, yeah. So, yeah, this is this. Yeah, the specifications are here. There are bundled together a little module empty so you can check them after this. Yeah, so the last thing, which was also a highly requested feature which modularity lacked is basically building modules locally. I know that we have, how to say, we have a way to build modules locally, but it's through MBS and this means that you basically need to know how MBS works and MBS is a service. It's not a very easy system to understand if you don't know all the concepts of modularity basically. And also, MBS builds modules in a way that it builds them in the pipeline which basically has some quirks and hacks which I would say are not really the best thing you can have. So, yeah, basically we wrote a tool which is called module build. This tool is quite fresh. It was like the first, like a proof of concept version was created in last year in November. So, yeah, this is still new. The benefits of this tool right now are that it has minimum dependencies for installation because when you install MBS you had dependencies on Flask and other things that you basically didn't need for building modules. So, basically, the only dependencies that this has is a lib module and the mock and then a create repo c. And there are like two small libraries of Python which enable the py objects, pyga objects. Yeah, this is the one other benefit of the local building tool is that it doesn't need the quirks or the hacks that basically MBS needs. And those are module build macros which basically exists because Koji doesn't know how to work with modular repositories. So, module build macros basically has all the information to filter out all the not-necessary RPMs from your build route. This is not needed in the module build tool.  Closer to traditional way of building RPMs. Yes, this is one thing is that basically right now you need MBS to have the information about which package should be built first which arranges the packages in some built batches which then are forwarded to Koji as a normal builds because Koji doesn't really understand how modules work internally and how they should be built. So this tool basically what it does it can do arrangement into build batches and then when you have all the build batches arranged when it's building it then used one build batch as a modular dependency to another batch. Hello, just remind you that you have two minutes. Okay then, so I will speed this up. So, please, this is a new tool. It needs a lot of testing, a lot of love so I'm still working on this. I have the package already for Fedora. I have it in Fedora review so I hope I will be able to release it in Fedora for installation in the next two weeks. And yes, and I think this is all... Yes, and then the module build tool only works with the new module and the package already free metadata. Yeah, and I think that's all. So that was quick. Quick ending. Thank you. Thank you for your talk. It was really interesting. Please, if you have any questions please head to the Q&A tab and ask there. Martin will also be presented in our virtual event. Yes. It's called Work Adventure. After this meeting I will be staying outside of this room because there are virtual rooms like Room 4 so I will be staying outside of it and I will be just gone and we can have chat. The link is already in the chat. Please go ahead and look at it. It's wonderful. I've just been there. It's like, you know, if you have been in offline DevCon it's like the old venue. It's looking so cool. Just go ahead and talk to your favorite people. And we have already one question for you. From Zbigniew, do you have any modules in Sedora? Yes. Basically, no. If someone is interested in this technology and wants to try it, you can but there is no main data that you have to or whatever. Okay. Thank you for the answer. If you want to talk more, just go to the virtual venue and there is another question. Okay. From Jens. Previously, it was quite straining to maintain large packages under modularity. Will that became easier? For example, the building system was not very predictable and sometimes modules were fragile. Yes. Basically, I can speak a little bit about the plans for the future.  The problems are that the pipeline, the build pipeline is basically not up to the standard as it should be, because as I mentioned that basically Koji doesn't know about modules, it's just like a little hack that you put the builds there. So what we are trying to do next this year is to make Koji aware of modular repositories and also so we can directly build modules in Koji. But this is still in planning phase. This is not something that we already have. I hope this will make the package and user experience better. That sounds cool. Hopefully everything will go well and we don't have any other questions. So thank you very much Martin for your talk and please look at the work adventure and meet with Martin there if you have any other questions. I will see you in the next session and have a nice day. You too. Bye.


An investigation is underway in Mingo County after the discovery of a body near a cemetery in Mayer, West Virginia. Police say that the deceased was shot here on site and his body dumped in the woods nearby. Right now we are investigating what we believe to be a homicide and we received a call from Martin County Sheriff's Department this morning that they had gotten a call from Canall County of a missing person and the phone was being off this area. After Martin County had checked in on it, I actually found out it was in Mingo County. With Martin County and some of our deputies, we came to this area and searched and that's where we found a body. And right now we are treating it as a homicide and with the state police, their help, they brought their crime scene team down here to help us investigate. According to sources with the Mingo County Prosecuting Attorney's Office, the body that was discovered was that of Ben Hatfield, former CEO of Patriot Coal and CEO of International Coal Group. Most recently, Hatfield had been the Director of Foresight Energy. The investigation is ongoing and the Mingo County Sheriff's Office is asking for any assistance. This is a, being close to more of a weekend, there's a lot of people here we believe on Sunday in and out between 11 a.m. and 2 p.m., if somebody saw something with just a vehicle sitting here or somebody at the cemetery, you know, we'd like to know. According to sheriff's officials, the body of the deceased has been transported to Charleston for autopsy. Reporting from Mingo County, for EKB News, I'm Jackson Ladder.