 All right. Let's get started. So I want to talk to you today about kind of what the UX team has been doing for Drupal 8. And for those of you who don't know, I'm Bojan Somers and I'm the UX maintainer of Drupal 7 and now Drupal 8. And I actually graduated yesterday, so I'm finished at school. Thank you. So I want to talk about two things today. I want to talk about the current initiatives, kind of the things that we've been doing, and the main, well, challenge that we have. But I think a couple more months to go, we want to still work on kind of three major things. We want to work on the content creation and editing. We want to work on blocks and layouts. And we want to work on the mobile. So let me start with content creation. It's not an official initiative, but we thought, you know, this is kind of one of the things in core that is very bland. It's not very striking for a content management system. So we feel it's kind of broken and we wanted to improve it. And I think we've done over 100 usability tests on this particular screen and found a whole range of issues. Some of them, the more important ones is that people don't really know whether this content is published or not. On the editing, it's not really clear to them, especially when they have a kind of a content editing workflow. That's information that's really important. And it's somewhere down in the vertical tab. Another thing is the vertical tabs themselves. When we introduced them, we thought they were going to be awesome. And they work really well. But they are hard to scan and it's really hard when there's a lot of contributed modules for it to not look cluttered. So that's another issue. And obviously previewing. Well, this is a bit weird. I guess it's a Drupalism. Because when you look at this preview, people go, what the fuck? Because it's not in the front end, right? A preview should be in the front end. So they're confused by this and they're even more confused that there's two different kind of previews. So with this, we started looking at, you know, what do our competitors do? We try to do a comparison, looking at what Drupal does and what other systems do. And we looked at a whole range of CMSs like WordPress, Joomla, Moveable Type, Hippo, which is a Dutch CMS. And we noticed that, well, the content creation screens aren't necessarily very well designed either. Often they design very individual fields. But whenever they threw in a WYSIWYG, it looks all mashed up because of that particular WYSIWYG. So it doesn't really match the visual style of the admin. But still, in comparison to Drupal, they're all pretty okay. Like over-the-top styling like Joomla or very minimalistic styling like text pattern. So we collaborated with Jared Punch, who works for Lollabot, to go over a few design rounds where we would research and iterate on a design. And we pushed these iterations out into the community for feedback. And in the final round, we now have this. And this is also the design that's being implemented. It includes a sidebar where on the top you have your kind of meta information that is published or not, whether it's saved or not. And then you have the accordion of configuration items so that on the left, all you're doing on the left is always just doing the content creation. And this was achieved really well by participants. We did a usability study and we found a number of small issues, but overall it stands. People really understand that on the left, I just do this. And on the right, I just have all my meta stuff that if I want to, I can configure. So that's for content creation. The Spark team, I think, during this week, there has already been some announcements and some demos of Spark stuff. They're working on, like, inline editing. It's likely just to complement this, because, you know, people still have to do creation. So it's really just for editing. And we've provided feedback to the Spark team. There are a number of UX and accessibility issues that need to be resolved for Spark, but we think it's going to be in a good shape to get into core. So that's all about content creation. Then mobile. So we've been working with the mobile initiative and really focusing on basically making Drupal 8 friendly for site visitors and site administrators. And I think many in the community can understand that the urgency of doing this, probably already a year ago, but, you know, we want to have it in the Drupal 8 at least. And there's a whole bunch of tasks that the mobile initiative set out. The UX team is really only focusing on this part. So the ability to use Drupal's administrative forms in mobile devices. And to do this, we really need to design kind of the complete stack of administrative tasks. So, you know, primary, secondary tabs, the toolbar, the 7 team, all those parts need to be designed for mobile. We've already achieved, I think, a small achievement through John, Albin has been doing a lot of work in helping to make this happen. So Bartik is already responsive. I think Stark is already responsive. So we really only have seven left. So I hope... Sorry? Oh, Garland's gone. Well, that helps, always helps. So we really have only seven left. So designing seven is quite a challenge. We still have a long way to go, but Louis Nieman has been working really hard working on prototypes for the navigation, because, you know, this is stuff you really have to try out. And the prototype so far kind of allows you to very smoothly move down the navigation just by navigating the list, basically. But we didn't stop there. We didn't stop by just navigation, because a lot of the stuff that's on the page needs to be designed as well. So whenever you come to, for example, the content listing, you don't want the first half of your mobile screen to be filled up with the action link and the weird filters that we have in core. So a trick that we tried there is to put the action link in the top bar so you can press the plus, and then you get to that action. When there's several actions, it might collapse into several actions. And you have a search button, but you also have a filter button. So the filter is initially hidden from few only when you select it in the toolbar are you going to show it on your mobile screen. I think it's quite a challenge to move this forward. There's new patterns and new technologies coming in, well, every day, pretty much. And we need to design these patterns so they scale to kind of all of the crazy things you can do in core, because managing your fields on your mobile phone is going to be very different from doing content creation. So there's a prototype. Luis Nieman is working on this one. It's not a mobile app, so it's really a responsive admin team. And I think to the actual prototype, because I felt this is something you have to try out. It's still a rough prototype, but in terms of focus, I think it's important to say that we're not just focusing on content creation. I think that's something we have to do, obviously, and a great part of doing this. But we also want to leverage site building, because we think that's an essential part of the Drupal experience, maybe even more so than content creation for a lot of our community members. So I think the biggest mistake that we had in Drupal 7 is that we really only focus on content creation in terms of UX, and we really forgot to improve things for site builders. You in this room, we really didn't improve that much around the UX of menus, terms, blocks. That's still pretty much the same in Drupal 7 as opposed to Drupal 6. So we still want to try and do some of that in the upcoming months. And if you look at kind of our competitors or friends in this field, they're really innovating hard on these elements, these building blocks or building your site. And the Layout Initiative sets out to basically revamp something we haven't changed in a long while, which is the placement of blocks and the creation of layouts. And we've been thinking about this I think for well over a year now, brainstorming and designing things. So I'm quite excited about this. And I think it's a fundamental UX part that we still can improve. So let's look at the current state. It's pretty ugly. You have your blocks, and you place them in one layout. That's pretty much what you can do. You can maybe supply some URL arguments for certain blocks to not show up on certain pages, but that's about it. But this model's quite outdated, right? This is the one-page site kind of model. And it worked maybe in 2001. But if you look at the problems that users have, they experience this gap. And we didn't really make it any better in Drupal 7, is that this is your site and this is how you administer it, placing your blocks. And it doesn't really match. There's a whole gap in between as to where their blocks go and how it's going to end up looking. So there's almost no cues for users to really administer their blocks well. And that's not all. In the testing that we did at I think the University of Minnesota in 2011, we found that people have a really hard time grasping kind of the conceptual model of Drupal in that they think it's all just content blocks on the page. Whereas a Drupal developer knows that's a node block, that's a custom block, that's another custom block, that's maybe a view, maybe slideshow, that's the main menu block. They don't really know how to access all of those modules and they have to learn all these different kind of concepts. You have to know views, they have to know node blocks, they have to know all this stuff to get that page. And if you look at all of the different modules that do this, panels, beams, they all do it in all their own ways. So there's no pattern in how you would place a block on this page other than the course block page. And obviously our competitors are way ahead of this. If you look at square space, they're already allowing a lot of very cool drag and dropping of blocks. But what do most of them suck at? Dynamic configuration. Making a custom landing page is actually quite easy from a UX perspective. But making a landing page or a page that shows a different image when you're watching the French version from the English version or showing different content when you're logged in or logged out, those kinds of dynamic configurations are really tough to do because then it goes beyond setting those custom variables to inheriting configuration and all of that. So the conception module that we made is that we think that this whole experience exists out of three parts. There's the page library where kind of all of your pages live. There's a component library where all of the blocks live and then there's the drag and drop editor where basically all of this comes together and then you end up having your page. So again, we made a prototype. You can access it from here. It's a prototype that tries to build this whole experience. So I really suggest you try it out. I'm not yet fully pleased with where it is. It allows for the creation of blocks, placement of blocks, but there are still some parts that are difficult to understand, especially if we want this to be usable for content creators and side builders who are just starting out with Drupal. I think the big question though, now that we've seen all of this, how are we going to make it happen? Because if you look at Drupal 7 now and you look at Drupal 8, there's pretty much no difference. And that's worrisome because I think after, what is it, 20 months or something of code slush? Having no noticeable difference is a problem. And I've tried to wrap my head around why we have no difference there and why it's all the same. And well, obviously it boils down to this. I mean, every initiative has this problem. And having been in the community for, I think, four years now, trying to build UX team, I think that the main problems that we found, that we found it really hard in terms of the UX team for people to get involved in UI discussions. Most of the time they're pretty heavy and very intense. And I think the UX team is now around two or three people in terms of staff, which is a very high bus factor, especially when they're kind of responsive for all of the UI in core. And in the last six months, a couple of us had other circumstances why we couldn't dedicate full-time or part-time or volunteer time to Drupal Core. So very little happened, really. So Angie told me there's a similar situation in Dock's team where there's a really high bus factor. And it's a big problem. And if you look at the ways that we tried to solve this, most of the times, at least in Drupal 7, it was that a big party stepped in, right? During the Drupal 7 UX project, Acya stepped in and really funded Mark Bolton and Liza Wright-Shelt to work on all of the UX in Drupal 7. And it really, I think it propelled a significant amount of activity in just the community, but also in actually changing the product. And in Drupal 8, I think they're trying to do something similar, but a little bit of a different model. And again, they're trying to propel significant improvements to the UX of Drupal. But I think this is also a sign of a clear structural problem, that there's just one company that's jumping in to help out on UX. And I think the structural reason that this is, is because we have a very small product community. I think we have a very big community that works on the framework, or at least the high technical challenges, but we have a very small community that works just on kind of the end user features. And I think that's really the core reason why UX doesn't progress as much as it, at least as we want it to be. Because it's really not the lack of designers, but it's really the kind of powerless position that they're in, in terms of executing upon UX IDs. So in terms of solutions, how we could solve this, and I would really like to see more discussion about this, is I think we can learn from things, for example, that did went well when it comes to D7 UX. One of the things that went well with D7 UX is that because of the continuous kind of funding of development activity, a lot of other activity spiraled, like the loan warriors would work on one feature, got their feedback, got their reviews. And it was really that continuous activity that also spiraled into continuous improvements to Drupal Core. So whenever people see Drupal Core moving, even from a visual standpoint, just by changing features, changing how it looks, people get the feeling that it's moving and they can contribute it to it. And that's not the case right now. We haven't really changed that much. And I think it's also the very open design process. We've tried to mimic that in the usability group now, but it's very difficult to do that kind of intense process. So I think those are some of the solutions if we try to bring that back into the Drupal 8 development or maybe Drupal 9 development that continues in your funded development and momentum by doing a lot of smaller changes is when we can get more activity and kind of grow that product focused community. And that's about it. Any questions, discussions? Sure. So how much do you look at these and just compare with the standards for Drupal Core? Yeah. So we actually did that. We have a research post up on kind of the research that we did for the content creation post. And we looked at a number of like very commonly used contract modules like, yeah, so FieldGrop, which I think, in combination with this which there's all kinds of things you can do from horizontal to vertical, vertical tabs and different kinds of groupings. So we did look at that and we always try to take inspiration from Contrib because that's often where things are experimented. And especially with distros now, I think they're pushing the brownies in terms of UX and things we can incorporate. Sure. Yeah, and I was just looking at the following. We have a... Sure. Other? Yeah, sure. So, well, in terms of Spark, we have been in discussion. I mean, we haven't been in discussion about the mobile stuff, but we have been in discussion about the inline anything and the layout configuration. I think the plan moving forward is that they decide what they're going to push towards core. And we're going to decide whether we're going to take that as input or whether we're going to actually take over those IDs. Especially for mobile, it's true. I think the Ember design that they did is very different. And there are some good qualities to that. There are some bad qualities to that. So it's likely that we're just going to flip and merge whatever good things and then move forward. At least that's the idea. Sure. I actually have a question that I wanted to follow up to. I feel like the Spark demos were really fascinating, really interesting. And I'm not sure that they did something completely different. I think what they did is they took Lewis's stuff, which was really focused just for mobile navigation and not looking at the desktop side. And the Spark team tried to integrate those into a cohesive navigation experience that works in both spaces. And they used Lewis's work as an inspiration and reused some of that stuff. So I don't feel like they threw it out and did something different. That's my opinion. And my question is like sort of about UX resources. What sort of things that do you feel like are good things for to get more UX people? Do you need like people trying to analyze problems and sort of come up with the pain points in order to create sets of criteria? Do you need people then, you know, coming up with ideas to... There's this UX process that I don't see happening on a lot of issues. Can we get developers working on creating sets of criteria? Can we improve that bit of the process and make resourcing easier for UX? Right. Well, I mean, in terms of the process, I mean, the UX process is a bit weird, right? Because we're three people. So on some issues, we decide this is a big issue. We're going to try and add process to this. You know, for example, with the module page redesign, with the content creation redesign, with the blocks layout, we decide, you know, we're going to take our full process and we're first going to do research prototyping, then we're going to design something and then we're going to validate that design again and see, you know, how far it is. But for a lot of small issues, that's just not feasible in terms of resources. In terms of resources we would like to see there is, I think, yeah, more interaction designers. We have a bit of researchers now and we can actually put up a research test plan and actually perform it within two weeks. So that's really good. But yeah, we don't have a lot of interaction designers. And then, as I was saying, we really don't have the development capacity to execute upon those ideas. I think a lot of good ideas are still lingering in the queue, you know, just adding search to the content listing, for example. That's been in there for like two or three years and there's just no one to execute upon. Does that answer your question? Yeah, thanks. First of all, congrats to the graduation. Thank you. And also, I believe I'm myself, mostly a site builder and that's big enough task than having time and then also to have time to learn to code. So basically, I don't have the time to become the skilled developer. I need to be able to contribute modules and improvement myself. But I think we have also like a language barrier between us who work in the UI and those who work in code. And we need to some way or other find a way to better communicate between us that we can transfer the experience we gathered over the years as site builders and the knowledge we have from talking to clients on what they need in the editorial UIs and what we need to be able to configure and create those features on the sites. More ways of teaming up with developers. So it's a difficult thing, but I don't think communication is necessarily a very big challenge if we, as UX designers at least, communicate our proposals very thoroughly. We've learned that over the years whenever we have a design proposal that's very timid in terms of its scope and in terms of its argumentation that we scare developers away because they feel we haven't really thought it through much. So we always try to do our research part and to really put out a very thorough and complete proposal. And I think that's the way right now at least it works better. If there's a language barrier there, I think there is a perceived language barrier, but that's taken away by writing very full proposals being very complete in the design that you suggest. Okay, and follow up. I took a look at the UI-standard document and it's quite sparse and what I would like to see in there is also like examples and recommendations for module developers on when to use permissions, when global configurations to be used and those kind of things. Yeah, I think the UI standards as we have them now are very basic. So they're not guiding the developer, they're just saying how to apply a specific pattern. So it's not ideal. I think we can complement much more if we figure out what the steps are every developer takes in deciding what UI element to use. All right, thank you. Other questions? Well, so I think the developer case is obviously that their clients in the upcoming years are going to be able to use a more usable droop rate. I think that's the primary use case. In terms of, well, community like exposure and maybe in that sense business exposure, I think Spark is a great example. I mean, it got a lot of exposure that they were trying to tackle this very difficult thing in Drupal. So as other companies come in, I hope they can get that same kind of exposure just by showing they want to contribute really cool stuff. I can add a few business cases for companies who'd like to contribute to UX. One of them is less service questions, perhaps even less training, less time in customizing their own UX, sorry, customizing their own administration. From my point of view, if they do a professional job, they do and they don't use the standard core administration because it doesn't scale to realistic sizes. So a few things from my experience as a trainer and being very closely related to end users. Yeah, I think especially on that second point of the administrative screens, I think before Drupal 7, we saw a lot of custom teams, companies building their own administrative team. Now that 7 is out with the 7 team, we see a whole lot less of that because people feel 7 is a good standard and we can maybe expand on that. Rather than having to completely invent their own. I think you had a question? Yeah, yeah, yeah. So to put up on my previous one, on many sites, you have complex performance, a lot of fields. I'm afraid that those focus on a simple side and then you get like 10 more menu items and then it breaks, something like that. Are your fields and now we have our solutions, our custom methods in concrete where we have put everything we do and then you say, okay, I have something better for you and you know how I like to look for on the phone that and suddenly it will work and work. So okay, I think one answer would be to have some flexibility that this is just a suggestion that can be used and that concrete can develop something that's the other would be that you have to really consider all different. So I mean, we always try to design for the 80%. I mean, as you were saying, that's like the common practice and I think we explicitly try not to design for the extreme cases because it's a very resource intensive to do that. You have to do a lot of research to figure out if we have, you know, from 100 items to 500 items, there's a whole lot of different things that you can do to make it more usable and that's where we think that's pretty much the space where Contrap has to come in and something we don't have the resources for to design but also we don't want to design for because then it makes the other 80% less focused. So it's a trade-off, yeah. Right, right, right. I mean, we trust on the development community to implement it in such a way that it can always be extended. Okay, last question. Two, it's both. It's stuck in design in terms of we don't know how we're going to group things. All the other stuff we've kind of figured out but we don't know how we're going to logically group stuff so it might be that we are not going to solve that. In terms of implementation, well, Jen Lamplin can probably tell you more about this but we have one row and this is an accessibility issue because, well, collapsing rows in tables isn't very common. So there's few accessibility issues on how to make that happen so that's, I guess, an implementation blocker. All right, that was it. All right, thank you.