 Welcome to Agile Roots 2010, sponsored by Version 1, Rally Software, Virio, Amirisys, Agile Alliance, and XMission Internet. Agile UX for Developers or Y Fluff is Stuff by Anders Ramsey. First of all, so my name is Anders Ramsey. This global IT consultancy has been doing Agile for a long time. And I've been doing Agile for not as long as ThoughtWorks has been doing Agile, but for a few years. And before that, worked more in the traditional domain, traditional approaches that many of us did. I've worked as a front-end developer, but primarily as a user experience designer. So, but I've been in sort of more many different hats. And over those years, particularly when coming to ThoughtWorks, you know, what I've discovered as a user experience designer is that there's been sort of this, and I'm not the only one. I think many have seen sort of this divide between this thing we call UX and this thing we call development. And it's this ongoing push and pull. And there's very much a desire at ThoughtWorks and many other places to find that integration between those points. And what I've also seen going at many, many different conferences, seeing different speakers and so forth is, of course, there's a tendency that the conversation seems to be how can we communicate to user experience designers what Agile is all about. And so they can understand that and apply that and bring that into their practice. So, there's been sort of this little bit of a one-way sweep there. As far as a tendency toward, is it kind of communicating to a user experience designer, how can you change the way that you are working, which is, you know, assumed to be sort of a traditional waterfall approach, how can you change that and integrate that into more of an Agile approach? And what's kind of been missing there is that there's really more to it. I mean, in some ways that's almost like an Agile anti-pattern, because, you know, an Agile approach is not about having this one person, you know, trying to figure out how to rebuild, trying to integrate it into the team, and then the rest of the team isn't understanding what this other person is doing, this other role is doing. So, something that has really come to a head for me, particularly in working at ThoughtWorks, is the need to look at this from another perspective, to basically say, what can one do to explain or try to communicate to, you know, developers, and not just developers, but also, and I realize after I write the title, I realize, you know, it's really broad of that, it's really anybody who is in the team who maybe does not really play a user experience, design a role, how can one help them understand what that means and why it's valuable, why it's useful. So, one thing I've just kind of cured before we kind of keep going, I'm curious to see how many people here would you would think of yourself as a developer, or would you put yourself under that category? And how many people did not raise their hand? And just to get a sense of what would you call yourselves, or what would you have your, just to get some, like, so what were you? U.S. designer. U.S. designer, okay? Same. Same? Yes. Okay, great. So, obviously the primary focus here is for me to, this is not really, the purpose of this, first of all, is not to be, I don't want to stand up here and talk for 90 minutes. I want to probably hopefully make you stand up here and talk maybe 10 minutes to, then we want, the purpose of this is for it to be a workshop where you can kind of get a sense of what it means, what a user experience does, and to enable you to then have a better understanding of how that integrates with your work. So, just as a kind of a quick overview, so that's what the intro, I want to kind of present, it's interesting because I wanted to look at, a lot of things that Jeff actually touched on in his talk, but from a somewhat different perspective. So, he was looking at it more of this process issue, and he had like this slide where he had, you know, when you have like, it was like this CD was like the output, and then he had like this smiley face, and it was like the outcome. And what he didn't say, but was very clear in my mind, is what we're talking about there is the output being kind of the delivery of the software versus the outcome is the experience of the software. And the ability to understand those relationships, something you want to talk a little about, and then obviously the primary focus of this is going to be the workshop. So, just to quickly, the workshop what I want to do is have three different types of activities that I think will sort of encapsulate and give you a sense of what a user experience designer does and how it is very different from what you do, and yet how it is valuable and has an impact on what you do. And then I'm hoping that we have some time, sorry, I'm hoping we have some time to do kind of an official discussion or do some similar format, because to me, definitely one of the most important things here is for you to be able to reflect on that and share, did I learn something new? Did I not? This was, no, this was just what I expected, or no, this was totally different. So, that's very important. So, in terms of introducing this a little bit, you guys probably can't see this, but you may recognize this book. So, this is Craig Lambert's book, Agile Interative Development, Now I'm Just Died. And for me, one of the first books that I read in Agile was very much a sort of in a ha moment in terms of the way that he, I mean the book's been around for a while, but the way that he really gets to the essence of one, what the problem is with the waterfall approach and summarizes very simply these very different models of Agile. And so on the one hand, this book has been a very powerful book from that vantage point, but at the same time, it's also representative of what I see as sort of the impetus or the seed for wanting to do a workshop like this, because it conveys a way of thinking about software development that is what I want to try to tackle with the workshop today. So in this book, Craig talks about the need to tackle really complex and challenging issues early in the development process, which is sort of a basic practice of Agile. And one doing sort of talks here, this quote, he says, maybe the client says, I want the web pages to be green and the system to handle $5,000 in things, transactions. Green can wait. So now I remember reading that way and way back and that didn't really kind of jump out at me. It says, oh yeah, I'm kind of nodding my head and say, that makes sense. I would agree with that. But now having worked, particularly having worked at ThoughtWorks, where it's a very intensive Agile approach, I'm working side by side with developers in a very clear sense of kind of their vantage point toward what we call the software product and things that actually Jeff mentioned, this idea of the focus is on burn downs and on velocity and on delivering in these things. And to me, what the problem with this statement is that it is measuring software by very much a developer-centric yardstick. And so basically saying that something like this, this clearly is a technological challenge. It has a clear technological, you can measure it and say, that's going to be really hard to achieve. This, from the perspective of developer, that may take, that's one line of CSS. That's two seconds, right? So clearly that's very simple. And the point that what I want to convey with the activities that we'll be doing a little bit is to show that actually Green cannot wait. And I don't mean to pick on Craig. This is not about him. This is about a general attitude in software-developed community in general and an agile community more specifically because that's the one that I worked on and that's the one that I think we're all sort of immersive. And the reason Green can't wait is because this somewhat relies the true complexity of what is sort of implicit here in that kind of the surface layer design is this kind of simpler thing that, you know, it's sort of the soft skill. That, you know, we have these hard skills. People, you know, are trained engineers or doing software development. That's something that's really complicated. And by the way, could you just go and work on the UI? Could somebody, who can work on the UI design? Could somebody just kind of discuss something that we need some UI? And that's sort of this thing. But let's just get that done. And, you know, I get, yeah, because I need to get back into serious work. So I don't have time for that. So what's implicit there is this. And the problem there is that is looking at the whole software problem at this one, from one single dimension being the development dimension. And the way that I think is a much more powerful and accurate way of looking at a software product is as you think of a restaurant. So in a restaurant, we have a kind of, in a restaurant world, we talk about, you guys probably don't really see this, but the front of the house being the dining area, can you see, can you guys see this? And the back of the house, which is the kitchen, right? And when you go to a restaurant, so how many people here were at the squatters restaurant last night? So when you went there, I mean, what did you think of the experience of that restaurant? What was your, kind of, did you like it? Did something bother you? Was it bad, good? I loved it. Okay. So good. But... And you go in and it seems it was pretty laid back with a comfortable place on it that you would want to be. Okay. So community over software. What's that? Community over software. So I think what you're touching on there is something very interesting, is that the design of this front room, the front of the house, was such that, you didn't really think about it, you were able to actually focus on things that really mattered. But something that you, none of us, because I was there last night either, and what you don't, you never really see when you go to a restaurant is the kitchen. The kitchen is the engine of the restaurant. There is no kitchen, there is no restaurant, right? But at the same time, nobody actually sees it. The things that we see are these highly soft, fuzzy, qualitative things, the ambience, the lighting, was the waitress, the rapport I had with the waiter or the waitress, and so forth. So the reason, so why am I talking about this? So the reason I'm talking about this is that Agile focuses on this problem. So Agile focuses on delivering, you know, in a kitchen, if you think about a kitchen, what do they focus on? They focus on consistency, delivery, quality, basically of delivering the product right up to here. Right. And then somebody picks it up, and then they present it. It's the presentation. It's the experience of little details. And so I actually, when I was actually at an event a few months ago, and I talked about presented this analogy, and some word coming on was there, and I said, you know, so basically Agile's focusing on fixing, making a great kitchen, and he kind of nodded his head. He's like, yup, Agile is hot food served quickly. And I think he said it a little bit tongue in cheek, but there's a certain amount of truth to that. And I think what's interesting is, with Jeff Patton's talk, what I think he was not really, what was implicit there, but I don't think it really came across is this dimension issue, that yes, process is one problem, but the other problem is that sort of the things that we're focusing on, estimates, velocity, burn down, it kind of sort of stops here. And now what I want to do is kind of introduce you a little bit to this world, because the reality is, in difference from a restaurant, in soccer, there actually isn't this line. It's just, it's a continuum. It's not like you have this clean little handoff, and suddenly, you know, softer ends and user experience begins, or whatever. It's a continuum, and that's why it's important for the people who are focused on solving these problems to have an understanding, and not necessarily become user experience designers. These are clearly, this is clearly a different type of thinking that's going into this side. Clearly a different type of thinking that's going in here that's more utility-oriented. This is much more about, you know, all the kind of fuzzy, fluffy stuff, right? But it's still really important. So, first of all, I just want to say, does that resonate as far as that analogy, or does somebody, yes, no? Yeah, that does, in fact, a number of restaurants that I really enjoy are going to have the kitchen open, so it has that relation. It's very clear where the back of the house is and where the front of the house is, but there is this, it does fuzz over, it does, there's this spot where it is both, it isn't either, that spot there, in fact, is where people like to gather, just like in individual homes, for exactly the same reason. Great, yes? I was just going to say, I think this analogy really holds up well because the kitchen, chefs do, a good chef will pay a lot of attention to presentation of the actual dish, and so in that way, even though you don't see him, you don't see any, you know, you don't see the kitchen, you definitely do see what he's created, and in that way he does reach out into the front end. Absolutely. You know, so it's not, I mean, if he just slops it on the plate, that wouldn't be a great experience for the user, right? So it takes some thinking on his part to say, you know, I'm going to send something out that's going to be a good experience. But also the, I guess how I see it is, I can do everything great on the back end as a developer, I can do everything great, but if I don't have the user experience part sucked, nobody's going to be experiencing what I'm doing as a developer. You do have an amazing kitchen, Rick, if you walk into a restaurant and kind of the music is a little weird or something, it's just that if something is off, then, and I've actually, I recently had an experience like that, where it was that the food was impeccable and I had a strange experience with some bad service and I'll never go back there. Yes? One thing that is interesting about this analogy though is that the chef or the professional, you know, the artisan so to speak, he's in charge of the back end. He makes a grunt, he does what he wants it, it all works the way he wants the front end, is all managed by the business people. And so they bring in some interior designer and design it and they, you know, they hire the way staff and they hire the major team and hire all of these people and they run it and the only thing that they really have to do with the back end is telling the chef whether or not their food's good. So that's really interesting. And I don't want to spend too much time on this because I want us to get started with the workshop but it does remind something that I wasn't sure if I was going to raise but when I was talking to Desiree about it, I can't remember the name of this guy. So there's a gentleman by the name of Danny Meyer and he's a top restaurateur in New York City and he has opened, he's done something that very few restaurateurs ever are able to accomplish. He has opened, I think, six or seven restaurants and none of them have ever closed. In most cases, you open a restaurant, they close and things don't work out and so forth and he has something that he calls the hospitality principle. So the hospitality principle is basically the idea that everybody in the restaurant doesn't matter what you do, if you're doing dishes, if you're a bus boy, it doesn't matter, you all understand kind of what, so his focus is on the front of the house but in terms of understanding what everybody else does and having the sense that what everybody does actually has an impact and you can't just sort of dysfunction in isolation. So I would say, in my opinion, that to me, if somebody worked to approach the design of a restaurant like that, I don't think that would be a recipe for success. And now, I'm sure there are a lot of restaurants that do approach like that and that's maybe the reason why they closed because there is that separation. So any other thoughts on that or yes? Just from the UX side of the conversation, it seems to me that your servers are going back into the kitchen. They are helping to move things forward. They're helping to give the client or the patron part of that experience and if the process from getting order sent back, getting the food brought forward doesn't work well, then you're left with that empty experience. It doesn't matter what the quality is in the back of the kitchen. So it does take someone that's in the front of the house to be able to move into the back of the house to facilitate that transaction, to create a dialogue between those two worlds so that your end user ultimately does enjoy the experience and wants to come back. So it isn't just that one way. Absolutely. There's a back and forth. There's a continuum. If you think about it, when I'm sitting here, I'm placing a menu ordering from the menu and that goes in. There's maybe some back and forth. There's this whole idea that you don't want whatever happens. You don't want to disconnect between this and this. For example, if somebody wants some little change that's made to their menu, you don't want the waiter to be the person who's saying, sorry, we can't make that change. When the reality is maybe the people in the kitchen have no problem, I can make that change. So there's that continuity. Yes? I agree with whoever said this over here that the metaphor really holds up quite nicely. I don't know if you're aware, but what happened in the evolution of the restaurant business could also be applied to what we're going through in the building of software. Back in New York in, I think, the late 20s, there was just this incredible frustration between the kitchen staff and the serving staff and they were just angry at each other and fighting and it was just meanness that was going on. This individual invented this little turnstile that the waiters would click their tickets on and hence was invented this method to eliminate communication between the kitchen staff and the serving staff. They would drag out the order, they would click it up on the thing, they would turn it around and the kitchen staff would pull it off, make the order and then put it back up on the dining table and then they would take it out to the kitchen staff. It's interesting that that evolution, really, if you think about great restaurants, they don't do it that way. The individual over here who made the comment is exactly how the great restaurants work. The serving staff will actually go way back into the kitchen. There's an interconnection. They have relationships with the kitchen staff and they will do things to socialize and know each other that, like you said, the focus is on creating great hospitality for the red gas. I think that's where we're at in an industry that we're realizing that the interconnection between these various roles that build software matters. Absolutely. So that's one of the goals here is to kind of provide somebody who's currently quite developed this product that just has a better understanding what the U.S. designer does not with the intention necessarily of becoming a U.S. designer, but being part of that. You know, it's like Jeff Patton was talking about having shared design and shared sketching. One thing that I think is very important for me to mention here, though, and which actually came up in my conversation earlier with Desiree, is that that is also a two-way street. Use experienced designers to also need to understand what developers do. This is not... Now, that is a topic for another... That's something to talk for me to give or a developer to give at an interaction design conference or something, but I just want to point it out. This is not just about sort of this one-way street. So, kind of to get started with the workshop. What's that? Oh, Caleb's our designer. We're going back and forth. Oh, it's okay, that's okay. So this is a workshop that's based on an actual project that I worked on and that really sort of stuck out in my mind as being very appropriate for this type of an exercise. And there are several reasons for that. So let's kind of look at what this is. It's this children's charity project that ThoughtWorks does a lot of pro bono work and so this was a pro bono project that they did for this children's charity that was doing really good work sort of out in the field, but it was just this tragedy. And it was very sad. So they didn't even realize that it was awful because they were doing such good work out in the field that people were donating, even though it was literally like, please donate and click here and then they had to go through this horrific process of actually being able to make the donation and all these things. So we met with them and if you were to think of what would be kind of the project level card that would come out of that first meeting we had would basically make it better. And so obviously we needed a little more information about that. And it's a start, it's a start. So but the long short of it was that they understood what the end result was of what they wanted in terms of we need more donations we need people to have these overarching goals. But in terms of the actual features that they wanted I don't know, whatever features would lead to those goals. So one of the problems with an agile method and something I think Jeff implicitly implied actually in the talk earlier was this idea that sort of an agile one of the goals of agile was to get developers talking to customers which is hugely important hugely valuable. But there's this implicit idea there is that the customer will be able to tell you what they want tell me where you want and I will build it for you. Right? So that actually I have to say in their defense this was coming from a more enterprise vantage point and in the enterprise realm you can get a little more of that because they're much more task oriented and it is more like when you're more in the consumer realm or getting to something more consumer facing public facing that tends to get harder and harder. So the goal here is to I want to kind of embody some of those things. So what we ended up with are these cards and I don't want to call them stories because they certainly wouldn't satisfy if we were to use kind of the smart qualifications or whatever of a story but this is what we kind of ended up with in terms of our high level let's call them kind of pseudo ethics that came out of these meetings right? So you want to persuade a larger percentage of site winners to make a donation and you want to persuade site visitors to donate a little more than they originally intended because they firmly believe that a lot of these people that somebody may be made $10 donation or $20 donation or whatever maybe if they would give you a little more courage maybe they would make a $25 donation or $30 donation and over a large number of people that would make a few generous. And they also, based on some research that they have done and we also kind of corroborate that visitors feel confident that their donation is going toward their cause because what that means is I'm confident that the donation is going toward this cause that I'm more likely to tell somebody else, hey this is really a worthy cause, you should also make a donation so it has that virtual cycle. So what's really interesting here is that there are these words like persuade and make somebody feel confident these words that, you know, you can't really build something up with these cards, I mean I can't implement build here, handstand developer, make visitors feel confident. Where's the confidence algorithm? Who's got that? So one thing to do, there's an intermediate step that needs to happen here because if I tell them, well what feature would you like for me to feel confident like I don't know, whatever feature is required to make them feel confident, so if this can go round and round. So this is where kind of a user experience design capability comes into place and so what I'd like to do as far as the workshop and I'm going to, we're going to be handing out these cards and everything, what's that question I thought I had to go up? So what I want to do is first I'd like us to pair up, we're going to do this in a minute, don't get up right now, then we're going to be doing kind of a, and I'll talk through each of these, what I call in the role playing or car still in the exercise, I'm going to be time boxing these, I'm going to be iterating on them, they're doing a check in to see how we're doing. I want to do something that Jeff again alluded to, a design studio, I'll be introducing it, why, remember why you guys are doing this, the expectation is not that you guys will be able to do this stuff, I'll be talking about the expectations, the purpose is for you to just look at it and get a feel for this, and then we'll be able to discuss it, so it's not expected that you're someone going to be, for example, you know master and the design studio activity, and then I'm hoping there's going to be some time for some storytelling, not possibly I think there are too many of to do it for, you know, to the whole group, but in terms of the purpose of storytelling being able to use those cards, once you have used those cards to come up with some idea for a user flow, for you to present that to another pair, and then that pair to listen and say does that sound persuasive or not, because that's also one key part of being able to kind of sell the idea, present the idea. So there are quite a few of us here, but I think and I don't actually know if we're going to be able to have enough, so this is kind of a logistical issue enough. I think what we're going to do is, I think we're going to work in 3Ds. I think that that should possibly be, we might be able to get a number that's going to be at least the order. Yes, that's right. So I think that's too many. So one of the reasons we pair up, so this is actually an example of how we're applying how taking, you know, the user experience practice is applying more of an agile approach in user experience design. I rarely ever work individually doing user experience design. I'm almost always pairing with somebody and it's just for all the same reasons that developers pair. So what I'd like to do is if we could just take a minute or two and finally pair up with it. It would be great if you pair with somebody one that is somebody that you don't know and two, somebody who does not have the set of the same skills that you do. But the second of those is less important. It's more important to just pair with somebody that you don't know. So if you just take a minute. What we're doing here is a little bit of sort of a surrogate for kind of doing user interviews and the practice of doing a user interview or meeting with the user to get them to understand what are to develop cards or doing what we sometimes call card storming. And the purpose of that is to create a foundation for a design studio. Design studio plays a few different roles. One is what's called sort of an ideation clearing house. And the purpose of an ideation clearing house is whenever you have somebody who presents a new product idea to you or we're going to be creating this new product concept that somebody has described it to you who tend to see in your mind's eye some kind of idea for how it might work and it might be a little bit blurry, but you start seeing some various ideas for how it might work. So the purpose of a design studio is first to do what's called passive ideation where each person just kind of sketches out those ideas that they have in their head. And the second step in a design studio is for you to go around, share those ideas and then you kind of iterate on those ideas. You find what was the strongest one in this case within the pair and then from that you take the strongest idea and then you iterate on it. Or so just for you to kind of get a sense of this. And then at the very end we have one pair present their idea to another pair. So basically that is being able to make a persuasive case for your concept. Because persuasion is a key aspect of a user's experience basically and sometimes it's highly implicit. It's not like I go to Gmail and I'm persuaded to access my mail. It's more as if there are no obstacles. I feel like I can just do it. In terms of persuasion in this particular case with the charity site the persuasion is far more explicit. So here it's about really explicitly persuading somebody to make a donation. So let me go back to these cards so you kind of have them up in front of you. So what I'd like you to do is in your pair we're going to take about five minutes at one person to interview the other person and that person kind of be playing some role-playing here and say what if you were at this charity site what would persuade you to make a donation? Or you can also think of what would turn you off to not make a donation. And the goal of this in five minutes to come up with as many cards for potential features that we're going to use for the next exercise. Does that kind of make sense to people? Do you have any questions about that? Are they only focusing on the first card? Well I'm going to focus on all three. So I'm going to focus on all three cards and basically the goal can be somewhat constructive. You don't have to stick with any one of these. You can move around. The goal is to put yourself in this situation. Imagine yourself in the situation of I am now going to be visiting this site it's for this children's charity to help educate build schools and provide care for children who are in poverty what would persuade me or what would not persuade me what would satisfy these other things. So I'm going to do kind of a five minute time box which starts right now. Anybody have some thoughts on how this went as far as your experience was ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?