One study was set in a gourmet food store in an upscale community where, on weekends, the owners commonly set up sample tables of new items. When researchers set up a display featuring a line of exotic, high-quality james, customers who came by could taste samples, and they were given a coupon for a dollar off if they bought a jar.

In one condition of the study, 6 varieties of the jam were available for tasting. In another, 24 varieties were available. In either case, the entire set of 24 varieties was available for purchase.

The large array of jams attracted more people to the table than the small array, thought in both cases people tasted about the same amount of jams on average.

When it came to buying however, a huge difference became evident.

Thirty percent of the people exposed to the small array of jams actually bought a jar; only 3% of those exposed to the large array of jams did so

For the detailed answer(s) to ‘why is it so’ you should buy the book (and I strongly recommend it, as I said, I reference it *all* the time). For the short answer – people don’t do well with a lot of choice. Be a good designer and help them by guiding them towards good decisions, even if not the perfect one. A decision made can be remade and refined, which is much better than not seeing your customers for dust.

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!

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’ 

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.

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)

Larger version available here.

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).

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?

I just don’t work that way anymore, it seems. Sure, I still do wireframes every now and then, but never a ‘complete set’ and often with no where near the detail I used to include. Why? I think there are three reasons. Firstly, I tend to work on more of a strategic level than a detail ‘exactly where does that button go’ level these days. Secondly, I tend to work on projects where there is no time for that level of detail. And finally – and most interesting I think – I tend to work closer to the production team these days – more often are graphic designers designing and/or developers developing the very same stuff I’m wireframing at the same time. Investing too much in the documentation is a waste of everyones time – much better to do just enough to get them going and then work collaboratively with the team to do the fine tuning.

Personally, I think I should have been working more like this since forever.

Does any of this sound familiar?

One of the great things about being in this hemisphere is that it makes it all the more easy for me to get to some of the conferences I’ve been dying to get to for ages. March this year is going to be very exciting because I’m going to both SXSW and the IA Summit.

Anyone else heading in that direction? I’m looking forward to putting some faces to some names!

I’m also very excited to be participating in a panel at the IA Summit. Chaired (and organised) by Peter Boersma, and featuring amazing people like Peter Merholz, Livia Labate, Larisa Warnke and Josh Seiden (and me!), we’re going to be discussing where in the design process information architecture fits.

Some of the questions that Peter says he’s going to ask include:

• When should IAs be part of a design team?
• How do IAs work together with other design team members?
• How do you communicate your design process to clients?
• How do you measure improvements in your design process?

 I have a few opinions… but I’d be really interested to hear how you’d field these ones!

Yay to David Carruthers for kicking off the IA Bookclub which will meet for the first time in February to talk about BJ Fogg’s Persuasive Technology.

I read this book in the first year I was doing my Masters when I first ever heard of captology, and it really changed the way that I thought about design. I’m looking forward to re-reading it and hearing what everyone’s got to say about it! (And to see how my reading of it has changed over the past few years).

I’ll get onto it just as soon as I finish re-reading Inmates Are Running the Asylum. The first time I read that one was before the first dot com boom. The anecdotes and examples serve as massive flashbacks to that innocent time, but the guts of what Cooper has to say is just as inspiring as it ever was. Have you read it yet? It’s compulsary reading for anyone who’s anywhere *near* designing the way that people interact with technology.

Anyways, back to the book club. Here are the details: