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.


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

29 thoughts on “Drupal.org – Initial thoughts on the Information Architecture

  1. Please explain again the concept of the “logged in” site, I do not completely get it.

    At the moment I get a sidebar with “my issues” “my posts” and so on. So your idea is providing this on steroids, and rearranging the site in a way the user can select, so that things he never uses, are hidden?

  2. I don’t see the download / project management distinction spelled out in the plan, so I am not sure what you mean by that. Unfortunately download heavily depends on some of the project management (ie. if I have Drupal 5 I can only download Drupal 5 stuff).

    Also, I am the guy behind tools for the localization of the Drupal project and modules/themes themselves. I was about to set up a new subsite on d.o for this, but seemigly it would best fit to the projects subsite (because translations have a heavy dependency on versions of modules/themes again, and need to participate in packaging of them).

  3. Regarding project/download sites, it would be helpful if you could provide more clarity as to what specifically you are thinking. We’re currently in the process of porting the project* (the suite of modules responsible for project hosting, issue tracking, releases, etc.). At the moment, project* might or might not be able to provide separate project and download sites, but it is possible it could be written to do so, if we had a better idea of what the proposal is.

  4. As usual, this is a terrific plan. I’ll only mention m concerns which is minor compared to my delight.

    The reason why events and jobs are on gdo today is that the authors of those posts often want a target audience which is geographical. By posting into a gdo group, they get that, and their posts get emailed out to those who subscribe. I think we should keep that feature.

    I agree we should feature Events and Jobs more prominently – but at least the authoring of that content should be done on the Community site. We can have a nice presentation of the same content on main d.o.

    A dedicated site for designers/IA is not really needed IMO. We should instead have prominent links into http://groups.drupal.org/usability. The pages in that group could be redesigned if you wish.

    As I mentioned, I am working on building teams for unified search and unified login. We’ll get those in features in place before the redesign needs them.

  5. I think this is a great idea, although it is going to take some work.

    For the technically minded, I’d suggest that download and project really be the same Drupal-installation, but have different theme, menus and frontpage, depending on which subdomain you’re accessing it from.

  6. Good ideas!

    Re: multisites and the global header: I would say this is the right path forward – I was just about to sketch-with-leisa the same thing :). There are several caveats though: single sign-on would ideally use OAuth protocol http://drupal.org/project/oauth that needs a gentle kick to make it to production. Also I am not sure how the “netvibes” part fits with global header and/or g.o structure: it’s meant to aggregate from all parts of g.o subsites, right?

    Re the UX: we (the UX guys http://groups.drupal.org/usability) have been discussing it for a while now. It feels like we have one leg in community site (as other working groups) and other in project site (to actually make our UX ideas to reality by developers). The same thing applies to many other working groups – certain developer communities and subsets of the issue queue are by theory very closely linked but our current g.o / g.d.o structure split keeps them way too apart.

    Your comment was a bit unclear “I was toying with creating a section specifically for design/UI/UX” — what do you mean by that? Is it similar to “high visibility” sections like Jobs and Events under g.o what get their source data from g.d.o?

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

    I’m not sold on this idea. Many of the subsites simply are not important enough to deserve inclusion there while other pieces of content within a subsite are worth including in the header all the time.

    Going back to the jquery example, they have two levels of navigation in the top and in certain circumstances they stay the same across subsites and in other circumstances they change on subsites. Yikes.

    I think I would prefer a solution for d.o where the “network header” was relatively small and then a separate site specific navigation was much more prominent.

  8. Leisa,

    Let’s hit your issues one by one:

    1.) I don’t SEE anything immediately missing except that there doesn’t appear to be a spot for g.d.o (groups). I’m not sure it’s been explicitly said one way or the other whether the treatment d.o is getting will make its way over to g.d.o… and if not that’s completely understandable. Maybe I missed the memo on this though, can you confirm/deny? thx

    2.) Technical pain: The suggestion for the “logged in/logged out” home page is compelling… I immediately think of iGoogle. Is this what YOU’RE thinking? if so it’ll definitely cause some pain. The closest thing we have to that is Panels. But last I played with it (and there is a D6 version I’ve NOT played with yet in dev) it wasn’t really suited to that sort of approach.

    3.) I’m not sure I like the idea of 2 views of the same content. I’m not sure it’s the best approach usability wise, but I understand why you’re suggesting it. If this were to go forward, I would assume that it could easily be done with some custom views theming for the slimmer “download” view. Can someone more familiar w/ project confirm/deny? I can’t imagine this would be hard. Playing devil’s advocate for a moment, however, I would suggest that perhaps organizing project pages so that the download information is at the top of the pages might go a LONG way toward helping to make this easier. That same layout could be broken into “teasers” and “full views” with the teasers being JUST the download information. Currently everything above the download info looks like it’s being used as the teaser (including the download info). Projects are actually under documented, and asking for JUST a description of what the module does would be nice to have, we could combine that (much smaller information) with the download info, and supply that instead… I dunno there are a million possibilities.

    4.) I like the idea of having a place where UI/UX work gets special attention, but this kind of goes back to the whole g.d.o question in 1.)

    Hope my feedback helps!

  9. I don’t know how far you’ve gone through this process, but have you asked people who use the drupal site, what they use the site for?

    It seems to me that this approach is looking at how to rearrange existing information, rather than considering what people actually drupal.org for, and making it easier to find the stuff people regularly access (modules, themes, and documentation.

    I’m not suggesting ditching information that isn’t popular. I’m suggesting approach the redesign from a user point of view.

  10. Lisa, one of the things I’ve always thought was great about the d.o/project/xx area was the way downloading brought you into contact with the project. I would suspect this has recruited more than a few people to give back to the drupal community..

    My comment is that a strong distinction between download and project may reinforce the distinction between those kinds of behaviour wrt community.. bridging these two behavious is (imho) one thing that contributes to drupal’s huge & strong community.

  11. What benefit does registering really offer the user?

    Registering to track things, contribute to the site, or for your own drupal profile is fine.

    Registering just so you can access documentation, modules etc is very annoying, and I would suggest off putting to new users.

    I know this is probably more a management decision, but I just wanted to comment on it.

  12. I don’t know how far you’ve gone through this process, but have you asked people who use the drupal site, what they use the site for?

    Michael, I know they’ve interviewed quite a few Drupal.org users of different kinds (even talked about it in their keynote at Drupalcon Szeged). I have been interviewed personally for example :) Also, there was/is a card sorting experiment going on (just hit a few blog posts back and check it out), which helps group stuff which people use together on the site, and which should be featured more closely tied. If you feel like you have been left out, there is no reason, just read up all the blog posts calling for user participation and act!

  13. Technical pain: The suggestion for the “logged in/logged out” home page is compelling… I immediately think of iGoogle. Is this what YOU’RE thinking? if so it’ll definitely cause some pain. The closest thing we have to that is Panels. But last I played with it (and there is a D6 version I’ve NOT played with yet in dev) it wasn’t really suited to that sort of approach.

    EclipseGC: The MySite module is much closer to what is required here, although it will certainly need UX love to be a better fit. And a Drupal 6 port without months of rearchitecting APIs to merge with Panels might also help :) I’d guess Ken might need to change plans there.

  14. I like John’s mockup – http://blamcast.net/articles/redesigning-drupal-project-pages. My only minor gripe is that the ratings are a bit *too* prominent.

    @Gabor – Consider how group admins can completely customize their group homepage today on gdo. Thats a panels API implementation, and fulfills the need we are discussing here. So there is no need for “months of rearchitecting APIs.” This has been at least once already, and did not take that long.

  15. Overall I like the idea.

    A few remarks.

    Download/Project: when choosing modules it is often advised to check the module’s issue queue, as it may be revealing of the quality of the module. Would this option get lost, or become more difficult?

    Documentation: would there be a separation between user and developer documentation, just like the Download/Project separation?

  16. @gabor @moshe

    My current thinking about MySite / Panels etc. is to abstract the OG Panels logic to create a Panels Collections module that has pluggable rules for CRUD, so that multiple authentication schemes (admin, group, user, other) can be supported by a single API. Access and control of a panels collection would be path-based, so that /panels/group/1 would have different editors than /panels/user/1.

    The big issue for either MySite or Panels is a good user-facing interface for adding content, which should be greatly improved by D6’s AJAX handling and some of the work by starbow, et. al.

  17. I think we should move the technical discussion to the redesign group on g.d.o – although since this has already got to implementation quickly, it looks like most people are into the sketch (as am I).

    I share some of the concerns expressed above about splitting project management and downloads, and would also be interested in seeing more thoughts on where the split would be. I’d be worried about anything which divides module users from maintainers too much (also bearing in mind that many module users are also developers) – but those issues aren’t insurmountable.

  18. Is it part of your mandate to tackle the information architecture inside of ‘documentation’/’handbooks’

    There have been at least 4 (in my memory) attempts at re-organizing the ‘handbooks’. While it has improved over the years – it needs the attention of an outsider.

  19. I just saw the post on your Card Sorting results, and realised that your information architecture has been derived from over 200 users, so I feel my previous comments about asking users what they think aren’t appropriate anymore.

  20. @Moshe – growing the Drupal project may mean growing audience specific properties. Groups has done wonders for local groups. API has done wonders for developers. Let’s let a UX/Design section do wonders for designers. A good group of designers came out of Drupalcon Boston to build a new home for Drupal designers, let’s give them the room to make it.

    @Michael Phipps – Comment 20. :-)

    Right now Drupal.org has a 3.5% sign-in rate per month. Most of the content is freely accessible and the history of the web shows that free access is the way to go, unless you are facebook, grrr.

    @John Forsythe: nice.

    @EclipseGC: Re: Technical pain, doesn’t front page module handle role (anon, auth) front pages?

    @Leisa: Should we address revenue from advertising and possibly a Drupal store in the IA? The store is a new requirement, just bubbling up with the rebranding and need to expand our marketing efforts.

    @Leisa: this IA will help users find things they expect to find. But are there specific IA’s which will increase participation in the project?

    Thanks for everyone’s participation. This is really great to see the level of engagement.

  21. Moshe is an awesome developer, and I understand that from the developer perspective it might not seem like there needs to be a separate design and UI site, as d.o. and g.d.o. are all about functionality, and that’s what developers do, but for broad adoption by the great designers of the world, Drupal really does need a place for designers to feel at home, where care is given to the very sense of aesthetic in that environment – one that will be conducive to saying “yes, it can be done with Drupal,” and with specific tools presented to them in a palatable way to help them achieve their design goals with Drupal and lowers the intimidation factor that they usually experience when trying to muddle their way into Drupal. For designers, I think that the drupal.org domain creates a bit of a feeling “fish out of water,” and it seems to me that in this whole process, and with all the various sites in the domain, it would be reasonable to have one area that strongly appeals to these types of personalities and meets their needs.


  22. OK, lets wait for some wireframes for a “designers site”. Only then can we really evaluate if the functionality and presentation are a good fit with groups/community. If not a good git, then we should consider dedicating a full site to it.

  23. Thanks for having the courage to share your work-in-progress with all of us. Your team is *spot on* with its approach. Our firm has been wrestling with many of your same issues over and over, to the point that some of these patterns are part of the theory we use in designing sites. If not to validate your thinking, here’s what we’ve learned:

    network/portal header – Great idea! We call it a “universal nav” which we use as a valuable strip of real estate at the top to move you around a large site’s different properties. It’s also a good location to let a user log in and log out, and you can use color to reflect this state.

    logged in vs. not logged in: you’ve got great approach, because these really are different pages for different audiences. One version should tout the benefits of joining and have very general information for those not familiar with Drupal. The logged-in version should have personalized content and be customizable to a power user.

    home page vs. portal: Different people will want to see different information, and you may even want to have separate pages for drupal.com (what a newbie would try first) and a link-packed portal page for a power user. Simplicity is great for a first-time brand experience, but lists of links are great time-savers once you know your way around. Personally, I’d keep a portal page in the spec that’s close in structure to the current d.o home page, and maybe give it the URL of my.drupal.org.

    Design site on drupal.org? Design and UI are such loaded issues that you should consider having a home for them on the d.o. site — but also keep a separate site where they can take center stage. “Design” and “usability” can mean _such_ different things to different people, especially when you’re trying to mix developers with the tech-shy creatives that Drupal would like to embrace.

    The creative community has such different values and speaks such a different language that it should have a targeted area separate from the community to court it. On the other hand, there is a huge need for a whole tree of Design and UI forums within drupal.org to address the needs of usability and user experience. That need is far too important to leave to a redesigned thread on g.d.o.

  24. We should look at the main categories of visitors the Drupal site serves (very high level) and try to see if the proposed IA / site design meets each of their unique needs:
    A. Those who use Drupal for their solutions (companies, newspapers, content editors etc.) – basically end users or “clients” of Drupal
    B. Those who develop or design using Drupal as a tool (service providers)
    C. Those interested in or who want to use Drupal (potential clients, decision makers, journalists, reviewers, technology or design companies etc)
    D. Those who contribute to Drupal (the developers and community) and make it what it is

    The exercise would involve making sure that each of these groups is easily able to find the information relevant to them, that they are looking for or that d.o thinks they should have. I think this exercise would make sure that whatever IA or design you pick it will work for most of the visitors to d.o

  25. This mostly looks great.

    My first concern is that I believe the documentation should “live” close to what it documents. In particular, the documentation for each contributed project (module, theme, whatever) should be an integral part of that project’s home page, not buried off on a separate documentation.d.o site. A significant portion of your IA work will be making it easier to find projects (sounds like you’re going to have 1 or maybe 2 subsites devoted just to this). I’d *really* hate to see a 3rd way to navigate the projects on the docs.d.o site, too. This will just be a pain in everyone’s ass — people trying to find the docs for a particular project, people trying to update docs, project maintainers, etc.

    In case you haven’t seen it, I’ve posted some thoughts about merging more of the “community” functionality from groups.d.o and the per-project documentation into the project pages themselves: drupal.org projects as Organic Groups. This has generated some good discussion which is worth a read.

    One of the topics that came up is having a per-project forum directly connected to each project, instead of having this stuff going into a separate catch-all forum on a different site.

    The people using, contributing to, and maintaining each project are their own (overlapping) communities, and those people need all the help they can get to be in touch with each other. The more we make the project pages into the hub of each mini community, the better.

  26. thanks so much to everyone for your feedback here and elsewhere (on your blogs, on groups.drupal.org, on the Flickr group etc.)

    I’ve been working to pull all of this feedback together and am putting together a new post with an updated / evolved version of the IA and some more thoughts/explanations etc. very soon! Stay tuned!

Comments are closed.