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.


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!) :)

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

  1. Although users are looking for the word “Download” we won’t give them it?

    I am not convinced that the reason of “ongoing project work and encourage participation” is really something that could be addressed by making a clever label. Where as creating a better page where the actual download is listed, to encourage participant and ongoing project work to me looks like an approach you don’t talk about?

    I completely agree with the motivations you gave to disregard the subsite, however isn’t the information scent on that page totally wrong? (As you suggested)

    Why would we be community centric with pushing participation all over the place? Instead of being actually user centric and just get them to the downloads.

  2. I think there’s value to having the keyword “Download” around somewhere, as people will be looking for it. It’s one of those common keywords like “Support”, “Contact us”, and “Home” that people look for automatically. It doesn’t have to be its own section or a link in the menu navigation, but it can be a deep link from the front page somewhere, perhaps?

    As for a more generic name for projects, “components”? That is an unusual term, which could encourage people to follow it out of curiosity. Of course, that only helps with the intellectually curious… :-)

  3. The first time I went to Drupal.org, I was definitely looking for a great big download button, like the one on WordPress.org. That said, “downloads” isn’t a great name for the section where all the modules, themes, and translations live; perhaps “extending Drupal” would be more appropriate.

  4. I really like the “extending drupal”. It has the double meaning of extending the drupal community by contributing, but also the meaning of extending your own particular installation. I also think it seems obvious enough. There should also be a promo somewhere on every “marketing” page with the big shiny download button.

  5. I start from the concept of Drupal as a “ladder of engagement” from downloading and using the software to contributing to the community.

    Therefore “download” is the perfect starting point for a Newbie engaging with the information architecture of the site.
    (1) It is what the outsiders are looking for.
    (2) The downloads section should (IMHO) be constructed in such a way to provide a measure-able funnel to broader participation (the various project page mock ups seem to follow this pattern).
    (3) If we think that insiders are going to have a personalized “dashboard” like space, then use of ‘download’ will have a minimal impact on the insiders — they are essentially creating their own personal IA for their home page.
    (4) Finally, as Suzanne points out there is a difference between core downloads and “extensions”. I would see a user coming to the d.o homepage, clicking on the download button, then seeing a really big “download Drupal core” linked to a project page and a dynamically generated list labeled something like “extending Drupal” of the most frequently downloaded modules. Then elements that funnel people into the directory of extensions– modules, themes, install profiles, etc.

  6. +1 for Larry’s suggestion of “Components” as the generic term for Modules/Themes/Translations/Core updates/Install Profiles

    I also tend to agree that we shouldn’t be so fast to discard the idea of a big front-page “Download” link that visitors are instinctively trained to look for. It’s what that link should point to that is open to debate. If we don’t like the idea of having the Download page be a list of download links as David G suggests in #5, we could, say, have it point to a page in the Getting Started docs that offers concise explanations of the Drupal Way of Downloading (“First you get the core from here. Next, here’s the definition of [a module, a theme, an install profile, a translation], and here is how you search for [component] and install it.”)

  7. When I did the cardsort, I proposed the term “Building Blocks” for Modules, Themes, and Translations. I think this, or a term like it, would be great for insiders and outsiders alike. Terming these as “Developers” is bad IMO. Installing modules and themes is (or will/should be) easy enough that anyone can grab Drupal, install some modules, and go. Isolating these under “Developers” or “Designers” will alienate a swath of people who don’t identify with either group but who could still realistically get a lot done.

    I do agree with Larry that Downloads should appear somewhere and lead to an appropriate index.

  8. The reason that ‘all downloadable things’ are called projects is largely historical – because we use the project module on Drupal.org, and it creates URLs starting with project/ – I wasn’t around when this started, but that’s my best guess.

    However, in the Drupal software itself, we don’t have any conception of projects – just modules, themes, profiles, translations – and there’s no overall word to describe those things. That means we have an opportunity to create a new one if needs be.

    Components makes sense, although I’m not sure it works for themes and translations that well, so my personal choice would be ‘extensions’, and have this as the main name of the subdomain running project module. Calling the site ‘Extensions’ gives the impression of being able to both download and find out more about each one (including development etc).

    If we do that, this in no way stops us also having a drupal.org/download page on d.o itself which has a big green button for downloading core, and links to extensions.drupal.org + deep links to modules/themes/translations as well. ‘Outsiders’ are probably looking to |Download Drupal| – and that’s what they get if they visit /download – insiders, or at least people who’ve already done that, they go to extensions.

    The only issue with this is that we’d be developing Drupal core on a subdomain called ‘extensions’ – but 1. Drupal core is in large part modules anyway, so meh 2. Active development of Drupal is extending it – and often bringing in functionality from contrib, so it’s semantically not too bad either.

  9. “Downloads” has inherent meaning.
    So does “Developing for Drupal” or even “Developers” (which has meaning for those developers familiar with seeing such sections on all manner of software project sites)

    I don’t think you should be second guessing your instinct with regard to the separation of these two activities / areas in the IA.

    People have to walk before they run. So let them walk. Let them be a user and when they are ready to be a developer let them run. Just make it easier for them to find where the joggers are.

    The next question when someone would go to these sections is the “what”? What do I download? What kind of thing can I develop?
    The answer to both is
    * “Drupal” – the basic content managment framework
    * “Modules” – components you can install that extend the functionality of Drupal.
    * “Themes” – pre designed skins that make your Drupal site prettier
    * “Translations” – ’nuff said

    A final point:

    In my mind all of Drupal.org can be boiled down to three things. Everything on the site should encourage or facilitate the following:
    * Get the Product
    * Find Support
    * Contribute back

    Downloads is obviously about getting the product.
    Developing is obviously about giving/contributing back.


  10. a) Yay for not making two sites with different views on the same content for different audiences. A single site for everyone fits in nicely with my proposal at http://groups.drupal.org/node/15295.

    b) I don’t know where the term “project” came from in the first place — that was before my time as well. The code was originally written by http://drupal.org/user/2 so it was definitely in the earliest possible days of Drupal. For me, “project” tends to invoke Getting Things Done “projects”, as well as “Drupal projects”. I agree it’s not the most outsider-friendly term, and I’d be happy to see it disappear from the IA/UI of the *.d.o network. Even insiders refer to a site they have to build for some client as a “project”, so it’s a totally overloaded term already. It’ll be fun trying to hack the project* suite of modules to make it so you can change the public-facing terminology it uses for itself. ;) But, I’m up for that challenge if we come up with a better name…

    c) As a hopelessly inside insider, I have to say I’m not at all opposed to this subsite just being called “downloads.d.o”. That’s what outsiders are obviously looking for. Insiders hang out there since they’re working on the stuff you can download. I really don’t see a problem with this. So long as it’s not *just* a download page, but a hub for the community (developers and users) of that thing you’re downloading, I think the concerns about a schism between users and developers are unfounded. Any “insider” who’s ashamed to be working on the “downloads” site needs a reality check — we work on stuff people download, folks. ;) It might be *slightly* weird that you go to the “downloads” site to handle issue tracking, developer working groups, and a bunch of support stuff, too. But then again, all that stuff needs to live close to the action, and it’s all related to the stuff you download…

    d) extensions.d.o is also a very good suggestion– I’d be happy with that option, too. In fact, I think this is the best option so far suggested. It’s not quite as self-evident for outsiders (though we could easily have a d.o/download page and have a prominent “Download” link in the site navigation as suggested). However, this potentially makes the support, issue tracking, and developer working groups fit in more nicely. “download”, “get support”, “talk code”, etc are all actions you can do on/about extensions. If the site is called “download”, that makes it seem like that’s *not* the place you go for those other actions, and you’d start looking around for “support.d.o” and “developers.d.o” and the like. However, by using a noun-based name for the site, it makes the site more “friendly” to various verb-related actions you might want to do with that noun. See what I mean?

    Another nice reason to call these “extensions” instead of just “downloads” is that a bunch of insiders get these things not by downloading, but by “checking out” from our revision control system. ;) So, again, they’re actually “extensions”, and “download” just happens to be the #1 most common action that outsiders want to do with them.

    e) [Hopeless insider comment] I’m -1 on calling these “components”, since we already have the “components” of each project in its issue queue. I know not everyone uses the issue queue these days, but I know many 1000s of people do, and we can’t completely confuse all those folks. ;) Sure, we could change the UI of the issue tracker to use a different name for this, but I’m not a fan. “Component” seems like the right word for what we’re already using it for — some sub-part of your “extension”. Sure, modules and themes are “components” of a site, but somehow they seem like more self-contained entities than what “component” invokes for my mind.

    f) -1 on “Building blocks”, too, since “block” is already a loaded term around Drupal, and that seems like a road to confusion. Plus, “buildingblocks.d.o” isn’t as easy to say, type, or remember as “extensions.d.o”.

  11. For me, downloads.drupal.org is the clearest. From there, we can expose all the effort that goes into maing these downloads (i.e. the issue queue, stats, etc.).

    Lets certainly ditch ‘project’. ‘Components’ is too wishy washy, and ‘Extensions’ is just slightly less clear (confusion with file extension?).

  12. Even though I like “extensions” better because it’s so nicely generic, one might mention “plugins” as the “other” option.

    This year’s Summer of Code has yielded a module called Plugin Manager which also spans all of these categories, and there was certainly some discussion on the name of that module before it was created. Also, it’s a term that people are widely familiar with, and doesn’t clash with existing modules, themes, etc.

    Might be a possibility. Apart from that, I totally agree with dww that a noun-based name is a good idea.

  13. -1 for coming up with a new term. That makes things only more confusing.

    +1 for just ‘Downloads’ — maybe a special block with a short one line description talking about themes and modules?

  14. hi all and thanks, again, for such great insight and feedback.

    never fear – the word ‘download’ is going nowhere and will definitely be found, as a call to action, wherever it is appropriate (contextually) throughout the site.

    after sitting with all these thoughts for a few days, I’m currently thinking that a section called ‘Download & Extend’ could be the answer. To me it does several things:
    a) it’s a call to action to download core/modules etc.
    b) ‘extend’ also hints at things other than modules like themes & translations – generally making Drupal do more, be more customised.
    c) ‘extend’ avoids confusion/ambiguity re: ‘extensions’
    d) ‘extend’ is also a call to action to help to extend Drupal and it’s capabilities

    I think it works quite well – what do you think?

Comments are closed.