 Thanks for coming. Understandable enough? This distance, et cetera. It's okay. Yeah, Drupal UX stuff. So my name is Roy. A long time doer of UX things for Drupal. And Drupal 8 has shipped. So we have new... We have room again to do new and exciting things. And that's what we want to talk about and discuss today. I hope you've all been to the keynote this morning. There will be some parallels in this talk as well. So, no news, but we got issues. And they do need work. This is not news. And actually, in fact, we've done more than... We've done multiple usability tests on core. And the results have basically become predictable. Because we're not tackling some of those, right? There's a couple of elephants in the room that we're skirting around. And which means that for Drupal 8, we kind of have to reinvent our approach. And luckily, there's some changes in what will be and how we'll be releasing Drupal 8 moving forward. So that there's room to change our process. Basically, we want to do more and we want to do faster. And instead of planning our new usability tests, we should plan and focus for getting more new interesting things that we can test eventually. So, Boyan, Angie, Gabor, and I, in that corner. We wrote up a first post on groups.drupal.org where we provide an outline of things that we think where we should start with changing things in order to achieve a new kind of momentum and make... Achieve this kind of momentum that we need and make sure or more sure that improvements designed and built will actually land in core. Spilling the beans from the front. The main talking points for today, as in that post, we need to tackle the big issues. We've avoided them long enough but we have to do something about them. That means that we have to create room to experiment. Ideally, in core itself, find ways to somehow lower our standards and play and find room to play in core, ideally, so that we can test new things. In order to do that, decrease our upfront design effort. There's a lot of development effort as well. We're talking UX here and it all relates but we have to decrease our upfront effort and we have to get more clarity on the priorities so that we can focus our work and be more sure that the things we're working on will actually land in core. I guess Dries discussed the visionary why of Drupal as a thing this morning. The best open web platform for great experiences. I subscribe to that idea. It's why I contribute to Drupal UX. I want more people to be able to own their thing on the Internet but not news but we're making it quite hard for new people to understand that Drupal power and make it their own. We have some systemic core-wide UX issues that run through the whole system as it is today and I want to start out with depressing you all with that list and then we'll look at how we can change that. This is a high-level summary of the things we keep finding when doing usability tests. This is basically the most critical of critical UX issues we have. For context, when we're testing Drupal core then we've basically always tested core without any extras and the participants were very smart web people without Drupal experience or with little Drupal experience. These are smart people. They're in the business of doing things with CMSs and building stuff for the web. It never is but it's not their fault that they're stumbling. One of the things is that our terminology is weird. We use weird words for familiar concepts. We use different words for essentially the same thing. Blocks, panels, panes, etc. I'm sure there will be examples of where we're using the same words to mean different things in different contexts. Contact. Yes. So, yeah, wording is a critical UX thing. We don't connect the dots for people. There's no getting started info. There's no once you've done this, go do this. We're not helping people become successful. So we have small pieces all right but they're not even loosely joined at this moment. And, well, these are actual quotes from testing participants. They have no clue where to go. We don't help people with a main path, etc. Making that even a bit more difficult is that we're not putting first things first. Our current process makes it very hard to decide what's more important than the other. So we don't make that distinction. We present everything in the same visual weight. And that makes it hard for people to decide what to do next. We can decide on the AD20 use case. So we compromise and make it hard for everything. Make everything hard to find. One of the big examples is the structure page itself which has, if you would enable... No, there's comment types and content types. I keep clicking comment types when I want to go. Yeah, all right. Right, and 80% is content types, right? I don't think comments even gets to 20. Views, because we do alpha sorting, because we can't decide. So we do alpha sorting. Views is at the bottom. It's a pretty important piece. Previews meaning not necessarily actual previews because that's what we're lacking basically. Previews meaning hitting save on the thing you're making. Go visit it in the front-end. See what you've done. No, that's not what I wanted. It's getting there, but I want to make changes. Go back up the admin hierarchy. Go back to that page. Make changes. Hit save. Look to the front-end and back and forth. That's really suboptimal in workflow. And that makes people lose confidence. Not good. Similar to that is that the order in how you have to do things is backwards. Yeah, so a side builder example would be people want to just add checkboxes to that content type and then say that those checkboxes should provide the options for the lunch preferences for DrupalCon, for example. But for that, now you have to first create that vocabulary somewhere and add the right terms, and then you have to add an obscurely named term reference to your content type so that eventually you'll have some checkboxes show up. So that's really quite backwards. You have to set up those containers, the abstract placeholders, that vocabulary first before you enable yourself to add those to the content type so that people can actually fill them out. The mental model there, the expectation is let me add checkboxes and configure that to mean lunch options and if that creates a new couple of terms in a new vocabulary, let people find out. That shouldn't be an issue upfront, ideally. All that together makes the standard installation just too sparse. There's nothing in there. There's a lot in Drupal8, right? There's views and all the things. But we don't make it available. We don't show it, sample content, getting started instructions, similar to the way finding, but it's basically that we don't provide initial features. And a more specific one, but also pretty critical in the sense that people feel like they're breaking things. Posting that first article creates a very weird homepage. Did I put it there? I didn't put it there. The River of News model is a bit outdated, but after that first post, it's straight up confusing. All that together, we're at the end of the list. This is weird. All that together, people are not confident and people see Drupal as limited. It's just the complete opposite of how we're selling it. It feels limited and they feel like they can break it easily. And if people don't find out that there's an extend page where you can add modules and enable more functionality, then there's a module for that. This is not a viable answer. That doesn't count, because people don't find that out. So, yeah. That's the diagram of that. We have a lot of Drupal. We have a big ecosystem. We have a quite arbitrary circle that we ship as being core, and there's no ways people don't find out about the rest of it, which reminds me of a core conversation I would have had five or six years ago if it were not for some volcano in Iceland, where I think that was the first one where we were to have core conversations, but this is the problem, right? Drupal can do everything, but core does almost nothing really well. And the idea there was, wouldn't it be great if we could provide install profiles with sample content, et cetera, so that people can choose to build my first portfolio or a great blog or the business website, give people presets and help them become successful. So now we know why people fail in understanding the Drupal awesome. So what do we have to change then? We have to change the core products. And, yeah, we make product decisions every day. Every time we commit something to core, we make implicit product decisions. And one of the goals should be moving forward to make that more explicit. So that's that first talking point, right? We have to start finding a way to tackle the big ones. We've already gotten a lot better at running big initiatives and splitting up the work and defining from that big vision the individual tasks that we want to achieve in order to get something. But that divide and conquer approach also makes us rather risk averse. It also blends the actual result into potentially not that spectacular as it could have been. So we need to tackle the big ones. Yay, initiatives. Data modeling, layouts. The outside-in approach of making workflows more like people expect them to be. The content workflow. Media, et cetera. So, yeah. Drees agrees. We need to tackle some of these big issues in that way. Duple-UX means we want to make bigger changes and have shorter release cycles. So how can we make that combination work first? I think there's a way, but that means that we have to change our process. How? One more look back. Duple-7 UX. I think the content creation page is I think the biggest obvious change we've made. We've made different ones, but mostly incremental changes requiring that huge up-from-design investment. I looked up all the comments we've generated by just that layout discussion basically for the content creation page, excluding wizarding, excluding the previous, et cetera. That's not sustainable. We're a small UX team, but even a big UX team wouldn't get things done. So we have this huge up-from-design investment. We perfect. One single idea. And we validate it mostly after the fact, as in after committing it to core or even after shipping core. Not always. We do test individual features, but mostly in the form of patches, so the code is already written. And a pain every core contributor feels is that all your efforts, there's no certainty right up to the end, so all efforts can be derailed at any time. And you shouldn't want that. So tackle the big ones, decrease the up-front design investment. How? Well, I think we should look in what the Lean UX approach gives us by generating and prototyping more ideas, validate before actual code is written, and become more clear on what we want to work on. Find some way to frame that effort and make it more predictable that it will reach some kind of finish line for a next point, 8.x release. So our goal should be to dramatically decrease the up-front investment necessary for finding out if a design or feature is useful. Usable and in the end mature enough to graduate to Drupal core. So the whole Lean UX thing. The current process means that we're right. There's too much work, right? And any significant change can take up to months worth of design discussion and code, and months of work for the redesigned content creation pages does not scale. So what can we maybe learn from things like Lean UX? Beware all the buzzwords, but Lean UX combines or picks and chooses approaches from user-centered design, agile development, sprints, scrums, et cetera, and elements from the Lean startup method where the build-measure-learn cycle is the big one. That also means that we should try and move from the consensus-based approach we have now to a more experiment-based approach. So we have to find ways to get us, work ourselves faster through this loop where we say, okay, we think, we know, we need to change this or we want to build this, we need to improve this. What is the minimum we have to do to build, to design, to be able to test our experiment so that we can get the right feedback so that we know which... What does this mean? Is this Lean UX? This was a small glimpse into our future. The basic idea is that we want to define a formulator, a hypothesis for an idea that we want to validate or invalidate as quickly as possible with the least amount of effort necessary to feel confident that we're making a right decision. So that's that MVP part. We have ideas, we have initiatives, say, and, well, we have to have a plan for that, but we also have to have an approach for validating that plan, basically. And that's that MVP. And I think this is one of the important messages for how we should be thinking about shipping features and structuring our work. On the left side, if we... So the minimal viable products, right? What's the essence of what we're trying to build? And we shouldn't... I don't think we should fall in there. Basically, the old way or in the trap of focusing on just API so that eventually we'll have something cool. We have to have that vertical slice that not only gives us something functional, but reliable and usable and desirable as well. So we have to find a way that we ship 8.2, 8.3, 8.4, not only with API improvements because, eventually, but each point really should have something cool to write a nice release announcement for. Because if you do that, my hope is that we have a lot of untapped contribution resources. If we know that... Maybe I'm getting ahead of myself. Yes, initial MVP should not necessarily require code, so we want to validate before we start doing the actual heavy lifting of writing implementation code. Ideas, concepts, approaches can be validated with really rough paper prototypes, clickable wireframes, HTML, JS, smokeups, et cetera. That's what we want to work on. And validate before doing the heavy lifting in core. Actual core patches, actual code. And the third element is, okay, how can we become better at making sure that efforts will result in something that does make it into core? Like I said, usability tests already... We already know what we need to work on. Dries outlines some initiatives and we can add to them, so that is the stuff we need to work on. Up till now, that has been mostly implicit and we need to become more explicit about that. We're now making those product decisions just by committing stuff. Now we have to become better and more explicit about, okay, and this effort is towards that goal. Yep, roadmap. Yeah, focus the contribution of people who are already working on it. And I think this is the untapped contribution resources that, whatever, say if we know that we're working on media and we want to ship a library in 8.2 or 8.3 or whatever, then companies, Drupal shops, can say, that's worth something. I want to assign one or two developers, designers, whoever, for the next six months to work two days on this. So if we are more clear about what we're working on, so this is the handover to the core conversation with Angie and Gabor we'll be having later. This ends up in the realm of product management, right? So if we have multiple initiatives going on, then we should make sure that within each vertical, within each initiative, if we make sure that ideally for every point release we have something to show for end users. And if at times that's really hard because we do have to clean up and add our APIs first and we can manage across all initiatives and let workflow do that thing for a bit and write a cool press release or release announcement about how we're working on the field you buy for contact forms or add it even more, file entities, et cetera. This is not promises about what we're doing. No, no, no, disclaimer, disclaimer, very good, very good. This is hypothetical. Who are we doing this for? Another discussion that we are not often that clear Dries discussed persona as well and I was happy to hear that we have to focus on, you could say authenticated people in the middle, right? People who don't code but they have some permissions in core to do stuff. And we have to get a better grasp on the goals and needs of those people. And basically that means we need to find a way to do some continuous discovery of user needs. The survey is great but we should get more insights on what it means for people to have content workflow. What does that mean? I mean, if five people agree that we need content workflow, that doesn't mean we need, that they mean the same thing, right? Chris making a guest appearance on this core conversation and I had a nice idea about this. Five minutes. Thanks Roy. Thank you everybody. I'm Chris Weber, software development for the Nurtury. Like all of you who are here today, I'm very excited about the new era of usability experience. Both the development that we have in the research. I asked Roy to pitch this idea about participant-led usability research. It's an idea a colleague of mine brought up. The basic idea of it being, and how do I, okay, there we go. Oh, I did it too fast. Your laptop, I'm not a Mac user. Okay. There. The basic idea of participant-led research is that we do not come with a script. The script comes from the participant. The participant leads the usability research study. They come with or we ask them for a set of three to five different tasks that they want to go over. You sit there. You listen to them. You watch them go through the tasks. You ask very pointed questions. You ask them about their intent, what they're doing. You try to gather up all this research because it is also about what tasks that they select. It is also important in teaching you about what are the tasks that are important for this user in general. In the aggregate, when you collect all that information, you can get a lot of good information about what tasks are users finding important with their site. And then afterwards, you can ask them about if they feel of those tasks were successful or failures, and why gather that information as well. Next slide. Come on. Thank you. Why? Why would we do user-led research participant? Five minutes. We start caring about what they care about. We start reviewing the tasks that they care about. We give them the ability to control the process to feel that they have control over the research, the process, so that they can put the actions that they find important under scrutiny. And we can gather the information about what tasks are important. The idea of this being that we can create an apparatus that has... Next slide, please. Come on. Thank you. That's so slow. How do you manage? It'd be a simple apparatus. You could have a laptop with a VidCam, and that's it. So you can record the screen of what the person is using and their face because visual interaction, their reaction to specific steps also communicates a lot of things. And with this very simple apparatus, we can take it on the road. We can take it to Drupal camps. This is an idea that works at Drupal scale. We can go to the cons. We can go to the Drupal camps. We can start reviewing the people that we really should be reviewing, people who never come to Drupal camps, Drupal cons. We can whip this apparatus. We can go to clients' offices. We can review them in their comfort zone. We can go to WordCamp. We can go to Midwest PHP. We can go to usability research conferences. We can go home to your parents, to your children, and get their perspective. Perspectives we've never really tapped into before. And I don't need the rest of 30 seconds because that is it. Thank you. Thanks, Chris. The title was Approaches for Changes Big and Small. So what about the small ones? If you look at the proposed initiatives and the features that we need to work on, there's one thing. But these more systemic paradigms are design principles that we need to change, right? And one of the big, really big improvements in Drupal 7 was cutting and rewriting lots and lots of the interface text, just removing redundant, unnecessary instructions or repetitive words. Things like the interface copy, creating an update to 17 that enables that more clearer prioritization of how we present things. That restructuring of the information architecture of the admin, outside-in workflows, and all these kinds of things are things that don't have to be an initiative, that can be ongoing efforts that we can start chipping away at right now. There's probably a big initiative in the interface copy, but that's probably Drupal 9 because that hits all the things if we do a really thorough terminology cleanup and we're ripping out so much and we get such a big cascade of what we need to update in docs and code, et cetera. But next to these big features, we can start chipping away at these things as well, right? These are our discussion points. Gabor has some time available to get the whole UX team up and running. One of the things we're starting is drupalux.org. Gabor was, of course, the hero of the multilingual initiative, or at least enabling the multilingual initiative, let's say. And we're using the same approach for bubbling up the right tasks to work on. This is all early days still, so no initiatives that we found here just yet. Take a look. We're starting to tweet at drupalux. That's the post on groups. Happy to hear your comments. I booked a buff session right after this session. If we want to continue the conversation. But for now, discuss. Thanks. So a few things. I should have made notes. Maybe I remember all of them. So first thing about the participant-led UX research, we did similar for multilingual in terms of technology. It was not participant-led, but in terms of technology, we used two laptops and Google Hangouts. So both laptops, you log into the same Google Hangouts and you use one laptop as the webcam to record a person and the other laptop as the screen sharing for sharing the person's screen, and then you just record both of them. So it's really, you don't need really nothing special, no special software, no special hardware or anything, just two laptops. So very easy to do. For the initiatives, I have mixed feelings because on the one side, I really like the value in making this plan out for a year and a half, two years. On the other side, whatever we plan when it meets reality is not going to happen. So on the one side, making promises to people that may not happen at all is not good. On the other side, it's good to inspire people with these nice animations that Drew did. So we need to find the middle ground of this, maybe possible somehow, some way, some time in two years in what we can actually deliver with mostly volunteers. So I don't know what's the good middle ground there. Let's find out. I mean, who has ideas or opinions or maybe your next point. I mean, you run initiatives, so you know how big a promise you could make, maybe. So one, did you integrate it? I'm XJM, I'm one of the release managers for Drupal 8. And so talking about the roadmap, and we're always very nervous about putting version numbers next to things on slides because people, that's why I mentioned that. But one compromise that we can make is that for each upcoming minor version, for the minor version that's in development right now, we can state what priorities we have for that minor release. Those aren't promises, but those are. So if we have the combination of, for the next minor release, these are the things that we're focusing on. And these fit into our long-term goals. And here's a list of long-term goals we have. Between those two things, we can sketch out roughly while we think maybe in 8.3 and 8.4 and 8.5, we might get to these steps in core. But we don't actually need to communicate about 8.3, 8.4, 8.5. What matters is that what we're doing right now fits into a big long-term picture. So I think for me, that's the balances between the long-term roadmap and the promises that we make. The promises that we make are we're prioritizing this right now. And we have a long-term idea so that it's not so much like the waterfall, this step and next step. That gives us each minor release to go through, see what we get done, test whether what we expect to happen actually does happen, and then revise the plan as needed for the next minor release cycle as that minor release comes up. So that was, for me, that's where the balance is. Cool. So one more thing, a tiny thing. So one of the things that Kevin Olui devised is the simple English translation of Drupal. So he created that on GitHub because it was not yet possible to do elsewhere. But now it's on localize.drupal.org so you can localize Drupal to simple English. And that allows us to experiment with terminology changes or at least adjustments to text already without needing to make changes in core. On the one hand, on the other hand, it will not allow us to make, like you would not be able to replace the word panel or pane across every contributed module in every single text or maybe you could, but it's going to be a lot of work. So that's a playground to experiment with these changes that allows us to iterate and figure out what works. Thanks. Hi. I was just kind of, I wanted to pitch an idea because you were talking about how to do prototypes and we would like to see more prototypes and paper prototypes are nice too and to get them online somewhere. Right now we have the ability to do that but it's kind of not really obvious until you come to the sprint on Friday. So, Predators actually helps us with embed buttons that allow us to put the images into the issue queue. And it would be nice to actually have some tools to allow us to present those things right in like Drupal.org and that might be an opportunity for us to like get more of that involvement on issue queue instead of... So that we have in the issue queue a link that says, click here for the prototype. Yeah, or the prototypes or the... Yeah. Yeah, it makes sense to keep our work centralized in a way, right? It's, I mean, the redesign of the content creation page that happened in a Dropbox that five people had access to initially. There's always that balance between a small team that can get things done and a larger group that needs to be brought along to actually make it happen on the implementation side. Keeping references to things in the issue queues is always good. Thanks. On that note, hi, Jacob. The Drupal Association. Work on Drupal.org. Great suggestion. We'll put it on our list. So actually my question was about blocks and layouts. So with the Scotch initiative, a bunch of us have been working on that and sort of pitching ideas to help try to get that to core. We actually have a bof right after the bof, the UX bof. So that's at 345. We invite y'all to come look. I'm trying to remember what the room is, but it's as well as rooms. So it's at 345. The one question about experimenting. How do you take... So there's one thing about using text and changing the words, but what about say, we have layouts right now with layout plug-in, but that's not as little in conflict with say, regions and doing something like panels everywhere or doing layouts everywhere. And once you put it into core, we felt like in the past you are baked in. It's not like we can move backwards after we do that. How are you thinking we can try to move some of this stuff into the core conversation or the actual core functionality without actually committing to it really. So we can experiment. Yeah. So one place would be experimental, right? Experimental modules. And it would be interesting to see how we can... So example, field GUI. We want a new field GUI with all the draggy dropy form builder functionality. If we do it for field GUI as a whole, for all the entity types across core, then we're not experimenting, right? We're taking on too much work right up front and we're setting ourselves up for failure. But what if we could create an experimental module that only does that for contact forms and scope it to contact forms which right now uses the same field GUI but can we experiment with a new field GUI for just contact forms and for those field types and then see if that works and how hard it is to just get a grip or get an idea of what it all means if we want to do that for the whole thing. That's what I would love to see is how we can limit the scope of those experiments in such a way that they're still representative for the 80% of what we want to replace as a whole eventually. Experimental module. Maybe install profiles can be our friends as well. Looking for ideas there. Hi Roy. Hi Chris. That was basically the idea I came up here for. Install profiles. But actually I wanted to talk about how it seems like in the past year maybe a year and a half it feels like Drupal is kind of in a different era. There was the era where Drupal was really frustrating for me and like last year and a half ever since like the twig the bug patch landed last November. Drupal 7 has been actually really fun and not frustrating at all. And part of the reason why is because it's simply test.me. I can go and test any module. Another prototyping tool. I can show the sales person who doesn't get what I'm saying until I show them something that I can actually show them and talk about it. Whereas in the past it was kind of that same situation with Drupal Commerce with the Commerce Kickstart distribution. Now I can just roll some kind of Drupal site and it would be really great if we could not even just focus on this being an experimental module just being a module that also has an install profile or distribution so that you can go to simply test.me and demo what the new interface would be like, like the module would have all the information about the new interface and then spinning it up on simply test.me would be a way to just immediately jumping to the page that shows the thing. But that means having written actual code, right? Yeah, yeah, yeah. It would be for the third or fourth iteration for that idea. We did paper prototypes for the idea. We did interactive wireframes. This looks like the right approach. Let's write a patch and see how it holds up. Well, fixed. Looking for people to help us out, right? So one thing that I thought you might talk about was the the actual process of getting you had a slide of a circular a diagram showing like plan, build, et cetera, et cetera. But the concept that that didn't convey to me that I think is part of what's being proposed here is that designs themselves are something that that gets signed off before we start building. Instead of going like make a big patch, do a big initiative, do all the stuff through the core queue, start with a design and then test the design, evaluate whether that is a good design, get the sign-offs from the people who need to confirm, first of all, that it reflects the functionality of the that the user interface is trying to represent that sort of thing. Can you talk more about that? Yes. Well, getting sign-off from core committers, core people I think should follow after validating the concept with the intended audience. And that part we should I think we should try that's the part where we should be agile and let's say nimble, right, where we don't have to write the actual patches, et cetera, yet to know that we are heading towards the right idea. So is your question the design process how that would work? So what we know is that the Drupal core issue queue does not work well for usability specialists, for designers for that kind of work. That's one of the problems that you stated at the beginning of the session. But how do we fix that and replace that process with something that does work without further separating the design community and the usability community from the core developers who are then implementing things. And then there's also this assumption here that oh well, don't do all the work of coding until you know you have a design that works, but that's in some ways as a developer that's like coding isn't the hard part, right? To some extent coding is the way that you prototype something from a developer perspective and so how do we fix that problem so that the answer to the question might be I don't know, Jess, that's a great question . Thanks, that's my . So I agree that we have to stay in touch with the core issue queue, right? Because even discussions in groups don't get the eyes sometimes that necessarily for getting the right buy-in or sign-off on time. I don't really know just yet. I'm hoping that the Drupal.org site can help us visualize the focus and we're not going to create new content like that, it's an issue scraper so we're seeing actual Drupal.org issues there. I think I'm just thinking out loud of course I think we have issues of type plan first and then we're going to hash out what we want to achieve but also how we think we are going to know how we're going to validate what experiment we're going to run to know that we're doing the right thing. So I think there's certainly a lot of new things that are not a lot of there's some new things that we need to introduce so in some ways we are going to be able to do that. So I think there's a lot of new things that are in terms of discussions and a platform to involve as many people as possible from the existing community but there are things where Drupal.org is not very good so one of the things that's already an existing example is is Google docs stuff that we put together that's being sponsored by people so we have 100 gig for sharing our design assets etc that's one of the tools right? So there's work going on to collect like visuals and visuals for a style guide and like PSDs to start up your design ideas and start drawing digitally so that's kind of a tool that we haven't had anything like that we could use on Drupal.org so we set it up for the UX team to try the kind of tools and things that we'll promote on Drupal.org and I think if we'll figure out that the design process is in need of a separate tool then we'll do that like we'll try to use the Drupal.org site as like a hub to connect all things from posts and Google Drive and Twitter feeds So the problem for me thus far has been that I don't have any these things are happening and I don't like this Google Drive and I didn't know existed so how do we like we also need to find a way to surface that on Drupal.org so that the people who are not like I don't consider my like I wouldn't go okay I'm going to work on the usability team now because that's not my expertise so there needs to be a way that when I am doing something that impacts the UI I know first of all that these conversations are going on and that there are community volunteers and resources there who I probably should check with first communication communication communication it's true yeah so I think so many initiatives set up their own sites because if you set up your own site it allows you to aggregate issues aggregate news aggregate these kind of separate tools like Google Drive and put up your demos and put up your videos and like and then you have your own space and there is no tool on Drupal.org right now that allows you to do that at least not publicly at least not like you can set up this area where you can like put these together and then you have like visual weights for things like you can actually have a UX for your UX site like people understand that so there is something we have an account for now Emily just told me yeah mural.ly so we have an account there for setting up designs that might be useful as well I didn't get it I'm closer to the mic sorry mural.ly m-u-r-a-l it's a prototyping tool she can explain it we got access to a non-profit account for mural.ly so it can be used for remote collaboration creating wireframes, workflows all different kinds of things that we would be able to use for UX nice happy to have a look so I don't think that answers the findability or the discoverability so I think that problem I think the best answer we have so far is we set up our own site and then we put everything there and then it's a well we can post it there too so people find it we can put our posts but we'll do like we've posted a lot of things and I don't think we've posted this yet but it's still in the works so that's why we didn't do that and that is not secret and then I have a semi-related question which is so on the usability initiative website that you and Gabor put together sorry Gabor so the question is are the things that you envision being on that page so you listed a set of priorities for usability that are kind of problem number one are these problems that we run into on the initial installation for every single Drupal usability test now the known problems that trip up everyone when they learn Drupal after 15 years or whatever the other kind of usability problem that gets introduced though is that we we introduce new functionality and new APIs without putting thought into the user interfaces and so that's the other kind of usability work that we're going to be in the Drupal 8 cycle there's usability problems with core currently that we need to fix related across the board but then there's also like the content workflow initiative we were talking about this morning or layouts how do when people are involved in the usability initiative on that site does that also cross over with the usability work that needs to be done for initiatives to put new functionality in core like a new layout UI or you know content deployment for example? We should find that out yes I know that's why the Drupal UX.org site is just basically empty and has some placeholders right now I was curious to hear what the initiatives would be and where we've heard that today now we can look into none of these things except the content one are real they're all just dreams dreams people make them real please that's something to find out we have these across core issues that I think we can start chipping away on that don't necessarily need initiative but that need attention and work and how that relates to coordinating the UX designer working on content workflow yeah we have to I think we have to do become more explicit about the roadmap and we have to I think introduce some kind of weekly bi-weekly update on remember we're working on this these issues need your attention right now remember it's all towards this common higher level goal and the interface between those two things I'm curious to find out yeah Hi Roy Hi Let me get this out You have them barred Yeah I'm incognito So first of all when I get back to Holland I will talk to my design team and see if they can make up resources to help you guys because it's super important Like that, like that, yes The second thing is what we've noticed in doing big projects because it's basically a big project what really helped us was splitting development and front-end and we did this by two theories, the first is what we also told today, atomic design So for those of you who don't know what atomic design is really look into this because it's gonna make your life easier it means that you can change the CSS code over a button and all the buttons throughout your entire platform will change and you don't have to test this much and the second is that we make out of this atomic design we make the prototypes like front-end prototypes and these, this is just HTML, CSS and JavaScript and we actually test those so I think this flow of testing very early in the process and having the style guide means that if we for example make a new module or we're gonna start one of these initiatives we can always look into the style guide that's going on there, create the prototype test it adjust the lean and then go into the development process so yeah we should look into this so maybe then if we're working on the components for the front-end if you have a living style library or pattern library that's our resource for building prototypes actually we're working on a distribution we've been working for five months now on design with four FTE so they are freeing up now because we're going into development and I would love to get them involved in the project and see if we can do this because having one resource like what you say finding out this Google Docs as a project manager I know this and having one resource centralized where everybody can see what's going on, what's being tested and how this can be implemented it's going to be helpful so we will talk so I know there's some worry and some question about uncertainty for how you're going to proceed in the future but these four things that you have already started are going to help immensely and because the Drupal UX.org scrapes from the Drupal.org issues it will inherit priorities that people set on the issue even if they don't know anything about the Drupal UX.org and it will also allow discoverability through tags and stuff so this is a really good direction to go in I think it will help immediately and we should be done yeah I think so too thanks a lot welcome so if we want to talk more we can move to 291 I'd be interesting to talk about what we can do at events to do actual Drupal UX work should we be doing usability tests should we be doing workshops etc thanks for your attention