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.
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.
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
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:
Is something missing? Is there an important part of d.o content that you don’t see fitting into one of these categories?
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.
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.
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)
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.
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?
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.
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.
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:
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.
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.
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!