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

If you’ve been following along you’d be aware that one of the nuts we’re currently trying to crack is the modules section of the drupal.org website – how can we make modules more findable?

In the interest of gathering more information to help make a good decision, i’ve put together another little cardsorting exercise. If you have a spare 15mins or so, I’d love if you could take a look at it!

You can find it here: http://disambiguity.optimalsort.com/drupalmodules/

If you have any comments/questions/feedback to the contents of the cardsort or the process, feel free to post them here.

The cardsort is set to close on Friday 21 November.

Thank you!

One thing I’ve learned on this project so far is that if you’ve been using Drupal for more than about ten minutes, chances are you’ve had a look for a module or two.

Research participants are rarely unanimous but I think I can safely say that every single Drupal user I have spoken to has told me how difficult it is to firstly find and then evaluate the usefulness of modules.

So. That’s one thing we’d really like to help to fix in this redesign.

In the latest iteration, you can see where we’ve gotten to so far with the modules landing page – it’s a start but it doesn’t really begin to address the really difficult questions which are:

• how do people look for modules? and
• how do we design the interface and information architecture so that people can find the module they need?

Frankly, I could really do with your help.

Here’s the current version: http://drupal.org/project/Modules

And, here’s what we know:

• most advanced users will use Google search to find a module on Drupal,org using keywords that they think are likely to be in the module name
• advanced users refinding a known module are likely to use the URL (remembered or bookmarked) to get to the module page
• everyone finds it difficult to find a module from the current list of categories
• in some cases, the category names are not sufficiently descriptive or specific to be very helpful (3rd party integration is an example of this I think)
• in some cases, the category names are in ‘drupal-ese’ and meaningless to new users (new users don’t know what CCK is, or what Organic Groups are)
• modules can live in more than one category (this is not a bad thing)
• you can only order modules by category, date or name (check this)
• it is difficult to distinguish between a ‘big’ or important module ad a small, very specific module
• categorisation is very much about what a module actually does, rather than what you can do with it (for example, to use an example given to me the other day, if you’re looking for a module that will let you do listings for an estate agents site what module do you want?)

Here’s what I’m thinking

• we need to better support people’s desire to search for modules (hence the emphasis on search on the homepage and the associated massive improvements to the search capabilities of search for this site when it is relaunched)
• we need different ways to ‘cut through’ the modules to support different scenarios such as: I’m new to Drupal and I want to know which are the most important modules, or I’m building a site for an estate agent and I want to know what module would be best for making property listings, or I want a module that will automatically resize images depending on where I put them in my news site.
• we *could* try to do this with a controlled vocabulary, but would we ever be able to agree on what it should be. Unfortunately, I don’t have the time on this project to be able to complete it, and I suspect it would be extremely challenging to undertake this task as a community…
• we *could* harness the scale and diversity of the community and focus more on tagging in a less structured, more Folksonomic way – but this isn’t going to help guide people through the scenarios that need more support as outlined above…
• we probably need to do a combination of the two – with some broad, fixed ‘structural’ categories, and categories that go beyond just describing an aspect of what the module does or how it does it, supplemented with community driven tagging, to help enhance the findability via search and possibly generate new additions to the controlled vocab.

So, assuming you’re with me on this (and that’s quite an assumption I know) – here’s what I need some help with… I could really do with some help compiling some list(s) of categories that would help people find modules in the usage scenarios I’ve suggested above. Also, if there are other important scenarios I’ve missed please let me know!

We should probably do this on a wiki, or something similar. But perhaps lets start with some ideas here and I can compile them into something more comprehensive.

Anyone got any thoughts on this? (Don’t feel you need to be comprehensive)

Welcome to the latest iteration of the Drupal.org redesign project which you can find here:

http://drupal.markboultondesign.com/iteration7/

We’re both excited and nervous to show you this latest version because we’ve taken a bit of a deviation from our previous path as a result of both feedback from you and usability testing, and us not being quite satisfied with the work that had been done so far.

