 My name is Danny and I am here to talk to you guys today about engaging design and UX contributors. Part of that is going to involve talking a little bit about what design actually means to me and to hopefully many of you in this room. Talking about what it's like to be a designer in the Drupal community. And talking about some of the roadblocks that I've uncovered in some of the research that I've been doing in the community for the last couple of years. So first let me tell you a little bit about me. I am entirely too busy. Right now I'm actually finishing my master's degree at Bentley University in the Boston area of Massachusetts. So that means I'm working at both the Bentley User Experience Center and patients like me in Waltham or in Cambridge. So I've got two jobs plus a thesis plus a daughter. And I also wrote a book called Drupal for Designers for O'Reilly in 2012, which is actually I'm going to be signing those books tomorrow if anyone wants to stop by and say hello because clearly I have all the free time. And what else have I done? Oh yes, I'm the UX lead on the community tools team, which means that yes that was me in the keynote. And clearly I've gotten the grease bump or you guys are just really pumped about design. Either way I'm glad to see you all. So what I'd like to start with is what happens when a designer goes into a contribution sprint. So how many in this room are actually, you know, consider yourselves designers, whether visual UX, what have you. Okay, and how many of you have actually gone to contribution sprints and like done work? Okay, so let me, I'd love to hear your story a little. Okay, okay, no worries. So one of the things that I did, I've been going to contribution sprints for quite a while. And at the last contribution sprint, which was at DrupalCon Austin, a couple things happened. First thing that happened was I tried to start sort of a community tools sprint because obviously I'm the UX lead of the community tools team now we've got a bunch of stuff that we're working on. And it turned into sort of a an ad hoc research brainstorming study. So this is something that I do fairly frequently. I'm working with a bunch of different people in the community. I'm pulling people out from the hallways. We've got whiteboards. We've got post it notes. We've got markers. I'm like in the zone. Right. And we're figuring out all of these problems. What is it that people are searching for? Why do people actually come to D dot out? What is the thing that they're looking for when they're actually trying to get stuff done? And, you know, this to me is just a beautiful thing. This is what I do. This is what I love to do. So now where the hell do I put it? We've got all of this knowledge. We've got all of this interesting stuff. Like, oh yeah, so we think that this is where we're going. We think this is where we should be heading. Where do I put it? So that someone who actually works on this stuff can take this knowledge and run with it. So I ask my collaborators, so okay, so where should this go? I'll put it in the issue queue. So now I'd like to take a moment to have a fun activity. Here's the D dot O home page. Find the issue queue. Anyone? What project is this? Exactly. But this is what we deal with all the time, isn't it? Even if you're not, like, what's interesting is I started studying contributors when I first, so a little bit of, you know, back history about me and my infinite schooling, the master's degree. One of the things that I decided I wanted to do, elected, I elected to do this. When I started my master's program, I said I want to do a thesis. And I want to specifically do a thesis on the roadblocks that design contributors face in the Drupal community. Because nobody does this research. And I find it really interesting. I've been in the community for five years. I want to see what this is so we can make this better. And the biggest thing that I found being an actual design contributor was the minute I had something that felt like we could move forward, I had no idea where to put it. And when it was explained to me where I should put it, yes, I should look for the project. But guess what? There were something like three different projects that it could be in. And which one of the projects do I put it in? So just that right there is more than enough headaches for anyone who's not slightly batty, and I'll admit to that right now, to say, oh, screw this, I'm not dealing with this anymore. But then another thing happened at Triple Con Austin. So who knows Morton? Yeah. So Morton comes up, and in that classic Morton way, says, I am going to scream. I'm doing a very bad Morton impression right now, but that's okay. And I said, well, okay, why? Hold on, why? And he says, we need to reach consensus. So I said, okay, well then you need post-its. I have them. So I like grab post-its out of my bag, run out into the hallway, and basically put these post-its on the wall, grab some sheets of paper, and I'm like, all right. And I'm kind of like I am now. I tend to take my shoes off when I'm thinking. It's a weird thing. But we're running around, and I'm saying, all right, tell me what you found. And he's telling me about how themers fall into two camps. There's the, I just want clean code, I want sensible defaults, and I want to control all the things. And we figured out the size of the camps, and we figured out all of these different things, and all of these strategies. John Albans shows up at the same time that my toddler shows up. And so I end up sort of having to run around with my toddler. And when I came back, this whole group had formed around John and Morton. And so there's some interesting things here. Now, this is not necessarily a critique as much as it is an observation, but one of the things that happened was during this moment, I had actually pulled in three of my friends who I knew to be in one of the camps because I knew that Morton was in the control all the things camp. And I knew we needed to hear perspective from the people who just want sensible defaults. And I happened to see a couple of them in the hallway. So like I do, I just grabbed them and pulled them here and says, you, you need to give him perspective on this stuff. But when I came back, this was what I saw. So two of those people, the one on the far left and the one and the woman in the middle, those were the people I brought in at the beginning. Notice how now they're in the periphery. And it kind of looks like everyone's just watching John and Morton argue with each other. Something that I don't think we acknowledge as much as we want to in the community. There are certain people we tend to defer to as authorities. And until they show up, it's often like we don't necessarily think we have a say. And I observed this when I was working on user profiles. So one of the things that I've done recently is basically revamped the user profiles for Drupal.org. A lot of the work that you saw Andres' keynote started from that work that I was doing. And one of the things that I experienced was the issue didn't feel like it was gaining traction. Until Angie and Jen Hodgden and a couple of these other sort of big name contributors started commenting on it. And while we definitely want to have this idea of community leadership, we also, especially as new contributors, we shouldn't have to like sit in the sidelines and feel like, well, you know, unless this person gets involved, I can't really say anything or my contribution won't be valued. All right, so this is something we need to be aware of, especially when we're trying to make big decisions. Another thing we have to think about is this particular event that I'm talking about, this consensus banana, happened on June 2nd. It took two weeks to get into the issue queue from that date. Again, not a critique, just an observation. There's a lot of stuff, a lot of decisions get made, a lot of important conversations are had. A lot of things move forward at contrib-spent sprints that the community doesn't know about, usually for a couple of weeks afterwards. And if a person is not at Drupalcon and is not at the sprints, they're often completely left out of that conversation. And this goes for development, goes for design, it goes for a lot of different areas of contrib. When I first started the research that I'm doing now, I really thought that this was just about designing UX contributors and how they're so different than developers and developers have it so easy. The more I looked into it, the more I realized this is all over the Drupal community. This is the roadblocks that we put in place and the hoops that we make people go through just to be productive as a contributor. So some of the things that are specific to designing UX contributors that I uncovered in my research, and in terms of methods, I'm happy to go over the full methodology, but this has been about a year of interviews, observation at Code Sprints while I was actually participating in them, and also a survey which had about 180 feedback from about 180 people, most of whom were actually contributors. So some of the things that I saw over and over again, one was getting feedback from everyone in the community, not just the couple of big name contributors. So this is specific to design discussions. On the profile, for example, we really needed to get everybody, the hobbyists, the new contributors, the people who are mostly site builders, the people who are using the system. We needed to get feedback from a broad level of people. What we ended up with was a whole lot of comments from three to five people who were brave enough to deal with the issue queue that day. And then, of course, there's the issue queue, which is really not designed to talk about design. And it's really not designed to help us make big decisions that really need to be made when the framework gets to this size. I mean, there's a lot of hard decisions that we as a community and we as a group of individuals have to face and have to deal with that we're not able to make effectively because we're doing it all in the issue queue. But the other thing, and these two are very interesting, I found very interesting, one was this really pervasive feeling that I'm not a coder. I don't write modules. I don't contribute because I don't know code. I can't even tell you how many comments I got. Like, I don't know, you know, I can do usability testing, but where would I put the results of that where someone would see them? I don't know how to contribute this particular type of thing. And then the other thing is, and this is specific, I think, to UI and design discussions, there is a somewhat excessive need for rationale behind everything that you post. I experienced it a little bit with the profile work, but in core, I saw one case of a screen design for the create content page, 300 comments, just in the issue queue. And prior to that, it was six months of debating groups and required a blog post by all of the people who actually worked on that design explaining why they made the changes they made and the rationale behind them and the whole process. And I got to tell you, you saw what I do for a living. I ain't got that time. Can you imagine anyone else who has a family and a job and maybe is in school taking the time to write a blog post, tweet about it, go into IRC, grab a bunch of people to go in and comment on it, hash everything out in groups and then bring it into the issue queue so that you can hash everything out again? And we wonder why seemingly simple changes take three years to implement. So I wish I could say that this is just design. But I've seen this happen with the... Yeah, I know, you know. I saw this happen also with the transition to GitHub. People are still bringing this issue up. The GitHub versus GitLab or whatever it is. I've seen this on groups and I follow it and every couple of months someone else is like, yes, let's do GitHub. And then someone shoots them down and then, yes, let's do GitHub. That's been happening for a year and a half. And some of this, I think, is the nature of an open source community. We're all humans. Humans are kind of stupid. And we don't necessarily have time to read through all of the crap that we get fed. But I think some of it we're doing to ourselves. And I worry that we're making it actively difficult for people to come in and actually be productive as contributors and still have lives. I worry a lot about that. So this is where I turn to you guys. There are some ideas that I have in my mind. I think we have a messaging issue. I think we have a process issue. I think that there are definitely ways that we can improve. But I want to hear from you guys. How do we fix this? What are the actual opportunities we have to make this better? And how do we actually take action on them? Two notes. One, I had a very similar conversation with Mark Bolton five years ago at Drupalcon Paris because for those who weren't around then, Mark Bolton was hired to do the design for Drupal.org and then hired to do the design for Drupal 7. He designed the 7 theme. And he got the same kind of nitpick on everything that annoys just about every designer who ever touches Drupal. And just about everyone else. And when I say designer, I don't mean visual designer. I mean anyone who's doing anything higher level than four lines of code. I'm just designing architecture, not pictures. So any design gets the same treatment. And a lot of it is because we're an open source community. Open source people are used to being able to crack something open and look inside and see how it works. And design at whatever level, it is inherently subjective. There is inherent subjectivity to it where you can't crack it open and look at every line of code to see how you got there. And so that annoys people who are used to that. So there's an inherent conflict between just the open source, tinkering mentality and consistent thought through design because there's so much subjectivity inherent in that. And I would argue that there is a hell of a lot of tinkering that happens in design. But we as a community don't really have the tools. And this is true of any community that deals with distributed teams, by the way. It's not exclusive to the Drupal community. We don't have the tools to tinker that make tinkering and sketching and brainstorming. Wouldn't it be great to have a big collaborative sketchboard where we can say, okay, do mind maps somewhere? Design doesn't have an intergift. Exactly, exactly. Design doesn't have an intergift. And it requires many more people than someone sitting at work at their desk and writing a bunch of lines of code, making sure it works. And that is not to say that developers aren't creative. I actually believe that developers are some of the most creative people I know. But we solve problems differently. And so I think that, you know, I would argue that there's plenty of tinkering that happens in design. It's just not always visible. Absolutely. I mean, the width of code is a lot easier for someone who is not tinkering to come in late, look at it and understand all the bits and pieces. Not necessarily trivial, but it's easier to do that with a patch than it is with the design of a UI. The other points I'll note. A huge part of the problem. This is teaser for my core conversation tomorrow. Huge part of it is our completely non-transparent implicit leadership structure, which means you don't actually know who the big people are who wander and buy, and you're supposed to listen to them. They exist. They're never not going to exist. We should just be explicit about who they are, and that will help a lot. But right now we try to pretend it's not the case, which means we're lying to ourselves. Let's stop lying to ourselves. For more on that, come to my core conversation tomorrow afternoon. Well, and actually that gives me, I mean that gives me the idea, like one of the things I was thinking about is what if there were teams? What if we were explicit that a module had a team behind it? That a section of core had a team behind it? I mean how many of us consider ourselves professional designers? How many of us consider ourselves like magic unicorns with a design stick that you just wave and design magically happens? You? Awesome. I'll make sure to craft you a nice horn that you can wear. Design requires people. More than just about anything else. I've been doing this since the frickin' 90s. I don't want to say that out loud again. I've been doing this for a long frickin' time. And you know what? When you're just sitting and banging out comps, you're not the designer in the room. You're the pixel pusher. You're the one who makes things pretty. When you're a designer, you're at the head of the table and helping everyone agree on what the direction is. You're listening to a bunch of different people from every different part of the room. I mean that's what this whole brainstorming thing was. Right? So both of these things were just as much design as putting together a compass. This is how we got to the user profile. This is how we got to figuring out what the priorities are. This is something that designers do every day. Whether we're sitting in a room putting together comps or whether we're facilitating workshops. We have to decide what is the most important and how do we give the most important things, the visual prominence they need. And so there's an opportunity here for us as designers to help facilitate those kind of conversations within the stuff that we see in Drupal.org but we need the infrastructure to support it. Oh yes, microphone. Oh. Alright, so I'll repeat what you're saying. Yes. And I think that that's another challenge I've seen. So what Theodore is saying is that the developers want to help us. They do. They just need to know what to do. And that's actually one of the areas where I think we as designers need to take some leadership and we need to do some self-reflection. So we need to think what is it that we need to do but then also I mean this I think is one of the things that the content working group is working on right now. Like where do you find things? Where do you find things? Where do you put them? We just don't know anymore. We've got too much crap on the site that's been growing for, and what was it that you told me at Design for Drupal? Like we've hacked the shit out of the issue queue far beyond what it was ever meant to do. Like we know the issue queue sucks. Yes, exactly, exactly. So I think this is one thing that as designers, if you want to contribute to Drupal, there are things for you to do. But we need more designers to come in and take leadership roles and basically say this is what I see we can do. What can we do to make this happen? What can we do to facilitate this? And this is where we turn to design as problem-solving and also problem-defining. I don't know how many of you have done this kind of work but how many times have you dealt with a client who says I want XYZ widget and you have to ask them, okay, so why? And they can't answer that question. That's where the Drupal community is now. That's really where we are right now. We're throwing all of these ideas at the wall. And what we need is more people to come in and say, okay, so how is that going to actually help us? What is the big picture here? I mean, if anything, that's where we're going to shine. Oh, they really packed you guys tight, didn't they? There's both of this collaboration so we have this shared understanding and actually to break down the specialities of the developers and designers that are throwing documentation or sketches. So I think, maybe, I like that BNUX approach and I teach it to my web developer students and see everyone is a designer and it's just a little sketch of some level course getting away from the pixel. Yes. Well, and actually, did you have something to say there? Oh, you were just, okay. Yeah, and I think that Drupal can learn a lot from the BNUX approach. Not necessarily the anti-deliverable approach because one of the uniquenesses of our community is we exist everywhere and so the person you are working on a particular project with is often not going to be in the same room with you and you have to find ways to encourage collaboration in a very distributed and self-organizing team. So there are some ways in which we need to be able to support asynchronous feedback. So, you know, feedback from someone who's not necessarily in your same time zone. At the same time, the big thing that we really need is we need to be able to do more than just discuss something. We need to be able to show design, to essentially show our work to use a math class term. If you want to say something, please phone a line behind the microphone. This is getting recorded, which means anyone listening to this afterward will have no clue what's happening for the second half of this talk if you're not up here. It's true. So if it takes a while to get out from the chairs, just get up and phone a line here, please. Yeah, I'm not sure why we're not doing like a Bob Barker like pass the microphone around. Can you do that? It's wired, not wireless, unfortunately. I looked, I checked. So stupid. It's taped to the ground, I can't carry it around. The AV team would yell at me if I tried to pull it up. I know. Please come up and stand by the microphone. Yeah, and the funny thing is like I tend to walk around, like I literally took my shoes off because that's a thing that I do. And I like to walk around and when I was in Austin, it was the same problem. I had to like stand here at the podium and be very, very still. All right. So I mean, that's basically what I have to say, but I want to hear from you guys. What is it that you want to make happen? How do we fix this? Two questions. Yeah. One is maybe because I walked in a little later, are we talking about UX contributions for D.O. and Drupal infrastructure, for Drupal projects, or for what? So when I talk about design, I kind of mean big D design, which is, you know, design is a way of solving problems and really sort of getting down to the nitty-gritty of what we're doing here. So on that level, I consider design and UX contributors to be people who want to contribute design in UX to the Drupal project. Now that could be core. It could be contrib modules. It could be evangelizing design within the Drupal community, like design for Drupal does. It could be any of those things, but I do think that we have a significant issue when it comes to discussing design, like discussing design essentially and design improvements within Drupal itself. And certainly within Drupal.org. I think in general that's true, but when you separate out the idea that, you know, there's design in core and Drupal core and the core is your Q, whatever, and then design in this sort of federated contrib space and then design in this tertiary D.O. sense, right? The incentives for somebody to participate in design are different for each one of those facets, right? The reason somebody would want to participate in core design versus a contrib project, which is wholly owned maybe by this one person or group of persons and then versus D.O. which is at once really easy to participate in and also impossible to change. The incentives are all kind of different for each, right? And so when we're talking about how to solve this, I don't think there's this one thing that we can say, oh yeah, boom, that outfix for everything, you know? Or even that one approach is going to even remotely come close to solving it. Yeah. And I agree with you there. You know, I think that the issue as most design issues is more complex than just like let's come up with a solution. I think that one of the challenges that we face is that we have a very rigid process sort of defined for core, or at least we think we do. But then we consider contrib to be the Wild West and people can just do whatever people want to do as long as they adhere to the coding standards. And so as a designer, I think it's very hard to come into this space and even know where to contribute. Like where would I put my energy? So why not focus on contrib then being that that's the one with the lowest barrier to entry? I don't know that it would be the lowest barrier to entry. Because for example, like one of the things that I saw in the survey from designers was that contrib maintainers are surly when you try to suggest UI improvements. One of the particular situations and why I focused on design in UX contributors is that most often we're not the ones implementing the things we design. So an inherent complication of our job is that the duocracy doesn't seem to apply to us. Because we can't actually do the thing. All we can do is say here's what we think it should be, here's why we think it should be that. Could you do it pretty please? And even when you do it, we don't necessarily get credit for it. So this is one of the reasons why even though I think that the barriers that we put in place for contributors happen across the board, I do think that designers and UX folks are in a very particular spot because they have to spend much more of their time just defending their right to be on D.o. I'm just looking right at you so I'm like, oh no, it's okay, sorry. Yeah, maybe something I would like to add to this is that design is not anymore just add on to Drupal or to any side you do. I think at Drupal we lag a little bit behind the standards of UX and design. When you look at WordPress and at other upcoming CMS they have really nice admin interfaces and I think it would be really great if we would wake up and integrate design and UX more into our processes and I agree with you, it's not easy. I have also tried it a little bit and I know that I think there are starts where it turned out really well and where teams are working together but I think it's not only a process change it's also a cultural change. People have to, a developer have to accept or have to feel that it's great to have a team that is great to have input that it's not only I sit in my room and I code this down and I think it's also on the other hand side we have to mobilize designers that dare to come with an issue. Now what everyone could do here in the room is like taking a UX issue from Drupal that we all know from working together with clients and go to the sprints with it and draw a little mock-up and say hey, this is my idea, this is how it is now and this is how I want it to be. Who would help me to implement that? And I think also as designers one of the things that we need to do is learn what is the best way to give feedback what is the tone we need to take how do we suggest these improvements without just ranting about a module because we've all seen how well that works. So I think it's a give and take on both sides. Developers need to be able to welcome the input and say thank you for helping me and like how can we work together on this and designers we need to apply the same principles that we take to our own work and apply those to the developers of these modules and say here's some issues, here's some areas I think we can improve here's a sketch of what that might look like what do you think? As opposed to just going and ranting about a module and saying this UI sucks, here let me fix it for you. So maybe a message of hope for UX and designer well back in Drupal 7 there was much less people working on the front-end either CSS or JavaScript or HTML but now that's changed we actually have a big front-end team that address issues and those are the guys that implement UX and design, new design and new UX stuff. So it's going to get better but we still need more people on the front-end developers to help you basically. So hang in there I guess. I have two thoughts I want to share and also as comments. One of the thoughts is every major company that works in the CMS business usually they start a new project by launching a new UI so there's a completely new set of icons and everything so they start by launching a new UX that's thought number one which leads me to Drupal the problem may be the way that we are organized. I work as a volunteer at a big musical festival in Denmark where I live we're about 10,000 volunteers and no one, we created a lot of bars and scenes but no one and I really mean no one would make a sign for a bar without going asking to the sign painters about having them make a sign for us so nobody does anything front-end without asking the design team. So that's how that music festival is organized so no one does front-end without asking a real designer. Yes please. I'm new to the Drupal community I'm from OnCloud so from my experience the designers and developers working together or you don't really have that when you don't really have that much of a split between developers and designers you have front-enders and stuff no matter what the split is it really boils down to the trust that people have towards each other and that kind of belongs to the designers to properly communicate properly document their changes why stuff has changed that way so I would actually disagree with what Larry said before that design is highly subjective I would actually say it's largely objective because that's why you do usability testing you do research, you write up specs you do mock-ups and stuff so actually mostly design is really objective I would say sure not when it comes to theming that's a different topic but in general I found that that works really well if you document everything if you spec everything you do mock-ups plus writing then developers have trust that you're making the right decisions because they also see that it works and they come to you or to the designers and I think that that's definitely true to a certain extent I think that what Larry was trying to get at was that design, there's a lot of people who either like or dislike a design so on that level yes it's subjective there are some stakeholders that all of us have had to deal with that really don't care what usability testing said they like it that color blue and they want it to stay that color blue so there's a little bit of both I think that one of the problems that design contributors face based on the research I've done is not necessarily the need for documentation but the excessive need for documentation and feedback and like to a level like this is your worst client and you know I don't think I've seen as much of it as some other people I think that the community got a lot better in the time that I was just sort of watching the community and waiting for my opportunity to actually come and contribute something but I mean there were times literally where everything was months of arguing yeah I mean that's the flip side of it kind of that new contributors um it tends to be or sometimes tends to be that people just or designer design contributors just submit mock-ups or just submit visual changes without any reasoning behind it or so it seems and that's really a stark contrast to how it should be and I mean actually working in an open source project as a designer is the hardest thing I can really mention like it's harder than in any agency so that's also really turning off the new contributors but at the same time the existing designers really need to yeah document it it's a two-way street it very much is thank you two couple ideas so first this design is actually difficult because you also need to think about the mental model and how the system can look very different and different use cases so someone configures the drooper side and has the same UI on the backhand but it looks completely different because there are different entity types or whatever so you need to have like the complete picture in mind when you design this of how it can look like and the different situations where it's applied which has different expectations for it and then the second thing that was just a quick idea I don't know where it goes is if designers would actually produce something like documentation like a spec or design patterns written or design guidelines anything so that designers could have a discussion and actually come up with something without having to wait for someone to implement it and then this could even be in version control and so you would say like before it says yeah this should be yellow and then someone says yeah I think red is better and then you just say it changes the senses which says this thing should be yellow and you say this should be red and then you make a commit and you can explain what you change and why you did it and so you would actually have something instead I mean now if you discuss something and then someone has to implement it and they have to look in the discussion what was decided there that seems like unproductive. I think both are good points I would argue that many of us who are designers are more than we have our share of complex systems that we have to work with on a daily basis I don't think that Drupal is unique in that so for example I work at a rail like patients like me where I work in Cambridge is a rail shop and that is the same thing I mean depending on what condition you have the entire UI changes and that's something that we're very familiar with in the Drupal world and in terms of design patterns that's actually something that is being worked on now is design patterns for contrib maintainers I don't know the status of that just yet but if anyone is interested in contributing to that get in touch with Lewis Nyman because he's doing a lot of that work yeah so I was just going to say I think one of the powers of having an open source project is the ability for you to just jump in and do whatever that you want to override something that exists so my point is you don't always have to get something into you know into a contrib module for instance you could just say I've created this patch do you want to implement this no that's fine I'm just going to roll my own module that overrides your styles and that's the way I want it and then you can see what kind of adoption you get from the community and as the adoption gets bigger then that becomes more of a pertinent issue to get into their module and this is I've done this a ton of times you know for panelizer you know panelizer was very ugly so I was like okay let's redo this in a much more you know way that makes more sense for Drupal and redid that and then it's got a really big adoption rate so I think that there are ways for you to to get in without having so not at the mercy of a contributor or the maintainer of modules and the maintainer of I guess it really only works in the module world in the theme world because you can't really say change this on DO but it is a place where you can you know start to get introduced into you know doing some of your own design patterns without having to require that piece of it to be part of it you don't have to have that be into their module or your own patch or you can write your own module that overrides that so I think that that's a pretty good way to go and it's worked pretty well and people are okay with having that be a method for you know getting around that at the maintainer's stubborn in the case of what you've said there so yeah well and at the same time though I mean many people who do you know many many of the people who do patches end up contributing those patches because it's one last thing for them to maintain exactly yeah so you can do that and then show that it has an adoption and they become more likely to want to do that yeah so just had a thought about like contract modules okay is there any easy way that a developer could ask a designer for UX help actually I think honestly the easiest way the easiest way to reach out to you know designers or UX designers is to list it on your project page like we need to I haven't figured out a good way to solve this particular problem if you are interested in working with me on designer UX please contact me so there is a usability group and you could also reach out to the usability group I feel like you'd probably get more immediate traction if you listed on your project page as well because that's where someone's going to read the documentation for your module and so your project's going to get more wide adoption if you have a complete you know here's what it does here's the documentation anyway so if you also say you know these specific problems I haven't figured out a good solution for if you're a designer and you want to help with the UI please get in touch with me I think that's a really great way of signaling that you're open to that feedback more thinking of a bigger scale where you could see these people are UX people you could ask them for help and these modules need help yeah so that's actually that's a fantastic idea I would love to see some sort of matchmaking service for UI and what yes I know I want to see something like that and I think wherever I'd like to see it headed I am on the community tools team I will bat my eyelashes at the DA I don't know how far we can get but that is definitely something that I feel like I really feel like contrib needs love it really does and I think that we do ourselves a disservice as a community by putting this distinct process or whatever we call it around core and then telling contrib well you can do whatever the hell you want I think we do contribute a major disservice in that way because honestly even with core in the state it is an 8 which is very strong there's still a lot you can't do without contrib modules and so you know especially when you start getting into things like I mean workbench needs help you know like views needed help a long time ago like all of these different things that just need they need some love so I think that's a great idea and I think that somebody should work on that there is I feel like boyan is the only one in there like I don't know you are okay but like with other projects like with noher noher I mean we need good experiences with focusing on that like also because IRC is a developer's tool so just like you know yeah I mean what I'm thinking actually what I'm thinking is something more like what's in my mind is more along the lines of elegant.ly I don't know if anyone's familiar with this it's basically a service that hooks up designers with startups and in order to be listed there on this site as a startup you need to have a business plan you need to prove that your model is scalable like there's all these things you need to do to prove that you're serious and then the designers get to go in there with their qualifications and decide whether you're worth basically working for free in exchange for equity and I feel like if we had a model like that for contrib where each side is basically saying you know here's an example of my commitment to this process I think that can work really nicely for contrib and not require too much more than what we currently put in front of contributors in fact it might even make it easier because it basically helps create these self-organizing teams that we're being talked about next door you know it's like I use this you know I want to make a module that does this but I need a GUI behind it so I need a partner with I need a partner to help me with that thank you I think we have time for let me just double check the time 15 minutes yeah okay so I'm like I'm the core maintainer for the sub-core subsystem that probably has like the well not probably the worst GUI ever namely field API and field UI and so standing at the other end of the line like I have the same position and the same question as you I like I don't know how to make this happen that like we get to a better field UI I have no idea yeah what's wrong with it to begin with I have no idea how to make that happen and I kind of know for sure that like it won't happen on the D dot O issue queues and I've kind of like completely abandoned even like getting involved in UI UX issues about field UI in the issue queue because after a couple of them like I know in advance that they're not going anywhere and so like the one single similar example that I know of and that I can think of is the views UI that was the work that was done for views three in the seven and that thing only happened because a a choir funded it yep and B it was kicked off well most of it happened in a dedicated sprint with people in one room for several days in a row to like hash the thing out because like it might be simpler it might be doable on the D dot O issue queue for maybe smaller scoped but for systems like these views field API like it's really a complex combination between the constraints of the of the system like why is the API that way because like it has its own set of fairly complex constraints so it would be nice that if the UI allowed that but like it's not possible because we can't code it or it wouldn't work because of this of that and the team with a an intimate knowledge of that the workings of the system we're trying to design a UX for like it really takes time and most of the like there are repeatedly one of suggestions we could try that and you can shut them down pretty easily because no the API cannot support that and cannot work that way for that reason and getting to that point of knowledge text really takes time one other thing maybe is about I don't know maybe it's about tooling like I don't I have no clue what are the UX and mockups and design tools available except apart then like just writing the code and testing it live and there is one big limited scope but still it's a 2k 200k patch issue to make some part of feel UI better but like the current process mostly is yeah we should try that way but in order to try it someone needs to code it first and so it takes an immense amount of time and it's just like after three iterations everyone is completely discouraged so maybe it's a question of tooling what could we what tools could we use to like try things and agree on things but first having to code for them yeah well and I think this is this belies the importance of having teams and having a designer on the team and part of being on a team certainly my role on projects as a designer is often to figure out what are those constraints and then how do we make improvements within those and in terms of tools I mean there are many different tools you can use it really depends on the designer but a lot of it you know this is where the argument of having someone who's embedded with you guys and is going along that journey with you like I am the designer for feel UI and so I've been saying for a while we need design maintainers as much as we need code maintainers because a lot of the stuff that we're dealing with media field is like these are really complex systems with a lot of dependencies and a lot of things that you need that sort of intimate knowledge and you need to stick with it for the entire period of time so I don't have an immediate answer for you unfortunately but I would say if you have UX designers on your team or if you want to reach out to any of the folks in here who are UX designers and just start talking to them about the issue at the sprint and say what are the things that we can do here, here's our limitations how do we design within them? I'm a project manager so I'm mostly sitting between developers designers and this weird thing called customers and nobody mentioned customers yet today or even users and these are usually the things that we used to bind developers designers together and that's kind of what you have there those drawings you have that could be a user story and it could be a good basis for a dialogue between developers and designers and create common ground but I think the team solution is where we need to go because you shouldn't be developing anything without a user story I know that sounds really annoying if you're a developer but if you can't justify an end user and you really want your function you shouldn't be doing it it might be a technical issue but that's different that's really core but most of the stuff you do you should have a story if it has a story that has a user interface and user interaction you should have a designer in there and you should of course have a project manager to make sure it all happens but that's another story but it needs to be a bit bigger and interfering with the stuff I'm doing with I see as sort of the developer idea and even the design idea sometimes you know I like to do this and I'm doing it in my free time so nobody should tell me what I should do and that's okay if you're doing your own homepage or you're doing it for yourself but this has gotten too big for that it's okay if you're in the French somewhere and doing your own module that's okay but if you want to make a good module for people you need to get a designer in there you need to have a team I'm not saying you need a project manager but it might be a good idea to make sure that somebody you know goes out there and finds the right resources for you knows who to talk to know how to pull in the right resources and more developers if needed so I'm not I mean there are tools for doing that like professional tools for project management well I think also that's where that's certainly where organizational credit comes in you know certainly in Larry's case at Palantir like you guys have teams that are working on modules right nominally not as much as we'd like to so you guys should have teams that are working on modules right but yeah I think that organizational credit can go towards that and I do think that one of the differences I observed when I was talking with French contributors last year is that there is a very different way that French companies treat contrib it's part of their work day you get X amount of hours during the work week to work on contrib and in the states that's very often not the case you're sort of expected to do work stuff if you can manage this contrib project you know in the course of your work stuff you can do that a lot of contributors end up contributing on their own time in the states and I got to tell you I've got a toddler I've got too many things to do how much time do I have to actually engage in contrib not that much so there's a little bit of got to give happening so I'm going to have to agree with the previous commenter on the one hand yes project management does matter the actual team matters the there are only there are like seven core initiatives officially for Drupal 8 there were only two I would call a success and mine isn't one of them and the primary one is views because they had from day one two developers a project manager slash coordinator there was three developers in a coordinator they had a team with different roles with resourcing from day one it was the only initiative that went well every other initiative has been a train wreck for that reason and some of them have been completely disabled right because I think the design initiative went nowhere the design initiative was still born whiskey I'm struggling along through the sheer force of stubbornness scotch disappeared most of the others petered out eventually to some degree of we got enough done that we can go home now views is the only one that was organized correctly because they had an actual team I will have to well this read though is if you're dealing with the bespoke application then yes everything is a user story if there's no UI you don't bother building it Drupal core is a platform not a bespoke application so the rules are a bit different certainly anything in the UI should have a user story around it and have a goal and a purpose and fit into a bigger picture but to when you're building a platform to get to their often requires a lot more plumbing than that would imply and one of our big problems in Drupal historically has been that we don't actually have APIs we have UIs that are tied directly to the database and we need to break those apart to a larger stance that you can design a UI and a workflow and a user experience an independent of that design a developer experience design the APIs design the core components and so on and those should be decoupled from each other far more than they are now and that would I think actually give a lot more flexibility to people who want to be UI developers for lack of a better term the kind of stuff that I do very rarely has a UI to it the stuff I've been doing in Drupal 8 so I don't deal with designers on a regular basis want to now do panels in Drupal 8 oh my god they need a designer working with them from day one if you're interested in that please please that's why the most important contrib module have designers working on it please but we need to keep those decoupled and have that separation there so I think it's also a question not just getting designers and developers working together but the right designers and the right developers on the right parts of the system APIs should not be dictated by UI and vice versa I also think that an important thing to think about is oh I'm losing my thought ah alright it's late then I think it's important to also to bring back this point about a user story is that a user story could be if you need to make this happen on your website this is the module you use so I almost view a user story as an excuse for this module to exist and something that should be on everyone's project page if you can't tell me why this module exists and when I would actually need this module like it shouldn't be on d.o feature request a user story field for project notes like seriously because it's one of those things like this is just you know who here works for themselves okay so those of us who work for ourselves we understand the importance of actually saying this is why you should hire me right we do that for a living daily we say this is what we do this is what we bring to the yard this is why you should hire me and it's remarkable to me when I see project pages that have like yeah this module does this thing and that's all that it says like this does not help me understand whether I should use your module I think a lot of what I'm hearing is the same thing we've been saying every time we've had one of these core conversations in the past six years which is we need to talk more and we need to talk at the right time yeah the focus should be on how do we get the people talking at the right time how do we close that communication there have been several failed attempts to do that that tag at one point for hey I need a designer to look at this issue it died because a tag in the issue queue is meaningless unless you know that you're looking for that tag yeah and no one has ever owned making and maintaining that communication channel because yeah every time this come up as a module developer I've said dear god please designers just tell me what to do with the UI for my module I don't want to think about it just give me instructions I'll do it and most module developers I know have a similar attitude yeah so the focus needs to be on the demand is there on both sides how can we connect it how can we do that matchmaking there that's what we need to put our focus to make that connection happen and I completely agree with you I mean the things that I've been arguing for is a design maintainership over modules like I actually have a designer listed as a model and just the ability to have some kind of structure around teams and some kind of structure that's around expectations not just of what your code will look like but of how you talk about your module and why people should use it you know I mean these are not super high expectations to set but the fact that we're not doing it I think is doing it to service both to core and to control what tooling can we do to make that happen I guess is the open question okay I think this is the last one and then we're done so I think this is a really valuable discussion and I think we should continue on this okay for example I am here still on Friday for the sprints okay I would be ready to discuss and sweet alright well I will also be at the sprint so I think hold on one second there were like two slides that were related to that as a matter of fact okay so one that you love me feedback and there is a sprint on Friday I will be there working with Tatiana on a bunch of community initiatives so please if you see me come sit down talk to me bring me coffee I will need it I really hope we can get some good stuff happening and thank you all so much