Archive for September, 2008

Drupal.org – What we learned from the Community Wireframing Project

 Stickynotes

I thought you might be interested to know a little about what we did with all the wireframes people submitted for the Drupal Redesign Project.

Around 30 wireframes were submitted, mostly to the Flickr group, but also on Drupal Groups and other locations (linked to in the comments of the original post). I think this is a really great effort and I am really pleased with the participation in the project.

It wasn’t just a fun exercise though, so since receiving the wireframes I’ve been doing a little work to try to understand what this exercise can tell us. In order to do so, I’ve been making a page for each template that people chose to tackle and then making a little sticky note for each piece of content/functionality or concept that people included on their wireframes and tracking how many times an idea was included. 

This process helps us to confirm a) which templates people are thinking about most (the homepage (predictably), community, support, project and documentation type templates were most common), and also b) what kinds of content they expect to be able to find on that template.

The results are certainly not a prescription for which templates we design and what goes on them, but it is a useful input to the process, particularly as a cross-check – to make sure that the ideas we are suggesting aren’t omitting anything important, and that we have considered all of the ideas generated from this exercise in the process of working on the wireframes and prototype.

Most excitingly, though, we hope that this exercise has helped to encourage more thinking about what the new Drupal.org can be, and to trigger some really interesting conversations – in particular some great ongoing discussions around the project page, and integrating groups and projects over in the Redesign Group.

Don’t feel that you have to stop now though – drawing things out is a great way to communicate your thoughts and give us feedback (can save a thousand words, so they say) – if you’ve got an idea or something you’d like to share, feel free to run up your own wireframe – pen and paper is fine! – and post it either to the Flickr group, or your blog, or to the Redesign Group, and let’s talk about it!

Drupal.org – more thoughts on the Information Architecture (Part 1 – Projects, Downloads etc.)

Thanks to everyone who gave feedback on my initial thoughts on the information architecture – it was certainly food for thought and, as a result of that and some more work on our part, we’ve moved on a little in our thinking – I’d like to share some thoughts and some questions with you now, for your consideration.

Download/Project

In my previous post I suggested that perhaps two different faces on essentially the same content could be valuable – one being ‘download’ which would be used by people who were using Drupal as a tool and looking for the core, modules and themes to download and use, and one being ‘Project’ which was targeted at developers involved in further developing and, of course, maintaining Drupal, the project.

After hearing all the feedback to this, I now agree that this is not a great idea – in a nutshell because, as you have said, we don’t want to create such a void between using Drupal and contributing. Also, given that we have a ‘getting started’ page, people who are less familiar with Drupal will be directed there, and from that section they can be given an easy guide to what to download and from where.

So, based on your feedback to date, let’s remove ‘Downloads’ as a section or sub-site.

Information Scent for Core/Modules/Themes/Translations: I’m thinking of a word that is *like* ‘Project’ but makes sense to ‘outsiders’

That leads me to one of the reasons I suggested ‘Downloads’ in the first place – being that ‘Project’ is a very ‘Drupal’ word. To someone who is versed in Drupal-speak, ‘Projects’ means ‘things that we’re working on, like the Core project, Modules, Themes, and even Translations/Localisation. But for someone who is NOT Drupal-speak-savvy, ‘Projects’ or even ‘The Drupal Project’ is not good information scent for really important (perhaps some of the most important) content on the site.

Non-Drupal-speak-savvy people will not look under ‘Projects’ for Downloading Drupal, Modules, Themes or Translations… so we need to come up with a label for this part of the site that makes sense to everyone. (Or, at least, gives them a clue of what might be contained within, sends them in the right direction).

The card sorting exercise gives us the following insight:

  • When asked to categorise ‘Contributed Modules’ participants who identified as ‘outsiders’ used terms like ‘Development/Developers’ and ‘Downloads’. 
  • When asked to categorise ‘Themes’ participants who identified as ‘outsiders’ used terms like ‘Designers’ and ‘Downloads’. 
  • When asked to categorise ‘Translations’ participants who identified as ‘outsiders’ used terms like ‘About Drupal’ and ‘Developing’ 
