 Well, thanks everybody for coming to this core conversation about usability and as you see from the title we are going to talk about usability especially for side builders and administrators, and we come to that in a moment But first of all... This is my laptop. Rachel? So I'm a site builder primarily. Any code I write is usually for patches for Drupal call really, on this side. The type of stuff we're going to be talking about. I work in the UK as a freelance so if you need any work doing, give us a shout. I'm Antje, or Ifric in the Issue Queue. I'm a biologist by training. I started building lots of websites for the kind of NGOs I'm working with, and this microphone is in a weird space, and I started actually with writing documentation, and then I realised that it's really annoying to write documentation to explain people how things work when they don't quite work, so actually I'd rather improve the usability so I don't have to write documentation. So I've been part of the usability team for quite for a year or so now, and we have been talking about usability and issues about the admin menu for doing a few sessions, and I'm glad to see that there's even more people and we can show you some of the issues we still had a year ago and we still have them. But first let's ask a bit about who are you in the room actually? Who is working on core and contribe modules? Who's more side builder? Who's the front-ender or themeer? Who has to change the usability of Drupal to make it useful for your clients? Brilliant. And then we have one other question with regards to the admin toolbar that we have in Drupal. Who's using the toolbar in a horizontal line? Who's using the toolbar mainly in a vertical line? Did you know there's way more options when you put it vertically than if you have it horizontally? Which means you can actually go... You don't see a lot of these. You don't see them on the horizontal screen at the moment. You can go three levels deep without any new page load. OK, but that explains why when we write an issue nobody actually figures this out. OK, so usability. The main question is of course who's the actual user we're talking about. And in this session we talk about side builders, front-enders and advanced administrators. The side builder is usually the person who uses Drupal as a tool to build something for somebody else. So you use Drupal, but you also make it usable for somebody else. The front-ender also needs to use Drupal to actually prepare the site to match the design. Front-enders typically also need to access the display, this content type, display these fields, those issues. And the administrator are usually our clients, the users that use the website on a daily basis to do the actual work. So for them the finished Drupal site or the finished whatever you built with Drupal is their actual tool to do the work. So in the context of this session we talk a lot about the kind of more professional users, the users that have actually invested into Drupal by spending time learning it, by spending their day hours working with it. And they are also the ones that are quite often involved in the question on whether to use Drupal for the next project. I mean they are the people who have the ear of the person who is paying your invoices. They get to say whether you continue to get paid. For the people in the back just come in and sit down. There is one more chair in the front and there is space on the floor here as well. So we are not explicitly talking about the kind of first time user about the people who want to set up a website in a day or so. But we are pretty sure that the improvements we envision will also help them. But mainly we do actually talk about people that will spend their time figuring out trying to find the same page again and again, this kind of things. So what can we improve? The navigation, that's mainly the admin menu. The permissions, UI texts and UI and UX standards. Are we going to go through them one by one? Absolutely. Now, as Dries mentioned in the Dries note, there's a lot of people talking about adding new technologies there. Adding things like maybe using a JavaScript framework to make it more a richer experience doing the admin. Even if that was done, the main fundamentals need to be right. So work that continues now, even though we are using HTML to present it without JavaScript particularly, it still matters. And it will still matter even if we have the most amazing JavaScript framework in the world running the admin interface. All of the things we are going to talk about today still completely apply. So about the admin navigation, let me just give you three examples on the... Where do I make this specific admin page visible for some users? Well, you first list all users and then you go from there. That's the permissions are on the people's page, which you might know but it's not obvious. Where do I edit or translate a specific block on the page? You first go to the layout page, where the layout of the whole site is defined, and then you go to the custom block library and there you can edit or translate a block. Or where do I see all media items with media in core? Well, actually you list first all articles and pages and so, and when you have done that page load, you go to the media items. So basically what we're doing in the admin menu is we have to teach our users detours. We have to tell them that if you want to set permissions, you first need to go to people. If you want to see media items, you first go to content. If you want to change the welcome message that a new user gets in the email, you go to the account setting somewhere at the bottom of the page. So, instead of providing a predictable interface where you could say, I think I should be there. We're actually teaching people you can't go from A to B. You have to go from A through C to B. There are some easy changes for that. There are some issues for that. For example, there's an issue to actually change the content page to make it something like the structure page. So you wouldn't have to go through note content to go to media content. There's also issues about moving the permissions and roles pages to move it into configuration of the user account and not as part of the here's all users of your site. We would like to move the custom block library from block layout to the actual content because they are content entities. But in order to do that, we will also need to change the permissions because you can only go to that custom block library page to even if you want to just change the opening times of your shop for Christmas, you have to have all the permissions to move all of the blocks, to go to that tab on that page, to then have some editor type in that you're going to be close on Christmas Eve. That's not the same workflow. It also means you have to give way too many permissions to people. So we come to that later. So as an example, if you think about it, if somebody in the office at the client has the ability to change the telephone number, which is a reasonable expectation in your profile, you're also giving them the permission to move things around. If they move them around and it breaks the site, it's your fault in their minds. We know it's not, but actually it is. It's your fault, the site's broken. And coming back to the content page. You know, the content page actually acts different than all the other points in the menu item because it's actually loading a view of all nodes, which very much made sense when we moved from Drupal 6 to Drupal 7 because in Drupal 6 we had, under content, we had create content types and the content and some other things. So with the move to Drupal 7, it was decided, okay, content should just be nodes. That was fine in Drupal 7, but we're now in Drupal 8. Content is not only just nodes. Content is also media in core now. Content is any custom entity you make. But still we end up with something there. This is a screenshot from a very simple site I've been working on, that already has 10 tabs on the content page. And I can't just make menu items on the content because that page is kind of locked in. So we need to work on that. It will break some documentation that says, you find content if you click on content, but I think we need to actually accept that we break that. So this is just tabs on the content page and you have some examples. So on sites that I've built for clients recently, I've been adding entity types, which kind of new for me is great, for things like points of interest all around the world. Now, I want to have all of my content of the site in one place so it makes sense to the client. That's currently quite hard because, as you can see, it turns into this crazy mess of tabs and it doesn't make sense to the end user. One of those links is to change the whole of that content page, as it's described at the moment, to be more like structure. So what you'd have is you'd go to content and then you'd see a list of the different types of content. You would see nodes, you would see media, you would see files, you would see my custom point of interest because it's then easy as me as a module developer to add that link there. At the moment, it's kind of a mess and we need to get there. So there's an issue to actually change that. We need to communicate that well because it will mean what we want to do is encourage people to work consistently across lots of modules so that we can do that. All users care about is consistency. We can make decisions about what we think is right but it needs to be right for everything. There's more space on the floor here. People want to come in. There's still one chair here. So, yeah. Okay. Yeah, come through seriously. You can sit on the floor here and I'll try not to stand on you or anything. It's okay. It's not promising but I will try. And yeah, if you can make a bit of space in case there's any... Thanks. So, yes, as what we see when we build sites for users that it's much easier if we can provide them with something that's consistent. If I can tell them, if you want to edit something that's content, then it's under content. A block with your contact details or so should live somewhere where you can actually find it. You shouldn't have to go through other detours. So there's a number of issues that are open and that need work so you're happy to come and join us working on that on Friday during the sprint. And there's also one longer term issue. We would like to actually develop some kind of guidance for module developers to see where should I actually put my module? Because currently when you make a contrib module you can just pretty much put it everywhere. You can put everything under structure or configuration or you can make a new top-level menu item or you can spread it over the site. There's no kind of guidance which means it's also not predictable for users to find something. We don't want to go to kind of a long endless bike shedding of saying this page should live here and this page should live there. What we are trying to develop and have been discussing that in different groups since death days in Milan, I think, is if we could come up with something like five questions, does this concern users? Does this concern content that's actually produced on the production side? Is this something you actually need to access on the production side? If we can maybe find a kind of five-question pick-your-own-adventure and find a predictable way of where to place admin pages, we would probably also provide something that's more predictable for the users. And it would probably mean we could also turn off whole sections of the admin menu on the production side. Permissions and access, we'd already pointed out that there's problems with permissions. Again, let me give you three examples. Any user who needs to fix a typing error, any user who needs to edit the content of a block, can remove any block from the site. It's actually quite scary that art. Yes. I think site builders will talk to different site builders and lots of us are making a workaround. The problem is we can't move this custom block page somewhere different. I've been starting to simply duplicate that page and put it somewhere and not tell the user that they actually have this permission to change these other things and discover it because there's only one single permission for blocks. Anything you do with blocks is done with one single permission. So we can't fine tune this. It's currently done with one permission. There's an issue. They're saying that we should be changing that. Anybody who wants to edit a taxonomy term via the admin menu, for example to add images to taxonomy terms, any site where you don't have a page per taxonomy term, well, if you want to edit a term like that, you can actually change the default language of the vocabulary. That's not necessary related. I need an editor when I have a free tagging field, for example, once in a while to go in and say these two words are actually the same. I merge them or fix a typing error or add an image. I don't want them to say, this should all be in English or German, but they can. This is the page they see when they want to edit a taxonomy term. Any user who needs to access one single page on the structure, for example, the custom block library, gets 10 configuration pages without any admin items. There's only one permission that says, see admin pages that gives you access to structure, configuration and help in one go. If you don't have anything on the configuration pages, these 10 submenu items still all appear. Every single page might say, you don't have any administrative items. That means I'm providing my users with an admin menu that is cluttered with empty pages. This issue is nine years old. My experience with permissions is that the lack of not being able to fine tune these permissions means it puts the integrity of the site I'm building at risk and it's confusing the users. I can't seriously hand out a site to somebody who only needs to translate content and give them access to, maybe to remove the branding or remove the main content or so. We need to have more permissions. The usual reply is, the permissions table is already so long and so confusing. Yes, it is. I'm looking at that permission tables when I set up the site for the users. I do that once or a few times. Then I'm done with it. The editor, the administrative users that are using the site on their daily work look at this admin menu every day. Even if I'm dealing with a table from hell that goes from here to somewhere, it's still a better usability for the end product. If we can actually have more permissions, if we can have three permissions for blocks, for example, instead of just one, we should fix the permissions table. Yes, that's an issue. That's also very long-standing. It's as long as the permissions table. Yes. But if we wait for the permissions table to be fixed, we are still putting sites out where every editor, every translator can remove your branding from the site. So I think we should just live with not having the permissions tables fixed before we add... There's also a situation where you've got those conflicting issues. The thing is, we've been living with the permissions table being a bit long and kind of got away with it for probably about nine years. The other stuff was being cut out of place. It does, but because the permissions don't exist currently, and we're reticent to put them there because of the permission table, it should be the other way around. We should have the permissions, which means that we're more likely to realise that it's a proper issue with that table and do something about it. Because at the moment we kind of live with it, and maybe if we do the permissions properly, it will force our hand. More people in this room and other rooms will go, hey, let's do something about that. So how about we work on both of that parallel? We add more permissions and somebody else works on the permissions table and whoever gets first is done first. There's no reason... There might also be other options of dealing with this maybe in the... Oh, short term. Where did that go? What did you do? I'm missing a page. Oh, no. I've actually asked people on how they decide to actually set their permissions, and it's a bit like... There isn't really any kind of standards for it. So quite often we end up with a module that does an amazing amount of things, and everybody who gets access to that module can all of these things. And then stepping back and saying, ah, should we now actually remove some of them? Is an extra work, but I think it would be good if as module developers you can get some guidance on saying what extra permissions should there be? It shouldn't be just be, there's one permission and be damned and figure it out. We could, for example, say if a task is more a site building task, a task that is done before the site goes live, it might need a different permission and anything you do with the module when the site is on the production site. That would be a very simple two different permissions. You could also say if things end up on different pages, there's probably a reason for that. So if part of your functionality of the module is on one page and the other part is on another, maybe that's a reason for two different permissions because you're clearly doing two things. We could also hack something as simple as we have the bit of the help text at the top of the judgment page. Maybe we could have simply having as simple as a link here saying the access to this page is controlled by this permission and if you click on it, you just come to that permission. Now especially beginning site builders end up on the which permissions do I need to enable to get to here or there. So we quite often see in sites that are built by people who are less experienced that too many permissions are given, simply because you just want to make sure the user can act something because that's better because otherwise you get the calls or the issues on the I can't see and then you just go and say oh I give you a permission. So there might be different ways of tackling that but I think we do need them. User interface texts. That's another issue and that's text like the label on a field, the page headings, the page headings and tab headings and secondary tab headings but also the kind of blurbs on a page that explain you what this admin page does as well as all the help text or the full documentation on Drupal.org and that's a quote from a session yesterday. We find model developers and core developers saying well I'm happily sitting now in 12 hours to write this code but I'm not going to spend 30 minutes on writing any help text for it. And there's lots of good reasons for that. For example on the, well I don't actually know what to put in it. Am I making an explanation here, a documentation for my other developers? Do I explain something to a site builder? Is it something for the end user? Is it so far disconnected that it lives on Drupal.org on a white page where I've spent months and months working on this and now I sit in the front of this white page and I have to write up a documentation. I don't even know anymore what needs documenting because as a module developer I know everything inside out. I don't know which the things are that people don't know. Or it's also the, I'm not a writer, I'm a developer, I can write the code but I don't know how to write a good text that helps people along and that's even more the case if you then also have to write it in a language that's not your native language. So we have lots of UI text on the sites that are just going to end up there. We have some guidance about which words to use but they're kind of long and rambling. They're actually deaditing. So as a community we should discuss only who should actually write this documentation. How can we help those new users look at your module for the first time to maybe write a documentation that's useful for them? Also quite often when you look at a module and you're finally figured out how it works it's very hard to go back and say okay I make a patch to change this text because you continuously feel like you step on somebody's toes. Sometimes it's like even if you fix a typing error or if you say your introduction doesn't make any sense to me but it still feels like we are trending on people's toes and we should find a way of encouraging people that use our modules to actually say here's room for improvement or the other way around maybe a module developer can actually say here's my module can somebody who actually knows about writing help me with writing this text? So who are the module developers here? There was a few, wasn't there? So when you want to look for people to get involved how do you go about that currently? Do you just kind of wait for it to happen type thing? Fame. All right. It's sorry. Oh I'm just announcing across. Yeah. I'm very excited when someone comes in with a little issue and try to motivate them to help out and do a little planning on doing it. But make it nice. You don't want someone to go through a nightmare but it's like someone comes up with a little figure I think you need a figure like this but I can't write a patch yet. Let's help you out and do that. I mean the next time they don't watch it I'm already making this. Rachel can you repeat for the recording of the salient Okay so one of the things that Barthas mentioned is the fact that when somebody comes in to his issue queue he will obviously help them deal with the issue that they came with but try to take them that little bit further and engage them so that they continue to be interested in doing other things. Is that a reasonable description? Okay cool. Absolutely there's nothing wrong with having self-interest in terms of writing a a module that's okay. Okay so so who at Drupal commerce? Oh at Boyan Z. He basically told me a while ago. Could you just get to the microphone? As soon as he's speaking. So to speak on behalf of Boyan what he told me a while ago was he tries never to answer someone's question in his issue queue except with a link to a recently written handbook page that he wrote for the occasion to answer that question so we won't have to do it again next time. As a module developer how about if you actually make an issue for your own module and say this needs documentation this needs theming or this needs design how we turn the this a bit around because now it always feels on the as somebody who has done documentation you have to come to the module I don't know who needs help but what would be cool perhaps for that kind of thing is that a way to flag we need help for this on the module page rather than creating an issue many people won't look in the issue queue looking for a ticket like that but might be able to if a developer could flag in some way on Drupal.org on the module page hey I would like some people to help me write some documentation and a visual flag there so that they know the person writing the module is open to that that might stimulate people to contribute where they might be more hesitant if they're afraid of stepping on somebody's toes I really like that as an idea and there's nothing to stop you as module developers already doing that because you've got complete control over your modules introduction page however what would be nice is if it was done in a consistent manner because that way people would see it in a consistent manner and then it would come forward I think actually what I would do is turn that back on the module developers and say okay how are you going to do that how are you going to get together come up with a consistent way of doing that and do it you can do that it's going to make your life easier absolutely great you're here, you're all together get together tomorrow make it happen could make a ticket and then have some kind of icon on some kind of visual representation that everybody agrees upon and link directly to the ticket from the introduction page that way you cover both the ticketing part and the fact that it's visible but of course you'd have to be able we as a community would have to find an icon we want to use or some standard phrasing we want to use to do that I think that's one of the great things about Drupalcon is that quite a lot of you are all in one place get together, talk absolutely one of the great things about being at a big event like this is you could physically I was going to say physically grab people but that might not be quite right it's just the way I talk talk to each other, find people group of developers creating contract modules talk to each other agree, get the whiteboards agree a standard write it up I would suggest in the project Drupalorg Q would be a good place to do that agree it propose it make it happen you are more than capable and you have the authorities to do it you have the facilities to do it you just need to talk that would be amazing amazing thing to do it might be counterproductive to what we are trying here but I usually spend more time on Drupal's tech exchange than on Drupalorg documentation and I subscribe to keywords that relate to modules that are made and they are published and then try to help it because then I get the feedback either it helped them or it didn't help them and also I get to know the different use cases that people have and I get to know the documentation which I did for a module long go which is probably now a bit out at it the documentation then I don't really know who is reading this and if they understand it or not and if it relates to any use case where if the starting point where I started this thing is really a good starting point where people want to start to read or if I'm coming from the wrong direction or something and if they have some ideas and then if they actually upload a page then it's probably I'm not happy with it anyway so then it's more important that they actually explain what they want to achieve and we discussed that yesterday in a boff already as well on the that there's lots of documentation we are not quite sure for whom it actually is or what they need to know so one of the proposals was also on the maybe we should have actually a few questions that we could ask on the what does this module do does it include does it bring any new field type for example or those kind of guiding questions to actually get some documentation started for example let's talk a bit also about UI and UX standards because as I said consistency would be really great and I think in Drupal 8 we have actually included a lot of that for example the order of the cancel, save and delete button and how they should look like there are kind of standards for that but if you look on Drupal.org you'll find a page that says here are the UI standards for Drupal 7 and we need to actually see if they still apply and we should go and actually look at at Drupal.org we should actually look at our core modules whether they really all follow these UI standards because if we can make core very consistent and also explicitly say why are we doing this why do we have the add to new entity button always at the top there saying it's a primary link or it's always getting displayed in the same way then it should also be easier for contribe modules to follow that that kind of pattern, that kind of standards because we can make core very consistent and then you install a contribe module and suddenly the yes I want to delete this purge button is really big and blue and there are some other issues where you think hold on this is the other way around why is this now in one really long form while everywhere else we have several forms next to each other so if we can make core consistent we actually have something that we can point other users to for contribe modules because most users most site builders they work with contribe modules they're not only using core so we also need to make this space across the whole across the whole Drupal ecosystem we can both make Drupal core consistent but we can also write down what that consistency is it's not currently there at the moment and it hurts you I saw a good example in something that was tweeted and this is from the Apple website the Apple developer website every new user interface widget process whatever you want to call it they describe not just what it does and how to code it but they describe how to sensibly use it and what things should look like it's not it's not complicated large amounts of content it's not unreasonable for us to create and be just as good at doing this as Apple are these it's just saying put things in sensible places this bit about augmented reality well it's augmented reality use the whole screen why would you not do and it's saying reasonable things each of the kits that they do they describe what it does and how to use it as a developer all there and we can do this the only hesitation I have there is what's reasonable for one person isn't necessarily reasonable for another I was in Morton's presentation on his 11th theme and I liked a lot of what I saw that's really in some cases very different to what we're doing right now with Drupal and Drupal Core there were things I didn't like and I think I'm actually absolutely sure that there were other people in the room who had the exact same thought as me except that the stuff I didn't like they liked and the stuff I like they didn't like so we're a community while Apple is in the end a top-down company so it's easier for them to realise this because in the end there's one person who decides yes it's this way and it's a lot less obvious for us to do it I think that core should be consistent I do think that there is a danger in enforcing consistency even at core level because it might put off people as much as it helps them and I think also one of the things that we can provide is making sure that lots of the functionality actually stays in a way that it can be customised so if I don't want a certain admin if I don't want a certain menu item I should be able to just disable it that's a great thing with having views in core for example that most admin pages are views or most listing pages are views so if I need to display a certain information to my users I can do that we don't actually have to go through the what is the 80% use case for this table and fix it if we can keep things in a way that the site builders can customise it using the default tools, default widgets then it doesn't actually make any difference what kind of admin theme we put on top of it and it also means that if you build your module following these you can either put 7 on it or 11 or whatever admin themes and it shouldn't break so I would have loved to actually go through the session and say what are our UX standards how can you apply them what are the things that we are discussing in the weekly UX meeting and I still feel that we still have to actually say why do we need UI standards where do we need UI standards that live on the same kind of level and importance of coding standards I mean we have a coding standard that says a line should be 80 characters but if that would be a UI standard we would probably be in comment 267 and still discussing on whether it should maybe be in 85 or maybe 75 and said we say ok it was the old terminals that had 80 characters that's our standard it's not the only solution, it's our standard and we stick to that so we need UI and UX standards for providing a consistent user experience both for core and contrip we need to document the reasons why we're doing that quite often we have really good ideas and they're discussed and they're implemented but not necessarily written down why have we decided this what is the reason for it what might break if we do it the different way and would also help us to avoid endlessly long bike shedding and issue queues if I can say this line of code is too long it's not a question but it should just be three nouns or something like that we have a page that says do you really want to delete this thing so if we can actually point to specific standards it would actually make the issue queues more workable because at some stage you just look at an issue and think yet another comment about something that we have discussed here or there and it just goes around in circles so standards are not fixed they change over time we go through an approval process part of the community we get there and we change them and we improve them over time but at least having them gets us somewhere and then if we're finding that something is inappropriate in the future we change it we do that with the coding standards as well as it happens so we're defining some UX and UI standards simply by doing things by being the first module to do this which is not necessary we also actually document what we do I think we're getting much better and that was the governments and the UX meetings another step is on the how do we actually use them and how do we promote them and other I've been working with a module last week that was actually using a different WYSIWYG editor that was coming from some external library we think why why can't you just use the one we have why can't I point you to something and say this is our standard is there a good reason why you're not doing that and this brings us to the main question on who's responsible for usability obviously when we make when we make modules we are responsible for that but the people knowing how to write the PHP code aren't necessarily the ones or the only ones who know how to do usability testing how to write a good coherent help text they're not the only ones who can do design for example as well so I think we need to put the first of what we previously mentioned if developers can also say I've got an issue with my module that somebody should help we currently have all our issues in this kind of silos of core and this contract modules we don't really have issues that are more for the cross cutting expertise if as a designer I want to help with some visual improvements I wouldn't need to go through individual modules for usability we now using one of the text that kind of adds up as the kind of free for all and we look at anything that's tagged with usability but that is a really big mix of bags as an accessibility expert it's difficult to say which issues are, who needs help so it feels like we should actually more actively have these issues help us use this text and maybe change the issue queue to also have something where you could say okay I'm on this cross cutting expertise who needs my help that's a long term plan so who's responsible for usability well who's responsible for usability well you are everyone I don't know if you've seen this picture yet it's every single person in this room influences what that is so make sure it's done right who here has not tried to do any changes to interface text et cetera and all those type of things before anybody who's never tried to do any of that now you've all got involved in changing Drupal core interface stuff before really? or modules of a client's project forget client's project so who's tried to do anything on Drupal no one anyone not done that who hasn't who hasn't who can't remember but actually I think it's also a good point every time we repeatedly change something for a client's site it's something that probably should actually be fixed upstream and core I had one of these small issues on the content page that lists all the content on the node page it had three filters on top of it the title, the language, the publication et cetera and I realized that some said that for every single project I was moving the filters around so that they would line up with the columns underneath and at some stage I thought that's silly it's actually a patch that because it's a view as a site builder I can actually change that I can change that it's a Yamel file it's a patch in core that's simply a Yamel file that changes something so that I don't have to do this with my projects anymore which means some other site builders don't need to do this anymore either so I think everything that as site builders we repeatedly do to make it workable for our clients is probably an issue that we should try to fix upstream for that we also have the sprints on Friday but I think I mean really you can be involved in this you can do this stuff you can save yourselves having to do the same changes for every client side you have that capability it's an enjoyable experience it's an enjoyable exercise as well for those in the room that have never written a line of code in their life or used git you're the best people in the world to have things like code sprints contribution sprints because you can ask the questions and sit with someone who can turn those questions into a change that makes your life better that's why you need to work together and I think that's where we stop talking we have about 15 or 20 minutes for discussions I suppose the people sitting on the floor might now need to get up but I'm going to tell you something I'm not that tall can you hear me otherwise come stand here it's higher no thank you you don't have to leave does Drupal have the ability to do some sort of style guide in a usability sense you were talking about X line of code or whatever could you do some examples of good examples and have that as a public facing page for people it's very old it's a Drupal 7 but it is old and needs updating and you can do it I didn't mean that people need to leave I just meant that they need to make space for the microphone no actually there is an idea for together with the accessibility initiative to actually go through a few pages and check whether they fit all the accessibility standards but also our UI standards that we then can say okay this is a kind of gold standard admin page and kind of work our way through that so that you have a few reference pages to answer for the recording the question about the style guide for core interfaces if you look for search for human interface guidelines on Drupal.org there's a very outdated handbook page that has that so that would be the place that we would want to update and find a way to make it more obvious so that people like you who have the question I wonder if can find that instead of knowing in the back of their head that if once upon a time if you typed HIG, HIG, question mark and IRC like that was the only way I knew to find it so obviously it's not very discoverable. With the documentation pages got rearranged on Drupal.org so there now is a page that has this kind of documentation and that actually has the coding standards on the same level as the UI standards and in preparation for this Drupal corner I actually made a big meta issue to say that we need to go through these ones to have the human interface things in there to have screenshots from Drupal 8 to have a comparison on how should this look like and so yeah that's work that needs pages that need updating and therefore work that needs done yeah back to the thing we talked about the permissions and the long list and so on I have worked with a client and I'm going to do this out, maybe someone can see if this will work for core or if there are some application for it but we had a customer that has like 10 different roles and the roles are put on users by subscriptions, they have kind of automated flow for that but what subscription should be allowed to see and use was kind of determined by the permissions and we have this kind of functionality we call it monitoring where you could monitoring different taxonomy terms by flagging them and when we have an overview page so in order to have that functionality you actually need three permissions you need the flag and flag and also the permissions for the page overview page so when we have like 10 different of this kind of functionality that the business has kind of requirements on the CAO kind of changes mind about the subscriptions weekly so we ended up doing this kind of grouping of permissions so I have a separate page did a hook where different custom modules can define a set of permissions needed for this functionality so then you have this overview page where you can say enable monitoring and it will enable those permissions for those rules and then if you disable or remove the permissions it will move all of them and it can also check if you have two or three permissions you maybe need to fix this it's just an idea maybe something like that for like administrating taxonomy terms what permissions do I need to do this or if you need this kind of like kind of some of wizard or groupings or yeah I have not think that through but I think that could be one way to solve these problems with a long list of permissions yeah there are things like that especially if you're talking about things that are repeating so you've got lots of entities and you need separate permissions for each my immediate thinking on that would be use the group module and put the taxonomy terms in the group modules and assign them to that and then you could use the permissions per group would be something I would consider I don't know I've only had 10 seconds of hearing about the project but yeah The problem comes that users have subscription time so they should go in and out of those groups one suggestion I have for if people want to go to the sprint Friday I think you're proposing that one place to start would be this audit to go through core annotate screens if people are interested in that I think that would be a good place to start the sprint on Friday because if you have a plan for that this is a non-technical work right this should be easy to contribute to should be easy to divvy up the tasks etc so just to make it more concrete and specific that could be a good point to start the work that would be really nice if you had someone who people could head towards really that would be nice wouldn't it find and chef The usability table will be next to the accessibility table because I think we're trying to pool resources there because for example auditing pages is something that we don't want to develop nice usability patterns and then have the accessibility people look at it like that doesn't work or they develop something different parallel so there's a certain overlap as well and which is why I'm really glad to see that there's so much interest in accessibility so we can piggyback usability on that a bit as well I'm really really happy to see that this room we had a point where there wasn't enough people to sit on the floor which is great because there's clearly an interest and this is something that you clearly care about and the next step is taking that out of this room and doing something about it I think really our talk hasn't doesn't fix things it raises questions we need you to fix it and it doesn't happen by magic it doesn't happen by somebody else fixing it it only happens if you fix it and you do that together so where do people go after this week where do we find they join us on IOC or Slack or if we ever bridge it on whatever matrix they also sorry if you have who has already plans for next Tuesday evening at 9 o'clock what is time zone European standard summertime zone only one which means the rest of you can all join us in the weekly UX either IOC meeting or Google Hangout so that's a weekly meeting that's on every Tuesday evening in Europe in US it's in the morning I think for the rest also go to your local camps, go to your sprints go to the issue queue and if you see something that doesn't quite work make an issue for it because we can also only fix the things that we know that are broken or that know that could be better first look for an issue yes but yeah this is also especially to the site builders that think we are just using this and we are cursing something that is on the wrong place or turn that cursing into some productive energy and into changing it really good to see you all and really engaged actually some of the questions have been really great this is the moment when the laptop will die of lacking electricity the bus is about to run out what's up my session last year no ok so there were massive and also this thing didn't work it was like my here is my notebook it's got HDMI so you don't notice where there is things on it the conversations I'm getting I'm showing you just getting it so I'm just pulling this line and everybody would find and after a while this is a direct HDMI