BADCAMP 2016 - Designing Drupal 8

Editor's Notes

• #3: Hey! Bojhan – I am User Experience maintainer of Drupal 8 and I lead up the UX-Team. I work at an agency called User Intelligence, where I mostly do work in product strategy and design. I am all the way from Amsterdam, The Netherlands This session will be; a small journey through designing Drupal 8 and what is to come.
• #4: First of all, - Designing in opensource, and Drupal – What is that like?
• #5: A lot of you imagine it like this? Coding often happens before the design There are a lot of different cooks in the kitchen There is not a lot of incentive for making something beautiful or even usable. And well, that’s true – it is incredibly hard.
• #6: But Drupal is also welcoming designers: We have a UX team, with weekly meetings. We have made significant progress since Drupal 6 on the usability front, with dedicated teams working on the user experience. We are slowly closing the gap, on whats needed to have a process for a truly easy to use Drupal. However, what does it mean to design in Drupal. Well let me paint you a picture.
• #7: We have about 3300 contributors to Drupal 8. Of those, there are roughly 6 UX designers (research, design, product strategy, information architecture) – who by large contribute in their evenings/free-time. In a system where its all about “scratching your own itch” – that’s a challenge. Views in core, adding Symphony has a large following of contributors – making a button just a little bit better looking or more usable – ehh. Not so much.
• #8: To put it differently. Which means that for each Drupal website, in 200k installs we have someone actively contributing to the Drupal core UX. (pauze) Not really uncommon in opensource! Firefox, a successful product, opensource and still some 500 million users – only have 15 dedicated designers on staff for Mozilla. Which means that per designer there are about 33 million users. Which would be crazy in any other application.
• #9: Drupal is itself a ecosystem. Drupal its success is mostly about its modulair nature, the ability to plugin new functionality without killing the rest of the system. Obviously creating a UI where everything is variable is vastly complex, but to me that’s also the interesting part. Take our tabs for example, in Seven they are optimised to have about 4/5 items – but a given module could have a perfectly reasonable usecase to have 8 navigation items on the same level. In that case, they can either go the route of creating their own interface – or leveraging a less optimized UI component. What do we do? Well we don’t want to get into the realm of Wordpress, in a sense where complex plugins provide a completely different UX to the main system – but also not the iPhone route where every part of the UX is tightly controlled.
• #10: As we come in: The role of the UX designer in the Drupal project for a long time, has been to magically fix usability problems. Why is that? Hard to get enough tool knowledge to make informed design decisions ( it took me 6 months to REALLY understand Drupal) Unfamiliar processes, you’d be surprised to know how many contributors in our community – have not really engaged in a design process before.
• #11: Well talking about process.
• #12: For a long time, our process was like the Sagrada Familia in Barcelona. A massive undertaking to execute on a design, lasting several years (up to 5 for the last one). This is flawed in many ways: Everything is perfected. We don’t receive any feedback about the usefulness before its hit the market. It causes a lot of burn out, as you might need to carry your idea for 2/3 years to get it fully in.
• #13: So with Drupal 8 out, we changed our corse dramatically. With that greatly impacting our ability to design more properly. ------ Adopting modern software development methodologies that speed up the process from idea to final product. With a set release cylce, able to change the design of major parts every 6 months. With that – hopefully moving more and more away from a consensus based approach to an experiment based approach.
• #14: The idea being that we can run this loop of: Building, measuring and learning: Validating ideas more early on with prototypes of appropriate fidelity for the hypothesis - actively avoiding, jumping straight into coding. Increasing community involvement in the early stages of a concept, as you can show something tangible. Adapting our release with “experimental modules” and learning from the market whether its useful and how “mature” it is or not. 
• #15: It’s a big transformation, and its taking a while for mindset and processes to change. We still quite often favor designing the minimal functional product. Where from a product and ux standpoint, we should be building funtionality – that is across the curve, of functional, reliable, usable and desirable. The outside in module, where we had the bare functionals in – we decided that it should also receive some of the UI polish to really get people excited about it.
• #16: I want to walk you through two projects that we did in Drupal 8, that had a big impact.
• #17: Relatively early on in the Drupal 8 release cycle we embarked on making Drupal 8 mobile friendly.
• #18: With the focus on making the content authoring experience as mobile friendly as possible. Meaning that we would start with the “create content” screen and not the “editing a view” This was a decision based, merely on the fact that for every Drupal website out there – its likely for there to be more people authoring content, than people building it.
• #19: For this I have to take you back to 2013, when Google Glass was still a thing.
• #20: When we started out – we took contrib as an example, and honestly Drupal 7 was and to a large extend still is a mess. There are over a dozen modules, that allow you to detect devices, screen resolutions and integrate with applications on the iPhone and Android. There are probably even far more themes, than I listed that are responsive and/or allow for a fine-tuned mobile experience. One of the most promising ones out of this bunch, when it comes to the administrative experience is Drupad.
• #21: Drupad is an iOs app that basically, allows you to log into your Drupal (7) website. It’s relatively focused on “Content administration” tasks but does allow you to do some of the more “site building” like tasks. I think it’s a good first stab at what this experience could be like, but there is much more to it – especially for more “advanced” tasks and patterns.. (modules, fields, blocks) So we took a look at how others do it.
• #22: And to be honest, when we started the process of making Drupal 8 mobile friendly – there were really only a few CMS’s that out of their core offer an mobile administrative UX. Wordpress, at the time has tailored apps for each platform (iOS, Android, Windows, Blackberry)….. HP WebOS…(tablet) was probably the most beautiful one at the time. Which obviously focuses on the heart the Wordpress experience, creating and editing posts. It is primarily beautiful in the details – transitions between screens and quick access to editing, replying and creation of comments, pages and categories.. Really all those detailed interactions, that make this app good.
• #23: Squarespace, has a really focused content adminstration experience – but also unique one, its unlike a lot of mobile CMS that just try to replicate a native app feel. The visual styling of the Squarespace app is in line with the desktop experience, that’s an important quality we wanted to pursue as well (there is no visual disconnect). However, we didn't’t just look at other CMS’s…. There are lot of interesting innovations happening in the app space.
• #24: Applications like Gmail for your, make very efficient use of the screen – providing optimized views for specific content. So with all that knowledge how did we approach it?
• #25: We spend 2-3 months diverging: sketching and gathering ideas on how to solve the key challenges; navigation (toolbar), but also in the admin (tabs, secondary tabs, listing pages), forms (text area’s, input forms, etc). After this we converged: into a HTML prototype that you could walk through the admin. Following this we took the ”Drupal” way of meticulously creating issues and solving each mobile challenge one by one – it took well over a year to change the UI.
• #26: The end result: Drupal 8 is mostly responsive. Responsible toolbaar, that wraps vertically on your mobile phone – very similar to how many apps work. Tables size appropiatly to screen width Content creation, taxonomy pages, content listings. And Yes, also Views – although I really won’t recommend using it on your phone.
• #27: That was back in 2013/2014, when the explosion of mobile meant we were close to ditching our laptops. It didn’t quite turn out that way. But there is a lot more to be gained:
• #28: What about platforms such as a watch? Are there tasks that one might do on a watch? Not yet, but is that because we simply havn’t found it yet – or is there no real use?
• #29: What I think is exciting is that…. Its all still moving….. ., we can leverage far more. Browsers are allow more and more mobile features to be used as input methods (albeit a little slowly) For example, capturing video, images and audio and directly placing it on your website – which is something we are working on. Enough about mobile, I want to talk about the next thing
• #30: The Drupal 8 style guide.
• #31: This actually started here at BADCamp I met with Ryan (designer from Canada), at BADCamp 2012 – and we basically spend a long lunch meeting discussing the visual design of Seven.
• #32: Style is a very personal thing, some people like round corners others don’t, some like a darker blue, others a light blue. However a visual style has to be defining of Drupal, it has to be opionated, we can’t do design by committee. Hard to really crowd-source the effort. Getting a singular vision on design, isn’t about getting more contributors. But also: It has to be completely accessible Work across platforms/browsers. Provide consistency across 35.000 modules Not be SOO opinionated that people think it doesn’t fit with the site they are making
• #33: We spend about 3 months, in bi-weekly meetings between me Roy, and Ryan trying to define what is really identifying of Drupal and then brainstorming a lot, ping-ponging Photoshop designs. R5yn would then spend a lot of time, detailing and trying out a final version for each meeting. Probably about 2 months diverging (Trying out ideas), looking at different parts of the interface – what the style should stretch to, and then about a month converging (getting dirty with the details, choosing) I think we have about 5 major iterations, that we did.
• #34: Then a draft was then shown to the UX-team at our weekly IRC meetings. Then we spend probably another month – writing up our ideas and overall rationale for the changes. Over D7 and D8, we learned a whole lot how to communicate rather drastic, but also very opionated parts like this. So we know our post had to be exhaustive, clearly lay out all the rationale and graphic design principles and ideas we applied. It spawned a lot of discussion (but luckily, mostly constructive feedback)
• #35: A primarily light tone to appear bright and open A neutral, desaturated color palette – no really flashy colours (a lot of systems moved that direction)
• #36: Aesthetically appealing, though minimal graphic style;
• #37: Its an EVOLUTION, Not a completely new one. The Seven theme is pretty good, not bad – principles weren’t bad. Its just oudated (the ones will become outdated again, 3 year cycles). These were deliberate choices, we could have added “shiny” elements everywhere (icons, etc.) but we chose not too – as it doesn’t quite fit the Drupal brand.
• #38: Typography More clearly distinguishable headings. Rules on the white space that should surround pieces of text. Not using a full black – on white, to ease the contrast and make it more legible.
• #39: A colour palette: A primarily light tone to appear bright and open. Keeping the Drupal “blue” which is a key brand colour – we could not just abandon (but we didn’t want it to be overwhelmingly blue, like Garland – anyone remembers that? – at one point we had 4 blue themes in core) However white and burlap are used for most canvases.
• #40: Input forms Slightly softer edges (2 border-radius) A focus style. A error style; with the error message close to the offending input.
• #41: Uploading files (this, after 3 years is still not in!) What we want to do here, is actually make a component that allows you to drag and drop in a space. With a progress bar by default.
• #42: Buttons! Buttons should be clearly identifiable as such, with normal and primary actions inviting interaction. Clear different styling for primary, secondary and delete actions.
• #43: One of the largest challenges was tabs: The negative space created where two rounded tabs are joined can be a visual distraction. The primary rationale for this redesign is the large disconnect we created by the right alignment of tabs, which were often missed. We moved them to the left, connected them. Usability testing - very good improvement
• #44: We went through a large number of the elements we designed, using the WCAG contrast ratio’s. Focusing on the primary elements, making sure we have crisp lines and sufficient contrast – but not to the extend that its jarring. Contrast, isn’t just in colour its also that we are avoiding large areas of bold colour, and bold shapes are reserved for headings and action elements. Not to many competing visual elements.
• #45: Two key parts of the design: It’s more soft - soft edges, to communicate more friendly and natural design – rather than the more stark, metro – clear lines principle. But also little or no ornamentation: no patterns, textures, gradients or shadow/emboss effects – except to communicate affordances/elements.
• #46: Generous and consistent use of whitespace – a whole lot more than we did previously, most notable in elements like the table. (a lot less cramped) Aesthetically appealing, though minimal graphic style; should appeal simple but not sterile. Those are some of the key principles that we applied.
• #47: How do we document when and where to use UI components? Interface guidelines offer advice on the best tools for the job, they help consistent experiences across systems that involve many small tasks and instances like apps. Ubuntu’s design documentation sits on it’s own sub domain. It also provides documentation about the components, how they behave, and their purpose. Examples of it in use. SHOW OF HANDS – who knows about our guidelines?
• #48: Drupal has UI standards! Few people use it. It actually has standards for most common form elements, text, navigational patterns – over 100 guidelines and common mistakes that module maintainers make. It’s definitely not as well maintained and build as other style guides, but it’s a start.
• #49: Looking forward -> Seven is a beast – in terms of what it has to support and how much work it is to change it. I hope to see: Much more movement in contrib space (Morten will talk a bit about that) Our core process enabling much more agility in redesigning pages.
• #51: What about Drupal 8? I think one of the biggest mistakes in Drupal 7, is that we forgot to improve things for Site builders - You in this room, and a large portion of our community haven't seen much UX change around concepts like blocks, menu’s, modules. - If you look at competitors/friends in this part, we are really lacking behind (something not even contrib can solve).
• #52: We want these tools to be more fluid, and reactive. Most of it still feels like 2009’ Hard transitions between screens No real previews. For the UX it’s not so much about transitioning to a new technology, as it is adopting a new paradigm of ”real-time” interactions – losing the disconnect between the front-end and back-end.
• #53: We are working on a new front-end theme Bartik is out-dated, and we need a new theme We are still looking for designers who are interested in being a part of this
• #54: We need your help! Making this better, requires a lot of intelligent minds to come together. If your interested in contributing, get in touch with me or find your way to the following site.