 My name is Roy. I've been working on core UX stuff for a couple of years now. And with Drupal 8, we have new room to do things differently. And that's necessary. We're going to walk through what are some of the issues, what we came up with in New Orleans already. Let's look at some initial results and see what we can discuss about how to do things better even. Problem is we got issues. There's many usability issues and I'm now going to depress you with the list of all of these issues summarized in some high-level topics. But the gist is that it's not really sensible to do another core usability test. Well, now it's become sensible again because we made some actual changes, but test results had become predictable because what came up was things like, this is a short list of, let's say, the systemic issues in core that we have. We use difficult or unexpected words for things, unfamiliar words, familiar concepts. We don't help people find their way once successfully installed. I'll let the quotes speak for themselves. And these are actual quotes from actual usability test participants. Yeah, this is a workflow bit. People save and then go look in the front end if they manage to do what they set out to do. This is not optimal. That's inefficient. This is a bit abstract sometimes, but right now we've heard the term outside in maybe the current mental model, or at least the system model is mostly inside out. So you need to create an abstract placeholder first. Like, before I can say I want checkboxes, I have to define how I want to store the data that I want to capture with checkboxes. And then I can say, give me checkboxes for that. And people want checkboxes and then fill out, oh, that's for meal preferences at Drupal Cards. The homepage is outdated in its format and, well, may not seem like a big issue, but once a first post is posted to the front page, it's totally confusing for people. Is this the post? Is this something else? And if it leads people to feel like, oops, I broke something, that's not good. That in summary means that the standard install profile is too sparse. People expect much more once they've succeeded in installing Drupal. And this combined makes it so that people think, Drupal doesn't do much, and it doesn't let me do much once I've installed it. And this limited and kind of brittle, easily broken idea is total opposite of how we want to sell Drupal, right? Flexible, extensible, there's a module for that, et cetera. But people don't find that. And this has become predictable, right? So on Drupal 6 had it, Drupal 7 we fixed of, still a very sparse initial experience, et cetera. So we have to make some drastic changes if we want to improve on this. Drupal 7 and Drupal 8 took multiple years to come out. Now we can release a new Drupal version with new good stuff every six months. And that's our opportunity to basically ship more and do it faster. And that means we need to change our way of working, because right now we ship not so much pretty slowly. We set out at this URL, we set out Boyan, Somers, Angie, Webchik, and me wrote a big post about what that would mean. And if I summarize that, it comes to these four principles. We have to tackle the big ones. We've become risk, we became risk averse, and that's just tweak things, right? But now we have to basically, it feels UI full on if we want to ever improve it really, et cetera. Layouts, there's no tweaking things there. We have to do something that gives us something, something panels or something, something layout. So we have to tackle the big ones. We have to find a way to do that. We have to create some room to experiment. We have very high standards for what gets added to core. Basically, we have to consciously lower some of our standards in some places so that we get room to experiment in core. Because in core, things get exposed to people and we can test if it really works. It's historically been quite hard to get user faces changing, changes done in core. So we have, there's a lot of upfront work and the amount of work wouldn't be so much of a problem if it could still be shut down at the very end of it. So we also need clarity on priorities to forth where we basically decide upfront, yes, we want this. This is a good idea. We don't know yet how, but let's pursue this change or this improvement and commit to committing something of that outcome when we design it. So that was the high level principles that we seek to apply. There's a bit of process and a bit of focus to that. Found this yesterday or the day before. This is basically our problem historically. We're making the decisions while writing code and that can be very expensive in time, in emotions, in just effort wasted. So maybe not all should be done in software. This is the outcome of many long meetings in New Orleans where the brightest minds and me were together and discussing what we should do and of course this is crystal clear, but we have basically, we have to do a separation of concerns. We know this for a long time already. We just really haven't acted on it yet, but we have to separate the design or the planning phase from the implementation phase. Right now that's happening, used to happen, let's say, but still happens the same time and that's where issues, for big changes, right, issues go to 300, 400 comments and people burn out and changes don't make it into core, etc. So you have to create a way to propose a simple idea and validate that in a sense that we can come to a plan. It's the first bit and the plan, if the plan is okay, we cross the border and we can implement something. Idea to plan and then the plan is a plan for execution. That's the process. The focus should also shift a bit and this is more like a culture shift, triple, having a history and being a developer-centric tool. Yeah, come in. We have a tendency to create nice APIs and make possible, but don't really show that it's possible. That's basically the gist of the list of issues I just started with. So instead of shipping possibilities, only possibilities on the API level, we should create smaller chunks of functionality that also have, from the start, user-facing goodness in them. MVP, Minnable Viable Project. It's become, to me, many things. For us, it's now our way to scope an initial feature where we do the thing on the right and not the thing on the right. And this is process, right? It's a change. This is almost like a culture shift. We need to focus on providing good things for end users right from the start in core. Okay, that was New Orleans and we were already planning and 8.2 was on the way at that point, right? 8.1 was just out or about released. Almost six months on, and 8.2 will ship with something to place a block on your page without leaving the page. Hey, we have content moderation tools, workflow states for your content. And a first application of the outside-in principle has been committed where we have a settings tray, a right-hand side tray where you can configure and tweak settings on the page without leaving the page. Yay, us. That's actually pretty drastic. We're shipping more and we're doing it faster because this, in six months, is pretty drastic as a change for how we ship Drupal Core. Did I leave something out? Maybe I wasn't sure. There's many small improvements as well and they can have impact as well. So we're focusing on the big ones. This is good. We want to do more of it. So this is, of course, a bit high level and this is the more detailed version. You still see the same line where we move from, I want to focus on that first bit because that's where the design stuff happens. We'll all visit Gabor's session later today where we revisit the whole thing. So the idea is to have, propose an idea and do whatever you need to do to validate, test the idea with a prototype. And on completing a successful prototype, start creating a plan for how to implement it. Idea prototype plan, that's the flow that we're going through. And the idea should not be a spec or just, I think it might be a good idea because, and if this and this is the outcome when we test it, then we know it's a good thing and we're doing it for these persona and these types of users specifically. So we want to provide a space where people can just propose ideas, not a patch ideas, proposals for improvements. And the check then is, I'll assume, we'll assume it's a good idea. Do we want this in core and how do we want it to move or get towards core? Is that an experimental module where we lower those standards or is this still basically an API chunk that we want to have work perfectly right out to the box? Is experimental not a good road for it? But we created experimental as that room to experiment in core, experimental modules. But so an idea like, this is the list of ideas we have now in our, we have projects slash ideas. It's a separate project where we, where you can propose ideas. And in that queue, we work through this idea prototype plan phase. And once we're happy with that, we shall, we can move it to an implementation issue for Drupal core itself. And that idea could be something like this. This is the background for the new user facing core theme. Lowry and team are proposing, this is the context. We think this is not working right now. And we also think that this approach, this idea is the way to fix that. What do we think? One of the things is that we need to clarify who we is, right? It's product management. And we have a product manager, which is Angela Webchick. There's Dries, who's also a product manager, of course. And there's, I think, I guess, there's Boyan and I, who are helping Webchick balance, make, make some of those decisions and other core maintainers balancing all the tradeups that we have to make once we move on. But yeah, we, the idea is to have very lightweight initial effort in just proposing ideas. Do you think it's a good idea for core? It's a good idea. Sure. Maybe not for core. Have fun in contract and maybe return a year later and we can see maybe it's, it is a good idea. Those ideas need a prototype. And the prototype is just to build whatever is needed to test or validate your initial assumptions or initial hypothesis. This ideas queue doesn't necessarily have to be about UX changes. Pretty sure there are some big changes people want to make just on the code level. I'm no expert. Pseudo code, whatever mock implementation, et cetera, could also be something to prove your point and this is a good idea. And based on that prototype, we can check does it provide the value because we want to test it with the target audience. Does it provide the value to users that we seek, that we wanted to provide? And then we have to check, of course, okay, so if, and if we do this, what is the impact? What are the tradeoffs we have to make in impact viability effort, et cetera, to actually do it? And that's of course mostly part of the plan because if we validated the prototype, we then can say, okay, here's the plan. And the plan should basically be the end of the design process. So bike shedding stops. Ideally, at least we have 80% of our spec, right, because we can't cover everything because then we're not being agile in that sense, that we're not catering for insights that happen while doing it. But we have to have at least a sign off on, yes, this is a good idea. 80% of this plan makes a lot of sense. We want to do it and we want to add it to core. That means involving all the core committers and subsystem maintainers who might be impacted by it and make the right tradeoffs. And this plan would be the starting issue in core to say, let's do this, let's build this. Yeah, just to clarify again, this does not mean that every idea should go through this process. This is for pushing features that are part of larger initiatives towards core, just to be sure. Because we're making smaller changes as well. There's medium sized ones, like there's a whole new redesign of the status report page. It's a pretty isolated effort to bring some better looks to a small part of core. It will look great on mobile as well. But we're almost at 300 issues already. That's partly our own fault because this is an older issue where we took 150 comments to arrive at the design, which is fine. And we continued in the same design, in the same issue for implementation, which is maybe good as well. But this is not, per se, a bad example. It's just good design takes a lot of work, I guess. That's the point. And this is also a very well behaved issue. People are still on track, even at 300 comments in. We're still working towards the same goal, which I'm glad to see, because that also proves the point that it makes sense to have a design that you're signed off on, basically, and then start working on implementing it. This didn't make it in 8.2. The views, just the listing of the views in your system, is, well, we have two views in view here. So we looked at how can we make this a bit more compact. And let's see. This is the after. It should be a small redesign. It took us 150 comments still. So let's say this is a medium change. And I see that we're, maybe it just takes that much time, right? Which could be fine. But it would be great if we could get some of that velocity that we have in the bigger ones applied here as well. But I had a quick look this morning at all the issues, tagged usability, and that were fixed or closed as fixed. And I'm seeing that we fixed and closed, committed 50 usability changes to core in the last three months. That's not bad. That's some measure. I mean, there could be many years old issues in there. There could be small type of fixes in there. But we have momentum. I think this is a good sign. Yes. Right. More of this. You want to tackle the big ones. We want to create room to experiment. We want to decrease the upfront efforts for getting things done, for getting, for agreeing on what to do basically. And that should clarify. And we need to provide more clarity on priorities. I'm just going through, I'm ramping down summarizing. This talk should probably focus on this part a bit. We can discuss. I have some initial thoughts myself. Let's go over those. And then we can tell me which point you want to give feedback on or other questions. I'm finding that the process we're outlining is not necessarily making a good distinction between are you proposing a whole initiative? And what's the plan for the initiative? And how do you push individual features part of the initiative? I think we're still mashing that up a bit because the idea prototype plan bit should basically apply to features part of the initiative. The initiative itself should have a roadmap, I guess, and a plan itself as well. I think that needs a bit of clarification. We need to basically start doing these idea reviews and get a process in there where we, and who define who is we, right? But product management reviews the ideas in the queue and says, sounds good. Sounds good. But in core, sounds good. But in country, et cetera, so that we can make our product management decisions more visible. And so that people know what their chances are for their proposed idea. The next bit prototyping enable we need to, we always need more people, right? But we're still looking for the way to how to involve people. We have to basically broadcast to designers that these fun unpaged jobs are available. What tools do we provide? Do we let, do we provide tools or do we follow the lead of what people use? And do we do that in the scary issue queue or in the Dropbox folder, Google Drive or whatever? And all the other things have, all the envision and prototyping tools have, of course, ways to input comments. And then that feedback is not in the issue queue, et cetera. So we need to balance that. Yeah, we need to get better at validating and being more explicit. I would love if we could do like a global user testing session every six weeks and just see what's happening prototype, whatever's out there, whatever patch or prototype, just in that state, uncomfortable as it may be, just to see what we're doing. Gabor, maybe this is something we touch on later today. This is from A to B, right? From the first bit to the last. Okay, place block is now an experimental module. Yay, new things. Let's do more new things. Really up to our standards. How are we going to inspire people to make the experimental code truly core worthy and lose the experimental tag, basically. So that we can say to people, yes, use this, we will support it. Okay, that was some of the issues I saw. 8.3, we're looking to get something, something media in shape, we're having meetings at least about tackling the big ones in for media, for field dry, or whatever data modeling capabilities we want to improve. We're having meetings around sample content in core, so more fleshed out structure and sample content, etc. And many other things. But yeah, this is the current state of things. I outlined some discussion points, if you like. Open the floor. Thanks. So, hi, I'm Gabor Hoici. So I'm curious how do you think we can validate if the idea process works? Like we started this doing this a week ago or two weeks ago? Yeah. So we still need to define how to validate if it works, any ideas for how to validate if the idea process works. In the in the big post we outlined on groups at Drupal.org, our measure of success was just the amount of change we were making. Just basically, we're not changing enough. Not changing is the worst outcome. Not changing anything is the worst outcome, possibly, which is a fake metric, right? But our initial assumption, initial goal was we need to create more changes faster. Maybe we've validated that. So we look in more detail. Yeah, I think for now, I mean, we know we need change. So if we don't have changes of problem in after a while, we'll see if we still need the right because the fun thing is 8.2 happened while we were thinking about this, this place blocks, content moderation and outside in settings tray, etc. Those happened in parallel to us thinking about this, so they didn't necessarily follow this process to the letter and they don't have to. I think having ideas in the issue, in the ideas issue queue, and I think that's the point, just that we install, that we start doing this and start seeing what people then follow up on is important to keep an eye on. But this is still to be set up, regular idea reviews. Yes, yes. I was hoping Dries was going to say, hey, we need to go through these. Well, depending on the momentum in the queue, but that's also chicken egg a bit. If we start showing up every two weeks, then people will put in ideas as we find out in our now regular UX meetings. People will show up when you're available on a predictable schedule. Yeah. Yeah, I think that challenge is promoting the process somehow and I don't have good, necessarily good ideas on how to promote this process. Any ideas? Yes. I'm thinking about Contrip France, Denmark. I'm thinking about setting a setup from core to maybe Contrip, setting a set of standards. And I saw the, in the Contrip modules, you have core to Contrip or Contrip to core? From core to Contrip, setting some standards. I'm thinking about the why are a lot of people not focusing more on UX. So we want to make people focus on that. I saw a lot of the Contrip modules. There's a small security tag, small badge. Yeah. So I wonder who designed it. If we could get some standards for UX and make people wanting to look at those standards and embedding them in Contrip. Yes. So that core set these standards, then a lot of more people would focus on UX. Yes. Antje has ideas about this. Actually, the question was how do we get more focus? Yeah. Just an initial response would be we have drupal.org slash UI dash standards, which is supposed to be our UI guidelines and lack of time, lack of people, etc. That's not really well maintained. The working assumption was core in itself is the reference for Contrip on how to do this. What's in core is the UI patterns we support. But yeah. Actually, what is on drupal.org in terms of UI standards, it's also very much all over the place. There is a session tonight, this evening at five, about usability for site builders, where I actually go into those issues as well because I think we do need UI standards that people or module maintainers can actually follow. And one point I think I really like the idea of regular idea reviews. I think what also needs to go in there is the question for whom those are actually taken into account for whom we're making these changes because the general statements of people want don't actually work for lots of users because there are situations where people want checkboxes and there's situations where people don't know how the end client will actually want this. We don't have actually the people in drupal, I think. So if you can take up into the idea reviews also which persona, which kind of users is this for so that we don't end up battling our UI standards between site builders and end users and back and forward. But yes, there's a session at five about UI standards and how we could maybe improve them. Thank you. Now, there's a conflict between our session and this session. Yes. Is it? Excellent. Yeah, we need to talk because I just talked to Tatjana who said that she volunteered me to maintain the UI standards documentation. Maybe we can discuss how we find more people to do that. Just like we have coding standards? Where actually module developers can go and say, how long should my line of code be? Oh, 80 characters. How long should an explanation of my module be on the modules overview page? Whatever you want. One sentence, three sentences, there's no nothing. So there's no place for module developers to go. There is like standards or proposals on how to name your functions. There's no decision whatsoever on how you call your page or your tabs or your secondary tabs. So I actually, I would really like to have something that as a as a site builder, I don't need to figure out how the hell module developers decided to do things and then write documentation afterwards. I would actually like something that module developers need automated tests for the UI. That would be at least we should at least decide on some standards first. Yeah. Yeah, that'd be nice. Yeah, true. How have the the regular hangouts been going? Actually, perhaps you could describe a little bit about what happens at them and something. Yeah. Yes. In check out this Drupal X dot org for times and places to meet. In Euro time zones, it's a Tuesday evenings and Wednesday mornings. Tuesday evenings are where the United States joins as well. They've been going very well actually. Um, Webchik or Angela or product manager is usually around the focus per meeting changes, but we usually have like we take an hour. We start on the live hangout and we set up a quick agenda beforehand and the ideal format or what seems to work is three topics, 20 minutes each, especially when people have wireframes or designs to showcase. If Kevin has a new prototype, he shows the prototype screen sharing works very well in that sense. We can review, give suggestions and see you next week with the improvements, etc. That works really well. Sometimes we have one of the last ones was basically, hey, let's look at the RTBC ready to be committed Q and Angie basically reviewed our patches and committed some stuff live at plates are set back to needs work, but then and we post a comment in the issue. We discussed this, this and this needs work, but go. Yeah. And what we're seeing is attendance is pretty good and predictable availability makes it so that people who we didn't know show up and say, Hey, we want to work on that one. What do we do? Well, ideally you go and do it. But if we need to provide some guidance and this and this is the first step. Gabor is always around and he knows his code, so he can give directions on implementation questions people have. Yeah, it's been very fruitful actually. Yeah, check them out if you want to get a feel of how we're working there. And that's a good place to experience that recommended for everybody who wants to make a big change. Basically, you need to have availability and regular check-ins. Yeah, you already are. So I think I want to say cute us actually like Bravo for getting this done because I think this is we've moved a long way with this bringing this process in so good on you. So I guess the next thing is, you know, there are always new challenges and hurdles to overcome. What is what is the thing that's stopping you from getting more velocity now? A couple of things. I mean, personally, I would like to do more of this every week, right? Because with my experience, I can enable other people to do that thing. So it's not that I do more work, but I can help other people do more work. It's a personal goal to get some more time for this. There's a couple of things we need. We need to get better at clearly specifying what the thing is we're looking to prototype so that we can invite more designers to do this. Same goes for the step before idea review. We need to make that more explicit now, but that's right now. The next step is just we're there now. Sorry. Yes, true. Yeah, the idea is the assumption is by providing a more finished and agreed on spec, our design, people to actually implement it. We need those and need more of those as well. So I guess an attention point or something to focus on is that transition between, hey, this looks like a good idea plan prototype and it has a plan. How do we then make that transition to actually implementation and support the implementation and find people who are willing to implement somebody else's idea basically, right? Because that's also a cultural shift, right? It's not scratch your itch. It's scratch user itches, pain. Yeah. Yeah. Yeah. I think there's a lot of developers who have the same itch. They just don't know that there may be a solution for that that they can implement. So I don't think it's certainly scratching others people itches. I think there's developers who would want to help. But if we can get the word there to that we need the developers to help implementing designs, because we have designs that are just maybe right there. And if we have developed like that we have specs for developers if they're if they are available to work on things, I think that already remove some of the blockers that they would have if they want to start implementing something. And we're just wondering how to do it because we have a target to implement for. And we have people to help review their work, both in terms of code and both in terms of how it works and in terms of how responsive it is and whatever. So we have a supporting network. So if there's more people interested in solving these problems, then we need more developers as well as more designers. Good correction. And I think there's also sometimes quite a lot of small changes that needs making. And I remember at the deaf days we had something like 2040 small usability issues. Stuff like I don't know if you look on the content page the filters don't line up with with the columns underneath. It's a very simple thing that you actually see when you use the site. But as a module developer you might have not been aware of that. And we made a lot of these small issues that can be actually fixed quite fast. The moment somebody actually points them out by making an issue. So I think also by allowing people to start with those small issues that can actually already contribute to making a clearer picture on which we then can build the larger exchanges. Yes, good point. Yeah, especially for new contributors, we need one to want them to become successful sooner rather than later. So start small is definitely a recipe for success. Yeah, and then the issue there is to keep it small, right? Because if we get, I mean, there's a lot of system thinkers in our audience. And then we tend to sometimes escalate the scope of the problem we're seeing where, no, but just that filter there. Oh no, we need to improve the whole filtering. No, just that there. But yeah, we can manage that. All right. Thank you for coming. See you in 8.3.