Drupal7 Experience Strategy & Goals

Experience Strategy:

  • Make easy things easy and hard things do-able.
  • Design for the 80% (ref: Pareto Principle)
  • Privilege the End User

Our Goals:

  • The combination of powerful functionality, amazing community and great user experience should make Mark & I switch from Wordpress/Expression Engine to Drupal7 as soon as it is released.
  • We should be so proud of the User Experience for newcomers to Drupal that we need to redesign Drupal.org to put the download button back on the homepage.

One of the things we were least happy with in our process for the Drupal.org redesign project was the experience strategy that we developed and then hardly referenced at all. This was because it was simply too long for anyone to keep in mind – an unwieldy experience strategy, as it turns out, is not much of an experience strategy at all.

With that in mind we have drafted strategy statements and goals which we hope to use as ’stars to sail our ship by’ on this project.

How do you like them?

[x-posted at http://groups.drupal.org/node/20066]

UX Suggestion Box – Drupal7 UX

Mark at Drupalcon

If you were at the recent Drupalcon in DC you may have seen Mark Boulton and I at the UX Table plying people with jellybeans and requesting offerings to our Drupal7 UX Suggestion Box. This is just one of the ways that we are hoping to engage the Drupal community in this project and to continue that process, you’ll find below the contents of the suggestion box (as of late Friday, unfortunately our desk and all it’s contents was trashed on Friday evening (boo!) so it’s possible we’ve missed a few suggestions).

Please take a moment to look through the very roughly (and quite possibly not entirely well) sorted list below – we’d be very interested to receive more suggestions from you or your comments on the suggestions collected thus far.

There are multiple destinations for the suggestions collected – many of these will feed into our thinking for this project, but there are also a few that will probably be added to the issue queue (if they’re not there already) and a few to add to a wishlist for releases beyond Drupal7 – don’t feel as though you need to censor yourself to only what you think is reasonable to expect for Drupal7 – let us know what you’d like and we’ll see what we can do to help make it happen!

Drupalcon DC UX Suggestion box contents:

Information Architecture (Task Based)

▪    Role/Task/Workflow
⁃    Have ‘packages’ that automatically install common functionality. Talk to Dimitri about install profiles
⁃    CRUD (Create, Read, Update and Delete) admin for specific admin types, terms etc.
⁃    Distinguish between site builders, site managers and site end users
⁃    Better default roles & config
⁃    Workflow improvements to core
▪    ‘Feature based’ administration/ Add ‘features’ then configure content types, views, categories etc. for each one. Everything becomes a feature, some that you can’t disable eg blog, forum, wiki, required ones for example are ‘users’
▪    Bring all options for content types into the same area but also leave the feature config under it’s own admin screen (find either way)
▪    I always use Path to define an alias of “login” for (site)/user. Login as the URL makes sense to people and they can remember it
▪    Get rid of Site Building and Site Config. No one really understands the distinction – you just gt used to where to find what you need but contrib modules are randomly placed. Think about tasks instead

Functionality

▪    It’d be nice to be easier to install language pack from core to modules (esp. Thai!)
▪    Node create and edit menu settings. The ability to set the weight of a menu item via the (existing) drag and drop interface but inline with the menu settings and node edit form before saving node
▪    Install modules, themes and updates through the UI
▪    In Drupal7 revisions should be allowed to be published in the future
▪    XML querying gate w module info
▪    Disable menu fieldset on content types that don’t need it. Also restrict menu locations
▪    Allow user registration using Open ID
▪    Widgets for user fields
▪    Add data types to CCK fields. This way integers and other data types won’t be sirted as strings
▪    Configurable node admin
▪    Smarty type var handling for themes
▪    After running update.php we land on a sreen with links to front or admin – why not just go to  Front and probably save a click?
▪    WYSIWYG Theme Builder/Editor

Interface

▪    Fluid project accessible reorder widget instead of arbitrary drag & drop for menus
▪    Content entry screen improvements
▪    Sorting/Filtering
⁃    Improve the admin/content/node page? I often build a view to replace this page. Clients of mine need: Sort by title/type/etc. (by column), Show last updated date (how about a flexible way to choose columns to display) and created date, search/filter by keyword in the title
⁃    Streamline administering roles & permissions (eg. as an option, allow application of permissions on module config pages)
⁃    Allow configuration of all content type settings on single page as well as existing ‘per content types’ approach. eg comment setting, uploads, etc
⁃    Comment views or CCK for better sorting and control
▪    The date selection shouldn’t just be text
▪    Wordpress-like dashboard
▪    Modal dialogs for confirmations
▪    Warn users if they are about to navigate away from an unsaved node or block
▪    Make the UI drag & drop
▪    Increase admin text sizes across the board
▪    Do not get rid of the front end/administration integration
▪    My users want an EDIT button on everything
▪    Smaller /admin page

Search (as in the core search module)

▪    cannot exclude content types – need to, if you have ‘database table’ types that are just used in views but never directly displaced. [I think there's a contrib module that does this]
▪    need ability to add pages and index them, composite pages like views and panels

Accessibility

▪    Our .gov contracts are v interested in accessibility, particularly in the admin section (since so few CMS platforms have admin accessibility)
▪     Accessibility by default – WCAA 2.0

Additions to Core

▪    Core SSL Support
▪    Bring in token and image API into Core. Should be automatically available not just in separate modules.
▪    Views query builder in core, UI as module (views is a single point of failure, too much risk if there’s another views version lag like w/dg)
▪    Image in core content types
▪    Media and WYSIWYG in Core! OMG!
▪    Bring CCK UI into core to bring further consistency
▪    Views in core!

Help

▪    An easy to navigate learning area. Clearly separated sections: learn Drupal, modules / implement learning
▪    Contextual help
▪    Video tutorials in the help area (see Wordpress.tv)

Migration/Back Up/ Export

▪    An export module to make migrating a site to a new server/restored server easier
▪    Build in back up and restore utility for admins
▪    When upgrading an existing site, the site’s existing folder and settings should not be over-written
▪    Migration tools that allow easier moves and domain names eg. filesystem path

RDFa
Remove and replace all core themes except Garland

x-posted on Drupal Groups

10 Social Skills for Community Designers (things we learned from the drupal.org project)

It was pretty obvious from the outset that we’d need some design and UX skills to get us from one end of the Drupal.org redesign project to the other. It was less obvious how important our ’social’ skills would be – and unsurprisingly, we learned a lot about good and bad ways to share the design process with a community along the way.

Here’s a few ’social skills’ we learned:

  1. you need to take responsibility for the way that your community behaves: it’s not in any way productive to associate the way that a community is responding to you by blaming the community or even the individuals in it. If you respond that way you’ll never be able to improve the situation. As with every relationship, the only person you can change is yourself. If you’re getting a bad vibe back, the first thing you should do is check your tone and content – what are you saying? how are you saying it? can YOU improve the way you’re communicating. The onus is on YOU to get it right.
  2. tokenistic involvement is a waste of time: if you don’t really care what the community has to say on a subject, don’t ask them. If you do want their input, take the time to design a way for them to interact with you in a way that gets the best from them. Be creative, put a bit of thought into it. Avoid polls and and use surveys with care – you might feel as though you’re involving the community because you have ‘numbers’, but do you have real involvement. Ask yourself what the community knows that you can benefit from, then consider the best way to help them share that knowledge and experience with you.
  3. ask for specific feedback: if you want to get good feedback from your community, tell them what you want feedback on. We *didn’t* do this much during the Drupal.org redesign – instead I was trying to keep it ‘neutral’ and not influence what and how people gave us feedback – we learned that by asking for specific direction we not only got excellent feedback on the issues we highlighted, but others as well. Without direction the discussion tended to be less helpful and was more likely to get personal (not in a good way!) This will also help you to get feedback on more than just the homepage.
  4. give examples: if you want a particular kind of response from the community, it is important to provide an example for them to follow and really great instructions to participate. For example, when we were doing the ‘crowdsourced wireframing’ I included a picture of one of my not very elegant wireframes so that people had a sense that their submissions didn’t have to look ‘designed’. If there are instructions to participate, make sure these are as clear as possible. Then make them even clearer.
  5. wait… wait… wait… engage! once you post something for feedback, go away and make a snack and do NOT get involved in the conversation immediately. This is probably the most difficult rule to follow and one that Mark and I had to coach each other on (and occasionally police! – step away from the computer!) throughout the project. If you dive in and start responding to the first few comments, what you unintentially do is skew and retard the conversation. Rather than exploring a broad range of issues and allowing key points to gradually evolve, the discussion focusses on whichever points you have responded to, everyone starts to focus on those few issues. The richness of the feedback is lost because you dive into detail too quickly. Rather, wait until at least a half dozen people have posted (or 12hrs has elapsed, whichever is soonest) and see what the trends are in the feedback, then start getting more involved in the conversation.
  6. admit errors quickly: the only exception to the rule above is if you’ve stuffed up. In this circumstance you should admit the mistake quickly so that the conversation doesn’t focus on your error. In one iteration of our redesign we accidentally omitted a very important call to action (I know… how could we?!) As you can imagine, that oversight dominated the feedback we received and by the time we responded (way too late!) things were getting a little frenzied. We should have been keeping a closer eye on the situation and stepped in as soon as we realised our mistake.
  7. don’t go dark, but don’t respond to everything: there is a balance in the correct volume of response that you need to aim for. It is really important that you don’t disappear (even if you get really busy) – the community needs to know that you are there and that you are listening. On the other hand, don’t feel as though you need to respond to every comment that is posted – unless you are only getting a handful of responses. As a rule, aim to respond to trends and issues not individual comments. Feel free to occasionally respond with a simple ‘I’m here and listening, I don’t have the answer yet’.
  8. lead by example: it’s an oldy but a goody - interact with the community in the way that you would like them to interact with you. Be polite and respectful. Others rudeness or bad behaviour is no excuse for you to let loose. It’s up to you to set and maintain the standard of communication you want the community to engage in.
  9. assume good faith: it’s a general rule of interacting with others online, but keep it at front of mind especially when you’re putting your own work out there for review and, therefore, more likely to feel a little defensive. Text is a tricky medium for communication – people might sound like they’re being mean or overly critical or agressive when they’re just not great at communicating (or you’re feeling defensive and read everything as an attack!), or being a little lazy with their words, or created unintentional meaning. Always assume that people are trying to be friendly and constructive and helpful if there is any room for doubt at all. In fact, even when it is evident that they *are* being a little mean, it is often useful to deploy this rule – play dumb and be extra nice. Don’t waste time fighting or being a smart ass, or just being mean, or engaging with others who are. Focus on the task at hand – doing good design.
  10. be a human: I think this is the absolute most important thing – don’t assume a Voice of God, don’t pretend to be infallible or to know everything. Don’t feel as though you have to use very big words all the time. Swear occasionally (if your community is ok with that). Admit that you are nervous (or outright terrified, if that’s the case). All of this is allowed and encouraged. Communities are made up of people, of human beings and you are but one of them. Use your real voice and speak honestly. Be open.

design is no place for democracy (things we learned from the drupal.org project)

Continuing in the series of ‘Things we learned from the Drupal.org project‘, this post actually starts off in the comments of the last post (design by committee vs design by community) where Keith picked me up on the statement that design should never be democratic and asked ‘Could it be? Or at least closer? And how to do that?’

Ah, democracy. It is a beautiful theory, but only – as with so many things – when applied correctly. Democracy may be great for deciding on a government, it may be great for Pop Idol (hrm..?) there may be other places it is great and noble… but design just isn’t one of those places.

When designing with a community what you should be aiming for is participation not democracy. Make your design process as open as possible, but don’t be fooled into thinking that because people ‘voted’ for a particular design, that is is the best decision, or even a good one. It’s probably not.

There are two key reasons that I believe this to be true:

  1. Good user experience is hard to evaluate when not in use – when you give people a screengrab or even a prototype to evaluate, people will tend look at things from a visual design perspective (highly subjective), and often a ‘heuristic’ perspective (usability conventions, best practice, what ‘users’ do and like etc.).These perspectives are valid and interesting, up to a point – but they come nowhere near being as valuable as the observation of a designer, or actually observing someone performing tasks that they would do every day using your design and seeing how it works for them. I’d give that trumps over popular opinion any day.By putting a design out there and asking people for their feedback, you are actually giving them a really difficult task. It’s hard enough for those of us who do it professionally (and there’s plenty of research to show that our opinions can vary wildly) – it’s not really fair to expect your community to be able to make a good decision about whether or not a design will work well based on just taking a look or clicking through a prototype.
  2. Your community are domain experts, not design experts – the best thing your community can do for you is tell you what you need to know in order to design well for them. Most of the time, they are not designers. They don’t have design training. Why are we asking them to do design work?If I could find my copy of Bill Buxton’s Sketching User Experience (which I have conveniently misplaced on the day of London UX Bookclub, d’oh!) I’d find the part in it where he talks about how ‘reading’ design, interpreting sketches, is actually as much of a design skill as doing the design in the first place – it’s just one we don’t talk about and don’t place any value on. Part of the reason designers often snort at the feedback given to them by clients (or community members) is because of a lack of design literacy in their feedback. Well, of course. They’re not designers.

Your mission when designing with community is to facilitate the community to make good design decisions by working with the information and insight they provide to give them good design and help them understand the design strategy and how and why it works.

Giving the community a true and meaningful voice in the design process is so much more empowering and respectful of them than letting them vote for which design they like the best. Letting a community choose a design by popular vote is, in my opinion, relinquishing your responsibilities as designer.

Help make Drupal7 amazing – what we’re doing at Drupalcon

You may have heard the excellent and very exciting news that following on from our work on Drupal.org, Mark Boulton Design has been contracted to take a look at the User Experience for the upcoming Drupal 7, and I’m very happy to be working with him on this project as well.

Our last project, Drupal.org, kicked off at the Drupalcon in Szeged which was a fantastic way to begin the process of immersing ourselves in and communicating with the amazing Drupal community. Happily, this project will also kick off at a Drupalcon, this time in Washington DC and starting next week – if you’re going to be there we would love to meet you and I thought you might like to know of two of the activities we plan to kick of whilst at the conference.

1. Blue Sky Design Workshops

We’re going to be running 3 workshops during the conference that we’d love you to participate in, they’re going to be held on Wednesday 3-4pm, and Thursday 9-10am and 11.30-12.30pm.

We’re calling them ‘design’ workshops, but that doesn’t mean they’re meant for designers only. These workshops are made up of a few fun activities that will help us explore the boundaries of what Drupal 7 could be. We want people from all different backgrounds and areas of expertise, and all levels of experience with Drupal – the only thing you need to be passionate about Drupal and the desire to see the next version of Drupal have an amazing User Experience to come along.

If you’re interested in participating, signup for one of the workshops using one of the links below:

Wednesday 3-4pm
Thursday 9-10am
Thursday 11.30-12.30pm

There’s only space for 10 people per workshop, so get in quick!

(If you do try to register and all the workshops are booked out, there’s a waiting list here. Yes, we’re optimistic!)

2. Pimp My Admin

The second activity we’re launching at Drupalcon is a little activity we’re code-naming ‘Pimp My Admin’. This is how it works…

One of the great things about Drupal is that you can bend it to your will – get it to do just about anything you need it to do. Same goes for it’s administration interface (admin).

Before we get to redesigning the Drupal7 Admin, we’d love to see what you out there have done to make the Drupal Admin System do what you need it to do, or just to work better for you and your project.

Here’s how we want to do it – simply take a little screencast, see if you can make it shorter than five minutes – walk us through your admin system and show us what you’ve done, even if it’s just something tiny – to make Drupal work better for you. Then you can either send it to us or, better still, post it up to YouTube – we’re still working out the details of exactly how to share these screencasts, but stay tuned for details. Meanwhile, if you’re going to be at Drupalcon, come find us and we’d be more than happy to sit down and do a screencast with you!

Come find us!

Even if you’re not interested in either of those activities, if you’re at Drupalcon and you’re interested in the redesign, please do come and say hello. We’re hoping to be very conspicuous and easy to find and we’ll have our suggestion box out and our ears reading for bending. We’re looking forward to meeting you and learning lots!


design by committee vs design by community (things we learned from the Drupal.org project)

Recently I presented a casestudy of things that we learned about designing with a community, the Drupal community, at the Interaction09 Conference in Vancouver. (I’m still trying to get my slides down to a reasonable size to post on Slideshare!) It was a short presentation so I thought I’d take some time to flesh out some of the ‘things we learned’ here for anyone who is interested. It certainly was an interesting, challenging and fairly unique project, and we’ll be doing more like this in the future, perhaps you will be too! This is the first post in a series of our learnings.

Often when I talk to other designers about the Drupal.org redesign project they can’t stop themselves from shuddering at the thought of having so many people involved in their design process.

It’s an understandable reaction – after all, how many of us have suffered design by committee, which is really it’s own special circle of hell, in which a group of somewhere between 3-12 (usually) stakeholders with various levels of authority (actual or effective) provide copious and detailed feedback to your designs – feedback that often conflicts either with itself, or with the objectives of the project, or just with the principles of good design. Usually these people are the people who are responsible for paying your salary or invoice. They can’t be ignored. As Whitney Hess tweeted and then blogged, they have itches that need to be scratched.

So, it seems logical that having thousands of people involved in the design process should be even worse right? Design by committee on steroids? Well, you might think so but, happily, you’d be wrong. It’s really a whole different beast with it’s own challenges and opportunities and – I’m happy to report – there is much more good than bad about design by community and it’s an approach that I’d encourage you to consider. (Unlike design by committee, which should be avoided at all costs.)

The main reason for the different experience is scale. Surprisingly, scale is your friend.

When you’re dealing with feedback from hundreds of people you don’t need to address every single issue raised. You’d be mad if you did and have no time for getting the design work done. Rather, what you’re looking for three things:

  1. emergent trends: what are the issues that multiple people are mentioning or agreeing/disagreeing with. If half a dozen people mention it, it’s probably worth looking at.
  2. unexpected comments: every now and then you’ll see something that takes you by surprise. (This doesn’t include comments like ‘your design sucks’ which you will get no matter how wonderful your design is – you have to learn to not be surprised by these!). When you get that ’surprise’ feeling (you know the one) – pay attention, even if just one person mentions it.
  3. obvious pickups: – with a few thousand fresh sets of eyes, obvious mistakes, things you’ve just left off or misspelled for example, will get picked up quickly. Acknowledge those as quickly as you can so that they don’t turn into big (and often dramatic) conversations.

The absolute best way to a respond to an issue is in your design, rather than in responding to comments on a blog, messageboard, flickr posting, tweet or wherever you’re gathering your feedback (and I’d encourage you to keep it fairly messy and don’t just do it in one place – more on that in a later post!). You should stay in touch with the conversation and respond when appropriate (again, that’s a whole other post!), but the ratio of your responses to comments should be at least 1:10, if not closer to 1:50

This is quite a departure for most of us who are used to consolidated feedback lists and having to respond to every piece of feedback we receive, to begin with it almost feels a little naughty (at least, it did for me!) – but it is a really necessary approach if you want to maintain your integrity and not reliquish your responsibilities as the designer.

Remember – just because you’re working with a community doesn’t make this a democratic process. Design should never be democratic. We’re not voting on interface elements here, we’re working with a community to let them help us the best way they can – by telling us about their community and their product, in this case the drupal.org website and what they use it for, and drupal itself of course. Communities aren’t designers – they can give you a lot of GREAT information to help you design well for them, but that’s the crux of the issue – you need to find ways to work with them so you can get from them what they do and know best, and so you can do what you do best – design great experiences.

A big part of your role on a project like this is facilitation and communication, but don’t let those roles waylay you from your most important responsibility, which is to do good design.

It’s a terrifying but exhilarating experience, this community design caper. If you have an appropriate project, I’d really encourage you to give it a try. I’ll be sharing more of what we learned soon!

UX Bookclub, London – Announcing first meeting 25 Feb

In the past month or so, UX Bookclub’s have started popping up all over the world. I’m pleased to let you know that the same is about to happen in London, and if you’re interested in reading about and discussing issues related to User Experience, then you’re more then welcome to come along!

We’re meeting at 6.30pm on 25 Feb at BDP Studios, in Clerkenwell and we’re going to be talking about Sketching User Experiences: Getting the design right and the right design by Bill Buxton.

We can only host limited numbers so if you’d like to come along, please register here.

Look forward to seeing you then!

Come to UX London!

UX London

People of, or near, London, have you registered for UX London yet? It’s a brand new conference brought to you by the people behind the most excellent dConstruct conference. I’m very excited about UX London not only because I’m lucky enough to be running a Design Research workshop, but also because we’re going to get to see The Don, Dr. Don Norman, live and in the flesh.

Please stop me from asking him to autograph my copy of ‘The Design of Everyday Thing’. That would be almost as embarrassing as when I asked Jesse James Garrett to autograph my copy of ‘The Elements of User Experience’. (Fortunately I don’t think JJG remembers that).

There are a bunch of other great speakers including the ever entertaining Jared Spool, Peter Merholz, Jeff Veen, Donna Spencer, Eric Reiss, and more, more, more!

Anyway, UX London promises to be a great couple of days of talks and workshops, with an emphasis on practical learning that you can take back and apply to your own practice immediately. I know, for one, that my Design Research workshop is going to be all about sharing a lot of what I do now for work, especially the range of design research approaches and analysis methods that I use for all kinds of clients and projects and, importantly, budgets.

I hope to see you there!

Drupal.org redesign – why is it so? Some insights into our design strategies.

Drupal Redesign V10

Over the past few days I’ve been posting a lot in the Drupal Groups at Drupal.org about the rationale for some of the design decisions we have taken on the Drupal.org redesign. I thought you might find them interesting, so I’ll copy them over here as well.

In particular we’re talking about why the header is so big, the global navigation is so small, search is so prominent, the ‘dashboard’ tabs are more prominent than the global header and why there is no ‘download now’ link on the homepage.

I can’t guarantee that the rationale is entirely holeproof, however it has definitely been based on paying close attention to what a broad range of people want to do on Drupal.org, making some decisions around how to best prioritise these needs, designing to suit these prioritised needs and then testing to check that the new design does actually support key user tasks.

There is one fatal flaw in this version of the redesign and that is that we accidentally left off the big ‘Get Started’ call to action from the homepage… d’uh! (Definitely one of the downsides of designing at speed to fit into weekly iterations is that these kinds of oversights can happen – thankfully the Drupal community let us know about it quick smart!)

You can see the interactive prototype here and the historical archive of the past 10 iterations here.

This is directly copied from my forum posts so hopefully make sense in this context… be warned… it’s long!

Post One: Get Started and the Download Button

evaluating a website design is a really difficult task, as the discussion here and elsewhere demonstrates. It is tremendously difficult to see the design from perspectives other than your own and to get some kind of distance from the content. It is also really hard to judge how well a design works from just looking at it and meandering through it – it can really only be properly judged ‘in action’ – does it actually let people achieve the tasks they need to achieve. Does it make easy things easy? Does it make difficult things achievable? Does it support the objectives we have for Drupal as an organisation? for Drupal end users? and on and on. This is why we’re trying to get the design out in as many ways as possible to see how it’s doing – both online and in person, amongst ‘insiders’, ‘outsiders’ and another groups we’ve recently started calling ‘mid-siders’.

Disclaimers aside, there are a few things that might help move the conversation forward, hopefully! I’m going to tackle the first one here and some others in posts to follow shortly.

Get Started and the Download Button

you are dead right, the strong call to action for Get Started from the homepage has disappeared and this was an oversight on our part. Expect to see this re-instated on the next iteration and thank you for making us aware of it. We have been focussing a lot more on other ‘internal’ pages and just made a few small changes to the homepage this iteration which resulted in this dropping off. Our bad.

If you’ve been following the redesign you’ll probably have noticed that we actually started with an enormous ‘Download’ button, which then evolved into an enormous ‘Get Started’ button which then evolved into more of a ‘Why Choose Drupal’ section. As Mark said, this is a part of a deliberate strategy on our part to ‘bury’ the download button a little – what we are trying to do is to make sure that they actually know what they are getting into when they ‘download’ Drupal, and to ’scaffold’ that experience a little.

We want them not to expect it to be completely easy to set up a website using Drupal (not to apply mental models of the hosted blogging services, for example, which seem to be quite strong in people’s minds), and we want them to know that there is both a strong and supportive opensource community and commercial ecosystem that can help them along the learning curve if they need it. And, I’m sure you know this already – a lot of people who are interested in Drupal will need that support. For many people who are evaluating Drupal as a solution, particularly within larger organisations, the last thing they should be doing is downloading Drupal.

So, the people we are primarily designing the homepage for are people who are coming to Drupal.org to consider it as a solution for whatever their requirements are, and who are not particularly experienced developers, or possibly not even particularly experienced with Content Management Systems/Platforms/Frameworks etc. This means that people who do have this experience, who do understand the existing Drupal vocabulary, who do want to evaluate the platform by downloading it and taking a look – these people are going to have to work a little harder to get to what they want and they will have to put up with some fluffy language (like the Legos, although I think the Lego reference is being deleted as I write this… which I think is a bit of a shame actually). But the thing is that this audience is capable of doing that little extra work, and they are also more likely to easily recognise what is so great about Drupal.

So, to summarise,

  • we are deliberately making the download link a little more difficult to find so as to better support the experience of newcomers to Drupal who do not have the ability or time to evaluate the product by downloading it, however;
  • the current iteration is missing a strong call to action to ‘Get Started’. This was a (bad!) oversight on our part and we’ll make sure it gets back in there in the next iteration.

I hope this helps make things a little more understandable. Do let me know if you have any questions that I can answer regarding this. I’m going to post some notes re: the size of the header and the placement/relative size of the global navigation next. If there are other issues you’d like me to address specifically, then let me know.

Post Two: That header is so big and it’s all about search? What the?!

First up, I’d like to acknowledge that yes, that is one big old header. It is bigger than your average header and designing a header that size does mean that you’re going to fit less ‘above the fold’. This may seem like an unusual strategy, but it’s certainly not unique, nor does it imply bad design or usability IF it is being done to support a strong strategic objective.

Hopefully you won’t be surprised to hear that we do have some strategic objectives in having such a big-ass header!

Again, if you have been following the redesign process, you’ll have noticed that the big-ass header is actually a relatively recent introduction to the homepage design, coming as late as iteration 7. Here is the last version before it: http://drupal.markboultondesign.com/visual/iteration6/homepage_notlogged…

1. approachability

Use of white space (or in this case, blue space) is very important to design, as I’m sure you know. Allowing breathing space around elements helps you to more easily review the content on the screen and for the designer to guide your eye from element to element. Mark is much more the expert on this tho, (In face, he’s written a bunch about it that is not directly relevant to this conversation but you might find interesting here: http://alistapart.com/articles/whitespace/ )

When I’ve been observing people using this ‘big ass header’ design, the response has been overwhelmingly positive. People say that it feels calm and approachable and easy. People have compared it to a horizon line. It does seem to create a positive effect. This is great because we are trying to ensure that people aren’t overwhelmed by Drupal, and that they feel positive in their ability to understand and engage with it. Everything that I’ve observed to date has demonstrated that the big-ass header is very helpful in achieving this end.

I can’t overstate how intimidating Drupal can be to novice users, although it may strike you as ridiculous. Alleviating this intimidation without getting in the way of active Drupal users is one of the big challenges for this project and the size of the header is a big part of that.

2. focus on search

As you’ve picked up, one of the reasons that the header is so large is because the search element is so large. As with the header, this is somewhat unconventional, but we’ve done this to support the way that people want to use the Drupal.org website.

I’m going to do a separate post about the size/placement etc. of the global navigation and the rationale for that, but suffice to say that for the majority of users, and especially for regular users of the site, Drupal.org is not a ‘browsing’ site- it is predominently a searching site, and secondarily a place to monitor and engage with activity and conversations.

This makes perfect sense, though, when you think about what people actually come to the site to do.

This is a big part of how we conduct our research. A lot of it is talking, asking people about what tasks they need to do on d.o, watching how they currently perform those tasks (much use of Google, as you’d imagine!), getting them to perform those tasks on the new design.

Invariably, for regular users of Drupal, search was the way that people wanted to get to their content. Many people would just just Google search, when compelled to use our redesigned site, they’d go straight to search. I can’t tell you how many times I’ve had to ask people ‘if you had to use the navigation, which link would you choose?’ when asking them to perform a task. This was true back when the global navigation was much more extensive and prominent, and it remains true today.

It was in response to the strong demand for search that we re-made the header to be so big and search focused.

We did some A/B testing between the more conventional navigation approach and the search-centric approach and the search-centric approach was more successful.

If you’re not convinced I’d encourage you (as I have encouraged the community throughout the project) to do your own research – get people who are regular d.o users to define the tasks they do on d.o and have them ‘do’ the tasks using each of the designs – and see what you find. I’d be really interested to hear the results.

Finally, the size of the search element is a show of faith in the ability of the d.o search to ‘do the job’ in finding the information. Generally speaking, search on sites is rubbish and a conventional positioning carries this expectation of rubbish-ness.

The bold positioning of the search element here says – search is the right option for finding what you’re looking for. Give it a try. (And yes, we have been assured that much work will be done on the search functionality for Drupal.org so that it does deliver on this promise).

3. search ‘furniture’

Some other feedback we’ve received is about the ’stuff’ that’s around the search field and that it takes up space/wouldn’t be used etc.
I agree that the vast majority of people won’t refine their search on the homepage, nor will they use the ‘most popular’ searches… although these are able to be used, their primary purpose is to give information about the search capabilities of the site and to help people use the search properly.

By showing the ‘filter’ options, what we are telling people (more or less subconsiously) is the types of content that will be shown in the search results and that you are able to filter out types of content. We’re exposing the range of content on the site and providing a hint that the search will be more fully functioned than a typical ’sitewide search’, and certainly than the current d.o website. (and yes, significantly improved search functionality is on the menu for the implementation of the redesign!)

By showing the ‘popular’ searches what we’re doing is alleviating ‘blank page syndrome’ – what do I search for? They are tiny prompts that are intended to help people formulate a search query, and especially if they are relatively new to Drupal, help to expose what others are looking at.

I could quite happily live without ‘popular’ searches, or replace it with something else, but the ‘filter’ options play an important role and should not be removed. In fact, we intend to add ‘API’ to the list of filters in the next release.

search results

A big part of this strategy is a much improved search results page. We’ve only shown hints of this so far in releases, but the next iteration will hopefully show the enhanced faceted navigation within search results to make it a really powerful and useful tool for locating information on the site.

not everyone searches!

There is an important audience who do NOT search, and they are our newer, less technical/experienced audience. They are the least likely to use the search element, and for that reason, the majority of the ‘index’ or ‘landing’ pages are designed specifically for their needs. Starting with the homepage and through all of the ’section’ landing pages.

OK. That’s a bit of an overview of the rationale and reasoning.

Post Three: Teeny, (Relatively) Tiny Header

ok. This is the last in my series of three monster posts trying to throw some light on why things are as they are in the Drupal.org redesign.

Before you read this, make sure you’ve read the previous monster post on the big header and search, it’s related.

Several people, on this forum and others, have made note of the fact that global navigation on the current design is relatively understated and certainly not one of the most prominent elements of the design. Absolutely true and, for what it’s worth, entirely intentional.

Why so? Well, a number of reasons.

First and foremost, when we considered what the most important and most frequent user journeys on d.o would be, accessing the landing page for a site ’section’ was very low on the list. Finding out about Drupal, getting access to specific information, monitoring issues and continuing conversations – these were much more important. None of these important user journeys require global navigation.

For ‘new’ users (outsiders) , we consider the movement from Home to About/Why Choose Drupal and/or Get Started the most important user journey. (granted you can’t tell this from the missing links to these on the current iteration homepage – our bad, and an accidental omission as discussed elsewhere)

for ‘existing’ users (insiders) the primary user journeys are to specific content via search/search results and to monitor content/issues/discussions/news etc. which is done via the dashboard.

Hence the emphasis on the search element and the dashboard element (which for existing users will generally replace the generic homepage and will be highly customisable and focussed on monitoring content of personal interest). And hence the demotion of the generic ‘global’ navigation.

We also know that you guys, once you get involved with Drupal, don’t tend to use the global navigation yourself. You use bookmarks, you use the URL (eg. groups.drupal.org etc.) using the browsers memory – both of these are more efficient than going to the homepage and navigating through a hierarchical navigation structure.

Yes, it does seem like a somewhat unorthodox approach, and contradictory to ‘good usability’, but that’s not necessarily the case either.

There is a lot of evidence that shows that people would really rather NOT use global navigation if they can avoid it. People much prefer to use contextual (in content) links for navigation and local (relevant to that section) navigation to get to where they want to go. Global navigation is usually used only as a last resort (or if someone forces you to use it in a usability test!)

Again, if in doubt I encourage you to conduct your own research. Get people to define a few tasks that they would ‘do’ on d.o then put them in front of this prototype and ask them to do the tasks here, and watch them. very few people will go to the global navigation as their first port of call. In my experience, if they are doing that, it’s because there is important information and links missing from the central content area.

A few authors more eminent than me have written on exactly this behaviour. If you have a moment, take a look and see what their experience has been with global navigation vs. local/contextual navigation and search.

http://www.useit.com/alertbox/20000109.html
http://blogoscoped.com/archive/2004_05_25_index.html
http://www.guuui.com/issues/01_05.php
http://www.uie.com/brainsparks/2005/10/19/global-navigation-not-worthwhile/

hope this makes sense and, as ever, awaiting your feedback.

Drupal.org redesign – a strategy for the documentation section

Docs Home

Leisa Reichelt:15:36:39
ok. here’s the theory
Leisa Reichelt:15:36:49
drupal documentation is essentially like wikipedia
Leisa Reichelt:15:36:53
lots of pages
Leisa Reichelt:15:36:59
it’s not hierarchical
Leisa Reichelt:15:37:06
because it is grouped around so many things
Leisa Reichelt:15:37:14
so doing a hierarchical IA for it is nonsense
Leisa Reichelt:15:37:23
will only show how complex it is and where it is incomplete
Leisa Reichelt:15:37:25
which we want to avoid
Leisa Reichelt:15:37:30
hence our emphasis on search
Mark Boulton:15:37:32
yep – agree with that
Leisa Reichelt:15:37:44
ok, that’s the first part of the strategy
Leisa Reichelt:15:37:46
here’s the next
Leisa Reichelt:15:37:53
there are three key pathways to documentation content
Leisa Reichelt:15:38:01
1. i have a specific problem I need an answer to
Leisa Reichelt:15:38:05
in which case, i search
Leisa Reichelt:15:38:16
2. i’m new at drupal, or some aspect of drupal and I need to get up to speed
Leisa Reichelt:15:38:31
in which cse, i need access to some ‘designed’ content (eg. tutorials)
Leisa Reichelt:15:38:37
and I’m likely to hit the docs landing page
Leisa Reichelt:15:38:52
or 3. i need more information about <x> which I am looking at now
Leisa Reichelt:15:39:02
eg. I want to see the documentation associated with this module that I might choose
Leisa Reichelt:15:39:12
in which case, I want to see the documentation contextually linked
Leisa Reichelt:15:39:21
convincing so far?
Mark Boulton:15:39:27
absolutely
Leisa Reichelt:15:39:30
ok
Leisa Reichelt:15:39:38
so, pathway A is covered already
Leisa Reichelt:15:39:54
pathway C is also covered (although we’ll need to check for other places where contextual linking is appropriate)
Leisa Reichelt:15:40:02
pathway B is the tough one
Leisa Reichelt:15:40:13
because what *is* this section if we don’t have hierarchical navigation?
Leisa Reichelt:15:40:24
what do we have to draw inspiration from?
Leisa Reichelt:15:40:30
wikis, of course!
Leisa Reichelt:15:40:55
so, the sub navigation for docs becomes something like: docs home | API | Index | Recently Updated
Mark Boulton:15:41:03
makes a lot of sense
Leisa Reichelt:15:41:10
API needs to be kept separate I think
Leisa Reichelt:15:41:21
and we can play around with exactly how the INdex works
Leisa Reichelt:15:41:37
and then the landing page of docs is all for new people needing structured guidance
Leisa Reichelt:15:41:52
so it links off to whatever of this we have available
Mark Boulton:15:41:58
sort of orientation
Leisa Reichelt:15:42:00
including, I think, the recipes?
Leisa Reichelt:15:42:07
yes, indeed.
Mark Boulton:15:42:19
I like it – it solves the problem
Leisa Reichelt:15:42:24
and there are two main kinds of documentation pages
Mark Boulton:15:42:40
plus it gives the freedom to the community to tailor it to their needs as they evolve
Leisa Reichelt:15:42:43
the actual documentation, and then a more flexible ‘index’ template that people can use to group documentation in whichever way they like
Leisa Reichelt:15:42:52
exactly
Leisa Reichelt:15:43:16
and, it doesn’t make it look as though there is too much/too little documentation at a glance
Mark Boulton:15:43:28
exactly – the holes aren’t as visible
Leisa Reichelt:15:43:35
exactly
Leisa Reichelt:15:43:38
ok.
Mark Boulton:15:43:47
I might do a dance now
Mark Boulton:15:43:50
:)
Leisa Reichelt:15:44:00
lol

Docs - Article