Helllo, Bojhan – I am User Experience Maintianer of Drupal 7, and lead up the User Experience team. What is it I do – I am an interaction designer – I work in the Netherlands on Applications and websites – my job is usally to observe and talk to users who use an application with all the information gather from that I help teams develop more usable applications I work on a wide variety of projects, from complex logistical applications – to mobile phones, anything which has a user interacting basicly. The past year I have been working with Mark Boulton and Leisa Reichelt on the Drupal 7 interface. This session will be about what we have learned, and the principles we have applied.
For me started In February I was contacted by Dries. The UX-Team had meeting with Mark & Leisa at Drupalcon DC - Problems - What can we achieve (in 6 months) March till July , they profiled the audience of Drupal, build an user experience strategy and designed mockups. (more importantly got discussion going) My involvement was mostly, providing guidance in understanding Drupal (complexities) Getting the mockups from photoshop files into Drupal 7 core
Goals we had in the Drupal 7 UX Project. --- 3 minuut
Goal 1. As you can see, it's not clear whether to push or pull the door to get inside…… and this may seem like a small problem, a lot of people get confused at first – but get the task done anyway. But on the web, its easier to just stop (perhaps even choosing another application) With the scale that Drupal has now of half a million installs, even if only 10% has an usability problem with a feature – that is still 50.000 people wasting minutes if not hours. With all these issues, we focused on one particular experience – that of the content creator.
Usability testing, we had done three rounds of testing one at University of Minesota and two at the University of Baltimore – 60 hours of research Profound understanding of the problems Each round we confirmed the importance of certain issues We found new ones, as Drupal 7 introduced many new features. We indexed the issues we found, we did presentations – all we could, to provide enough discussion material to work with in the community – to work on issues --- 5 minuten ---
Over those three rounds we indentified 120 issues…. Small issues like – being able to put dots in paths to – really big ones, like not being able to find content after having created it. But the underlying trend was, that people where unable to do the simplest things like creating content, creating a menu link – changing the theme.
This problem is because by default, Drupal 6 – doesn’t map to how people think a CMS would work. For example, users are confused that the administrative interface is visually within their site – instead of a separate admin interface. So with the D7UX project, we focused on the bigger issues that affected the content creator and some the site builder – while the normal community process would continue to work on all of the other issues.
Second goal, was to empower developers. - Providing them with interface patterns, that they can apply all over their modules. Educate design process (we are simply, to short staffed to help out in all design areas of Drupal) Creating a sustainable process for Drupal 8 (designing core)
So we have just last month started work on a pattern library, and to explain some more about patterns – they are proven interactions, proven as in tested on users in different contexts. Common design problem Solution Solution rationale Visual examples ---- MAX: 12 minuten ----
So I want to cover a few principles that we have applied in the Drupal 7 UX Project. User Experience principles Applicable to any project. Principle, this is the direction we want to take it – along the way, we will make some mistakes… sometimes the particulars don’t make sense, until you see the whole.
So finding functionality or content is critical, because if you can’t find it – you cant use it right? When we take a look at Drupal, I think we could all agree – that its not particularly easy to find functionality such as module settings.. Battle the paradox of choice (provide less options) Functionality is not equally important…. (my module is!)….. If all functionality is important – nothing is. 12 Minuten
Drupal 6 has – a sitemap, a big dumping place for links. The ability to plug-in functionality without hacking the application is at core of Drupal. However once you start to use the modules in combination with each other, workflow issues start to occur. Can you imagine needing to use several plugins within Firefox or the Iphone to achieve a goal? Finding the right functionality within the interface is nearly impossible. - Finding functionality once a module is installed - Finding functionallty a while after the module is installed Content creator - Finding functionality (with no knowledge of modules whatsoever)
I think our current information architecture, is like sorting your books on color. It makes sense if you are looking for blue books all the time, but that’s not a likely use case is it. If we look at our current IA, Site configuration is the dumping ground, for most modules.
So what we have tried to do is properly categorizing modules, applying knowledge that has existed for years in the library science. As you can see from the picture, Drupal is nicely categorized – and you know where to go in your book case, to find your Drupal books. That experience we want in Drupal, that you know where to go – that you do not have to jump around Drupal anymore, to find something. As we tested this, we saw a lot of that old behavior going away. And even then… a lot of backslash… from the community… Some core developers : Where are my blue books? …. --- MAX 20 minuten ------
Drupal 7 Content (all your content, comments ect) Structure (Building your site, highly accessed stuff) Appearance (theme page – why is it here? Promote design) People (all your users)
This special page. Configuration & Modules (settings, listing of settings) Setting up this page, is incredibly difficult – because the functionality in Drupal core is very diverse.
The biggest challenge is that in Drupal 7, our bookcase is pretty much empty still. We don’t know what modules we need to categorize, because they haven't been created yet. For example, a lot of image modules will disappear – since that’s in Drupal core. So we designed it after modules we saw in Drupal 6, and trends we think are going to be important in Drupal 7. Principle – The Information Architecture is at base of your application/website – treat it as such. 19 minuten.
My experience from observing a lot of users. Is that how people, say they will use something – and how they actually use it is vastly different. And this important to note, because we design for how we THINK people will use it. And then often, forget to change it to how people actually USE it. I want to show a small video, (not sure if you can hear the sound) We asked a participant in one of the usability tests we did, to put up some content. And the red ball, jumping the screen – that is the participant is looking.
Its kind of like the soap on the kitchen sink, you know how you always seem to miss it – while you wife points out it is right in your face. Did you see in the video - how he, completely ignored the create content link? This is because of the mental model…. Design for user behaviour…. Not just what you assume they will see. Mockups – and real behavior Princple – Adapt your design to how users Actually use it (by observing them – in their workplace or at home) --- Rond de 25 minuten -----
For example, this page – we added the action to Create content. Design towards the Mental model..
The first-time experience, is something we needed to resolve – most issues we saw with Drupal where really within the first 10 minutes of using it. These first 10 minutes where a major bump for new users, and Drupal failed in conceiving its awesome concepts. So with the coming of CCK in core and more new features, we made sure we to keep our focus on optimizing the essential experiences first – those of creating content and simple site administration like activities as blocks, menu’s and taxonomy (if people can’t use those, how could they ever use CCK)
Repeat quote When you have so many issues to fix, and its very common to have 50 to 100 usability issues. You need to make sure, you work hard for the right ones – this might seem obvious. But its really easy to get lost in redesigning a new feature, or discussing endlessly over a certain label – because design tends to be treated as something highly subjective. But you have to constantly be aware, that you are solving the big impacting usability issues first – and resolve the easy-to-win battles first. Because this builds leverage within the organisation or community to work on the harder ones.
As you can see, we removed the : The name of the term… Drupal is kind of suffering from waaaaay to many descriptions… and its impacting everything… by taking this small, step here (which everyone can agree upon) we where able to use it as principle, to remove a lot of descriptions else where. Because it clutters the interface, and most of the time its easier to learn the interface by not reading the help text – than by reading the help text. And even smaller changes like, 2px more white space, alignment and stuff like that. Its not so much the size of the change itself, it’s the sum of all these little changes. Principle – Focus on essential experiences, don’t get lost in the cool ones – small changes add up.
Working on Drupal and other projects has really thought me this, and with applications this is even a bigger issue. Because you build it, you usually have quite some content to work from – but what happends if the client starts to add 10, 20 perhaps even thousands of pages? Will your interactions keep up? Will you still be able to find information? Is the site still manageable by the client – or do you need to step in all the time? Drupal is highly effected by this, because – you can have 10 nodes but also 100.000 and in both usecases Drupal has to stay usable. Which is a BIG constraint, and keeps us from optimizing for a certain use case. So to tackle this issue : ---- Rond de 35 minunten ---
See the mobile… We try to stress test our designs as much as possible – by asking “What if?” ---- 10.000 nodes 30 to 40 modules are installed We try to keep in mind that, every single interaction could have far more then the optimal amount of choices. And there are very few ways, of restraining modules to adhere to a optimal design.
Point naar action.. So this is an example of a pattern we created, which is separating the list view from an action. You probally know how in Drupal 6, you just have a whole bunch of tabs – not really ordered on frequency and you have to kind of fish, the “add term” or “add menu” button out of it. So as you see here, the “install a new theme” is a clear action (which by the way means, you can upload a theme to your site – in the browser, just by pasting in the download url from d.o). This is a pattern, that we introduced because we saw how in the real-world – that this was a biggest issue more then anything… And we stress tested this by looking at, how many actions would be added up there by modules (because anything which adds more then 3 actions up there, means this interaction becomes less usable).
But I think more importantly, is that we are taking away resource requirements – by providing good defaults. You don’t have to become an interface designer, to make Drupal work for your client. The ratio of designers working on Drupal core is about 1 designer per 100 developers . So we simply don’t have the resources to fight every battle.
Within the Drupal community, communication is worth everything – as add1sun pointed pointed out. Communicating the design choices that we have made is critical. Because you need to convince programmers, that what you designed will really work with users – and might not scratch their itch. Deliverable in Drupal’s case isn’t the most intresting part, it’s the decisions you made to get to that deliverabe
Design your documentation to fit your audience, don’t just create standard documents. If you are communicating an interface, its very good to be aware of the audience Programmers want highly detailed information which effects the implementation Designers want more big-picture ideas, how a certain page will effect the workflow (how it will effect behaviour/expectations)
We have over 4000+ modules – we need to create a consistent user experience when you are using a amount of them combined. We are optimizing the experience for around 30/40 modules – because that’s kind of the average. And we need to convey to all these module developers, not to reinvent the wheel and come up with their own interactions and information architecture – but to follow Drupal standards. So again, communication is the key – and all of the things we come up with have to be well documented for a programmer to understand the rationale, which quite often goes pretty deep into design. The same applies to clients, maybe its just me – but clients can completely screw with your designs. By breaking rules, that you have applied consistently within the design. Especially if there are inhouse developers and designers – its important to provide insight into the design decisions that you have made. Principle – Adapt your documentation to your audience
So to sum up. The 5 principles are Information Architecture is at base of your website / application. Design for user behavior (not your own) Focus on designing essential parts first Be aware of different contexts and resources Adapt your communication to your audience, continues to live within the organisation --- Rond de 40 minunten ---
So now that we know all these principles – how can we make sure Drupal 7 will get the media companies its attention?
When you start using Drupal, and I think up to this day – Drupal is still confusing as hell. With Drupal 7, a lot of basic interactions should be far less confusing. As we focused on the content creator, a lot of authors will be more comfortable in working with Drupal. Simply because they will spend less time, worrying and fighting how Drupal works. But since we had the whole community work on usability, a lot of other area’s such as the CCK interface, taxonomy, content page and more have also improved.
I know, not all of you like doing training. And getting someone started in Drupal requires a lot of training, because the basic concepts had a few major usability problems – which are all solved now – big bump So you should be able to do less training in explaining – why the Drupal UI is “different” … with this allowing more space for explaining the awsome powers of Drupal. I think this is the most obvious cost-benefit from moving to Drupal 7.
For your developers it should be less work, to
Some resources….. A great book, and some deliverables The project blog and my blog…. Questions about usability or the Drupal 7 project?
Bojhan Somers <ul><li>[email_address] </li></ul><ul><li>The Non-Designer’s Design book – Robin Williams </li></ul><ul><li>Unify.eightshapes.com – Deliverables examples </li></ul><ul><li>D7ux.org – The project blog </li></ul><ul><li>Bojhan.nl – my blog </li></ul><ul><li>#drupal-usability on IRC freenode.net </li></ul>