Drupal.org – One site or many?

One of the information architecture questions we need to resolve for Drupal.org is whether we try to make it one cohesive website experience, or whether (as it is now) there is a ‘family’ of mini-sites that make up the online experience of Drupal. 

The current family consists of drupal.org, groups.drupal.org, api.drupal.org, association.drupal.org and more (including a proposed developer.drupal.org).

It seems to me that it has been mostly through the organic growth of the site and of Drupal itself, some technical and perhaps some social issues that have lead to the propagation of all these mini sites. Creating a new site helped get the required content or functionality up and running where as, if it had to go into the Drupal.org infrastructure it may never have come into existence.

Some of the mini-sites theoretically appeal to all users (for example, the ‘groups’ should have almost universal appeal. Others, like the API, are perhaps more targeted towards the technical audience.

The question now is – given that we essentially have a blank sheet – should we attempt to pull everything back in under the umbrella of a single ‘drupal.org’ entity?

The proposed Information Architecture that we received as a part of the RFP for this project seemed to indicate that this was the preferred approach (ref: http://groups.drupal.org/node/10003)

In my experience, however, a better experience is usually created by trying to architect content into one website, rather than a family of sites. There are, obviously, exceptions to this!

I’m interested in hearing what you think about this question? What do you think are the advantages and disadvantages of the ‘one site’ approach? What, if any, content should be shelved onto a separate site, and why?

Drupal.org – Help Overhaul the Information Architecture – participate in our online card sort!

Continuing in the community led approach to the experience design, let’s get started taking a look at the information architecture.

A really useful exercise to help understand how people organise, understand and label/name information is to do a card sort. (Ref: A definitive guide to card sorting)

As we’re scattered all over the globe, we’ll have to settle for an online version. I’ve actually set up two versions of the card sort because I particularly want to understand differences between the way that ‘insiders’ and ‘outsiders’ deal with drupal.org information.

If you identify as an ‘insider‘ (which might reflect either your expertise and/or closeness to the drupal community) and you want to participate, please go to this link and participate in the cardsorting exercise.

If you identify as an ‘outsider’ (particularly if you’re new to Drupal, but also if you don’t feel close to the community) and you’d like to paticipate, then your cardsorting exercise can be found here.

It should take you about 15-20 minutes to complete the exercise, so be sure to get yourself a nice cup of tea before you get started!

This is just an information gathering exercise – it’s not going to define the Information Architecture, just help give us the understanding we need to help shape it correctly. Don’t worry too much if there is information missing (we’re just using a sample of the entire site(s)) and don’t worry if you don’t understand what a card means, and feel free to leave copious comments as you go through the exercise – there is a space for you to do so.

As ever, I’ll let you know what interesting things we learn as they come to hand.

(Remember, you can also participate by submitting some wireframes!)

Drupal.org – come wireframe with me!

There is a design game that I like to play when I’m working face to face with my client (and when there aren’t thousands of stakeholders!) which involves everyone on the project sitting down together and individually sketching up some wireframes that then get shared back into the group.

Aside from being good fun, it is also a really great way to uncover good ideas, common themes, and a whole raft of information and assumptions that haven’t yet surfaced in the project but that are important to us getting the design and information architecture right.

I don’t see why we should let our ‘virtual workspace’ stop us from playing this game, so, let’s do it. Let’s do some wireframing together!

Here’s what I want you to do:

  1. pick a page on Drupal.org – it could be the homepage, it could be your profile page, it could be a project page, it could be a page that doesn’t exist that you think *should* exist – just pick one that is important to you.
  2. have a go at sketching out what you think might go on that page. What are the content and functional elements, and which ones are the most important.
  3. post the page somewhere – if you’re using Flickr, you can post it to our Flickr Group, or perhaps you want to post it on your blog and put a link to your post in the comments here, or you can email it to me if you like and I’ll post it – whatever you prefer. You might want to add some notes as to why you’ve approached the page the way that you have or, if you’re like me, to decipher your handwriting.

You can use whatever you like to wireframe – I tend to use pen and paper to start with or sticky notes. Then I’ll use Omnigraffle a little later. You might prefer to sketch in code. Whatever works for you. As you can see from the example I’ve posted above, early wireframes are usually pretty rough (mine disintegrated into a list at the bottom!) and not so pretty. This is fine. It’s not about how they look or even whether they’re right. It’s about getting ideas down on paper – to paraphrase the old saying – a wireframe is worth a thousand words.

Don’t spend too long on it – try to spend no more than a few minutes on a wireframe. If you’re not happy with it (and you probably won’t be at first!) just put it to one side and start fresh. You don’t want to labour over them too much at this stage.

Don’t think you have to be a designer or a UX person to participate in this exercise – this is all hands on deck. Even if you’re not an experienced Drupal user and you were flummoxed by your experience of Drupal.org – what did you *want* to find on the homepage?

I know there have been lots of discussions over the years about various parts of Drupal.org – let’s roll up our sleeves and get stuck in! Yay!

Outsiders and Insiders – Understanding Drupal.org users

OK, there are two important first steps you need to take when contemplating a design (or, in this case, a redesign) – understanding what the business/organisation wants the design to achieve, and understanding who your audience/customers/users/potential users are, and what they want to achieve, what their goals are.

A really common way to capture this information about users is in the form of personas. The personas can then be referred to throughout the design process to test that what you’re designing is actually the right thing for your end users, and to help you to prioritise functionality and content on the site. Basically, to stop you trying to be all things to all people, which as we know, is the fast track to failure.

Now, I’m the last person to suggest that personas are highly scientific (although some people do work very hard to make them statistically sound) – to me, this is not the best way to spend project time. It is imperative that personas are based on research though – going out and actually meeting a bunch of people who form your target audience, because very often, the personas you need (or, at least, the way you ‘break down’ your audience) is what it might first seem.

The Drupal Community put together some personas a while ago, featuring characters like Mary the Manager, Tim the Tool-User, Wendy the Webmaster and more. As you can probably guess, they are based on the ‘role’ that users are playing in relation to Drupal. At first blush, this seems like a logical way to segment the Drupal audience.

It is an important segmentation but – as I’ve discovered over the past few weeks – I don’t think it’s the most important one. Firstly, as we saw in our survey, and this was supported by what I heard when talking to members of the Drupal community, very many Drupal users work across a range of different roles. They do some developing, some designing, some decisionmaking, some sales… all kinds of things. I don’t know this as a fact, but I’d hazard a guess that the ‘pure’ Drupal developer is actually a minority. Just a guess.

At any rate – it doesn’t really make sense to have Danielle the Designer as a persona we’re designing for because Danielle is much more likely to do some code, some design, some content administration, some dealing with clients. The role based persona doesn’t accurately reflect the kind of people we’re meeting out in Drupal-land.

Proposed segmentation – outsiders and insiders

I think our audience segmentation for Drupal.org should actually be a lot simpler than personas – it’s about ‘outsiders’ and ‘insiders’ and the path that people take from their first encounter with Drupal.

Insiders:

Insiders are those of you who are close to the Drupal community – who know and love Drupal and the people who gather around it. You understand ‘Drupal-speak’, you know who’s who in the zoo, you ‘get’ open source. You’re clued in, and you’re also incredibly important to the ongoing success of Drupal – both through the project work that you’re doing (if you’re an ‘insider’ you’ll know what I mean by ‘project work’, if you’re an outsider, you probably won’t – see, Drupal-speak in action, I’m rapidly being indoctrinated!). Also through the community work that you’re doing – Drupal ‘insiders’ are critical to getting people over the ‘brick wall’ I was talking about in our Experience Strategy, they are the people who help ‘grow others up’, or to educate them in the mysterious ways of Drupal. They’re very important people.

They are most likely to be, but not exclusively, developers. Or, at least, to have written code in a past life. This is why Drupal-speak is very much techy-speak.

Outsiders:

Outsiders don’t know much about Drupal, although they have have installed it and gotten a site (albeit ugly) up and running. They may not know what a module is, although they may have posted on the Drupal forums seeking help. They definitely don’t know about the IRC channel where the insiders live. They are facing a fairly steep learning curve (including learning Drupal-speak!). They haven’t ‘hitched their wagon’ to Drupal – yet. They might get a better offer elsewhere.

Along the engagement pathway:

Some of you will identify as Insiders and some as Outsiders, but very many will fall somewhere along one of the ‘engagement’ pathways I’ve scrawled in the picture above. Some of you know a LOT about Drupal, but you’re not a developer so you don’t feel like you’re a ‘proper’ insider. Some of you are well on your way to becoming an insider, having gotten access to the right tools and – more importantly – the right people! Some of you used to be much more of an insider but have other things on your plate at the moment that have drawn you away a little. Some of you have tried to head down the engagement path, but are being thwarted or scared off.

As we move forward with the redesign, this is the model that I’m suggesting we use to evaluate the work we’re doing – to consider this engagement pathways and to plot some key points along it and to see whether what we’re suggesting is going to support users at each of these points on the pathway.

This way, we avoid designing only for those of us who are loudest (and probably most engaged in the community), and we maintain a focus on the range of experiences we need to support on drupal.org – maintaining focus on what matters – the people who use the site, rather than the technology, or the tools or anything else that needs to be wrangled into a good user experience.

What do you think? Does this make sense to you?