 So, good afternoon everyone. This is designing Drupal 8. I'm Lewis Nyman, a front-end developer and a designer. I'm a freelancer. And I'm also the maintainer for the 7 admin theme, which, if you don't know it, is the default admin theme for Drupal. I'm Bojan Stomers, and I'm a user experience designer. And, well, I work on the UX of Drupal, and I'm a, well, maintainer, UX maintainer of Drupal 7 and now Drupal 8. So, today we want to talk about kind of the design process that we took for the new style guide for Drupal and kind of our desire to raise the bar in terms of the user experience and the visual style of Drupal. And we're talking specifically about the admin style. So, let me start it. So, let me first kind of give you impression of why we thought a style guide would be needed and why we needed to kind of reframp the style of Drupal 7 in Drupal 8 now, obviously. We made a lot of changes to Drupal 8. And not a lot of those changes are very consistent in terms of their visual style and their user experience. And that's really because we kind of lack kind of a central guideline as to how things should be. And that makes for a rather inconsistent experience. So, it's something you might not notice when you're using it. But, you know, as you're going through it and looking at different screens, you might notice the inconsistencies, especially if you put, you know, two screens next to each other. You might see it even more. An example of that is this. In Drupal 8, we have about five different styles for buttons now. These are two styles for primary buttons. This is the save style. It's all different, you know, different rounded or border radiuses and different colors and all of that. Clearly, this isn't very helpful for the end user, knowing what they mean, what they do. And also, like, none of them actually look very good. Yeah. Sorry. Yep. And for the developer, well, contract developers have to choose which one do I use, which one is the right styling to apply, and that isn't really clear. So it's also a little bit out of date. If you look at the 17 now, you know, back when it was introduced, it was fairly new. But if you look at kind of the Drupal styles, which is really the kind of popular design thing now, is that it looks a little bit dated. And that's kind of part of its design as well. Mark Bolton initially designed the 17. It's humble. There's not a lot of augmentation or there's not a lot of, you know, big gradients and stuff like that. It's really part of the style that it's humble and very clean. And that kind of fits Drupal's brand. So in itself, it isn't a bad design, but it can be approved upon, you know, for this time. Especially when you look at things like, well, the iOS or Lumia, it's something that has come up in the last four years since Drupal 7 has been out. And it's really two new styles, especially the Metro style. So that's the one on the right from Windows and that's used on Nokia Lumia as well. That's really been defining for a lot of new UIs that come out. And if you look at, well, our team, it's not as pretty. And, you know, a lot of designers who look at our system, evaluate it and go through it and are kind of set off by the fact that it's so ugly. So that's something that we looked into and how, you know, how can we resolve that? And it's very tempting, you know, for us, but also for designers who come into Drupal to take this interface and just update it to the new kind of style of that moment. It might be the Metro style now. Well, a few years ago it was kind of the bootstrap style. So it's very tempting to just copy that style and go with that. But since 7 is for many people, many end users like authors, it's kind of the main way that they interact with Drupal. It's how they perceive the brand. So, you know, as these new styles come up, we need to make sure that we kind of pick a style and stay with a style that can last for a few years, especially because, you know, installs don't always get updated very quickly. It might be that people are running with that same 7 style for six, seven years maybe. So it has to kind of really stand the test of time. So let me quickly show you kind of the process that we took to redesign 7. So the first steps that we took is in the community. We went to Bad Camp and I met with Ryan there. He's a designer slash frontender, slash UX guy. And we basically spent a whole lunch meeting kind of talking about, you know, how the design of 7 should be for it to really, you know, feel and look the way that we think it should look in 2013. A small disclaimer. Style. Style is a really personal thing. Like, if you like, you know, light blue or dark blue, or if you like rounded corners or, you know, very sharp corners, that's a very kind of subjective thing. And obviously there's, you know, a lot of graphic design kind of principles that apply. But in essence, you know, especially a lot of discussion around style tends to be very subjective and very personal. But the style also has to have an opinion. Like, we can't do kind of committee design and, you know, have this white design and black design and say, let's choose the middle. Let's go with a gray design. Because that will make for a very boring design, right? It's not something that really stands out or has an opinion. And the last thing is a hard thing to crowd source, because everyone has their kind of, you know, different view. Every designer has a different view of how it should be, which makes it hard to crowd source the whole effort, because you need really a consistent style, you know, that can be implemented across all of Drupal. But besides these things, it's also something, you know, it has to be accessible. It has to be mobile-friendly. And it has to provide consistency across 20,000 modules. So when we're doing this style, we need to make sure that counter-maintainers can actually use it effectively. So the process that we took was a pretty common design approach, where you're diverging, so you're trying out all kinds of IDs, and then you're converging where you're kind of choosing the IDs that you want. And we spent about three months in bi-weekly meetings with Ryan, Roy, and me, redefining and identifying what the Drupal brand is and how we can make it work. And so we did a lot of brainstorming, you know, Photoshop file, kind of ping-ponging to find, you know, what's the detail that we need. And Ryan spent a lot of time each meeting making new revisions and making kind of a vinyl version for that meeting so that it can really go into the details. And I think we did about five major revisions over the course of those three months. And then we posted our results to the UX team meeting, which is every Monday, and we put out a proposal on groups.drupal.org. And this was really to show the whole community what we've been doing and kind of a rationale of why we think the design should be like this. This probably took us like a month to write up, because it's, you know, communicating something like this into the community need to really have kind of a good background as to why you made those choices, because it can be very subjective. And, you know, when it doesn't, when it isn't exhaustive and it isn't really going into detail as to why certain choices were made, a lot of discussion will be kind of uninformed as to why, you know, we chose a certain selection style or why we chose a certain font. So that's something that we took a lot of time on writing, because we know from experience in doing design in the community that unless you have, you know, a clear description and clear rationale for even the smallest changes that people might get kind of, you know, upset or uneasy about the fact that you didn't think it through, even though you did. I think a lesson as well for this is that we need to get it out earlier. We probably took a little bit too much time writing it. Yeah, but that's something for next time. So if you look kind of at the primary principles of designing it, and I'm going to show you in a second, is we chose a very kind of neutral palette. So it's desaturated, so it's not, you know, really bright colors. But there's good contrast and it's, the colors themselves are relatively calming. And so it should be aesthetically appealing, obviously. But it should use kind of a minimal style. It's not metro, but it shouldn't be all out there like a lot of those dribble designs or Joomla or other tools. They have a lot of, like a lot of fluff around it, a lot of augmentation to emphasize the design. And we thought, in Drupal's case, that's not really part of our brand to do that. But it's also an evolution, so it's not a major redesign. It's really tweaking, you know, details and making sure that issues that we found in Drupal 7 that are, you know, difficult in terms of usability and aesthetics that we fix those. So there we go. It's quite fast, isn't it? Should I just show it again? You can't adjust the easy on keynote, so it would have been about half an hour to have it moved. There you go. So, yeah, the form styles. Broke it apart. File fields. We can show more in detail. We'll post the link, I think. It might be easier. Are you so modest to see where it goes quickly? No, it's actually blurred. The designs are just blurred right now. There's a huge PNG that you can see. But we also looked at, for example, the icons. As you might have noticed, our icons are a little bit inconsistent and a little bit ugly, especially in like messages. It's something that we designed and we didn't take that much time for Drupal 7. So for Drupal 8, we have like a set of icons that we can now use and all of you here can use as well to really have a consistent style. So let's take a really close look at some of the things that we did. So for example, we made a palette, a color palette, and there's a secondary palette as well. But these are kind of the main colors that are used in the 7 team. And you might recognize some of them. If you're using the overlay, you might not recognize this one, but burlap is like the background on titles and it's used for tabs as well. And while the Drupal blue is kind of used for all links and a lot of actions and buttons, well, the text and obviously background. But in all, the color palette has to be kind of light and it has to be kind of desaturated. It has to feel kind of natural. And then we looked at the font and more largely we looked at kind of the typography that we're using. And we look at Sensor's Pro as something, it's kind of a humanistic typeface which makes it kind of more applicable to Drupal. And it was chosen for reasons like legibility and it's arguably better than what we're using now. It's like Lucian Lucida is what we're using. But we know this is kind of a tricky thing because fonts and typefaces and GPL doesn't really work well together. For some reason, typeface designers aren't really keen on releasing anything in GPL, so there's all kinds of other licenses. So we know there are some complications around that getting something like this into core. So we're already working on at least getting a lot of the typographic elements like line height and kind of the white space around a lot of text, fixing that with Lucida, making sure that that looks nice and that it takes over some of these elements. And hopefully we figure out a way to get a humanistic font in. But yeah, that's not an easy task. And then obviously if you're taking something like Drupal, you have to take into account all of the accessibility standards that apply. And we have to be WCHTAA compliant, not AAA, because that's even stricter. So we're using AAA generally across core. And we have to have a certain, sure. Oh yeah, sure, version two, yeah, sorry. Version one is really old now I think. Yeah, yeah, so we're using WCHTAA for everything, all of the ARIA stuff as well. So there's certain contrast ratios that we need to hit. And I'm not sure if anyone of you have used Drupal 8 lately, but if you use something like contextual links, they'll be nearly impossible right now to actually read the text when you're hovering over an item. That's because the contrast is so low. So hopefully we'll solve problems like that with this design. And contrast isn't only about accessibility, it's also about we don't have any large bold areas of color. We felt that wasn't really the style that Drupal should be using. But the same thing goes for shapes. Bold shapes are really reserved for titles and headings, and it's not used elsewhere. Finally, well, the model dialogue, well, you can't see the header. One of the key things that we thought the Drupal style should be around is that we're relatively friendly and calm. So we really looked at what kind of ornamentation or roundness can we introduce to make it a little bit more easy on the eye. And two key parts of this design is it's a little bit more soft. And you'll see that transpire across all of the elements that we designed. So a little bit more soft edges, not too many big contrasts between elements. And this is all kind of to communicate that more friendly, more natural design rather than a more stark kind of metro look. So we hope that is something that will come up along the lines. So there will also be kind of no ornamentation as far as I know. There's no patterns that we apply to backgrounds, which is also really popular now, no textures. If we use gradients, they tend to be relatively easy on the eye. There's no large contrast going from really black to really white or something like that. So we're only using that whenever it's enhancing the visual look of a certain element. And then the last thing is it's all rather minimalistic. So this is, for example, redesign of the tables. And we're trying to use more kind of white space. We're trying to remove as many unnecessary lines or at least lines that might be guiding but aren't. For example, the zebra striping that we initially had on a lot of large tables, it makes it relatively hard to read, even though it's aimed at helping that. So we introduce like a hover style, which makes it easier to see. And those are kind of some of the key principles that we apply. And Alou is going to talk a little bit about what's in now and how we're going to work on that. Thanks, Bea. Does anyone have any questions at this moment in time? Okay. So, oh, I was going to mention what's already in core. So this is the work in progress. Not everything is in now, but we've got the messages in. The icons are mostly in. The new styling for vertical tabs, which is actually pretty subtle, is in now. The new progress bar is in. And the new admin navigation listing is in already. But what I really want to talk about with the style guide is where we go from here. So the style guide isn't just, in my eyes, it's not something that just represents the visual design and the look and feel of all the UI components. It can also document where we should use these components and how we should use them. And in the future, I hope that the style guide can become kind of like a living documentation for designers and core developers and contra developers to help them create better, more usable interfaces in Drupal. And beyond Drupal's release, I think we can expand the style guide even further to accommodate even more patterns that are found in contra and other places in core so it becomes a better toolkit for developers. So it's not a... It's an obvious fact that there are way more developers in Drupal than designers. We barely have enough designers right now to deal with all the different pages and interfaces that are built and generated in core. And there are about 20,000 contra modules out there and we have absolutely no chance of being able to go and help advise every single developer of every single contra module with the designer. It just won't happen. So we have to kind of admit that there isn't a Drupal site out there that doesn't at least install one contra module. So we have to admit that the experience of using Drupal goes way beyond just core. But I think the only way we can solve this is instead of trying to find more designers to help more contra developers is to use a style guide to create a better toolkit so developers in contra can create their own better interfaces and consistent UIs. So let's look at some of the contra modules as they are now. So some contra modules just take existing patterns that we already have and they kind of lean on them very heavily almost to the point of where they break. So this is panels. And I remember there was a lot of fanfare when... I remember a lot of talk about vertical tabs coming in as a new UI component. It was a big deal. And panels lean quite heavily on vertical tabs. You can see we actually have vertical tabs inside of vertical tabs inside of vertical tabs. And along the top we have horizontal tabs as well. And actually I still don't think I understand its interface. Again, it's not necessarily the fault of the developer. We don't really give them a lot of help. They kind of have to figure it out for themselves. Tables. So tables is the default way that we list any item in Drupal. It's kind of like if we show anything no matter what it is or how many items it has. Even here where we have an associated information and a button, it goes in a table. Which I guess is kind of consistent across the Drupal but I think there are better ways of displaying information sometimes. This is a quote that falls into my head quite a lot when I work with the Drupal. And as it happens, Arale is actually speaking at the keynote tomorrow. So if you can make it tomorrow, please do try. It would definitely be worth it. And some other control modules, they do realize that there's no existing UI they can use to accomplish the job they're trying to do. So they just kind of go off on their own and they create their own UI for various different levels of success. But that still creates an inconsistency across Drupal and you kind of feel like you're in your own separate interface that doesn't really work with the rest of Drupal. And views is a good example because views is in core now but it still maintains a lot of unique patterns and components that don't exist in any RIO syncor. And then I think the majority of modules kind of fall back to the most simple interface there is. When you need to get tasks done, they just throw a form at you. And it's kind of the safe option for me. If I use these to get tasks done, just give them a form and eventually they'll get to the bottom. But I think there are better ways of showing interfaces than just a flat form that goes straight down. So interface guidelines. I kind of want to talk about how we can use interface guidelines or how they are used now to document components and inform developers of when they're used and how they can be used. And when they're done well, they can offer consistent experiences across systems when there are actually very many fragmented tasks going on like imagine a mobile operating system with many, many apps. A good system guideline can make them feel consistent and more intuitive. And a bad system guideline can make everything feel fragmented and unpredictable and confusing. So when I first saw this presentation, the iOS 6 design guidelines were up and I was actually going to critique them a little bit but I checked this morning and they've updated them with the iOS 7 ones obviously and they're actually really, really good, a lot better. They include best design principles and guidelines as well as UI examples for developers. And you can see here, here's an example of the progress bar. They show what it is and they show its purpose, what it does and why it should be used. And then it links directly to the API to show you exactly how to implement it. The Windows 8 design guidelines offer design principles as well, advice on touch gestures, animations and they even describe how the app should work when the window resizes. Oh, and they also have an app UX checklist so you can check out all the best practices before you launch your app. It's a pretty good idea. The Ubuntu design documentation sits on its own sub-domain, Ubuntu. or design.ubuntu.org. And it's very clever. It outlines the audience spectrum as well. So they have these switches between community or commercial, consumer or enterprise or end user and developers and they give you different advice depending on the user you're talking to. And they also provide loads of examples of all the Ubuntu branding and use. So Drupal actually has UI standards. Can anyone raise their hands if they knew that they existed? Can anyone raise their hands if they've used them? I feel bad. I feel like I'm twisting the knife in your... because you and Roy spent a lot of time, many hours working on it but it doesn't get used as often as it should. It exists and it doesn't get used. So there's obviously a lot of potential room for improvement there. So I'm not saying you should use Bootstrap. What I'm saying is Bootstrap is a very good example of a front-end framework for back-end developers. Its documentation is actually really good and it's very intuitive. One of the problems with Bootstrap is that it isn't very opinionated. It pretty much just gives you any possible UI widget component you could need for some app. It doesn't have any use cases, it just throws everything at you and doesn't really tell you when you should use any of it. But it is very influential I think for me anyway because it's a great example of something that has become so popular because it is so easy to use and implement. So going forward in the future, oh you can actually see it, it's not moving. So going forward in the future, I hope in the next few years we can kind of build on the star guide we have now and build on the documentation and add best practices to kind of build our own user interface guidelines that are really intuitive for developers to use and I hope that core and contribute developers will be able to build much better UIs with the star guide. Thank you. So this is a core conversation so make sure we have loads of time for questions. Does anyone have any questions? I was just wondering about the roadmap that you guys have got in place to create the star guide. So right now we got very worried about the deadline for Drupal 8. So we had to move very quickly from making the star guide to actually trying to get it into core. So we're actually still doing that. And once we've done that, we hope that we can go back to star guide and look at it again, add more examples, like I was saying, try and find new patterns and contribute and try to just make it more useful for developers because right now it's very bare bones. Anything to add? So I guess all the pencils as well when Drupal gets out but we think like getting all of the styles into core will take like another three or four months and after that we can start developing the star guide. But that obviously helps. So it's going to be a lot of work. So I guess that does tell us what I was going to ask about. So for the module developer style guide, what are the major holes in that still that still need to be developed? Or is it a state where your typical standard module can just use it and most things should be covered? I'm assuming like it doesn't yet have guidelines for something as complex as views or panels or rules. But for just your ordinary one-of-the-mill module, do you feel it's at a state where module developers can just look at it and say, cool, I'll just do what that says? Or are there still big gaps in it? Yeah, there are huge gaps in it. It's nowhere near the level that I would be happy with for module developers just to pick it up. Really right now it is just showing you the components, which is better than what we were doing before but there's not nearly enough advice about when and how to use it. So big gaps. Other things module developers can do to help that along who don't have a design eye but may be able to identify, you know, here's a problem I keep coming up with in my UIs. What do I do? So first of all, we'd love more feedback on the actual standards that we have now. There's a comment field below them. So that's something where you can add your comments. But we're really acting on little feedback as to how it's actually used. Partly because it's probably not used a whole lot. But for those who do use it, we'd love more feedback as to what we can add. I think in terms of your previous question, another thing is that it's relatively easy to describe the pattern and how it should be used and how suggestions how to use it better, et cetera. But it's really hard to give kind of an overview as how you should organize your elements because just putting them on the page is generally the easy part. Figuring out whether you need extra tabs or whether you should place it somewhere else in the information architecture. That's like a larger question that a lot of kind of content developers struggle with as or just decide to do about this probably makes sense that they could help it. But that's also kind of a larger question which generally needs some like vision behind it what audience you're serving with which page. It's also worth putting out that we do host UX happy hour every week still. Every week and module developers are more than welcome to come along if they have any UX problems or questions. That's always been available. I should have said this before but I think you guys are doing a great job. I reckon it's looking really awesome. My second question was what's your vision for the actual platform that you're going to present the style guide on because when I see it on Drupal.org obviously there's no way to navigate it right now and you're going to need that when you create more patterns and these kind of things. So what's your plan? So around the time the style guide was posted I was working on a style guide presentation framework called Tencel that allows you to display how the components work in different screen sizes. It lets you drag and drop stuff around but I didn't have a lot of time to actually work on the presentation framework itself because we were so busy implementing the style guide and since then there are probably about a thousand new style guide frameworks that are out there. I think Sam Richards has developed one for his SAS components. I know Hedley Smith has worked on one called Agile Patterns and then speaking to Brad Frost the other week about Pattern Lab which is another really useful presentation framework they don't. None of them do exactly what we need with all the documentation and stuff like that but I would much rather work with one of them to get a framework we can use that's really good than work on my own. So it's still up in the air about how we decide to present it but it probably won't be on Drupal.org because of the UI limitations. Sorry, there's someone. Hi, I also wanted to start by saying awesome, good work. And I have two questions. One of them is at the moment you haven't shown a lot about how the whole thing is changing for mobile like I did see the vertical tabs for example that turn into collapsible field sets and things like that but I think a truly mobile first approach actually needs a bit more than just that and I'd love to hear your thoughts on that and see some of the work you've been doing in that in that area and the other question is like for example me as a designer I'd be happy to do stuff but what I found quite hard in comparison to for example to just contribute a module or work on issues that it's harder to get into it like how do you approach Drupal as a designer and what's the stuff that you're looking for like how can we guys help you? I really wish you were in the conversation we had yesterday because we were actually talking about trying to solve that problem about having designers contribute but for your first question so mobile UX was a big passion of mine a few years ago and I started one of the first things I did in Drupal Core was redesign the mobile UX completely it started from scratch and I just built a prototype with no relation to how Drupal works on a desktop but that ends up being extremely difficult to actually execute because everything is broken up per issue and you have to do component at a time so being able to control the whole experience and put that in in one patch was basically impossible so I learned a hard lesson so it is actually very difficult to take an interface that wasn't designed to be mobile friendly at all and adapt it to be completely mobile first and when the style guide came up it was an opportunity to basically redesign everything in one go a little bit so we had an opportunity to take some of the components that really struggled on mobile interfaces and redesigned them so they worked both on mobile and desktop with the same design and the tabs are a really good example the horizontal tabs they collapsed down to a collapsible expandable menu based on the amount of tabs there are on the size of the screen it's some JavaScript algorithm to work it out it's really clever maybe I could demo it but do you have anything to add? sorry, your second question was how do I get involved into core or how do I contribute we have, design wise design wise yes we that's a tough question because the issue queue works really well for developers and not as well for designers and we're still trying to figure out whether we need a separate sub-site like design.duper.org with the right flow to facilitate design or if we can improve duper.org itself to make these tools easier for designers to contribute to so I don't have an answer but we're trying to figure it out if you could help us in that process it'd be great yeah I can't the best way right now to get involved is that we have meetings every Monday on IRC where we kind of discuss the design activities that all the people in the UX team are doing and even if you're just lurking that is a good way to get kind of a heads up as to what's going on and where it can be involved obviously it's not ideal and we know that so ideas like Luz was saying having a sub-site or at least having some kind of explanation what the flow should be and where people can help out is something that we do want to do in the future I just wanted to say like not many designers use IRC chats yeah that's true I did also want to say that we have a front-end sprint this Friday at the sprint day so if you come down then we'll gladly if anyone wants to gain a vote we'll gladly help anyone out we don't have any core development at all or any design work with core yeah yeah so first of all I actually wasn't aware of the UX hour thing so I'm more a module developer so that is actually super useful and really cool thing so I wasn't aware of it so I don't know if it might make sense to make that more public in any way or it might be just me that I missed it yeah and so another thing I also love, I really love the work you've all been doing and I get that you said that it's important to write up like in the style guide to write up very specific details on the decision-making process that you went through and be very exhaustive and I get that but then on the other side when I'm writing a new module and I'm writing an admin interface for it and it's maybe not just a simple form so I have to do like you know I get into the question of what UI to make I really like there's a really different use case because I don't need all at that point I really don't need all the reasons I just need like this canonical source so the designers have decided this and this and that and I'm fine with it because at that point I don't care so I just need like basically just need like a screenshot do this and another screenshot with a big red X don't do this so for example in Drupal 7 this was like a real revelation for me when we introduced vertical tabs and it was like the coolest thing so I thought just do vertical tabs everywhere and I posted a patch that did like three levels of nested vertical tabs and I thought it was like the best interface ever that I've just done and then someone came in there and said like please don't do that and you know so that was like a really really good moment for me because that was like a teaching moment yeah so yeah so so we tried to do that in IRC mix and we have like a needs usability review tag you can apply that UX team is watching also for conflict so whenever you tag your issue like that that's something that we look at and about your your point it's true like the the proposal that we put up on groups at Drupal.org was a very different audience and it was really aimed at core developers and kind of making sure that they buy into our IDs because they have to be the ones that also advocated when people do it wrong and the guidelines obviously they do have to be very clear on what you should use and shouldn't use and obviously they shouldn't be spilling out all the rationale why it's you know tiny bit lighter blue than the other one so yeah does user accessibility include 508 accessibility check on Drupal.org like for country modules or or for just core so if we are checking country or country or core in general so the accessibility team obviously is doing a lot of that work where they're checking in so we did show the whole style guide to them and in a lot of cases what happens in core kind of flows out all over country so if we make decisions that are accessible that generally inspires into the country community does that answer your question or sort of okay other questions I was more kind of looking like some of the images all tax that's a big fiber tax accessibility because I work for a company and we have big government clients and they are really focused on fiber so a lot of those issues aren't necessarily like style guide or design issues it's more like how it's implemented technically and whether we for example by default require image fields to have all tax that's one of those discussions that everyone is on board with that idea but ideally the accessibility team takes care of making sure whatever we design that that is implemented fully correctly of the right area labels and all of that stuff so that it is completely accessible other questions the hashtag to notify you guys that it's a UX can you elaborate on that is there anywhere we can go was it just the IRC just that sort of thing I think that there's people out there that want to help and I feel like that's a pretty important thing to solve because obviously you guys got your hands full just getting things ready for jubilee I mean I for example am a designer and I would like to contribute to some extent maybe I'll come along to the IRC but wouldn't it be cool to see a list so there is a list and as it happens I have a slide for that so the the style guide issue tag lists every single style guide related issue we're working on right now so it would be a great place for you to help thank you