Now, we know that we don’t want to use ‘Downloads’ because it doesn’t reveal the ongoing project work and encourage participation. I have given quite a bit of thought to creating ‘Developer’ and ‘Designer’ sections and splitting content off that way, but my gut feeling is that is a highway to pain – primarily because both the content and audience are rarely clearly divided into one of these categories – I imagine there would be an awful lot of crossover – and also because it seems unnecessary (and less than ideal) to divide the Drupal community by role.
That leaves us with the enormous question of – what do we call the section currently called ‘Download’ (on the Drupal website) and ‘The Drupal Project’ (on our proposed IA), from which the Core project, Modules, Themes and Translations can be accessed. It’s got me stumped for the moment, so I’d love it if you can throw some ideas at me. 
Or perhaps the whole idea of having one section to house all of this is the problem, and we need to expose the contents of this section at a higher level?
Any thoughts you have on removing the ‘Downloads’ subsite and re-naming ‘The Drupal Project’ sub-site would be most welcome! (Insiders and outsiders both!) :)

Drupal.org – what makes up Drupal.org Community?

I’m going to call on your expertise again to help me think through an issue for the Drupal.org redesign. This time we’re thinking about community.drupal.org, which is theoretically the community ‘hub’ of drupal.org.

At the time I proposed it, I imagined it being a place where both Groups and Forums would live and potentially also Planet Drupal and other community type ‘stuff’. Now that we’re starting to get into prototyping (yes, you’ll see it very soon!), the devil, of course, emerges in the detail…

The major part of Forums is – at least to my eyes – support. That being the case, putting it under a ‘Community’ label is not the clearest way to direct people to this support.

Other (apparently less important) content in the forums includes News & Announcements, General Discussion, Drupal Showcase, Events and Paid Drupal Services. Now, short of ‘General Discussion’ each of these other items have natural homes in the proposed new IA.

I’m also aware that there is a very active ‘groups’ section who have all manner of discussions going on (and, perhaps, quite a bit of duplication with forums?)

So, here is what I’m thinking… what if we pull forums apart a little. We *might* rename ‘Documentation’ to ‘Documentation & Support’ and include the support forum topics there. And we might retire the forum topics that are now duplicated in the main information architecture (paid services, news, events etc.). We might keep the ‘general discussion’ forum in Community, because it seems like a good idea to keep a nice ‘light weight’ place for all kinds of topics to be discussed, but the bulk of the Communities section would be groups.

The more we work on this project, the more obvious it becomes that Drupal.org is, in its entirety, a community site – so in our context, what does a ‘community’ section mean? I’m thinking that it means a place where the *topic* is more about the Drupal Community than it is the about the Drupal Project. But also that we want to intertwine these two much more than they are at the moment, so contextual linking is also going to be important.

How does that all sound to you?

Drupal.org – what we learned from the card sort

If you’ve been following this project you’ll know that we’ve been doing an online card sort recently to help inform the information architecture for drupal.org. To date we have had more than 200 people participate in this card sort exercise, which is a tremendous effort and a bucketload of data! Thank you all!

In particular we were interested in understanding how we group and label different types of content, and whether the language (as in terminology) varied between insiders and outsiders.

The card sort is still running but we have done an initial analysis of the results to date – the findings are not really so surprising, but nonetheless, useful to have available.

Essentially, what we found is that insiders and outsiders generally use similar words to group and label content where that content is not particularly specific to Drupal, or doesn’t involve ‘Drupal-Speak’

So, for example, for both insiders and outsiders there were lots of occasions where a significant majority of users grouped terms into the same category, for example:

  • ‘Local User Groups’ was grouped into ‘Community’
  • ‘Installation Documentation’ was grouped into ‘Documentation’
  • ‘General Concepts’ was grouped into ‘Getting Started’
  • ‘Getting started’ was grouped into ‘Beginner/New/Getting Started’ and ‘Documentation’ – both equally split in this way in both groups!
  • ‘Features and Mission of the Drupal Project’ was grouped into ‘About’
  • ‘Administer Drupal’ was grouped into ‘Documentation’

