 Is that microphone for clipping on or is it just standing here? I'll just get some water while you're... I might send an email to Tristan. Did you? All the volunteers are supposed to tell you to use this thing because it's being recorded, anything. Is it working? Do I clip that on? The more you keep together, the more I have an idea whether people are falling asleep or not. No, I'll be right back. Okay, given that this is the last session of the day and the pub is apparently opening in about 43 minutes, I think we can just start. This session is about improving the usability of Drupal Core for site builders and administrators. If you want to follow the slides or the notes directly, that's the link there. My name is Antje, or ifrik in the issue queue. So, let's talk about usability. First of all, the question is, who's the user that we're actually talking about in this case? I like to talk about the site builders, the front-enders, and the advanced administrators of the site when it's actually up and running. Because to me, that's the kind of professional users. It's the people that use Drupal both as a tool and a product. It's the site builders, the front-enders, the administrators who really have to invest time into using Drupal, or the Drupal site project that has been built afterwards. And it's also the people that take the decision about future projects. If you like Drupal, if you like the site you're working with, you're more likely to say, let's do this again. If it doesn't work for you, you might go for, let's try something different. But I also think if we help these three types of users, we're also helping the kind of first-time users and the kind of hobby users. So a site builder to me is somebody who actually builds something that other people will use. It's the site builders using Drupal both as a tool as well as a product they're building. The front-enders quite often are preparing the site to make sure actual design. They're the kind of people that need to set up image, styles, display modes, all of those kind of things. And the advanced administrators are the people that will actually be using the site later. It's the content editors. It's the people that approve of user accounts. It's the people that make sure that the commerce sites are still running. So based on that kind of criteria, any site builders in the group? Any front-enders? Any administrators of existing sites? Any developers of modules, of core? Any people who think I'd rather be in the pub by now? Okay, so that was it. So why should we care about improving usability? First of all, I think it makes Drupal easier to use for us. It makes the sites that we build for Drupal much more easy to use. And it also contributes to much better accessibility. If we can get the usability right, then the step to have a good accessibility is also much smaller. And it's also actually freeing our time for making building more interesting things. If as a site builder I don't have to spend time to make approximately back-end more accessible, more useful, I can actually focus on the interesting stuff that I'd like to actually build for clients. So what I'm talking about in this session is not about the nice new big functionalities that we get into Drupal core now, like the Unami theme or the out-of-the-box initiative or workflows, layout builders. So I'm talking about the more small, gritty things that are still hanging around. So it's not about designing a new kitchen or developing a new fridge. It's turning about the fridge door around so that you stop banging your head because the door always opens to the wrong side. I'm really irritated because I've got two screens here. So a bit about me. I'm a biologist actually by training. So I'm a scientist, I'm a scientific editor, a political activist with lots of grassroots experience. I'm a Drupal site builder, especially for small NGOs. I've worked with the documentation working group and I'm now doing much more than X. So I've basically moved from documenting things to explain how things work and how they can use this to actually fixing the things. And I'll give you a few other people that are kind of representing Drupal as it is. I think some of you might all know of them, others not, so bear with me. Roy is one of the product managers, one of the core maintainers who's, when I ask him what he's doing, he says, I'm an illustrator by education, interaction designer by trade. In my contributions, I focus on visually clarifying the problem and suggesting possible solutions. This enables people to agree on what to build next. So what he's doing as one of the core maintainers is not coding anything. Jenny, who also is here, said, well, I just figured out how Drupal works through theming. And then I taught myself Ph.P. to actually build the modules I need. She's actually giving a session on the tasty backend module tomorrow, which is quite worth going to. Or informally, she said, actually, I just got into understanding Drupal by swearing a lot. Tim Milwood, a maintainer of the node module and of the statistic module and involved in the workflow initiative, was that I haven't built a Drupal site in years. So somebody who knows a very specific part of Drupal very well but doesn't know much about building a site with what he's built. Gabo, who actually did study computer science and is now much more involved in organizing things like organizing Drupal in Europe. Or Justine, who basically is currently learning about how Drupal works by reviewing the merge requests of our colleagues as a designer. So why am I telling you all of this? Because quite often we have this traditional picture of expertise when it comes to any software project or anything else, where we have the beginners at the bottom, the intermediates and the experts. Or in terms of software, the user, then the front-ender and then developer. And that makes this magical thing at the top that really the only initiative to understand. And I think in Drupal that doesn't actually work that way. In Drupal we have much more something like this, which is we have core development, we have concrete modules, we have documentation, we have event organizing to actually share this knowledge, design and theming, usability, accessibility, mentoring, translation, and also use specific project. And all of that feeds together into making Drupal what it is. All of that brings different kinds of expertise to make each version of Drupal better and more usable. So bearing that in mind, what can we improve at the moment? There's lots of fridge doors that we can deal with. The navigation, mainly the admin menu, what's where in the admin menu, permissions, fielded fieldable entities, and UI text. So I'll give you a few examples on what are the kind of things that can improve on the small day-to-day tasks that people are interacting with. So for the admin navigation, we just give you a few examples. So where do I go to make a specific admin page visible for some user? Well, you first list all user accounts and then you can go to the permissions. Or where do I go if I want to edit or translate a specific block, like the block was the opening times that are in the footer of a page? Well, first you go to the layout of the whole page and then you can go to the content of the blocks. Or where do I go if I want to see media items? Well, you go to the content page that lists all the content and then you go to the media items. So basically, we're continuously teaching users detours. We're not providing a consistent or predictable structure. We're telling them you have to remember to go from... If you want to go from A to B, you have to remember to go to C first. As somebody who has been working with Drupal a lot, we can actually remember that. But the question is do we actually want to teach that to our clients? And do we want to teach that to new users? Is that what we want to spend our time on? So there's a couple of issues that are covering these questions. Yeah, pretty much all of the points I raise actually have issues and some of them are nine and a half years old by now. With this one, I have a specific other request because Rachel and I have been looking at a way of restructuring the admin menu. For example, not having content blocks hidden under the structure of the block layout. But instead of doing yet another card sorting exercise, we're trying to see can we have a set of maybe seven guiding questions to know where everything should live. And to move that forward, we basically build a form where you can answer these questions like you can pick a page like the Custom Block Library and say, does this belong here? Or does this have this or that on the page? And Rachel said, I should tell you to bookmark it and go there because if everybody just puts a few of these pages through this system, we'll see whether they end up on the same place. We'll see whether that works because discussing it in the issue queue is very long and tedious. I'll come back to that link later. Permissions and access. Any user who, for example, needs to edit the content of a block can also remove every single block from the page. If you want to edit the opening times of your shop at Christmas, you can remove the main content from the page. That's not something I want my user to stumble into. It's certainly not in the last day before holiday or so. Any user who needs to edit a taxonomy term, for example because you have free tagging and you want to get out a typing error or so, they can change the language of the vocabulary because that's just one permission. If you can edit a term or if you can access those terms through the admin interface, you can also change the name, you can change the language settings. You can mess up the sites like that. And if you want to access a single structure page, for example the custom block library, you get 10 configuration pages without any admin items. Any of those subsections under configuration will be there no matter whether you have anything you can access there or not. That has been hanging around for nine years and seven months now since it has been reported. It means that also if I build a site for a user and I just want to let them just see the things they need to do, they still end up with these pages that they wonder about. And I would just like to be able to give them a site that just says here are your three things or your five things or whatever. There isn't anything you don't need to be concerned with. But besides it being inconvenient, I also think that the lack of these more fine-tuned permissions can actually put the integrity of our sites at risk. If a user can accidentally remove the main content or mess up the menu because they change the language, that's confusing and it's messing up the site and I mean somebody else needs to come and fix it and hopefully remember how the configuration was. Of course our permission table is already really, really long and I've been at projects where I was like, yeah, but if we need to sort that out, kind of take another day, so we just leave it. There's only three users, they're going to be fine. But remember, you're looking at this long, long table once and sort it out. The users see the result of these permissions every single time they're using the site. So again, there's a few issues for that, for example, to have more granular block permissions or hide these empty admin categories. So a bit about user interface text, because again that's something where people are interacting with the site and trying to find out what a specific page is doing. And sometimes these texts are really short and you don't really, only if you already know what it does, does the text make sense. Sometimes the text is really long and too convoluted. But we also mainly end up with the problem that, this is a quote from a developer from Dupercon in Vienna, said, I'm happy to sit down for 12 hours to write code, but I'm not going to spend 30 minutes to write a helpdecks. And the reasons for that are actually, they're quite reasonable. I don't know where to put it. Does it should go on the help page? Should that go on the admin page? Should that be the long description under the field? It's too disconnected if it's on duper.org. I don't know where to find things there. I don't know whether anybody's even going to find whatever I write there, so I just don't bother. The question is also, for whom is this documentation, this helpdecks? Are there for other developers? Are there for site builders? Are there for the end users later? We don't give any guidance to any developers on what kind of text is required where. Or also, I'm not a writer. I'm not even a native English speaker. So I don't really know how to write this. So it leaves us with the question, who should write these UI checks? And after 10 years being involved with Drupal, it's like pretty much all of us. But in a collaborative way of doing it together. Because on the one hand, I need the person and can tell me what does this module actually do? Sometimes I'm undocumented functionality because nobody has figured out that there's this tick box or that this and this happens if you do this. But on the other hand, it also needs to be people who know what Drupal can do to find out how to describe this. But not the people who already know it inside out. Quite often you find that terms are used. And the sentence makes sense except for you don't understand this first word. And therefore you are just as lost as you were before. So I think we need to put more efforts into actually looking on this text that are showing up on so many pages and find a way of dealing with that. And at the moment, I haven't got a clue how to do this best. But yes, I think it's both the developers and the users and also the feedback of users saying, I don't understand what I need to do here. It might be that they have not been paying attention but it also might be just that it's just not clear enough that this label that is so clear for you because you've been putting in the code for the last six months. It's just not clear. There is also work to just redo the whole help system. But I didn't have enough time to actually look into that. Jennifer is working on that. So I think it's in good hands. But there's more help welcome on that issue as well. And then fields. I like fields. I've started using Drupal when it was 4.7 and I've seen flexi nodes or adding fields. So Drupal agencies, wow, pretty much everything is fieldable. I can now just in the configuration make so many different things. So you end up with, you know, you have a taxonomy term which just has its name, its description, its parcelize. And then your colleague comes in or your client comes in and says, can you just add a help text in the description just to make sure people know what to put in there? And can you just always expand that relation because all the terms there in this case will either go into food or vegetable. So we need that expanded. It shouldn't be collapsed. You think, yeah, great, fields. I can do that in five minutes. And you go there and you look at managed fields and neither the description nor the relations is a field. So you're already stuck there. And if you want to change the form display, well, you can say how many rows the description should have. But for example, you can't even change the position of this relation field, let alone say it should be expanded and not collapsed. So what you said, hi, I do that in five minutes. It's like, yeah, week later and you're like, what do I do now? Similar was the author and date field. You know, a notice by default displayed was submitted by username on date. And I think the first site I built, I tried to change that. That was the 4.7 site. I'm still stuck on this. How do I change this? But in this case, if your colleague comes and you can maybe say written by or also so-and-so date, so-and-so, and you're a bit more careful and you check, yes, there actually fields. I should be able to do that in five minutes, no problem. Just except in this case, when you come to the managed display, there's no way of actually changing this. So even so there are now fields, as far as I see that in the managed fields list, I can't change them in the display. So again, there actually is an issue for that to make sure that we can now just treat the author and the creation date as fields on our display. And then something which has become a bit of my pet project by now, fieldable menu items. If I understand it correctly, menu items are fieldable entities. Even so, some of them are created, for example, by views or so, and you can't really change the name or the path. But still you can change things like whether they're enabled or disabled. In the menu item configuration, you can still change the weight. But why can't I put an image on there? I mean, there aren't that many fields I would like to put on the menu item, but I would like to put images on menu items. And if you think that's an unreasonable request, that's too hardcore. That's hard coded images on the menu items. Which means if I, because I'm building a site for a client and I need another section in there, I need to then go into the seventh theme to put another icon in there instead of just having a field. This is this icon now. So I think there's lots of space where we can also improve on just making more accessible through the configuration to users. So who's responsible for all that usability? First of all, I think developers need to be aware of how what they're building is actually used, which is actually a step quite removed from what you're doing. The users actually need to raise issues. Users shouldn't be sitting there brumbling, saying, oh, this is really annoying. I lost two weeks because I can't actually do this. Like you need to raise the issue and say, I would like this functionality or I think this doesn't work quite. So I think it's up to all of us to actually deal with usability issues. So this is not necessary usability testing with first-time users who don't know what a block is. We need usability testing with people who haven't worked in knowledge after a pile to see how often you're actually clicking around to get to a certain page, for example, or where you're struggling, where you're actually starting to write custom code just to get that image where you want it. So it needs input from all of us. Especially because I think a better UX for site builders, for front-enders, is also a better UX for the end-users. Everything that works well for me as a site builder means I can pass on something to the end-user that is more usable. Anytime I don't need to spend on getting lost or writing custom code or trying to find things, means I can spend that on improving their specific usability needs on top of what we already have. So don't work around your grievances if you come across UX problems. Help us fix those issues in core. Make issues when you see them, review them, be clear about what the problem is. So get involved. I see some faces who are definitely involved, but even if you come across an issue, report it. As a core maintainer, you still don't know where the permissions are, which is one of the issues of CatchMate, I think, a few years ago. Make an issue. We can try to solve that. We have 10 sprints. That's a very good way even for people with these very diverse experiences that I showed in the beginning. The designers, the users, the administrators. You can all come to a sprint and help working on these issues. You can review issues. You can say, yes, this patch actually works. It now does what I like it to do. Or you can say, yeah, this patch works, but not on my multilingual side. You can join the UX meetings. There's a UX meeting at 8.30 UK time every Tuesday evening, which is always announced in the UX Select channel, where we just look at UX issues, about different initiatives, about small issues, about big issues. It's also recorded, so you can also watch it afterwards if you just want to get an idea first. And yes, give us some feedback on whether we can use these questions to sort out this admin structure. A bit faster than intended, but... APPLAUSE The question was on how much of the UX problems I think is structural. I haven't actually assessed it in that kind of... But I think there's lots of underlying small structural problems that make it more difficult to, for example, the lack of permissions on blocks is the main reason why we haven't... There's an issue to move the blocks' custom library out of blocks and under content, but that's still hanging on the fact that it needs different permissions. So the small step of moving the page, that's something that I, as a Cypher, can do. But I can't fix on the fix that permission issue. So it's more that these kind of things are inter-tangled, and that every time you think, ah, that's a quick fix, that's a quick win. We can make that happen. But you'll find yourself going on this rabbit hole. So that's why also we need really good descriptions of what is the problem, what are we trying to fix, and then finding a way of doing that step by step. How do you feel your success rate... Oh, not the UX, the people looking at it, but how do you feel your success rate is at the moment how much do you feel you're actually achieving and improving as you go along, and how much do you feel you're logging on to a lot of issues that are problematic and not necessarily getting fixed through the Zoom call? Until a few years ago, I think usability was just kind of a random tag that was showing up. And therefore, when usability issues were locked, they didn't really get noticed that much. Since we now have these regular meetings and look at usability issues, it becomes more worthwhile actually reporting them. So because we look at usability issues, those kind of issues come up, those kind of issues are raised, which means it looks like there's never growing number. Sometimes the changes are small. There was one issue in there where in the early 2008 versions, when you looked at the content table, it had three filters. The filters were in a different order than the columns underneath. I realized that some states are quite a bit and move these columns around or these filters around. That's not fixed. So that's a very small fix, but probably goes completely unnoticed unless you realize that you don't have to do this anymore. There's a few other things where I think there will go unnoticed. Other things like changing the admin structure, moving the custom library, for example, will be more disruptive. So I'm not quite sure what the success rate is. I mean, it would be great to have only a few issues with the usability text. I'd also say RTBC, but that could also mean that nobody actually bothers reporting something, so it's difficult to say what the success rate is. But having these meetings already gives that input a focus on it. Do you structure it? Is there a need to organize any feeds? On Drupal.org, you can. You can take issues with novice issues, for example. Again, that depends on what the actual expertise of the user is, whether this is really a novice issue or not. For me, as a scientific writer, editing a text is something I can do late at night without too much thinking, but that's because I have years of training with that. Changing something with PHP to me is somewhere there. But for other people, issues that for me are really... I don't even know where to start can be an easy fix. So again, it depends on what your expertise is, but we definitely have novice issues that are especially taken up with the mental sprints of telling people, this is an issue that hopefully can be done in a day, where you don't need to understand the whole legacy of Drupal and Inside Out and everything. I don't know, that's actually the only one where I haven't actually made an issue yet, but I see you're shaking the head there. Yes, it would be nice, but I think the three-year-old in menu links in the same would be nice, but they aren't the same, you know. That's why you can't add the editor here. But can't I add views to them, no matter whether they're created there or coming from somewhere else? Yeah, that's exactly the thing. If you create menu links in menu links, if you do that thing, they are confident. If they are coming from use, or if they're coming from the gamutized model, they aren't, and that's why they are different. And just the ones which are content, because content is based on views and everything, you can just add it to the menu creation. I feel more like it would be nice. So that's what I mean to me. As a user, it's a cycle that looks like a simple issue that you asked. To me, actually, getting a bit of these small, witty things is very much a long-term structure. I'm the kind of person who will fix the small things before building something big and new. I'm the kind of person who makes sure that all the wallpaper is off the wall before you start painting it new. There's certainly other people who like the starting from scratch doing a completely new functionality. And I think that's great as well. But I think we need to really need to deal with getting some of these legacy problems out of the way, because otherwise we're just dragging them along and we end up just kind of trying to work around and around them. So I would like to kind of clear those up and be able to work on that basis. So to me, that's a long-term goal. But I would like to have not a single issue in Drupal 8 that was raised in Drupal 6. Well, then I will still be open one and say, can we get rid of these empty admin sections? So unfortunately, or fortunately for us, so we can just make new issues. In the, what's core, I should go into the core issue here. That's under Drupal, project Drupal. Yeah, yeah. No, if you say it's usability or needs usability of review, for example, then you put that in a text. And it really had to actually describe the issue well. I don't know whether you're all aware of, when you put in an issue, you can actually put in this kind of template to say, what's the problem? How would I like this to be fixed? Because quite often when you see an issue, it might not be clear what people actually want or envision. So you try fixing it in a way that you think is fit. That's no matter whether that's total core or whether that's your client work. If you don't quite understand what the problem is, you might come up with a solution that doesn't actually fit. Or if you know what the problem is, you might actually come up with a different solution that addresses that problem. We had a situation where, in a social space with a small bar, we had a fridge. And I had lots of bottles of beer in it. And people said we had too much beer because they couldn't find the bottles when people asked for them. So instead of reducing the number of beers, we just got a different fridge. There was a glass door and light. Now we have twice as much beer. So in that case, the question was not, we have too much beer. The problem was, I can't find the beer that he's asking for. And if we can make issues that are clear on what people want to achieve, I think then we can also solve them better. And especially with, I mean, for code, we have to see whether it works or not. We have coding standards we can test on. For usability, it's much more difficult to know whether something works or works as intended, but the intention didn't fit the user's needs. Yeah. Yeah, that's the point where you also need to do the social engineering. They're actually raving the issue. Not only putting it in there, but possibly also talking to somebody or trying to get starting on it and then ask. And anything that's tagged with needs-usability review, ever so often is getting checked or looked at by the UX meeting on Tuesdays. So if you got to that point... It has a Slack channel. Unfortunately, the IRC channel got abandoned, but on the Drupal Slack, there's a channel called Usability. I think usability. And on Tuesday evenings, you will see that either GABA or Roy pops up about half an hour before. It says, is there any issues that we should talk about? And then by 8.30, there will be a group of four, five, six people who will actually say, okay, these are the issues we're going to discuss today. So yeah, being in that channel, saying a while... And if you say a while beforehand that you have an issue you want to discuss, you will also usually get pinged on saying that whether you're around for the meeting, so you will see your IRC client or your Slack client e-ping or whatever is set up for you. Yes, any other questions? Talk about passing on benefits to the administrator. Could you say something about... I think shortcuts should be something where you can get faster to something that you can actually already get to. So shortcuts... To me shortcuts should be something that I can set up for a specific site for the... Okay, these are the main tasks that needs doing, or these are the pages I go to quite often as the individual user, while my colleague might need to go to other pages quite often. So I think shortcuts are an added bonus, something that is individual. It shouldn't be... That shouldn't be holding the main, like the relevant structures. So if we can move, for example, the custom block library into content, you could still add a shortcut to that if that's something you use often, but you still should be able to get to it through the main menu. So yeah, to me shortcuts is more like the... It's your personal things of... Yeah, they're more personal, less generally, structurally to me. I know that the add content link is in under shortcuts, but we do have an issue that is quite far by now to actually add something in the menu bar to add all types of content and media directly, so that we don't need to use shortcuts for that either. Any other questions? Any other usability issues that you have or would like to enter the list? Okay, so any usability questions that cannot be discussed over here? Okay, thanks. I'll just put it back in there, so... I feel like I did your session last year, because I recognized you, and I was on your channel, but I definitely recognize that. You did your session last year? No, I don't think so. Why did you do your session last year? I've done this session before, I think. I've done session at other places. The last one was when I first went to the camp. I knew a lot of the content stuff, but I've never been at a club. I've been at a club for a couple years, but I want to know where is that? Is that a club where you run into your head a little? I'm not big of your calling trouble. Well, they've just sent us an urgent thing that we're in for a long time. Have you got to go? Yes, I need to get mine as well then. Are you in the... are you in a club? No, no, I'm at a club. Thank you guys, I have a goal. I don't think that the humanity has actually dealt with any of the utilizations, at least not on the side of it, and they are looking at making everything really accessible, so that's something that I'm probably going to go into the other scenes, if there's anything else. I think it's really good to have this additional, but yes, we just need to make sure that we are not just kind of building something on shifting sand or anything else. I think what I would suggest is, like I said, I'm going to have my professor there on camera, so if you want to help a lot of people, so that it goes away onto their intros, and then like the work, so I had always been experienced, but it's not going to take that experience, but building a fresh interform, so I think that's a critical approach, if there's enough to call ideas here, what people can put forward ideas before they start working on things. Yeah, I think implicitly it has, because my web check is also at the weekly UX course, so ideas that I looked at by the ideas, by the web check, and Roy and Gabor are also issues, they are aware of the infinity issues, but sometimes it's also like that. I remember one issue that I was just kind of, I was catch coming by, and I said, oh, I should review it, I don't even have time, I just make a branch on this project that I'm working on and chuck it in there, which is when I realized that it completely doesn't work on a multilingual site, but when you test things usually they're more compartmentalized, you're just doing it on a fresh install, so actually having these bigger initiatives that are really trying to integrate this core from the beginning on Yes, I think that's what I think it is. I don't want it to be added through the library, I don't want it to be added. Yeah, is it, I think it's in the proper form that you run the online community, I don't know, so yeah, it's not a lot of work. Yeah, thank you. I'm sorry, I have to be... No, it's fine, showing you something that's much more... Yeah, that's what I think it is. I think it's a more... It's a bit more... It's just a bit more... ... Yeah. Yeah. I don't know if you agree with that. I don't know if you agree with that. Yeah, we should be working on the library side then. The way that I come to these situations, the way it would be better. From May, from May we're out of the bunches, from May. From Leeds.