There were a couple of things that were really bugging us in the versions up to now.  In particular, the navigation in the header (there was so much of it and it looked kind of messy and confusing and in tests, we observed that people completely ignored it!). The Logged In version of the homepage was a good idea but the execution was coming up short as we learned that ‘hard core’ Drupallers thought it was a v valuable addition to the site but just about everyone else wasn’t interested… 

A behaviour which we have observed since the very early days on this project has the use of search – lots of people use search lots of the time, and a lot of the tasks that the site has to support are heavily search oriented (finding modules, finding help etc.). Drupal.org users have some of the most advanced Google skills I’ve ever observed! – and yet up until now, the redesign of the site didn’t really pay this much heed – it was still very much a hierarchical site made up of silos of content… forcing people to choose between this section or that to find the content they required. Another thing that we had largely ignored is the use of URLs as shortcuts to information (eg api.drupal.org to get direct to the api documentation site)

(Having said that, I am very pleased that the information architecture has actually performed well in task based testing - with a few exceptions like, say, ‘Professional Services’ which was too limited for the content it needed to hold and has now been changed to ‘Commercial Services’ (you like?))

So, as a result of these issues, we’ve made some fairly significant changes to the homepage and navigation structures, placing a much greater emphasis on the search behaviour from the homepage (and throughout the site), and significantly simplifying the ‘header’ navigation. Early participants in the crowdsourced wireframing exercise may also be pleased to see the inclusion of the ‘big ass footer’ (refer to some early posts on the Flickr group if you have no idea what this refers to!)

We did some initial usability testing showing a more ‘search’ based alternative earlier this week and it was quite well received – since then we’ve done quite a bit more work on it. 

There is one important thing that has been missed in this version (which hopefully Mark will be able to get sorted tomorrow!) which is that the search refinements (modules, themes, documentation and forum posts) will be links direct to a ‘landing page’ for those sections to better support a browsing interaction style).

The ‘logged in homepage’ has evolved to a ‘dashboard’ which we hope will be more useful to a broader audience whilst still supporting the needs of the ‘hard core drupaller’. The idea would be that you could set whether you see your dashboard or the standard homepage as the default when you visit the site.

There are a whole range of changes and updates and additions, I won’t go through all of them here, rather, dive in and take a look for yourself. I’d really encourage you, as you do so, to think not only about ‘how do I like the look of this‘ but also think ‘how do I use the Drupal.org website now (or how would I?), and how would I do what I want to do on *this* version of the site?’

I do want to give a little more feedback on what we’ve learned from usability testing which explains the high priority and size of the ‘case study’ on the homepage. With virtually everyone that I have interviewed so far, almost without fail one of the most valuable pieces of content (not including modules etc.) is the case study – this is true both for ‘outsiders’ who are evaluating Drupal, but also for ‘insiders’ who are on the learning curve – the case study is a great opportunity for us to challenge the perception of what a Drupal site looks like, to showcase some of the great companies and organisation who use Drupal, to explain more about how Drupal sites are built, what modules were used, the team that is involved, any challenges and learnings along the way – in short – they are really very productive and impressive for a large group of our audience. As I said to Mark recently – I cannot overstate how valuable case studies are to the people I have met and talked to about the Drupal.org website – hence their very prominent position on the site.

We still have a lot of work to do – in particular, I’m hoping that we can make some good progress in the ‘documentation’ section and the modules and themes pages. These are very important parts of the site and what you see there at the moment doesn’t reflect our current thinking on how it should work (which has been influenced and inspired by listening to the community talk about what they need and what they’d like to see!). The community landing page is still very much up for grabs (needs more thought and love and doesn’t really reflect our current thinking).

Please go in and take a look and let us know what you think – show your friends and tell us what they think, and consider getting involved in our crowdsourced usability testing if that takes your fancy. 

This week I’d really like to invite people to do some usability testing comparing the previous (iteration 6) homepage with this one to get some feedback on this new direction.

Please feel free to post any feedback here, or there is also a discussion over on groups.drupal.org if you’d like to join in over there. I look forward to talking with you about this some more!