NOTE: this is a work in progress. We're trying to gather up a summary of this group's postings in preparation of the d.o redesign talk. Pardon the dust.
Table of contents
- Purpose and Aims
- Initial Analysis
- Redesign Components
- Improving Documentation
- Improving Search
- Improving Module Downloads
- Improving quality and recommendations
- Other considerations
- Draft RFP
Purpose
The drupal.org main site and associated sub-sites (api.drupal.org, association.drupal.org, etc.) are under the formal responsibility of the Drupal Association, a Belgium-based non-profit founded in 2006 to support and promote the Drupal project. The sites were produced and continue to be managed and maintained by teams of volunteers.
The idea that drupal.org could benefit from a thorough redesign arises from a feeling that the Drupal project has in some senses outgrown the current site design and structure. The current site is an organic product of years of community-driven development. The main drupal.org site serves as the primary entry point for groups and individuals interested in Drupal and is visited by many people with different purposes and needs, not all of which may be fully addressed in the design.
Strategic aims identified for the drupal.org sites include:
- Increase Drupal adoption and market share
- Inform and attract individuals and firms evaluating Drupal as a potential platform.
- Ensure Drupal site administrators can readily identify components (modules, themes) to meet their needs.
- Serve as an example and showcase of beautiful, effective, and high quality design.
- Increase the capacity and quality of Drupal development, both core and contributed
- Ensure bugs and other issues are effectively identified and addressed.
- Provide Drupal developers with the knowledge and tools they need to produce and collaborate effectively.
- Produce a revenue stream to support Drupal Association work
- Provide the basis for lucrative advertisement and/or product sales.
Supporting objectives discussed include:
- Increase the ease of locating relevant resources and documentation, e.g., handbook pages.
- Improve site navigation patterns so that e.g. users with different needs more readily connect with relevant resources.
- Produce a visual design of the site that conveys the full flexibility and flair possible with Drupal.
Initial analysis
Who uses Drupal.org?
Jeff Eaton defined a series of Drupal.org personas to describe who uses the website, and what their likely focus on the site will be:
- Evaluator: seeking overview information about Drupal and what it can do.
- Manager: decision-maker, looking to be "sold" on Drupal.
- Site builder: looking to use Drupal to build a website; needs introductory information, tutorials, modules and themes, etc.
- Webmaster: has worked with other CMSes and needs to know more details about how Drupal compares.
- Developer: code-monkey who wants API-level details about Drupal as a content management framework.
- Designer: looking for themes, looking for information on how to make Drupal look beautiful.
This document is still incomplete, but it's a wiki page. Edits/additions welcome.
What is Drupal.org?
An important piece of the initial analysis was to catalog what all is actually at Drupal.org, and how it all fits together.
[need details on:
- current subsites (groups.drupal.org, etc.)
- infrastructure
- usage statistics
]
How might drupal.org be restructured?
Angie Byron drew up an IA Mockup to try and catalog the functionality of drupal.org and categorize it according to general audience.
This mockup could form the basis of individual sub-sites which each specialize on their particular aspects of Drupal. This would have the following advantages:
- Use modules that fit the use case. This would open up the doors to using specialized contributed modules for different sub-sites without threatening the stability of the "main" drupal.org website. For example, Diff module on the Documentation site, Project/Project issue tracking on downloads.drupal.org.
- Drupal.org can stay current. It wouldn't be necessary for Drupal.org to wait on one or two contributed modules that are only used by some of the sub-sites in order to update to the latest version.
- More flexibility with sub-sites' access permissions. For example, turn on the ability to post images for normal users on documentation.drupal.org.
There are also challenges:
- Link rot. This is a big one. If we split content among various sites, we suddenly kill 7 years' worth of links. Our Google Page Rank goes in the toilet. Kittens cry. Any thoughts on how to mitigate this would be greatly appreciated!
- Global search/session support. We'd need to make sure that the various sub-sites functioned as one. That means being able to search content across all sites (optionally), as well as ensuring that your login session is carried over from site to site.
- Sharing content across sites. It would be a huge pain to have to post a "Drupal 7 released!" announcement on drupal.org, developer.drupal.org, docs.drupal.org.... We need some way to centrally manage this.
Besides creating new subsites, a complimentary or alternative approach would be to present logged in users radically different views of the main drupal.org site based on their roles. This might look like:
- Enable users to select their own role or roles (with some roles reserved for admins to assign).
- Present content and blocks based on role.
- Possibly, allow users to select a primary role for a session, or assign a role only for a session. E.g., user follows a link to evaluate drupal and is assigned an 'evaluator' role for that session.
Redesign components
Summary: initial focus has been on are improving documentation, Drupal.org search, and the module download section.
The first step of the redesign was to try and figure out based on user feedback why Drupal.org is hard to use. There are two parts to this: qualitative analysis and quantitative analysis.
User interviews
In April 2007, Kieran conducted a series of ten interviews [#1 | #2 | #3 | #4 | #5 | #6 | #7 | #8 | #9 | #10] which asked the following seven questions:
- How would you describe yourself as a Drupal.org user?
- How often do you visit Drupal.org?
- When you visit Drupal.org, how long do you spend on the site?
- What are your goals when visiting Drupal.org?
- What is easy to do on Drupal.org?
- What's hard on Drupal.org?
- Is there anything else important about Drupal.org that we haven't discussed?
You can view a summary of the interview results. It should be noted that these interviews were conducted over IRC, therefore each individual is a) already familiar with Drupal and drupal.org, b) relatively tech-savvy.
Community-wide survey
Then, in early Fall 2007, just prior to Drupalcon Barcelona, Dries Buytaert posted a survey which asked a number of questions, including one about drupal.org improvements, which resulted in a drupal.org wishlist.
This bears a lot in common with the feedback from the interviews. Again, this survey was completed by people who already use Drupal.org.
Improving Documentation
Criticism about documentation includes that the handbooks are too massive, it's difficult to find what you're looking for, old and new stuff mixed together, lack of images, lack of structured tutorials.
Handbook landing page redesign
Angie Byron started a thread asking for input on a handbook landing page redesign. Here's a nice one that yoroy cooked up:
There are other really great comments on this thread too.
TODO: Summarize/Incorporate them here. ;)
Advice from O'Reilly
Kyle Matthews pointed out an interesting article on O'Reilly Radar about tools to improve documentation.
The two main tools:
1. Quizzes (was this information helpful?)
2. Cross-reference management
Status: Needs speccing out
Improving Search
Improving Module Downloads
Criticisms of the module download section include that it is hard to find new modules, hard to find relevant modules, hard to judge module quality, hard to match your website's requirements to modules. Most efforts around this and other Project/Project issue tracking module-related improvements may be found at the Issue tracking and software releases group.
Improving quality and recommendations
Research from the University of Michigan has lead to the implementation of a recommendation system based on analysis of content on Drupal.org. This is implemented as a batch analysis done in Java, and a Drupal block in javascript. This can be seen at Drupal related discussions and projects block on the right hand side.
Module categorization
The categories for modules shown at http://drupal.org/project/Modules was developed by during a sprint in Drupalcon Vancouver and has since seen only minor updates. Frando started a thread about ways to improve module categorization. Within, he defines a two-level hierarchy for module categorization; for example:
-
Usability enhancements
- Menus
- Javascript-based usability enhancements
- General usability enhancements
-
Administration tools
- General administration usability
- Taxonomy management
- Content management
Unfortunately, this is currently being held up by limitations of the existing categories implementation. Testing/patches welcome.
Other
- developers.drupal.org mockup: A mock-up showing what the landing page of the theoretical developers.drupal.org could look like.
Draft RFP
An early draft towards a Request for Proposals for the drupal.org redesign is here http://groups.drupal.org/node/7070 with scope and guidelines information here http://groups.drupal.org/node/7071.