 OK, welcome to my session, One Size Fits All. As you have seen, one size usually doesn't fit all. There's problems with cables. There's problems with slides. Anyway, this session is about usability for site builders and administrators. And I'll just start with a very bold statement. I think usability for site builders and for advanced administrators is currently neglected. But I think we can still change that. And I will talk about three things in this session. Well, I will tell you who I'm talking about when I mean site builders and advanced administrators. I'll say about why, I think. We should actually change this and some ideas on how to change this. So a bit about me. My name is Antje, Antje Leuch. I'm a site builder. I've been working with Strupper since 4.7. So that's quite a few years. But it's also very different versions of Drupal. I'm a freelancer. So I mainly build sites on my own for very small organizations or work in small teams. I'm also a biologist and a scientific editor by training, which comes in at different moments of my work. And with Drupal, I've been also working with the documentation working group. And I've been coming more and more engaged with usability in the last few months. And my Twitter handle and my Drupal.org username is ifrik. So how about you? Are there any people in here who have built Drupal 7 sites? And Drupal 8 sites that are actually in production? Anybody who has done front end or theming for Drupal 7 or 8? And anybody who's really only doing module development? OK, great. So we have a mixed back. But all of you also have some idea on what site building includes. And I'll talk you through three personas that I think are relevant. Just to say beforehand, they're never that clear cut. It's never that you really only have this one person doing this thing and the other person doing that thing. They're usually some overlap. And depending on the team or the way you're working, that overlap is bigger or smaller. So I'm going to talk about site builders, about front enders or themers, and talk about advanced administrators. So to me, a site builder is somebody who builds the websites for others to use. They're not necessarily the end user of the actual site afterwards. They're building something that others use. They often do that together with other people, like with backend developers, with front enders, with designers. They work usually with core and with contract modules. So when we talk about usability, I'm also thinking beyond core. I have my experience with how does it work with contract as well. Site builders quite often also still have to find and apply patches. So if something is broken, they usually need to figure out at least the first line of the, can we fix this before going to somebody else and say, could you fix this for me? Site builders often also have to manage configuration. And they're basically preparing the site for other users later. So when you start as a site builder with all permissions, lots of modules, you actually, in the end, should come down to a site that has a different admin interface, depending on the different roles that later use it. So site builders often also have to do the translation between the Drupal technical wording that the back end developers use and the more human versions of words that the editors, the content editors of the site later will use. So as a site builder, you usually have to know both the technical terms of this is an entity bundle, this is a this or that. But you also need to be able to talk to somebody else later to say, OK, and then you go to the People's Page and then you find everything you need. The front ender is also somebody who does not only write CSS and applies JavaScript and makes everything look pretty. I think more and more front enders also have to configure the actual site for the design to be able to put on it. So what I've seen, typically, front end developers should actually be able to do is configuring display modes, placing blocks on the site, configuring image styles. They often do that in cooperation with site builders and designers. But you don't want every time a theme or things, ah, well, actually this picture shouldn't be the large one here, it should be the small one. They shouldn't be making an issue for the site builder to move the display mode of this block. They should be able to actually go to wherever this fieldable entity is and change the display mode for that thing that they need to theme. So more and more also front enders, themas need to understand the site building part of a Drupal site. And then we have the Advanced Administrator, and that's the people that actually work on the production side, on the live side. Where they quite often manage content, they manage users, they change UI text, so they're not only changing the kind of text in nodes, but they might also be need to change the text in a block. For example, adapt the opening hours for the Christmas opening special. They might need to change messages. They might need to change the automated emails that go out when new users subscribe. They need to be able to add or disable menu items, especially for example if you have a campaign organization whenever they have a new, when content makes a new menu item, they need to be able to move that around in case it ends up with the wrong weight in the menu. Disabling blocks is something I've come across quite often. And adding forms. In Drupal 7, I've seen several sites where you have to train the content administrator to make web forms without breaking the whole thing. That's become slightly easier in Drupal 8, but still making forms as this mix between, it's kind of structure, but it's also content, at least for the content editor, it's content. So they also need to find their way around. And quite often these advanced administrators don't actually have the constant access to a site builder, especially when you build a site for a client and they might have some kind of support contract, but they don't want to pay this previous site builder every time they want to change the contact details or the opening hours. Trick do not put eyes in glasses. So outside that the site builders and the administrators who can structure their site are actually Drupal super users. They might not be the users that day to day run the site, but they're the users that continuously have to find their way through all bits and pieces of the admin interface. They're usually the ones that see way more of the admin interface than anybody else. So I've been not talking about content editors because I think they quite often have an admin interface that has been made for them with less options visible. And I'm not talking about the first time user who looks at the Drupal site and thinks, oh my god, where am I? What am I doing? I come to them later. But these are kind of my three personas that I keep in mind when I think about site builders and what they do with the Drupal site. And then we come across quite a few UX problems. So I'll go through a few of them just to give you an idea why I'm passionate about improving this usability issues. First of all, let me start from backwards. What's the result of bad usability? Quite often it's lots of frustration and wasted time. When you go around in circles because you can't find something and you think Drupal can't do this, even so I'm pretty sure Drupal can do this, but I have no idea where or why. So you end up with also unnecessary workarounds and overcomplication. Quite often if a tickbox is too hidden away, you find stuff being built or written in code to get around this. I've taken over a site at some stage where I couldn't figure out why Boost wasn't working because whoever built the site had overlocked the Drupal 6 tickbox to say comments are enabled or comments are disabled so they had hidden them in the CSS. So Boost wasn't working and I spent a whole day trying to figure out what was wrong with the caching until it turned on batik and everything became obvious. Bad usability can also lead to security problems and that's quite often what it has to do with permissions. Because the permissions don't seem to work, you just give up and say, ah, go ahead, take all of these permissions. I've seen sites where basically just to solve this problem that people couldn't get to certain pages, they just get administrator role, everything. Or even worse, they just log in as user one to run the site. And I think that's problems we have to avoid. What makes bad usability if I want to categorize it? It's quite often not being able to find things or overlooking options. It's a lack of documentation. It's because there's little documentation, it's assuming that you think you know how it works instead of actually knowing. Assuming that you know what a certain term means because you know it from another module, so you end up with thinking you know what context means. Because you have used views and there's context in there and then you use the context module, it means something completely different. And you use Skype in Drupal 7 and context is again something different. So there's lots of problems if the words aren't actually explained properly. Other bad usability comes from inconsistency in the user interface, and I'll give some examples for that. Sometimes it's hard-coded workflows. If the module developer thought, I know what people are going to be using it for, I make it easy. I'm just going to stick this together. And then you spend a lot of time trying to undo it or write some PHP that you don't understand to make it do what you want. And sometimes it's unclear requirements. That's quite often when you don't really, when it's not really clear which library is necessary or how certain modules interact. So I'm just going to give five examples for now because I think I don't want to get you all depressed. So finding pages is quite often actually my main problem. So this is a typical question on the, where the hell are the permissions? So you go to people, you think, well it must be under account settings or somewhere, actually no it isn't. It's still under people, which is a different section. I still, even when I'm making the slides, was still going to the wrong page. There is an issue for that from Ketch, one of the core committers who in his reasoning for the issue wrote, I can never ever remember where roles and permissions are when I need to find them. I get it wrong every time. Now that somebody who has worked with Stupa for quite a long time. That issue is currently stalled because even so, people agree that it's in the wrong place. There's no agreement whether it should go under configuration or structure and therefore it stays under people. This problem even gets worse. Once I've built a site, I quite often have additional tabs on the people page for staff pending accounts. So I still then have permissions and roles bundled in with that. So it's getting even worse. Another typical, luckily not so typical example is a question on where's the migrate page? When you have installed the migrate module, which is still experimental but you can install it, if you install that, that's the page you get. Does anybody know where to find the migrate page on this? Well, it's actually there. And that green message to say, proceed to the upgrade form is the only link you ever get to the migrate UI page. Again, there's an issue for that. And I think I tried to put on issue numbers for all of these examples that I give. So in case anybody wants to spend on that on Friday or earlier, there's the issue numbers. I actually asked some people in the Mandi the Drupal UK channel on how do you find the admin pages when you install a new module? And the overwhelming answer is I checked the routing.yaml file. The other option is actually installing the module with Drush and then go to the modules page and then go control left to find your module and then look on the where it is and then find out from the pass. What does that do? Okay. There actually also is an admin slash index page that lists all of the modules and its admin pages. However, that's not linked from the admin menu. So we have a slight circle there. It also does not link with tabs. Yes. That's the other big problem. We have lots of pages that are not actually in the menu, but are tabs and secondary tabs. And none of them should actually show up on the admin slash index page. And then some examples for consistency and UI text. If you get a field like this, you need to put in the pass with a slash or without a slash. Any guesses? Well, first of all, this is the field that you get with CK editors. This is the front face. So any user gets who can use a CK editor just gets this field with no indication whatsoever. And for the rest, yes, it depends. On pages, you use a slash. On shortcuts, you use a slash, but at least you have the domain in front of it. For shortcut links, you use a slash. And for views, you don't. And as you see also, all the explanation texts are all over the place. So I've previously done the screenshots in Dutch and hadn't realized it because none of the explanation texts actually were translated. So to make things worse, you then even leave the side builders, the front-enders with help texts that are not in their language even so they have a translated version. So consistency in this case would be both. Let's decide on whether it should be with a slash or without a slash. So that also, even if we can't fix it in core, at least we would give some guidance to contract modules and try to make those texts a bit more consistent so that translators can just go copy, paste, say yes, that's pretty much the same. Another question is, does deleting mean deleting or not deleting? Because this is the example from the block layout page and you see I've put in a custom block here that I placed it so it's in the header. And I don't want it there. So I go to configure and have the delete option. Delete or... Yeah. It makes it even worse. If I won't be an experienced Drupal user, I really would hesitate to click on that delete button because I don't want to delete my custom block. I just don't want to have it in the header region. Yes, actually when you click on delete, you get a warning message saying, do you want to delete this block? This cannot be undone and you click on delete and you go to a list of your content custom blocks and it's still there because what you have deleted is the placing of the block, not the block. So I think we should really, with UI text, be very strict on making sure that if we use a word in a certain way, we should always use it like that. We don't want to teach any new site builder that they can safely click on delete because it's not that bad. It does say it deletes everything, but it doesn't. That's not what we want to teach people. We want to make sure this is either removing or deleting. But I think if we can be clear on saying... Unplace the block. Unplace the block, that's... It's all over. It's all over. No. No. Okay. This all gets worse if we do it with translations as well. In any case, there's an issue for that and I think somebody already wants to work on that. Another issue I found when I was preparing a similar session for the Dev Days in Milan, learn, because I was looking for inconsistencies, and I found that if I want to configure a menu item, like I want to disable an item, I want to change the order. And I couldn't find where to actually configure the menu items. So I figured out that I have to actually click on edit menu to then get not only the configuration of the menu, like the name, the description, language, languages, and all of that kind of stuff, but also all the menu items and the tick boxes to disable them. So I was about to write an issue for that, when I realized that this is the outcome of user testing. Because in a round of user testing, people didn't know what adding a link meant. So they weren't able to deal with the links. So as a result, the links were placed on the edit menu page. They're still called links. That's the thing I don't get my head around. So we have an anti-pattern that is created by, as a result of user testing, because in general, there is a rule to say there should only be one thing on a page in the Drupal administration. So we have the configuration of the menu where any other module could also potentially add even more things. And we have the list of menu items that are actually content, because they can be added, for example, by nodes. And then these ones, unless they come out of a module, they're not going into the config YAML file for this menu. So this page currently has configuration and content on it. And the save button at the bottom saves that partly to the database, partly it goes into YAML files if you export the configuration. So we have quite a mix in there. There's a long issue, which is currently postponed, because then follow up issues to try to solve this, because the save button is kind of somewhere down there. If you have the standard administration menu, as you have here, that has about 50 items. So the save button, if you want to change the description of your menu, which is way down the page, where it has nothing to do with that visually anymore. So there's some more examples. And I just invited you to look at my slides of what my session from Dev Days. Luckily, in the Dev Days sprint, we actually solved half of the about 20 or 30 examples I put forward. So it's also actually a nice thing to do, to do a session. And afterwards, see the sprint actually working through your session. But I think for us more, the question is now, where does this bet usability come from? And I think quite often it's simply it's a lack of guidance and standards. We have lots of guidance and standards for coding. Does anybody know how long a line of code should be? Does anybody know how long the description of a module on the modules page should be? One tweet actually breaks off because quite often after 120 characters, the end of the line just disappears. And you have to click on the extent thing to see the rest. There's also modules that write something like three sentences or write uninstall information into the module description in the info file. So why we have lots of coding standards, we have lots of guidance on how to call your functions, but there's no guidance on how to label your pages or the pages and the tabs. So I think there's a lack of guidance and standards. There's quite a lot, quite often an assumption by module developers on how Drupal will be used, which doesn't necessarily line up with how it's actually used in the end. Quite often it's not enough user testing. And sometimes it's as a result of user testing when kind of one or fixes are done or so. So who's to blame? Well, I would say user one is to blame. And with that, I don't mean Dries. I just meant, I mean, anybody want to treat that? But what I mean is that the concept of user one is to blame. Because when somebody installs Drupal and especially even when they install Drupal for the very first time ever, they get this, they get the whole user interface with every single option. And then they look at it and go like, what? Where am I supposed to be? How does this work? And they get lost. And that's clear. I mean, I would get lost if I would look at this now. I started with 4.7. There was way more options, way less options. And if I wanted to need an image, I would need to install another module. So now you get image styles and responsive images and where to place them. And so I think the fact that we start with user one with everything is actually a real usability problem. Because yeah, then we come to the, we need to fix this. It's too much. So let's move things away out of the admin menu into tabs or maybe only as a link on the page. But there's no strategy for a kind of progressive disclosure. So once you've figured out how small things work, that doesn't lead you to understand how other things work. It's actually more stumbling around and clicking on a link to see that actually, oh, there's something else that might be useful. I didn't know that existed. But that's not really a strategy for getting people on board, getting people to understand how Drupal works. And sometimes when we introduce this kind of anti-patterns, like putting both configuration and content on one page, I think it even makes it harder to understand how Drupal works. So how about we would you have a user two? And I've just learned this morning that I should put this forward as an ID on the new ideas process. How about we would have a user two? Because when you install a computer game, for example, you usually have this kind of safe space where you can try to find out how not to run into a wall, how to use your tools or your weapons before everybody starts shooting at you or you have to do something. But with Drupal, we just say, here you are, here are all the dragons, here are all the animals. Get figure. But if we would have a user two with less options, that has kind of the kind of pseudo option to become user one, then we could actually concentrate. But they could start with with less that they see at the same time. And they could use that to actually learn how Drupal works. And then we could actually concentrate on making UI standards and stick to them instead of making one of fixes. And I think we need UI standards for consistent behavior, for UI texts, and for placing admin pages. So what consistency? And I think we can achieve consistency both for first time users and developers. Because it's not only the first time user that looks at this and thinks, where the hell do I do the custom block setups? It's also developers who quite often don't use the admin interface that often. And they get lost as well on the, where is this? Where do I set this display mode? So we shouldn't make one of fixes. We shouldn't introduce anti patterns. We should check whether the same problem actually exists somewhere else. If you look on the content page, for example, we see that there we have a button filter, which overwrites the standard view option to say when you have exposed filters that says apply. Now we have an issue that deals with doing this retroactively to all the pages again. Maybe we could have just fixed that in the beginning. And another thing is there are actually quite a lot of UI decisions taken and implemented. And I think we need to document them better so that other people can actually look at them and see, yes, there's a reason why the action button is always on the left. And then there's the cancel button. And then there comes the delete button. That is a pattern. But I don't think it's actually, and it's probably in an issue queue somewhere that has been fixed. But I think we should also document this kind of UI decisions. For UI texts, quite often there's lots of text all over the place. There might be on an admin page a three paragraph explanation on how this module works. Rules is trying to explain I think in one sentence how this module works. I've installed a module that very usefully made lots of videos, but placed the link to the video on every single admin page. So, or we have the uninstalled information that goes into the info file and therefore shows up on the module page when we installed a module. So this is where, where as a scientific editor, I come with the question, what does the users actually need to know where? And I think that's the guidance we can actually give two module developers when they write text. It's all blue now. What you can basically separate text into three different types. One thing is what I need to understand the concept. Hopefully only need to read that once. And that can go on the help page or the online documentation. Then the stuff I need as a reminder, and I need to read that a few times. That should go on to the admin page. That's especially when you don't use a module very often. There's some basic things that it's good to remind yourself of. Can be turned off later, but you might want to read that a few times. Yeah, that's a bit on top of the page between them, the, the menu, the tabs and the actual content of the page. That's this, that's also displayed by the help module. And then there's some information that I need to actually choose the right tick box, get the right format in, know whether I should put a slash in front of my path or not. And that's basically pretty much every time I use it, I should be able to see that that goes into the labels and the help under a field. So I think with that kind of guidance, you can actually separate lots of text to be able to place information where users would expect it. And then the last thing where I think we really need to do some work on is where do we place pages? I've been talking to people at deaf days and at other situations and quite often the answer is, I just want to have everything together, which is fine, except from everything depends on who the user is, what the use case is. And I just walk you through the blog page, because I think that's a very good example on how the concerns I'm not mean about the blog module alone. And I'm happy to work on that just. So if you go to the blog layout page, that's the page you find in the menu. It's actually, but that's clearly a page that is for site building and seeming. So you're placing blocks, you configure them, but it also has theme specific settings. So any front end developer that makes a new theme actually needs to go back to this page and put their blocks for that theme in this layout. So that's fine. It's under structure. That seems to be reasonable. However, if you click on this tap, you come to the custom block library, which when you look at it is actually content creation and editing. This is where you make a new custom block that, for example, can have something as simple as your opening times or and this is the edit button that my content editors need to go to. If they want to say, on the Friday before Christmas, we open until nine o'clock, they need to go to this page. That's the tap of the blog layout. And if you then continue and click on block types, this is now the secondary tap. You're basically back into site building again. This is where you make custom block types, for example, blocks with 23 images or blocks with entity references. It's a fieldable entity. So you have the usual manage field, manage the form display, which means it's also managing display. So that's where the front end and the theme needs to get back in. So we basically like two or three levels down and have two pages that have stuff that concerns site building, theming, but also content. So you could say, okay, it's everything together. But it also means for the content editor, for example, they have content which is under structure. That's not everything together. That means content editors have content which is on the structure in block layout, they have content which is under taxonomy if they need to edit the taxonomy terms. So on this basically comes from a site we just built, where we have a content editor. They really only need to deal with the content of different content types. All of that perfectly fine fits under content, except from they need to be able to edit some blocks, which I currently can't because they only have access to the content page and all of that. So I just need to give them some permission to edit the block. It should be easy, right? So this is what they see. Because in order to get to the custom block library, you need to be able to administer blocks, which means my content editor can just mess up the whole site and remove the main content or whatever. But they're also because structure configuration and help and that's the help about Drupal modules all come with one permission. So they get the whole configuration page. Every page will tell you you have no configuration items here. Just enable to get to this custom block library. So there's an issue for that. And that is that actually editors should be able to edit blocks. Because at least that would solve the permission issue. Because I don't want any, I don't want to give any vendor personally opportunity to move the site branding into the photo or anything. That's just, that's just not saying permission that opens all this stuff. It's the permission you could still hack the URL and go get this page. Yes. So it's about the hierarchy of the tree. Yeah. Yeah, that could that could still go to the page. And that's how we solved it as well. But there's only also there's only so many links you can put in the shortcuts. The same problem exists for taxonomy terms. We have a site where I want editors to be able to edit taxonomy terms like change how they're spelled, for example, or what, but we don't use taxonomy terms as such on the page. So the contextual links don't work. Because you could use contextual links to edit them. But they're all used in facets. So don't have contextual links. So I need to again, give them the option to get to the taxonomy terms, which means they have the option to delete them, which breaks my facets. So again, taxonomy terms are actually content. There shouldn't be under structure. Yeah, I think. Yeah, you can you can move them around. You can make your own admin menu, which I think is done by a lot of sites. But actually, we shouldn't have to. Because I don't want to spend my time moving pages around for admin users more than I need to and still not sure whether the permissions are correct. So, so to solve this, we could of course go into Epic Bike Shedding and move all the pages around. However, this is from a process we did at Dev Days. And there's a proposal and an issue and that's the issue that is currently stuck for Drupal nine. To actually say we should reorganize this admin structure, based more on personas or the use of these pages. And we should have a simple set of questions. Because even if we solve all of this for for core, we still have contract modules that come and say, I don't know where to put this. I won't put everything together. Let's just put this in the top level menu. So we have worked on that a bit. I'm basically come up with a set of I think six or seven questions that would basically say, will the page contain user generated content, but user generated items? If yes, is it related to users or other users, then it goes on to users. If not, it's content is a pages that extend functionality, like installing modules, libraries, themes, then goes on the extent does have to do with languages or translations. Fine languages. Then comes a bit tricky. Does it contain site specific configuration? Like the configuration that's different between the production site and your development site? Like, like your Google analytic keys or the settings for caching or stuff like that. Is it configuration that's actually likely to be changed by those administrators on the production site? Likely. There will always be lots of edge cases, but if it's likely to be changed on the production site by somebody, it should go into a section called administration or something like that. Does it only contain configuration? And I'm using configuration now in the wider sense of configuration management. Does it only contain stuff that is not needed on the production site? Like adding fields to content types. Shouldn't be on a production site usually. If it only contains this kind of things, or if it does contain anything that should be done or might be done on the production site, then we put it in an administration and for the rest we just see, does it have to do with the look or feel of the site? Is it team specific? If so, put in an appearance. That's where all the front enders, the seamers can find their things. Like image style settings, responsive images. The question where they look, placing the blocks per theme. And if not, it's site building. And this would probably mean, we still have to try this out again with all our pages, but it would probably mean that I don't need to give any content editor, any administrator on the production site, any of these permissions. That wouldn't just show up. So they're probably, extent wouldn't need to show up either. So we could actually, by that way, have a much cleaner admin interface where, A, people would have an expectation where to find things. I'm not saying there's a routing YAML file. I'll check there first. And it would also be guidance that could be used for module developers, for contract modules. And maybe that way we could find our way around much better. That has an issue number as well, by the way. So to summarize this, I think for usability, we actually need UI standards. We need UI standards for consistency, for guidance on how to make our UI text, and where to place pages. The question is, how do we get there? How do we have people to actually do them, to follow them, to read them? We currently have UI text somewhere in Drupal.org in several places. If we would make them, if we would make a UI standard, would module developers actually be willing to look at that? Would it maybe help you to get patches in more easily, if you could say, this is what the UI guidance says, instead of going through 30 comments on the why it should be this word or that word? And that's the kind of things I would like to discuss. Thanks. Any questions? Any confusions? Oh, yes. I can also repeat questions if you are. Thanks for bringing this topic. Very important for for the future of Drupal as a software solution, I think. I'm a project manager, so I, you know, I come from a very different background, right? And I have to be the the bridge between the developers and the clients and the teams that need different tools for marketing and publishing content. So this is such a big pain point for everyone. You know, everyone is having issues with this, and I think this is a very good follow-up on on the conversation that started with the what other CMS are doing kicking us. Webchicks session yesterday morning was a lot about how other other systems do how they admin, especially the admin, how it looks like, how that is way more lots of them are way more useful for content editors. But again, I think we also need to not only look at the content editors. So that's my lot of my point that I might just think after you, before you came in. Oh, okay. So just wanted to say that I think, you know, now having this more granular approach to how to solve that big issue of Drupal being so unfriendly for newcomers and for people that are non-developers, you know, that this is gonna, this is gonna help many of us. And I'm just gonna say something that might sound like very, you know, hard for many developers is what, but what clients see in Drupal 8 was not an improvement, actually. You know, they pretty much saw the same thing. So it's like why their experience didn't change. It was not, they were not even considered in the UI part. I'm talking just the UI part. So the editors, they only see this very narrow world and the Drupal 6 and Drupal 7 and Drupal 8, they all look alike. Not even the colors of the labels, the labels themselves is just pretty much like the same. So it creates, these things create a lot of friction with the editors and communications and marketing. And they are having more and more leverage to decide what content management system we use or what tools we use to publish content. So just why I'd say I think this is a very good, you know, starting point to address these issues. And I wish that when I bring the need to improve the UI in the back end for the editors, I wish that the developers not always tell me this is very hard. This is a lot of work. This is double the time that we have to spend in front end or you name it. Because that's usually the type of feedback I get. And I see it. I mean, it goes in iterations, in iterations and it's very hard work. Thanks. Yeah, I think this standardization, it's probably a good idea. But I usually, as a contract developer, was just look how existing modules and the core modules already did it. And then how this kind of fits into this mental model that I already made of this stuff. And it didn't really, mostly at a time when I wouldn't read something that explains me where to put the stuff, but just think, oh, these stuff, things are already there. And these other contract modules do it like this. So I will just do the same. And then the other thing was awareness, it's awareness for both the side builder and admin and then also the contract developer. And maybe one idea could be that you actually display when you're visiting a page or when you see an item in the admin menu that you actually have an icon or something that shows you, you can only see this because you're the admin or you can only see this because of some other reason. And so some of the items are marked like special permission thing. That works. So then you get an idea when even if you're logged in as a super awesome admin user, that you can see which pages would be visible to the normal guy and which don't. And for this, maybe, I don't, I think interpolated doesn't exist like more default roles for content editor and side builder or do they already exist? No, there's only one role. That is an administrator that has every single permission ticked and you can't untick anything. And because it's the only role that is available on the user account page, it's even more tempting to say, ah, you need to do something. We make you an administrator because the fact that there are different roles is hidden away under the people's page a level down. Yeah, if there were these default roles or maybe some categories where new roles can be put in or something, then as a module developer, as a contract developer, you would have to make a decision what should be the default, which permission should have these default roles or which role should have which of their new permissions. So you don't have to think about this. Maybe I should have gone into that more detail. There are some ideas on making your first Drupal install more easy to understand with things like example content. And I would think adding additional roles would be something more the yes, if we can have something an install profile that gives you a simple site with example content and some roles would make sense there. If we add more roles, I know I would end up first thing turning off these or getting rid of these extra roles because they're probably not what I need. So that's I think the idea was the if we can move the experience of the first time user and the the simple cases out of this, but give them a place somewhere else, then we could put something like that in there. And yes, I think another idea to in the help text have a line to say if you don't want anybody to see this page turn off this permission would also be a useful option. Yeah, but I think in most at least there were seven most of the sites I had the content editor and then the admin and the client where I did it I named them staff. So they don't shouldn't do dangerous stuff, but they should still do a lot of things. I think everybody has their idea on how the average site looks because that's the kind of sites they build or the kind of clients they have. And I think we need to find a way of keeping this flexibility as well as providing some kind of use cases. But lots of the UI changes I see is based on the oh but 80% does without knowing what the 100% are and so I'm a bit wary about saying this is the average case. They will always need something like this. So the issue number for adding a content editor role to Drupal's standard profile is there's an issue for adding an additional role to core. I just moved it to the idea skew. Thanks. Thank you for this presentation. I really like the rigor basically that you're dissecting our problems with. The blocks example and was very illuminating to me. And I agree that this way of like what basic questions can we ask about this feature or this functionality. Must we answer so that we can find its place is a good way to try to come to this high level framework for improved information architecture basically and text. So yeah thanks. It's really really very good. Are hopelessly outdated UI standards and documentation currently lives at Drupal.org slash UI dash standards. But I think there's some other pages where they live as well. Yes exactly and under UI standards we're collecting some documentation on the core patterns that we have. So this is how tables work. This is how vertical tabs should be used etc. It collects results from usability tests and it has some input on text UI text guidance. With the new documentation restructure that section needs basically a community owner. I'm the provisional owner right now I'm hearing from the association if people feel like they want to work on that specifically. I think the challenge for some of them is actually also to find out what the standard should be. Yes because one issue I come across quite a lot is seeing that sometimes the page and the tapped name have are the same. Sometimes they're different. Sometimes you don't really know when you swap around where you are or and there was I'd asked that previously and there wasn't really a or there's two different opinions whether it should be the same or different. So there's some things where we also actually need to take or should take some decision on saying this is the guidance. Of course everybody can decide not to follow that but then at least I should do that consciously and not just look at at some bit of core saying oh this is how you do it in core. Well okay do it like that and then somebody else looks at another bit and says oh this is how core does it. So for people interested in this what do you think is the next steps? Because some of this in if we really do this this is Drupal 9 material in a lot of ways. Yes the restructuring of the the page structure we had discussed that at death days and that was like oh don't be so enthusiastic it won't get an 8.2 but we thought no it will never do that anyway. It has now been moved to 9 but the question is could be at least do something in between like for example move some of the content pages out like the content block I've so far simply copied that view so that it's in there twice so that the content editors actually also have a blocks page on the content page on the content overview. I think we could do something similar with taxonomy terms there at least the passes that we break would be so few that we hopefully could do that still like do backwards compatibility by redirects because everything will be changed it's going to have a new pass. There's also an idea to at least make an an experimental module to say how would this look like if we just restructuring that's something I want to work on at the sprint on Friday after the mentoring which I'm supposed to actually tell you about so I want to go through to see whether these questions work whether if we apply these questions we can actually place pages somewhere and actually yeah see whether we can make an an admin menu that follows that more closely and let people see whether that makes sense to them and for the rest yeah all the smaller issues that we have I think if we can clear out the kind of small inconsistencies it becomes easier to also apply the bigger pages yeah because the smaller issues if we fix if we do small tweaks we do them without the guidelines right we do them based on consistency is a good idea right yeah we'll write the guidelines up as we make things consistent but they will would likely eliminate what principles we need yeah I was I think wouldn't it already help to make submenus accessible as like the right now I think the submenu is locked if the top top level thing is not accessible and so if we would just still make that submenu accessible even if you don't have access to the top level item wouldn't that already solve a lot of things I'm not sure what the problem is why pages either show up as tabs or menu items I think there was a technical problem but I don't know how to start or solve or but yeah I think if if you use the toolbar on the on the left as I I like to do it then you actually have even then you have more menu items visible like under content you actually see files but if you have the toolbar at the top you only have these five things and that's it and unless you click on them you don't know what's going on so yes I think we can actually already improve on the on the current toolbar Roy was asking where do we go from here I was wondering whether we sort of start with a central place with a sort of UI audit or inventory which you've already started doing in many ways and just somewhere where it's a central place we're doing an audit of all the inconsistencies where we can just refer to in every single UX or UI issue yeah I think it might be a better good idea to actually start somewhere fresh and take the things that we decide are useful instead of starting with a page that has kind of stale guidance on it I actually I did at some stage look through all the Dupal 8 admin pages to see which ones have a menu item which ones only accessible through tabs which one only accessible through secondary tabs like the custom block creation which is several levels down and which like migrate don't even have a tab or anything to go to and I didn't know where to put that even so it's a big document but yeah I wasn't quite sure where to put it and it looks scary you did you say this has changed since Dupal 7 like that some pages don't have a menu link for them I didn't look at that systematically but I know in Dupal 7 roads and permissions were even worse because you had people and permissions and roads was a tap on permissions so some things have improved and since admin pages have become lots of admin pages are views now so it's also actually easier to fix core for your specific site to make sure that pages show up where you think they should show up so there's less hard coded since we have views in core that's my that's my big improvement I think views in core and admin pages made by views because in Dupal 7 you were first when when you implement hook menu to decide which title and everything by the way I don't want to do hijack the microphone if other people want to yeah just come on I think we're going to be thrown out of the room in about out of the building in about three minutes building yeah I'll be very quick I'm coming completely from the backend module developer typing and I have automated code testing when I'm typing and it tells me if I'm meeting the coding standards and everything I was just looking at the UI documentation and there's quite a lot missing and what is there is actually really long so it's very thorough the bits that are filled in but as a module developer I'm not going to read them and so it's too hard to so because it would be more something that if I post a patch onto the core issue queue that it would be very easy for people to say yeah it doesn't meet that standard and it doesn't meet that standard so you need to tidy them up which is exactly what happens in the core issue queue in terms of code for the more bigger things then you need the detail but if it could be like checklist then might get followed when people will check it people are sticklers in the issue queue particularly in core you know so if there is a checklist it will be followed I think earlier today there was also the approval the idea that in addition to the little icon icon that says this module isn't a release that it has security security thingies maybe we could also have a have a little icon that says that okay this module follows the UI standards okay given that yes so on Friday there is contribution, oh gosh contribution sprints if you haven't sprinted before you're more than welcome because we actually there was lots of people to mentor you and we will be very lonely if you don't come so we will be helping everybody to find issues that can work on find even issues that can finish on that day and for the rest there's also the generous sprints with whatever and lots of work to do lots of usability issues to work on and lots of other issues so I hope to see you on Friday then I was supposed to show this