 Okay, hey, what? Maybe you're right, thank you. Good call, B Dragon. All right, hello everybody, and welcome to the session on Drupal 8's usability. So we're gonna run through some stuff about how we did usability testing in the University of Minnesota back in the day. This was back in June, I believe, it's all a whirl. And then talk about how we're gonna make our product better based on that feedback going into the future. So I'm Angie Byron, I'm WebChick. I work for Acquia and the Office of the CTO, and my job is to make Drupal awesome. Hi, I'm Lewis Nyman. I work as a designer and a front-end developer for Wondercrown. I've been involved in contributing to call for maybe four years. I maintain the seventh theme, which is the admin theme that ships a Drupal call. I also maintain all the CSS because no one else wanted to do it. All right, well, I'm Boyan Somers. I'm a youth experience designer. I use intelligence in the Netherlands, and I am the UX maintainer of Drupal 7 and Drupal 8. So yeah, deal with all of the UX thingies. And yeah, it was one of the organizers of the actual tests that we did in Minneapolis. So I will, wait, what, it doesn't work. I'm pressing all of the buttons. All the buttons, that's a lot of buttons. So this will be our one slide. Yeah. I think you do have to have it on that one. Yeah, there we go. The focus is on. Okay, all right. So we spent about a week in a dark basement in the University of Minneapolis, which is their usability lab with this team. So we have kind of contributors from all over. We have people who are working in the kind of Drupal core development team, and we have kind of a few locals that came from Minneapolis that also kind of participated in kind of organizing, but also observing all of the sessions. And this was supported by, well, the University of Minnesota. They kind of supported us with providing us with a lab, but also providing us with a moderator. And yeah, we have a few sponsors. So the camp sponsored us, Tag 1, Triplo, 10.7, Wunderkraut, and Akia, all sponsored, either they're the time of their employers, employees, and yeah, just funds to make it all happen. So to give you a little bit of insight into what we kind of did, we spent time in a lab. And a lab basically allows you to see the participant use Drupal while you're kind of in a separate room. So it allows you to kind of see their behavior, but still be kind of relatively close. So they have like a one-way glass, kind of where you can see them, but they can't see you. And there's kind of a neutral facilitator. So Nick, who is the kind of moderator from the University of Minnesota, they kind of helped us run the study. So he was kind of that neutral voice that didn't really know Drupal, but just allowed him to kind of play that role in the study itself. And basically we allowed people to do kind of various tasks with Drupal. I'll go a little bit deeper into that in a little bit, but essentially what we do is we give people a task, and we ask them to kind of think out loud as they're carrying out that task. Kind of tell us what they're seeing for us to understand the top process that goes behind choosing to go in one part of the Drupal interface and not go in another. And during the test, we actually tested both on mobile and on the desktop. With mobile, we tested kind of the contents creation experience. And what we also did is during this testing, we actually had like a WebEx livestream, which allowed people from other places to kind of listen in and watch the sessions as they were going on. So why are we actually testing Drupal 8 now? Well part of it is actually kind of evaluating what we've done so far. So to kind of understand whether our assumptions and expectations that users have when they start up Drupal 8, that they're actually kind of correct that we're aligning there and that we're actually validating the kind of improvements that we've made that they're all actually making it more usable and not making it harder to use. And we're also here to kind of identify issues that could still be addressed before release. We're getting really close now. Back in the day in June, we still had a couple months to go. And we also want to kind of explore the ideas that we have and the big issues that could potentially be addressed after release, for example in 8.1 or beyond. So in terms of methodology, I think this is always kind of important to kind of emphasize is that we invited seven people, either with kind of front-end experience or back-end experience, but there were all kind of web professionals. Five of them have used Drupal 7 before and they're all experienced site builders. So they either used WordPress, Joomla, they knew how to code in either HTML or PHP or well, all of it. And I think we selected a bunch of people that were really smart and should actually be able to use Drupal. These people, they have a background that should allow them to be able to use Drupal effectively. So we presented them with a few scenarios to use kind of to kind of go through Drupal. So we had kind of the following tasks, kind of starting off with something that's relatively kind of, you know, kind of core to the content creator experience, the content management system is to just create a piece of content. I think we all agree here, like that's something you should be able to do if you, you know, run up Drupal. And then the next task was slightly more complex, but kind of still in that realm of kind of the content creation experiences to add that kind of page that they've created as a link to a menu. And then you can already see there's kind of multiple ways of doing that. And from that on, we kind of started to gradually go into the more kind of site building type tasks. So, you know, creating a content type, then creating a session. And it's going to be good to give here a little bit of background. We asked them to create kind of a conference website. I think for the, like Mississippi River, that was kind of our context, very appropriate there. So to create a content type, and then to create a session, which was kind of the content type that they then created. And then basically go to the mobile phone and also create a session. And then on the mobile phone also try in place editing, which we introduced in Drupal 8. And then the last task was to actually place an existing block that they've already had in their install to actually place that on a page. And if people got stuck, we had a helpline. And we had a phone there. So people, if they really got stuck and they didn't know where to go, they could call the helpline. And that would either be a man by me or Angie or Lewis or the other people in the kind of observation room. Sadly, we don't really have a help desk. When you're using Drupal, they can't call anyone. So that's a, well, that's a challenge. But this is kind of to give you an insight. What we're doing is as we're kind of doing those sessions, we were writing down all of our notes. And we're kind of going through them after that. So at any time we had like between like eight or 12 observers, we had quite a lot of people in the room making notes. And the process that we took is well, we made our notes and then we started to kind of collect all of the insights that we have and kind of identify the issues that we saw. So the things that didn't go well, but also the things that didn't go well and kind of categorized them into kind of sensible categories. So kind of, you know, field admin or kind of default install or content types. Like there's loads of kind of different categories that we could identify as people are moving through the administrative interface. So we identified them and then we started to kind of score how often they actually occur and how critical these issues are. Some issues are, you know, they're kind of stumbling blocks, something that people go like, ah, I don't know how this works. But then they can kind of get over it and can kind of quickly move to the next thing. Whereas other issues really stop people in their tracks and make them not able to actually continue using Drupal because they just don't know how to resolve that issue. And after that we did this part which is actually coming up with suggestions. So now that we've identified the issues we know how critical they are. Do we have an understanding of potential solutions that we see that could solve this? Some of them being relatively easy solutions like changing a label or just moving a few things around whereas other things might be really hard and kind of requiring a revamping of the whole system. Yeah, and basically all of this happened in the basement of the usability lab of Minneapolis. So that's kind of a process that we took to kind of take us to the testing and Andy and Moose will be talking about the results. So first let's talk about what was working well because some things really did work well and that was good to see. The first was mobile. Even if people hated Drupal by this point they were super impressed by how Drupal worked on a phone. They did not expect that. This is a before and after in Drupal 7. If you have the mobile toolbar it sort of wraps and crunches up and all of a sudden takes up a third of your screen size. Everything scrolls off to the right. This kind of a thing and that's how they expect things to work these days. However, Drupal 8 looks sharp on mobile. It's got the nice little icons on the toolbar and everything is stretchy and it all fits really nice and it flows well and even features like in place editing and that kind of stuff work on mobile and people like that blew people's minds. So that was really, really great. Another thing that worked really well. Well, it didn't work great but it worked two expectations was with Wig. They had some problems pasting from Word but they also knew they would have problems pasting from Word and so they cleaned those up manually. The good news is we've recently updated to a newer version of CK Editor which fixes all of these problems. So that problem's addressed but they were able to instantly see, okay, I know what this is, they were able to add images, they were able to do all the things that they needed to do and then when it didn't work as expected they knew to flip into view source mode and edit things there. So that performed great. Content preview people really that performed way better than when we did this test in Drupal 7. In Drupal 7, if you'll recall, when you preview something it shows you your content twice in your admin theme which is so helpful to know what it's gonna look like on the front end. So in Drupal 8, we've revamped the content preview to actually show you what your site's gonna look like or what your content's gonna look like on your front end theme. You can switch between view modes easily, it's awesome. Everyone was able to get the previews, see what they were doing and instantly go back. So that was really good to see. Another thing that worked amazingly better than in previous usability tests was the ability to add menu links in Drupal 8. We made an adjustment, two big adjustments to the menu links UI. One is you can create links to things that don't exist yet which is huge if you wanna build out your IA before you start adding pages. This is a functionality we lost in Drupal 6 so a lot of people don't remember that Drupal used to do this. Another thing that we do now is we have an auto complete field so you can type slash user if you wanna link to that path but you can also type A, B and start filling out about and it will automatically auto link to nodes. And that was great, everybody could find their way around there. They had some other issues getting into that UI but once they found their way in it was really really great. And the seven theme, we've done a bunch of revamps to the seven theme. Back in Drupal 7 we had this problem where the really important things to get into other parts of the UI are over here on the right. And nobody looks on the right. And so people would get to a UI and miss the tab over on the, sorry, right for you guys. That told them the next thing to do and so they would wander around the UI completely lost. In Drupal 8, this looks much much better. Everything's on the left, the visual hierarchy is very clear so all the hard work that Lewis and others did to revamp the seven theme in 8 to be really really slick and nice looking and coherent. That seems to have worked really well. And then another thing that we added recently are accessible form errors and we weren't sure if this was gonna confuse people or not cause it's quite a bit heavier than the error messages we saw in Drupal 7. The advantage of these is that if you can't see the screen to see where red fields and asterisks and stuff like that are there's little jumpy links that will jump you directly to the field with the problem. And we found that people had no issues with this when they encountered an error, they just went past it, they were able to do things, it was really great to see. And that's it. So thank you everyone for coming to our talk and you know, wait, why are you coming up here? But no, no, don't do it, no. Are you sure there's nothing left? Cause I haven't said anything yet and that doesn't usually happen. Okay, oh, I'm sorry. There's been a misunderstanding. We have a few more slides to talk about. Just one or two. So there were a few things that we found that didn't work so well and because I got the short straw I have to present all the depressing things. But I'll just give you like a broad overview we won't go into everything because, you know, lunch. So Drupal uses very weird terminology and this came up in almost every participant who tested or who participated. So one of the things that they said was that in WordPress you don't have to figure out how to place your block inside your view, inside your region, inside your homepage. These are all concepts that people don't understand coming into Drupal. And at some point we expect you to figure out how to what these mean and what they're for. So those people just got stuck initially cause they didn't understand what a region was and they didn't understand what a block was. They also said they were also looking for HTML style terms. So we had quite a few people who had some understanding of front-end development techniques and the building blocks of the web. So when we asked people to look for or add form elements to a content type they were looking for a dropdown, they were looking for a checkbox and those words don't exist when you're building up content types and fields and stuff because it's based on the data structure. It's not based on how it's presented to the end user in the form. And that's the kind of way that people were thinking about it, so this really checked them up as they were going around Drupal. So a checkbox is a Boolean value. Yeah, that. I'll get to that, I think. That came up again. And also, yeah, it depends exactly. It depends on your data structure and what you allow people to select. Someone also said that if all you use is Drupal you're not gonna be able to use any kind of website. And it's amazing how people who aren't familiar with the community, they kind of, they see our problems really easily and stuff that we've been trying to deal with for a long time. So how do we fix this problem? Well, this isn't an easy thing to fix. It's probably something that we would have tackled already if we could have just fixed it with code. So what we wanna do in the near future is maybe add an introduction to Drupal. So when you install it, it would give you an overview of what Drupal does. This is what a region is. This is a block. You put blocks into regions. And this will be a way of onboarding people into how Drupal works and so we expect them to figure this out as they go. And this will hopefully remove some of the initial blockers that people have just figuring out where to go to achieve their tasks. But in the future, we wanna fix the real problem. The real problem is that we're using these words that people don't understand. So we wanna conduct a terminology review. We wanna ask people to describe what they think they should do and what they think they would call it. So a good example would be the views module. Maybe we'll change that to the list module or some other suggestion. But these things take time and they break all kinds of things. So this isn't something we can do until Drupal 9 I expect. So one of the tasks that we ask them to do is to place an existing block into the UI and put it into the front end somewhere in the sidebar. So we just ask them to add a block of recently registered attendees to the conference and have it appear on the homepage. So the first thing people did because they have this mental model looking at the front of their site before they look at the back is they went to the homepage of their website and they thought, how do I add something to you? So they're clicking around, they saw these contextual links over the existing blocks and they thought, oh, this is a sidebar. Maybe there's a way I can add something there and there's no way to do that. So this was an initial problem they had. They didn't realize that they had to go to another page to find where they would place it in the block UI. I actually have a video of this of one of the participants trying. Oh, wait a minute, sorry. Things moved around. There we go. Yeah, I think this participant had Drupal 7 experience. Yeah, one of the differences is that we no longer place blocks at the bottom. I had to speed this up quite a lot because, lunch, you actually managed to create. So we have one way glass that's soundproof which is really helpful at this point in time because we're kind of shouting like, it's just over there on the right. Please just look over there. All right, that's fair enough I think. Okay, so there clearly are some problems with this page. So what we did in Drupal 8 is we redesigned this page to support the fact that blocks are plugins and what that means is you can place multiple instances of a block as many times as you want in any regions you want with any configuration. So if you use the context module before to put blocks in different places, this is now supported in Core which is great but we had to change the UI because we just used to have the blocks at the bottom and then you would drag them around to where you want them to be but if you can have a limited number of blocks, doesn't work anymore. So we designed this right hand sidebar that lets you place blocks wherever you want. But the thing is like almost every user, I kind of saw the page like this, they didn't actually see this right sidebar at all. And this actually makes a lot of sense because what we did on the content creation page is we added a right hand sidebar which actually speeds up the content creation process because what you're saying is that the stuff on the right hand side is less important than the fields you have on the left hand column. You have like metadata and URLs and stuff and it's not as important as your body field, your image tags and all that stuff. So when we reused this pattern here, we were kind of saying that this stuff on the right hand side isn't very important but actually it is really important. It's the primary purpose of the page. So something else that a lot of participants try to do is once they got to this page, they went to the region and they're like, okay, so how do I add something to you? I found the left hand sidebar now, how do I add something? So we actually have already fixed this in core because it was maybe the biggest problem that every participant encountered. So what we've done now is we've added buttons to every region that say place blocks. If you wanna add something to the sidebar, there's a button right there saying place a block in the sidebar. And then once you do that, you can see that we've removed the right hand sidebar completely from this page. Now once you click it, the list of the blocks appear in the modal window right in your face, pretty much impossible to miss. Okay, so another task that we ask people to do is to create a content type with fields, which is a super common thing to do in Drupal. I think I have another video for this one. Oops. So if you can't read all the field options there, we've added a lot more in Drupal A and we've added loads of fields that were in contraband to intercore. Then we ask users to create a, I feel the list of text options. I feel like the names were a little, or not as intuitive as I would like them to be in a list of field sites. But I think that's maybe kind of a overall Drupal issue and not something that's specific to the way that this is designed. All right, so let's talk through what we just saw and what we saw in other participants as well. So again, they have this front to back mental model. They're looking for what they expect, the form to show them, not what Drupal decides is the content structure or the data structure for that, for that content. And they were saying, again, like we're using different words that they're not expecting. But one of the other problems that we have is that we're kind of switching around the way that they are looking to build these things anyway. So the field type listing that I was talking about before, we've added loads of new field types to core, which is great. It means you can build loads of stuff without any contrib. You can actually get really far into play. But it's made this selection, this drop down select box really long. And it's also like the naming of it is not very good. So you can see on the right hand side, all the options for text. We have text plain long, text formatted long with summary, text list text, text formatted, text formatted long, text plain. And these are really like, they don't really mean a lot if you can't see what they do. And so one of the things we've talked about is maybe trying to reduce this list to more simple options and then finding ways to enable some of this functionality later. If you want to have it formatted, you can maybe choose that later on. One thing that someone actually did is they actually Googled Boolean. And something I didn't point out here is that the first option you see is Boolean, as if this is the most important thing that you would add to it. And the text options are actually right at the bottom. There's other people use all the time. So just changing the ordering of this list that should be really helpful. And one other thing that we found is when people were adding taxonomy terms, they got really confused with the terminology here. So when you add a taxonomy term field, it's actually an entity reference now in Drupal 8, which is a generic reference to any entity. But we have these short hands so people can understand how to add a taxonomy term or they wouldn't Drupal 7, they can see the same keywords. But this actually proved to be really problematic because once you go to the next page, it gives you the settings form for the entity reference and it asks you again what kind of item you like to reference. And someone actually said, I just answered this question, why are you asking me again? Is it a different kind of setting? Do I have to, is this something else? Does it mean something else? And they really didn't know what to do in this situation. And then once they'd saved it, when you go to the listing, it's called entity reference. And they're like, this isn't even mine, I didn't even make this. Where did it even come from? I don't think we actually fix this yet. No, come to the sprints on Friday, please. So something that we could do is something that we do in the block UI now and in views is when you're selecting fields, it gives you the title of it and it also gives you a small description about what it's for. So something we could do here is reuse this pattern in the field UI so we could give people a little bit more information about what's gonna happen when they select this option. So they don't feel completely paralyzed by all the options they have, if one's right or if one's wrong. Maybe in the future, we could do something more. We can kind of build something like a form builder because it's enough to just improve the basic things but the real fundamental problems is we're not meeting people and we're not meeting their expectations. They're expecting to see and build a form and we're giving them like a data structure and modeling tool instead. So one other problem that came up a lot is that the homepage isn't very distinctive. So one of these images is the homepage and one is actually a article page. Does anyone know which one's which? Yeah, okay, so it's the one on the left because the home tab is white and not a light gray. Oh yeah, yeah, and the RSS page. Yeah, so this confused some people. This is actually quite a serious problem because when they created their first piece of content, they went to their homepage and all they could see was the title of this piece of content. So they thought that this page become their homepage. So they actually didn't know what they did wrong and they had to go back and look through the settings and they weren't actually sure how to get back to the page they had created. But if you think about how most modern homepages are, they look a little bit more like this. They don't just have like a news listing on them anymore, that's a pretty, I guess that's quite a retro thing to do nowadays. So what we could do here is actually think about the design of our homepage. To meet people's expectations of what a homepage should be, what it should look like. I know we've been talking about the future, adding the ability to build landing pages in Drupal. That's a super future thing but a homepage is usually not the same as just any other page, so it should look really different. Oh, so Angie's gonna talk a little bit more about what we're gonna do next. That slide was a little earlier than I was counting on. All right, hi. So we have problems. How do we do solutions? And more importantly, how do we evolve our product over time so that we can radically erase all of these things and get us to a state where everything is really good? So it's really awesome that we have semantic versioning in Drupal 8 because that gives us an opportunity every six months in order to introduce new UI patterns, fix old mistakes, these kinds of things. So it's a really huge opportunity for us but only if we also improve the process. So how many people know of this book and this process? A couple people, okay. The book, the guy is kind of obnoxious, he's basically padding himself on the back the whole time but there's a really great thing out of this book which a lot of people use in lean manufacturing, lean UX, blah, blah, blah. And basically it's the idea of this build loop. And what you're trying to do is you're trying to build something and that means generating some kind of code or whatever. Then you're trying to measure it so that you figure out what happened and people liked it, did they not like it, how did they fail with it, how did they do it? You learn based on the data from measuring and then you funnel your ideas into the next build. And the idea is make it around that circle as fast as possible. And the big example that he used in the book that stood out to me is do you know Dropbox? Everybody's heard of Dropbox, okay. So the first version of Dropbox was literally a video where they just like bandy wired some things together. They had written no code yet. They just kind of like used little graphics and stuff to show how they wanted the thing to work and they put that up on a page with an email signup box and that's all they did. And instantly they had like two million people emailing wanting this thing and then they turned around to a VC and said fund this and da da. And that was with writing zero lines of code. They were able to validate their idea and they were able to measure that it had impact and now they have data that they can go into to get money to build their thing. So how normal people improve their products using this method is they'll build in the cheapest way possible. So paper prototypes are popular, things like that. They'll then measure. They have really deep instrumentation tools like WordPress has WordPress.com and that thing is littered with JavaScript that explains how people actually use their product. We don't have anything like that. And then they learn by just shipping really fast and seeing what happens and then moving things back through the loop. We don't do any of those things. We start by building elaborate cathedral things. We put things in core which have to pass usability gate, accessibility gate, performance gate, testing gate, da da da da da da. Once we've finally have gotten it through like okay I got a patch now then it has to survive the bike shed gauntlet. And so that's how we measure really as we see how many insider core developer people hate this thing, right? And if the answer is more than one then we change it so that makes them happy but it actually reduces the power of the design that was originally there. And then we don't learn because we don't talk to our users. We like throw it out there and we're like well they'll bitch about that in the forums and we don't look at the forums. So okay. So this isn't good, right? This is really, really not good. So what we do instead of a build measure loop learn is we just build in this horrible spiral and then once in a while every three years we do something at the University of Minnesota and we're like oh, you know, that's no good. So I would like to see us change this. There are some challenges though. Like we have to raise awareness of these usability problems because you know for everyone in this room I assume you guys know how to use Drupal. You've been using it for ages or you came to an event called DrupalCon. That sort of implies an investment and the idea that either you already know Drupal or you want to learn it or your boss is forcing you to learn it or whatever your situation is. We also have to really help with our decision making because it is not cool that a lead developer can say no to something that a designer has spent time and energy and focus and sort of building out. I think that will only get better if we can systematize our ability to test things and get that information into the issue queue. So we need to leverage external tools to try and get some kind of that instrumentation to give us the data needed to defend some of these opinions. Also we need to start tackling some of these elephants in the room. Like AQUI has been great because they've invested a whole bunch of money in the content authoring experience both for Drupal 7 and Drupal 8 but nobody has invested any time in spiffing up field UI or views UI or these kinds of things that are like really fundamental site building features and really, really difficult to use. We also need resourcing because I'm lucky and that I have a full-time job doing this kind of stuff although my full-time job also has 75 other things on my plate but like Boyan works at a totally different company that doesn't use Drupal at all I think and Lewis works for a Drupal shop but also only gets a certain sliver of his time. So we need reliable resources who are expertise in this and can help us see this thing through because it's really hard to build a piece of product in like five hours a week. So what we should do here are some of my ideas but I am totally open to other ideas and I think we should all go to lunch after this and talk about this more. So I think the first thing we need to do is document a process and the process has got to involve design it's got to involve the maintainers of a thing and it has to lay out some kind of a sequence of how we're going to get things done. Right now we don't have the process so the process is kind of like propose an idea and see if people yell at you and then if they yell at you, run away. No, but you know what you have to and I've talked to a lot of developers who are like I would love to work on this stuff if you can give me a spec because if I have a spec and I know that it won't be bike-shedded I will totally step up and help with this. So that's what I'd like to see us do as well as identifying things that are low-hanging fruit UX-wise that we could throw people at a designer developer team just bang out and get out of the way. So I'd love to see us do more stuff like that. I would love to see us prototype super cheaply. HTML5 and CSS and mock up a thing. We can show it to people around us. We can put it up on like user-testing.org or whatever, get some crowdsourced like user-testing data going. I'd love to see us doing some stuff like that. I'd love to see us do continuous UX testing. So not waiting every three years for the big bang where university gives us time in their lab but doing this once a month. Doing like monthly demos or this kind of stuff where we can like get the product in front of people early and often get their feedback in and this sort of thing. We need to do more promotion and awareness of UX problems. Maybe, I was thinking literally of like let's do, do you guys know of MST3K or Mystery Science Theater? Yeah, so I'm thinking like, let's have like Drupal Movie Night where we like watch these painful UX videos. There's an IRC channel and we all, because it's important. Because until you see someone struggle through this it's easy to just say, well those people are stupid. But they're not. These people were literally in our target audience for Drupal and they can't use it and that's bad. Because what I wanna stop is this thing where people use Drupal. They download Drupal, they download WordPress and they go to Drupal like, I don't even know. What is a node? And they leave and they use WordPress and they love WordPress and then they use it for five years and then they finally find something WordPress can't do. And they're like, okay I guess I'll use Drupal now. And then they love Drupal but we could have had them for five years if we just impressed the crap out of them at the beginning and not scared them. And then we also need to figure out the resourcing. So whether this may be crowdfunded efforts or kickstarter kind of things I'm not really sure but we need to somehow invest resources into this and we need to make it so AQUI isn't the only company who can change the UX of Drupal. So this is how we could improve products, cheap prototypes, do a live demo once a month or something like that. And then a really cool thing we have in core is we have the idea of sort of unfrozen code even in a stable release. So you have this idea of experimental modules that is new in core as of a couple of weeks ago. We also have the idea that standard profile as well as Bartik would be unfrozen. And that means that we can make changes every six months to how the default product looks out of the box without screwing any existing sites because none of them are gonna use Bartik probably unless they're super lazy and then they'll be like, oh you made my super lazy theme look nicer, thanks. And the experimental thing is great because we could write awesome new field UI module trademark and make it an experimental module and then revamp that based on real user feedback. And then once we decide we want to use that module and make that the primary field UI, we move the old one to like a core BC crap package or something and we move it to the old thing so people don't break their existing sites but they can use the new cool thing and we can continue with all of them. So I would love to brainstorm all kinds of ideas about this. So if you wanna help fix the problems that we've identified, you should go to drupal.org node 2497361, that was node 2497361. I ran the help desk a lot anyway. There's a lot of people who are like, the best Drupal feature is that help desk and I'm like, crap. Anyway, or we have this tag umn2015 and yeah, otherwise, oh sorry, were you trying to take a picture of that? Great, otherwise, your ideas here, let's have lunch. I have a little issue there which is 2573119. For us to discuss some of these process improvements because what I would love to do, probably not at this con because I'm a little busy, but if some people wanted to get together, I would love to have a draft of this process of how we're gonna make these big changes because we have a lot of big changes we need to make in order to make Drupal awesome but I'm really excited that we can finally do it and we don't have to wait four years to see it happen. So join us, thank you for coming. Thanks a lot for the testing and thanks a lot for showing actually the issue about the blocks because as a member of the documentation team, we face the problem that we tend to write the documentation afterwards on Drupal.org but what actually needs lots of attention is the little bits of text that actually ship with the code and if you look on the current Drupal 8 version, it now has these blocks changed but our help text still said choose a block from the list because when, and that's a really big, that's two please I'm gonna do here. On the one hand, we actually have an issue for that for the sprint on Friday. It's an obvious one, it just means changing a little bit of text but the other thing is in general, if you do change the interface, we also have to change the help text that ship with core and quite often also the small text that actually are on the page because if you look on the help text now and we have pretty much finished the first round of all the help text in April, it will now give you wrong information. So really if you update a module and it has in the template this line saying, this is a UI change, you need to change the documentation and also we should pay actually attention much more on these bits of text that now say still stuff like if you click here, you can change the default user or the default user behavior or tell Drupal to do this and I think if we can make those texts better, it also contributes a lot to much better user experience because they can read what this bloody text box is for. Thanks. Yeah, I should definitely do that. I think one of the things that we've already started doing kind of going towards Shropway is actually not explaining the user interface too much. Like if we have to explain how drag and drop works, maybe it's not the right way of doing it. Like a lot of those interface elements should actually be intuitive and rather than explaining how drag and drop works or where to find that add link, we are explaining like the concepts. So the things that you actually need to internalize to understand how Drupal works. Yeah, one next. Question about demographics. So you tested a lot with, in this tests you used the test against site builders and developers actually, any IDs or future plans to test with end users, real content editors or authors of the system because of a totally different background than these more technical people you were now used in the test. So any plans there? So the University of Minnesota offered to do testing once a year for us so we could kind of revamp it. The trick with testing the content authoring experience is often people customize that heavily to whatever, if you are a, well if you're an event website, your content authoring experience can be completely different than Drupal.org which is a community site for developers. So we lean towards testing the site building experience just because it is prevalent to all Drupal, and so we're going for impact there. I think there is a lot we could do with that though. One thing that we're hoping to do, and if you saw Tim Plunkett's session the other day, we're hoping to put more stuff in core. The problem is you can't put Drupal out of the box in front of a content author, it's just not gonna work. But we hope we can evolve the thing over time so that that is more the case. So I think an interim step could be taking a distribution like Panopoly or Demo Framework or one of these really well built out ones that's shiny and polished and put that in front of content authors and then see how they do and filter that feedback back in. But currently at least on the development side we don't because we're after Drupal adoption from a technical point of view, core is just not there yet in terms of being able to be something you can sit in front of a content author. So we're hoping to get there but that's more of a long term plan. But yeah, if you have access to those people and you wanna throw a polished distribution with a bunch of that stuff built in, yes, that would be awesome. We would love to do that. We see that a lot at our customer side, we observe them also using systems, using the CMS and we see problems occurring, reoccurring actually with different clients so it's very interesting. We try to optimize back end in some ways to make it more usable indeed. Great idea also about in, you talked about tutorial in the beginning when installing Drupal about how to use a system and the different steps you can, what's the node, et cetera. Very interesting system but in our case most clients don't install the system themselves. So if you show it during installation it would probably be a lot more useful in our cases than if it would be shown one the first time a user logs in with a certain role and if he's a webmaster or a contender first time he logs in, for example. But great thoughts there. Yeah, one thing that came out of usability testing was the idea of adding a content editor role as an official role in Drupal like we treat admin special so treating content author special and then we could do something like you're describing. So if you're logging in as user one we show you that this is what a taxonomy is, right? But if you're a content author we say here's how to add your content here's how to moderate comments here's how to do things like that. So more role based that way and I think that would be good. Cause you're right, you do not want to show your content authors like here's how to make a view. You know, it's like no, actually that the contextual links friendly pencil thing is one person wandered into views UI and they just gave up. They're like, ah, I don't know. Anyway, so yeah, we definitely need some separation. Great suggestion. And also thank you for fixing the preview system. Yeah, really underestimated feature really un-netredized on the website on Drupal Adorg. I discovered it's very useful. Yeah, that was Christophe de Yeager who, it's Quentel who did most of the work on that. So if you see him buy him a beer he has Drupal tattoos. So he's easy to spot. And what I would emphasize is you're exactly right and people now want previews for everything. So if we can expand that in 8.1 and 8.2 to be more expansive that's what people want. The biggest advantage is that you can switch the view modes. You can view teaser and default view mode, full node but you can also make the browser screen smaller and have to look at how it will look on smaller screens. That's a big advantage. And you can really, not only before publishing a note when you create a note but also when editing a note you can view what you changed actually. Yeah. And preview that. So no need for workbench moderation to install workbench moderation if you want to preview changes you did with note. I think it's very useful. Absolutely, thank you. That's great. Yes and perhaps we can once have a live preview. Yeah. Yeah. This talks makes me very happy. Thanks for addressing and also thanks for the audience that many people are here attending it. Because I recognize these things as a trainer. I do give training. I see people using Drupal for the first time. They have the luxury of having me at their site and watching them struggle and giving them instructions. But this points out the problem very well. And for me it's again a moment to step in in UX. I'm not making any promises. Great. I mean. Well you did wonders on localization stuff. So if you could help with UX that would be amazing. I'll finish there and then. Okay. Right on. Thank you. Hey there I have a question about priorities. So you've already prioritized some users and I'm curious to know what the process is and how that applies to everyone else. I don't think we necessarily need to know that right now. But one of the important parts of prioritization I think is changes that if they're made in 8.1 are gonna have a huge amount of backlash from the community that's already gotten into 8.0. So for instance nomenclature is something that it sounded like in the talk is something we're gonna tackle later. Unfortunately if we have our 5,000 most prominent most vocal most important devs using the old nomenclature and we shifted in 8.1 we're gonna have a huge backlash whereas if we change it in 8.0 it might be a little more painful right now. Like I'm just wondering if you guys have given any thought to how to prioritize that. Yeah that can't happen till nine. It would invalidate every piece of documentation, every video, every book, everything. So we could only do it with a major version change and when we're two weeks away from RC we're not gonna do that right now. But a way we can iterate on that and contrib this is an idea from Kevin O'Leary is make a translation called Simple English that only uses words from the top 1,000 words in the English language and see how that would apply and we could test some stuff like that and sort of gear it up. The other thing they talked about in terminology review the Nick, the gentleman from the University of Minnesota had this, he said this is what they do in the university all the time. Like they'll give people sticky notes and they'll say okay, tell me what the name of the building is that has the exercise equipment and you get all sweaty in. And they're like oh a gym, right? And they're like okay, we call that the Family Health and Wellness Center. So that might be why people can't find it on the website. Yeah, so I think doing some exercises like that, feeding that into a translation, we could start, there's a lot, we just gotta be really creative with ways that we can innovate in this space without breaking BC. But we can't break, changing all those words is gonna break all the backwards compatibility so we're gonna have to wait till nine. And we already have the 5,000 developers who are angry about the way the words are. So we're not that problem no matter when we do it. Okay, cool. Yeah, but that's great, thanks. Okay so I've been using Drupal according to my oldest site for 10 years and I downloaded Drupal 8 one day and I went into the modules page and I tried to figure out how to configure the core modules. I couldn't and come on, it's from Drupal 4, 5, etc. It's so easy to figure out and I'm just basically I'm clicking all, I'm clicking all those module names to make it expand and finally there's the configure button over there. And we can't ship RC, well we can ship RC one but maybe we can't ship RC two without making a list of all these major usability points that we have. And that one, like another one which was, there's an issue where I collaborated and you asked that it wasn't really that issue where I unified the teams with the modules but I left out in the teams, I left out the actions outside of the collapsible field. We need to also make that now in the modules page. Is there an issue for that? I don't think so. But I think this is one of the main things because we're now moving towards this well different release schedule is actually something we can actually fix in 8.1. Like we now actually have the opportunity to make all of those small optimizations where we learn, we've now did the module page quite differently and we learn, oh, the configuration links aren't as optimally placed as they could be. It's something that we can still actually change rather than being stuck with that for like another five years. Yeah, we can change it, I mean it's not breaking backwards competitively. Exactly. You also can't find the permissions page, which is kind of annoying and stuff like that. So why, we should just like make a huge list of the major usability gripes that we have and okay, we can't fix them all before ourselves. How about make a huge list of the usability gripes you're willing to fix? We got lots of usability gripes. We got nobody to fix them. So if you're willing to fix them, I would love to hear them. If you aren't, that's still valuable but we've got a huge backlog that we will never possibly see the end of. Yeah, yeah, yeah, but some of these are... But yeah, I think that's great. Some of these are there. They have patches and we can put them on some kind of fast pass towards RTBC because we will have the eyeballs very soon once all the criticals are gone. Yeah. The only thing I'd caution is we cannot change anything. String, UI, et cetera, after RC1 because that's when translators and documentation team needs to do their thing. So if you have a crushing usability problem you think needs to be fixed before RC, you've got two weeks. So... Okay, thanks. Otherwise 8.1, so. I suppose to extend slightly upon the tutorial on first use thing, it might be a good idea for 8.1 to like reshow. Here's what's new in 8.1 that will affect you like user facing changes. That's a great idea. I would like to take a step back from all the details and maybe ask the most fundamental question that I think that often we shy away from in the Drupal community and that is who are we actually building the system for because sometimes when you talk it seems to me that the idea is that anybody should be able to download Drupal and build a site because anybody is able to download WordPress and build a site. But is this actually what we want to do or are you thinking a lot about who's actually going to use Drupal and isn't this actually the most fundamental question to answer even before you start looking into usability at all? Yeah, I think you have a good point. Drupal's always had the dual identity of being both a product and a framework and one of the strengths of Drupal is it's a big enabler. It allows developers to do, sorry, it allows non-developers to do developer-like things. So it is a question that we have to ask ourselves on what Drupal's identity is but I think that it's always, as an open source product, it's always supposed to be an enabler for people so it depends where we want to set that bar of how much experience do you need to have to be able to use Drupal. I would respond and say Drupal is for VCR kid and what I mean by that is if you drew up in the 80s you had a VCR and every time there was a thunderstorm or something the VCR would blink 12 and if you were the kid who your parents were like get that working again and you just punched buttons until it stopped blinking 12 Drupal is for you. So I think Drupal is for anybody who doesn't mind tinkering with things and wants to solve a problem and doesn't like tedious work and wants to hand that off to other people to do. Like I don't wanna be pinged every time. The website copyright needs updating to edit an HTML file in 1800 places, right? So I think that all the changes we're talking about don't impact Drupal's target audience at all because even if I'm Larry Garfield and I can code my way in circles around everybody I still don't wanna have to spend 30 hours on every site build making Drupal usable enough so my clients can actually take it. So it's a dual purpose. I think if we make Drupal better for non-technical people and on the content authoring side that's a win for site builders and developers as well. So I actually don't think it's quite as dire as we need to pick one audience. I think we need to understand who all of Drupal's audiences are at every stage in the development process from deployment to initial ideation to wireframing to everything and make sure the tool works really well for all of those people. I think I would optimize for site builders now which is why that's who we talk to simply because if they can't figure it out you're not gonna choose Drupal. So yeah, that's why we're optimizing for them now but I don't think they're antithetical. I think you can make Drupal better for content authors and make it better for site builders as well. Yes, you switch between those roles. Do you wanna? You're Roy everyone. So we often talk in content creators versus our separate from site builders separate from developers. And what's important to keep in mind a single person switches between those roles. So you start out maybe as a site builder to build your own site which you don't use as a content author. Not going that deep as you went before. So it's often making the right trade-offs between for which role do we optimize which interface then it's as much as a question on who, what role do we optimize it for? Do you smell the distinction I'm making? That's a separate, yeah optimizing for a role is something else and optimizing for a specific target audience. Yeah, he was saying if you wanna grow the community you can't just optimize for people already inside the community. I completely agree with that. We are at time so let's take one more question from Doug Green and then everyone will wanna meet probably. It really wasn't my question was an idea that I thought as we only hit seven or eight people in this study which gives me some question about legitimacy but one of the previous speakers mentioned he found several usability problems. I think there might be an opportunity that in droop weight is new to me also. We have a huge number of people that really haven't been involved in droop weight that are involved in droop weight and now we're gonna be starting to use it more. I think there's an opportunity in our issue queues to create usability issues but also have some type of voting polling involved with it so we get feedback that hey, yes, this is an important issue that this was confusing to me so that we don't just have the bike shedding that hey, I like this, I like this, I like this but we get some actual numbers associated with it. Yeah, that would be great. Absolutely. Yep, one last thing, Arsha? One last thing because as a documentation team we're actually working on a droop weight user guide that is not based module by module but task by task. Yes. And if you want to work on that we're sprinting on that on Friday. Woo, it's great. AsciiDoc for the win. All right, that was awesome. All right, thank you so much for coming everybody and yeah, let's go eat.