However, when it came to content items or terminology that was particular to (or used in a particular way within) the Drupal community, the split became  more apparent. Drupal ‘insiders’ familiarity with the current structure of the drupal.org website also seemed to come into play – in fact, sometimes people actually responded with a specific URL! (eg. groups.drupal.org). Examples of these kinds of content include:

  • Contributed Modules – responses from ‘outsiders’ were all over the place and didn’t show much of a trend at all. Terms included community, customise, design, development, features, modules, enhancing Drupal, understanding Drupal, getting involved, mastering and  more. On the other hand, ‘Insiders’ showed two very strong categories – Download (where modules reside in the current IA) and Developer
  • Core Project – most ‘outsiders’ put this in a category called ‘About Drupal’, where as ‘insiders’ unsurprisingly used the same cateogories as for Contributed Modules (both are considered ‘downloads’ in the current IA
  • Themes – again, the categories suggested by ‘outsiders’ was wide ranging, but most commonly suggested was ‘Customise’ and ‘Themes’, were as by FAR the most common category suggested by ‘insiders’ was ‘Downloads’.
  • Same for Translations, which clearly went into a ‘Downloads’ category for ‘insiders’ but left ‘outsiders’ perplexed – again, no clear trend emerged from them and suggested categories ranged from Customise, to Advanced Help to Projects.

You  may also have noticed that, in general, suggested categories were quite broad – there was extensive use made of the categories ‘About’, ‘Community’, ‘Documentation’, ‘Developing/Developers/Development’, ‘Get Involved’.

So, what does this mean for our project?

A card sort is never intended to ‘set’ the information architecture, but is rather used as a ‘probe’ into the existing and potential audience to get a sense of how they make sense of the content that you are trying to organise. We are not going to take the labels suggested by most participants and map the content to those labels and call that our IA, but we have learned some very valuable lessons. Including:

  • We need to be very careful and aware of Drupal-speak – it causes no end of confusion for people who are not familiar with Drupal. This doesn’t mean that we abandon it – after all, it is part of the efficiency of communicating within the community. But we need to make sure that we don’t use it for major ‘sign posts’ in the information architecture and that when we do use it, we add ‘supports’ for new players (outsiders)
  • Opportunities for cross-referencing – there were several instances where a piece of content showed more than one ‘trending’ category, for example the inclusion of ‘getting started’ content in both a ‘beginners/getting started’ category as well as a ‘documentation’ category. There are several instances like this where we can ensure that content is cross-referenced from one section (or sub-site) to another based on expectations shown in the card sort data.
  • Category naming – for example, a term like ‘Community’ is not currently represented on the Drupal.org website but are widely expected by both ‘insiders’ and ‘outsiders’ alike. This supports the consolidation of the more ‘social’ aspects of Drupal (groups, forums etc.) into a major section labeled ‘Community’.

Going forward

We will use the insight we have gained to date from this card sort to help inform the proposed Information Architecture for the Drupal.org website, which of course we will continue to share with you as we proceed.

It is *possible* that we may conduct a further card sort in the near future, however this one will be a ‘closed’ sort, where you will be asked to place content into a set of pre-defined categories. I’m only half convinced that this is a good approach (having had mixed success with closed card sorts in the past… ), so I’d be interested in any thoughts you have about whether this would be an interesting and useful exercise.

I’m glad to hear that several of you really enjoyed participating in this exercise and I do thank you for taking the time to do so.

Drupal.org – Initial thoughts on the Information Architecture

Firstly, I want to start by thanking you all for your participation to date in this project – it has been beyond helpful! Of course, now I’m going to ask for more, as we move forward to working out what the Information Architecture for the new Drupal.org is going to be.

If you have been following this process you will know that the overwhelming response to the question of ‘one site or many’ has been – many. And for many very good reasons, covering issues from technical and implementation through to community, scalability and usability. So, it should be no surprise to hear that we’ll be proposing to take that approach to the information architecture.

In terms of how it breaks down, here are some initial thoughts on which I’d value your feedback.

Homepage:

We propose that Drupal.org have, in effect, two homepages. On ‘not logged in’ and one ‘logged in’.

The ‘not logged in’ homepage would serve as the public face of Drupal to ‘outsiders’ (those with little or know knowledge of Drupal) and will be the place where we can introduce Drupal and ‘sell it in’ – showing it’s features, capabilities, reliability, the scale of it’s use across industries and around the world, and it’s amazingly active community.

We will encourage people to ‘join’ Drupal.org so that they can access the ‘logged in’ version of the homepage. The purpose of the ‘log in’ is not to ‘hide’ content, but rather to ‘activate’ the homepage as a tool for managing the vast amounts of content and activity that make up Drupal.org (or d.o as the ‘insiders’ call it!)

We imagine the ‘logged in’ version of d.o to be similar in approach to Netvibes - the idea being that there are a range of ‘widgets’ available that you can select and arrange as best suits your needs – so depending on what you are most interested and engaged in, you can ‘tailor’ the content on your homepage to best reflect this. Developers might also be able to develop new ‘widgets’ and submit them for use on the d.o logged in homepage.

We believe that a single login solution is imperative (and we’d like to suggest that supporting OpenID would be an excellent idea).

We also advocate a unified search across all of the d.o content, with a search results page that better identifies the type of content found and it’s source, and good filtering capabilities.

‘Portal/Network’ Header

Although we agree that the ‘many site’ approach is the correct approach for this project, it is important that we resolve a current issue with the information architecture which is that many of the current sub-sites are unfindable – we need to make these visible and easily accessible to all.

The logical way to approach this is to use a ‘network header’ which is global – shown on all pages of all d.o sites – and which contains links to each of the sub-sites in the d.o network.

A different visual treatment may be developed for some or all of the subsites to allow for their specific purpose and character, whilst clearly positioning them as a part of the Drupal online presence. We want to balance the need for flexibility and scalability with their inherant threat to usability.

A few people mentioned jquery.com as a reference site and – broadly speaking, in terms of the header/sub-site treatment, this is a guide to the approach (not to any great level of detail and not from a visual design perspective of course!)

It is quite a big task to decide what ‘sections’ are required and what requires it’s own ‘sub-site’, but here is a first run at what we are thinking.

Sections of d.o (but not their own separate subsites):

  • About (includes marketing information – features, benefits, demo etc. – also information about Open Source in general)
  • Jobs (pulling it out of the ‘groups’ site and making it more prominent)
  • Events (also pulling it out of the ‘groups’ site and making it more prominent)
  • News (similar content stream to current d.o homepage. Include link (at least) to Planet Drupal here)
  • Get Started (a quick start guide for new players, helping to get them over the hurdle of getting their Drupal site up and running and showing them how to access the community and other help)
  • Get Involved (an overview of ways that people can get involved in the Drupal project and/or community)
  • Professional Services (a directory of hosting, design and development services for rent, possibly paid listings?)

Sub-sites of d.o

  • Community – the social hub of d.o hosting groups, discussion forums etc.
  • Documentation- where all drupal related documentation is hosted, including Handbook and API
  • The Drupal Project – the project management aspect of the site for core, modules, themes etc. Issue lists etc. live here
  • Download – essentially an alternate ‘window’ on The Drupal Project, but focussed on helping people locate then download core, modules, themes etc. (rather than the ‘development’ aspect of them)
  • Association – as per the existing Association content

Feedback required:

As I said, this is the first run at the structure and I’m looking for your feedback on where we need to make improvements. Specifically feedback that I’m looking for is:

  1. Is something missing? Is there an important part of d.o content that you don’t see fitting into one of these categories?
  2. Technical issues. Is something that I’m suggesting here going to cause more technical pain (which will equate to implementation delay) than it’s worth? Let me know.
  3. Drupal Project / Download – two windows on the same content – what do you think of this idea? I’m not sure that it’s entirely right, but we *do* need to resolve the fact that people who access modules just to ‘download’ them seem to have entirely different needs to people who access them to ‘develop’ them.
  4. Design and UI – perhaps this is just my personal mission (I hope not!) but I’d like to make an information architecture that was more appealing to people like me who might want to get involved with the project. I was toying with creating a section specifically for design/UI/UX… but it didn’t feel quite right. At the moment I’m imagining it living under The Drupal Project… what do you think?

I have some images that I’ll put up shortly to roughly illustrate these for those who prefer pictures to words (don’t we all!) – my internet access doesn’t allow me access to my images at the moment… grr.. but I thought I’d get this up now rather than wait.

Looking forward to your thoughts on this!

Updated: here are a couple of images that might illustrate my thoughts a little. Larger versions available on Flickr (via links below)
IA
Larger version available here.

IA
Larget version available here. (Note: this is not the proposed design for the header, just a sketch of all the ‘bits’ that might be in it).

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?

DRAFT: Drupal.org Experience Strategy

The redesign project for Drupal.org will be guided by an experience strategy that will inform our decision making in all aspects of the redesign and which will, we hope, be able to be used as ‘a star to sail our ship by’ (as Jesse James Garrett would say) – as a clear objective to design towards.

What is an experience strategy?

An experience strategy is a clearly articulated touchstone that influences all of the decisions made about technology, features, and interfaces. Whether in the initial design process or as the product develops, such a strategy guides the team and ensures that the customer’s perspective is maintained throughout.

- Subject to Change, Creating great products and services for an uncertain world, Merholz, Schauer, Verba & Wilkens (Adaptive Path) 2008

This is a good example of an experience strategy:

Google Calendar Experience Strategy

How it worked out for Google Calendar:

Google Calendar Stats

(hat tip to Peter Merholz for images)

Experience Strategy for Drupal.org (Work in Progress!)

  • Drupal.org is for anyone who is interested in Drupal (not just developers!)
  • Drupal.org will make building a site you’re proud of as painfree as possible (from deciding to use Drupal through design, development and deployment)
  • Drupal.org is the home of the Drupal community.
  • UPDATED: Drupal.org is the project management and release tool for the Drupal software (thanks Robert Douglass)
  • Drupal.org will support people and companies from their initial experience of the product and community and as they continue to increase their knowledge and experience with Drupal and become more active in the Drupal community.
  • Is a showcase for what can be done with Drupal

What we believe:

  1. Drupal.org is as much (if not more) a social site than a content site
  2. The Drupal Community is as important (if not more) than the Drupal Product
  3. The Drupal product is a market leading CMS solution
  4. The ‘end point’ (goal) is not getting more people to download Drupal, the end point is to get more people to have a Drupal site running that they love (with as little pain as possible)
  5. Anyone can find out what they need to know about Drupal on or from Drupal.org
  6. We must flatten the learning curve – anyone can learn as much as they want to learn about Drupal
  7. Modules are easy to find and evaluate and are an obvious asset to Drupal
  8. People can see/learn and align themselves with Drupal’s (and Open Source) values…
  9. Drupal.org is a living organism and, with the help of the community, will continue to grow and improve.

How this plays out

Drupal Family

Drupal.org has two equally important audiences – people who are new to Drupal and people who are already part of the community.

Drupal.org needs to inspire and educate people who are new to Drupal – the end goal being that they become active participants in the Drupal community who have a Drupal site (or sites!) up and running that they are proud of.

Note: getting people to ‘download’ Drupal is not the end point. If anything, it’s just the beginning.

Drupal.org also needs to be a comfortable and safe home for members of the Drupal community, wherein participants are both able to develop their own skills and experience (grow up), as well as help others on their developmental path (help grow others up).

Things we need to do:

  • be nicer to ‘outsiders’ (non drupal, non developer)
  • encourage people to engage with the community (starting by showing them that it exists!)
  • work at flattening the learning curve
  • get all the right content on the site and keeping it updated
  • show the community in action (without ruining it)
  • make things findable (IA)
  • communicate drupal/opensource values
  • help Drupal users kick ass

Getting past the brick wall

Brick Wall

As one person I’ve interviewed described it: ‘I can get Drupal downloaded and installed and get an ugly blog that I don’t want, but then I hit a brick wall’ – Drupal.org’s job is to help people over that brick wall – to help them get the site they want using Drupal.

Helping Users Kick Ass

Bert Boerland pointed me to this great diagram that Dries posted a while back (inspired by Kathy Sierra) which I think really nails a big part of our strategy.

Drupal Users Kick Ass

So, that’s what we’re thinking.

Over to you now. What do you think of this as an Experience Strategy for Drupal?
Questions? Comments? Suggestions?

(Remember, there are lots of ways you can point us to things you think are important for d.org)