Drupal.org redesign plan for the Drupal Association

Drupal.org web analytics and key performance indicators web conference

Amazon — Wed, 02 Jul 2008 00:00:54 +0000

I am pleased to inform the Drupal community that we will be installing an advanced enterprise analytics solution HBX, on Drupal.org. This is possible due to a generous donation of this HBX software, valued at over $10,000. These tools will give very advanced reports of how users are using Drupal.org, which forms they are using successfully, what page flows are working and which ones are not. The goal of these analytics tools is to provide the Drupal community with an ongoing user experience toolkit with which to make improvements to Drupal.org.

We are installing these tools now, to ensure the design firm the Drupal association is hiring in the next several weeks will have a good baseline of how Drupal.org is being used today. These analytics tools are the first of three parts of a new UX toolkit for Drupal.org. The other two parts are improved search engine usage with tracking and user field studies.

This meeting will cover what we've learned from the analytics in the first two weeks and present the Key Performance Indicators that we've initially scoped for Drupal.org. In this web conference we will present these KPIs and have the community propose alternate KPIs we should measure. Our goal is to produce customized reports to help different audiences help improve drupal.org. These audiences include: the drupal.org designers, Drupal association members who are responsible for the Drupal infrastructure, the Drupal infrastructure team, the Drupal.org webmaster team, and members of the community interested in improving Drupal.org.

This meeting will be a web conference using adobe connect presented by Kieran Lal and Mike Bishop.

Marketing of Drupal

Google search block offered when Drupal.org search module is throttled

Amazon — Mon, 30 Jun 2008 18:29:02 +0000

When the search load gets too high, Drupal.org now offers Google search as a substitute.

http://drupal.org/node/273483#comment-899413

Offering higher quality search and publicizing search queries are important inputs into the Drupal.org redesign.

Drupal.org redesign plan for the Drupal Association

Drupal.org redesign business objectives

Amazon — Thu, 19 Jun 2008 16:27:03 +0000

Drupal.org Redesign Business Objectives

These objectives were developed by Michael Meyers and Laura Scott of the Drupal association.

OVERVIEW:

Writing objectives at the start of a project gives you a solid foundation – a set of clearly defined goals that should guide every step of the initiative. This shouldn’t be about “HOW” we’ll accomplish the redesign (specifics like “ratings for modules” or “we need a CDN to improve site performance”) this is a higher level outline of “WHAT” we need to accomplish (“improve site availability and performance”).

After you have established your objectives, you can then determine the best way to achieve them. Throughout the redesign project, when we come up with these ideas (the “how”) we should constantly ask, “does [this idea] help meet one or more of our business objectives?” and if it doesn’t we shouldn’t be doing it! At the end of the project or a specific phase, these objectives will be used to measure our success or failure – did we meet our objectives?

It’s said that good business objective are SMART: Specific, Measurable, Agreeable, Realistic, and Trackable.

The objectives outlined below are more abstract then SMART and are meant to build consensus in the community. Also, note that any examples of HOW we might work to achieve objectives were provided only to provide context – they are not meant as recommendations or endorsements of any particular idea and are outside the scope of our current goal.

Once we agree on the high level objectives we can then create more specific and measurable ones (i.e. “increase repeat visitors by 20%” vs. “make the site more sticky”, “sub 2 second page load times” vs. “make the site faster”) and THEN we can turn our focus to the how…

OBJECTIVES (in no particular order):

Modernize the Aesthetics and GUI, Leverage the Power of Drupal.

The current site design is stale - web aesthetics have come a long way and so the site does not inspire confidence in terms of professionalism. It also poorly represents the power and modern capabilities of Drupal - it barely takes advantage of the functionality Drupal has to offer.

We need a cleaner, updated look and feel (design) in-line with current market trends, implemented consistently across all of the association properties (association, groups, d.o, etc.). A more appealing, modern, and usable set of sites will make for a much more marketable Drupal.

Re-think of the Information Architecture and Usability

There is inconsistent architecture and it's hard to find information. We need to step back and look at our many properties and re-think the overall structure and organization of the individual sites and re-build from a solid, new foundation. The navigation and IA needs to be more intuitive and approachable, and the various sites or sections of sites need to be more tightly integrated and cross linked.

Important pages shouldn’t be more then two clicks away, we need to leverage non hierarchical ways of organizing content (tagging and improved searching) and there should be consistency in the placement of navigation elements.
We need to cross link and integrate various aspects of the site – for example, when you view a module there should be blocks showing recent related activity on the forums, in docs, issues, etc., with a link to a full rundown (and not like the links we have on project nodes).

We need to introduce missing and important functionality that is found on most successful community sites (trust and credibility metrics, popularity and ratings, etc.).

Contain Expenses and Generate Revenue

Revenue is essential for sustainability but the site does not exist first and foremost to generate revenue – that would change the purpose and tone of the site. We don’t want to overly commercialize the site - we want to find palatable ways of monetizing our properties to generate necessary ongoing revenue that will help fund this redesign, the associations operating costs, and future initiatives.

Increase user participation throughout all aspects of the project (documentation, testing, design, development, etc.)

The Drupal community makes use of social production, which relies on many users contributing to the project. In order to continue to make improvements, we need to continue to make it easier to contribute.

The size of the community activity makes highlighting and parsing that activity very difficult. Participation is easy in some areas, but hard in others. It's hard for people to know where to start, or how to best contribute. The only area where it seems to go well is in actual code contributions.

It’s critical we continue to grow the community - we need to solicit (calls to action) and foster more participation, make it significantly easier for folks to contribute (lower the barriers to entry, provide starting points), etc. It also needs to be easier to follow what’s going on day to day or month to month (in summary), and be more welcoming and transparent to newcomers, outsiders, and the more casual users or evaluators.

Empower and Leverage Drupal Community Members (Crowdsourcing)

We need to empower our member base and leverage their input to improve the quality of, and to help organize the ever growing amount of content and contributions.

For example, we should be tracking the number of views or downloads, and have some type of rating system. We can then enable filtering and sorting based on these metrics, making it easier to find content. We also need to encourage people to add metadata like tags – helping to better organize things – we should encourage as much user editable content as possible.

Facilitate the Product Evaluation Process

Most companies and individuals go through a similar evaluation process prior to adoption – there are common questions and concerns.

 Does Drupal have the features I need?
 How does it compare to other frameworks or CMS systems?
 Who else uses it? Will it scale?
 Will I be able to find development resources?
 etc.

We need to support and facilitate this process making it easier for the various constituents to evaluate our product.

Increase Downloads and Grow the Install-base

Success is driven by our community and active successful installations of the product – we need to increase downloads, and more importantly increase our conversion rate (folks who just download vs. those who actually continue to use it and find success through it) to build our install base of active users.

Improved, Better Integrated, and More Comprehensive Documentation

Great strides have been made in this area but we need to continue the progress on this critical front.

We need to improve the structure and organization: All docs should be versioned with the appropriate Drupal release. Taxonomy can be leveraged to organize content on more than one axis. Type of documentation, for example: tutorial, review, guidelines, introduction, etc.

We nee to provide better integration (cross linking and referencing), for example help links in the Drupal install process should link users to specific help pages, not the documentation home page.

We need to increase the overall quality of the content, provide deeper and greater coverage of topics, establish and improve standards for all types of documentation, etc.

Make it Easier to Setup, Run, and Support Drupal Installations

Whether your are looking for documentation, modules that best meet your needs, tips on tuning and scaling your configuring, testimonials and tutorials, etc. it needs to be much easier to find what you are looking for.

Improve the Performance and Availability of our Properties

The availability and performance of our properties directly reflect the viability of the product and form an indelible impression of our capabilities. If a users or evaluators go to one of our sites and it’s slow or down, they will wonder if Drupal can scale, if it’s right for their business, etc. It also directly hampers community contributions, time spent on site, etc.

We also need to ensure critical information (api.drupal.org, handbook documentation, etc.) and product downloads (core, modules, themes, etc.) are /always/ available, that we set, track, and meet performance standards (i.e. sub 2 second page load times), and have the necessary tools to monitor and measure our performance.

Internationalization

Drupal caters to an international audience. Our web properties should be available in multiple languages.

MarComm - Promoting the Product and Brand

We need to maximize SEO and have an actionable marketing strategy to go along with this redesign - including supporting collateral to empower grass roots campaigns and viral promotion (buttons, banners, badges, broiler plate copy, etc.)

Insight and Analysis

We have limited insight into site usage. We need a modern real-time analytics solution in place to help us better understand how users navigate the site, what areas are important to them so that we can make informed decisions.

Marketing of Drupal

Interested in bidding on Drupal.org redesign project?

farriss — Fri, 06 Jun 2008 23:13:54 +0000

In preparation for the anticipated release of the redesign RFP, I am soliciting the names and contacts for firms or individuals who are interested in receiving a copy of the RFP and all official communications about the project.

The scope of the project includes:
- research
- information architecture
- design and branding

(The full draft RFP can be found here: http://groups.drupal.org/node/11336)

Firms or individuals who can show successful experience in one or more of these areas on projects of similar size are encouraged to participate in the bid process.

If you wish to submit the name of your firm or recommend another firm that should be included, please e-mail drupal@palantir.net or respond to this post. Thanks!

Drupal.org redesign plan for the Drupal Association

Study: .gov web sites should focus on RSS, XML—not redesigns

Amazon — Thu, 05 Jun 2008 05:02:03 +0000

http://arstechnica.com/news.ars/post/20080603-study-gov-websites-should-...

Should the re-design focus on exporting data and allowing the community to mix and mash-up Drupal community data?

Kieran

Drupal.org redesign plan for the Drupal Association

Project taxonomy revamp proposal

catch — Wed, 04 Jun 2008 13:54:07 +0000

Every week it seems like there's a new issue in the webmasters/issue queue about new taxonomy terms for projects, this is a sure sign that the existing categories don't fit current needs. An obvious issue is that some of the categories are huuuge, which means in some cases you're just as well off browsing the full modules list. Who wants to look through 414 'utility' modules? What does 'content display' even mean.

So... let's look at reworking it. I see this having two elements to it. Overall, the categories should be task based, I want to look at modules which fulfil a particular need, I'm unlikely to want to view a list of modules that happen to include third party integration (although I might want to exclude those, which afaik I can't at the moment). For that, it'd be better to have a longer list of more specific categories, and less modules in them.

Additionally, more technical categories can be useful categories for some kinds of browsing especially for developers - say I want to find a module that supports Views2, or want to see examples of third party integration. However, I don't think they belong on the main modules listing - and strongly think we should move them to a separate free tagging vocabulary.

current list
* 3rd party integration (291)
* Administration (236)
* CCK (158)
* Commerce / advertising (78)
* Community (166)
* Content (392)
* Content display (422)
* Developer (157)
* e-Commerce (64)
* Evaluation/rating (65)
* Event (41)
* File management (54)
* Filters/editors (141)
* Import/export (63)
* Javascript Utilities (96)
* Location (38)
* Mail (100)
* Media (143)
* Multilingual (25)
* Organic Groups (53)
* Paging (19)
* RDF (15)
* Search (63)
* Security (55)
* Syndication (60)
* Taxonomy (119)
* Theme related (115)
* User access/authentication (138)
* User management (127)
* Utility (414)
* Views (92)

Rough draft of a new list:
* Advertising
* Amusements
* Audio
* Content administration
* Content rating and recommendation
* Content organisation
* Development
* E-commerce
* E-mail and messaging
* Events
* File management
* Form building and enhancement
* Forums
* Images
* Import/export
* Javascript
* Mapping and addresses
* Menus
* Multilingual
* Performance
* Permissions and access control
* Search
* Security
* Site building tools
* Syndication and aggregation
* Text editors
* Text filters and processors
* User authentication
* User administration
* User interface enhancements
* Video
* Web services and semantic web

That's 30 categories, I reckon it could get to 40-45 pretty quick (currently there's 38).

The next thing though, would be adding a separate free-tagging vocabulary, this would handle stuff like module groupings (views, cck, panels, ecommerce, ubercart, RDF API, Organic Groups), and stuff that's either not useful to 90% of Drupal users trying to find a module, or not task-oriented enough to go in the above list - things like Third party integration, taxonomy, node_access, third party migration, blogging, community etc. - which either have little to do with what the module actually does, or are too broad to be useful.

These tags could be displayed on project pages, in a list linked off project/modules somewhere, maybe a tagadelic thing at some point, and we could then use modules like "similar by terms" to show related modules based on this (or use it alongside pivots and other recommendation algorithms). We could also very slowly move tags from the freetagging vocabulary into the fixed one, if they turned out to be very useful, or vice versa.

I'd volunteer to do some of the work of reclassifying modules if something like this was implemented, obviously it'd be quite a big job though, but since only project maintainers and drupal.org site maintainers would be able to tag, it'd probably have some limitation on noise and bad tags.

Module metrics and ranking

Drupal Docs

José San Martin@drupal.org — Mon, 02 Jun 2008 03:12:11 +0000

Following discussion here in this group and at IRC, I'm presenting a demo for what may become docs.drupal.org. It's still very crude and I also need to write a project of what's intended, but it's a beginning anyway.

Suggestions are warmly welcome. :-)

Drupal.org redesign plan for the Drupal Association

Request for Proposal (final)

farriss — Thu, 08 May 2008 22:41:46 +0000

This is the final Drupal.org Redesign RFP.

Contract award schedule:
- June 25: RFP released
- July 7: Vendors express intent to bid, submit questions for clarification
- July 14: DA issues responses to questions
- July 25: Vendor responses due
- August 4: Notification to finalists (2-3 will be selected)
- August 4-8: Interviews with finalists
- August 12: Vendor selected
- Week of August 18: Project kickoff meeting

Project deliverables:
Phase I – Research:
- competitive analysis of other project site structures
- refinement/finalization of personae and tasks

Phase II – Information Architecture:
- revised information architecture and organizational framework guidelines
- marketing content audit and revised manuscript for drupal.org, excluding subdomains
- approved, finalized wireframes

Phase III – Design:
- preliminary design concepts
- usability test report on design directions
- layered .psd for site templates
- .eps of logo/mark in CMYK
- brand style guideline documentation that includes articulation of the grid and font specifications

Drupal.org redesign plan for the Drupal Association

Groups.drupal.org local meet-up goals interview

Amazon — Thu, 08 May 2008 20:37:50 +0000

I conducted two brief interviews to understand what the goals of local event organizers were.

[13:19] yoroy> ok, inital goals:
[13:20] yoroy> - get a first idea of how many and what kind of people/shops are using/working with drupal
[13:20] yoroy> make them aware of each other's existence
[13:21] yoroy> since it was the first one
[13:21] yoroy> we tried to be as 'open' as possible, something for everyone
[13:22] amazon> and business goals?
[13:22] yoroy> though 'Translation' was the central topic for the hands-on part of the day
[13:22] amazon> ok, great
[13:22] yoroy business goals: not explicitly, just the networking part
[13:23] yoroy again, first time so we didn't really know who/what to expect
[13:23] amazon What education did your users want?
[13:24] yoroy well, the profs said they missed the opportunity to go in-depth, code-wise, that day
[13:25] amazon Different audiences then
[13:25] yoroy scaling Drupal, workflow for staging > live site, e-commerce solutions are topics I remember
[13:25] amazon Ok, great
[13:26] amazon What's the goal of this next meeting you are organizing?
[13:26] yoroy oh yeah, different audiences for sure. I read that from reading other experiences in g.d.o groups and it turned out to be very true
[13:26] yoroy - newbies
[13:26] yoroy - pro's
[13:26] yoroy little common ground in the middle
[13:27] yoroy Goals for the next meeting: more explicit business networking, actively invite people who are looking for Drupal service providers
[13:28] amazon Is that beneficial to you?
[13:28] yoroy Mind: I'm not directly involved with organising the next one
[13:28] amazon Ok, understood
[13:29] yoroy but it could be.
[13:29] yoroy as a designer 'in the know' it should be good opportunity to showcase a bit
[13:30] amazon I see
[13:30] amazon That's useful to hear
[13:30] yoroy good!
[13:30] amazon I think that's all I have

Drupal.org redesign plan for the Drupal Association

A social strategy for Drupal.org

Amazon — Thu, 08 May 2008 16:51:14 +0000

Reposting: http://association.drupal.org/blog/kieran/how-to-successful-social-strat...

Two weeks ago I attended a joint Web 2.0 (conference) and Web2Open (unconference) two part session on building a social strategy for your business. Web 2.0 and social software luminaries Charlene Li and Josh Bernoff presented a session " how to have a successful social strategy" based on their extensive research and book "Groundswell".

Pragmatist

They recommend that in order to lead a successful social strategy you should assume the role of a pragmatist. Pragmatists try to meet the company's goals, usually selling a product, as well as the needs of the community which wants complete access to the company's internal resources. In the case of Drupal.org this means carefully striking a balance between adding any set of modules the community wants on Drupal.org and respecting the time of the half dozen active members of the infrastructure team who are responsible for maintaining Drupal.org software and infrastructure.

Objectives

A social strategy should have clear business objectives. For over a year now, there have been active discussions about what a Drupal.org redesign should accomplish in the redesign group. The association is recruiting community and Drupal association leaders who are taking the responsibility of creating those business objectives. The leaders will be able to focus exclusively on the role of defining objectives and ensuring they are met. While those objectives have not been finalized yet, let's pick a few that are reasonable. First, a Drupal.org social strategy should make it easier to learn about Drupal. Second, Drupal.org should make it easier to contribute to the Drupal project. Third, Drupal.org should allow for income from association memberships and highly focused advertising revenue to help fund Drupal association activities like a re-design of Drupal.org. If you have some ideas about objectives for a social strategy, be sure to share them in the Drupal.org redesign group.

People, Objectives, Strategy, Technology

Charlene and Josh recommended we use their People, Objectives, Strategy, and Technology approach to frame a Drupal.org social strategy. For the Drupal.org redesign we've completed three significant People activities. First, we conducted a set of 10 interviews of Drupal.org users. Then we surveyed 1200 Drupal users about what they want to see improved on Drupal.org. Finally, we developed some personas to describe the different types of Drupal.org users. We are assembling a team of people to work on Objectives.

We've not yet spent a lot of time formally discussing our Strategy for how a re-design will change the relationship with users on Drupal.org. The Drupal community has often taken a very conservative approach to empowering users on Drupal.org. For example, we frequently leave technical barriers in place and restrict permissions so that spammers, and even legitimate businesses can not cross-promote Drupal and their business. We need further discussions on how empowering the community might change the workload of Drupal.org maintainers and how we can deal with it.

From a Technology standpoint, our choice is pretty clear, we should upgrade Drupal.org to Drupal 6 and allow for more capabilities to be handed out to maintainers. Currently, feature development on Drupal.org is restricted to half dozen maintainers who are responsible for maintaining the code. With the content listing Views module, page layout Panels module, and web form building Content Creation Kit module the 93 site maintainers don't need to install extra modules to help meet some of our objectives. This added flexibility will also help to produce better marketing landing pages.

Line up backers

The last step in building a successful social strategy for Drupal.org is to line up our backers. Who are these backers? First, they are the 9 members of the board of directors of the Drupal association who vote in association board meetings. Second, they are the general assembly of the Drupal association, comprised of the 26 members, who have already made a symbolic vote to make the redesign of Drupal.org the number one priority for 2008. The general assembly of the Drupal association will meet and approve a budget to fund a redesign of Drupal.org. Third, our backers include the 500 paid members of the Drupal association. Fourth, we need to line up advertisers who can help generate revenue by placing ads in limited areas of Drupal.org such as the handbooks, hosting, and paid services or jobs sections of Drupal.org web properties. This means we need to reach out to the 76 hosting companies that have posted in the Drupal.org hosting forums and see if the are interested in advertising on Drupal.org. We need to reach out to the almost 2000 people who provide Drupal services through hundreds of companies and see if they are interested in advertising on Drupal.org. Fifth, we will need to conduct a targeted fund raising campaign to help pay for the redesign. Sixth, we need to solicit and recruit a capable set of design firms who will choose to take on this project in a long term partnership. Seventh, we need to generate agreement with the infrastructure team, and maintainers who will be doing a lot of volunteer work to make the re-design happen. Finally, we are going to need to get the support of the Drupal community and ensure they are supportive of a re-design.

If you are interested in learning more about developing a social strategy for your business, read Groundswell. If you are interested in participating in the development of a social strategy for Drupal.org, join the redesign group, and look for an upcoming meeting between the redesign group and Charlene and Josh who have agreed to meet with us when we are ready.

Drupal.org redesign plan for the Drupal Association

Userpoints/karma/slashdot style reviews

chx — Fri, 25 Apr 2008 20:35:38 +0000

Today two concepts were raised on IRC: Slashdot style reviews -- but also, Amazon.com also have a "was this review helpful to you" feature. Also we could have "karma" (userpoints) that you can earn by handbook pages, comments here and there, patches, commits... you can spend it on badges and reviews. Very quickly it'd become quite visible who has Level 32 in Module Maintainership :D

Drupal.org redesign plan for the Drupal Association

How to make it possible to contribute to the Drupal project with small tasks in a few minutes?

Amazon — Wed, 23 Apr 2008 23:22:16 +0000

Please indicate how to make small tasks to contribute to the Drupal project.

Drupal.org redesign plan for the Drupal Association

Redesign implementation step one: Test Views 2 Beta 1 so we can use it with the project module

Amazon — Sun, 20 Apr 2008 18:36:14 +0000

If you want to help with the hands on implementation of the Drupal.org redesign you can help right now by testing Views 2 Beta 1 for Drupal 6.

http://www.angrydonuts.com/views-and-help

The project module has been undergoing a major redesign for the last couple of years, and it's currently waiting on Views 2 for Drupal 6. Once Drupal.org can be upgraded to Drupal 6, we will be able to do significant changes on Drupal.org including Internationalization, Single-sign with OpenID, improvements to documentation with Book module improvement, more use of CCK for collecting information, anonymous commenting to allow for more participation, better polls so we can solicit community feedback on topics, better forums to support other content types, and new menu system that will give more options for navigation and information architecture design.

Please help by downloading Views 2 Beta 1 and providing the views team with help.

Drupal.org redesign plan for the Drupal Association

services.drupal.org and themes.drupal.org

José San Martin@drupal.org — Wed, 09 Apr 2008 00:47:37 +0000

Disclaimer: It's just brainstorming. I'm not strongly supporting these ideas for now.

1) services.drupal.org
A place for Drupal commercial services. It would be:
- Yellow pages for Drupal shops and freelancers
- An extension of Paid Services forum section

2) themes.drupal.org
What about resurrecting Drupal Theme Garden? Users normally like it and its helpful to show that Drupal is not that ugly.

José San Martin
Chuva Inc. | Southern Drupal

Drupal.org redesign plan for the Drupal Association

my.drupal.org

catch — Sat, 05 Apr 2008 13:49:34 +0000

Thought it'd be a good idea to start a discussion specificially on how this might work.

This is a very rough outline from my first post on this subject Drupal.org the redesign - high level.

If you haven't read that thread, this one will make much more sense (and hopefully be more focused, if you do that first. You should also look at these two related discussions where ideas are being thrashed out: Drupal knowledge base and video.drupal.org

Here's a slightly edited copy paste from that first post:

my.drupal.org new
mitigates the subdomain split, and provides a way to avoid splitting into any more.

It runs panels 2, views 2, feedapi. rips off netvibes.
my.drupal.org/ - customisable personalised home page
my.drupal.org/planet - souped up planet + internal .d.o news aggregation
my.drupal.org/developer - cool developer stuff (see webchick's original mockup for developer.drupal.org)
my.drupal.org/designer - ditto for designers.
etc. etc.

my.drupal.org/video - aggregates video stuff
my.drupal.org/foo- if 4-5 people are willing to maintain one, they get something similar to og panels collections to work with.
essentially my.drupal.org

Phase 2 of my.drupal.org might do this:
By using feedapi and feed element mapper, we make sure we get the uid of every node and comment into my.drupal.org. That way, rather than parsing 200,000 x4 tracker rss feeds (+ my issues), it can take four and process those. Then my.drupal.org knows about my issues, my tracker etc. fairly intelligently.

edit: Moshe also mentioned trying to make an entirely 'push' system where *.d.o sites create nodes with metadata (but no body) on my.drupal.org. I think we'd need title, taxonomy terms, groups, project, author, comment authors, hopefully subscriptions information, last updated/commented time to do this. And also it'll have to be insert or update to keep track of updates to nodes.

Once it knows this, if we install user relationships, and I make friends with cwgordon07, webchick and chx, then it also knows what patches they've got that need reviewing, which modules they just released, which cvs commits they just made etc. etc. This is one possible way to deal with the potential of a million or more posts a year across *.d.o within the next year or so. It'll also allow my.drupal.org to pull that information in and spit it back out as feeds - so on projects.drupal.org it could show me a block with 'recently downloaded by your friends' or something. But my.drupal.org does the donkey work for users who are logged in a lot, so higher traffic hit and run sites like drupal.org docs.drupal.org and projects.drupal.org don't have to (as much, anyway). We'd have to make sure that my.drupal.org/[nid] is masked some to avoid link rot since there's no need for it to accumulate information for years - it'll need to periodically clean out. We also want all activity to happen on the primary subdomains, with this just for convenience.

Additionally - my.drupal.org could potentially host my.drupal.org/your-user-profile - a configurable public profile for all *.d.o users - so this is centralised in one place (and probably takes advantage of panels/advprofile/mysite as well)

Cross posted this to semantic web and Views developers group since I imagine we'll be making use of both in one way or another.

Views Developers

Drupal Knowledge Base

José San Martin@drupal.org — Fri, 28 Mar 2008 13:34:17 +0000

I've been discussing with wundo a few ideas we have about a "Drupal knowledge base" and I think this could be included in the coming Drupal.org redesign.

This Drupal knowledge base would be a place for keeping very consistent and comprehensive documentation for users and developers and a place to gather useful information that is currently dispersed on the web.

This knowledge base, as planned, would include these elements:

Handbooks. Very concise and precise documentation. A clean-up could be done on current documentation to reduce to essential. At the same time we would expand the handbooks to cover more and more topics. The unessential information would be moved to other parts of the knowledge base.
Tutorials. An easy way for people to create step-by-step tutorials full of screenshots.
Tips and Tricks. Short nodes would store short tips and tricks to do simple or complex things... From taxonomy theming to OG tweaking.
Screencast. A screencast repository, probably with videos hosted at blip.tv or at another similar service.
A comprehensive and specific taxonomy system, including vocabularies: for Drupal version, for user level (beginner, intermediate, advanced user, module developer, Drupal hacker, core developer, very very very advanced), for topic (site building, configuration, contributed modules, etc) and free tags.
Drigg. All tips and tricks published in the blogs should be gathered and classified at Drupal knowledge base, in a Digg-like style. And when I mean "all" I mean "all": we should digg all blogs registered in Drupal Planet and look for interesting things.
Drigg. Content karma (voting) could also be implemented to select the best tutorials/tips and tricks/screencasts in town and promoting weekly a few to the front page. Perhaps user karma could also be enabled to encourage community contribution.
Heavy investiment on Internationalization. A true Drupal knowledge base should allow non-English speaker have their content in their languages too. Just a few national Drupal communities have sites that are good enough to host comprehensive documentation. We should be able to translate the handbooks, tips, screenshots and everything else.

Build a website with these feature is not a complex task. The necessary documentation work is not simple, though and require a lot of work, but on the other hand it really worth it and would represent a significant step in Drupal world domination.

Drupal.org redesign plan for the Drupal Association

Drupal.org - the redesign (high level)

catch — Fri, 21 Mar 2008 06:13:19 +0000

OK, this is a proposal for drupal.org's overall structure, drafted out of an irc discussion which lasted at least 2-3 hours.

In total, drupal.org + 4, 5, 6 subdomains

drupal.org
- Primarily for people visiting the site for the first time, or for the first time in a month or more. Big download link, not a lot else. this has to be ultra-fast, major news posted to it, site showcase content type, block aggregating front page news from subdomains, it has download links for core, it takes people off to where they need to go. Not much else. This could be built from scratch almost.

docs.drupal.org new
- The handbook, maybe api.drupal.org (docs.drupal.org/api?). Essentially we start with a dump of drupal.org and rip out everything that's not in the book hierarchy. Then we bolt api.drupal.org on somehow (even if it's a prominent link and unified search).

projects.drupal.org new
- Downloads + issue queues, including support. This includes module and themes. This starts as a database dump of drupal.org, with everything ripped out that's not a project or issue. I don't think there's a clean way to separate out releases from support from bugs from development between subdomains - and it's an unhealthy split anyway.

either way - projects.drupal.org/ - aggregates new and popular modules and themes and stuff
projects.drupal.org/modules - probably not the full list, that's a level down for performance
projects.drupal.org/themes
projects.drupal.org/core
projects.drupal.org/profiles (but ideally this is /distributions or something)
projects.drupal.org/translations
projects.drupal.org/issues - the issue queue.
projects.drupal.org/support - maybe goes to a support landing page, including support issue queue (cleverly disguised as a forum), links to docs etc.

groups.drupal.org
- Much the same as it is now, with some enhancements. At the moment the docs team is discussing removing large numbers of the forums. Possibly all forum type stuff should be in groups, except support (which is in project.g.o). For example paid services goes here and becomes more like a classifieds section.
g.d.o possibly takes on mailing list functionality as well.

drop.drupal.org
- Hosts the DROP site. Very much as it is being hosted externally.

association.drupal.org
- No change

my.drupal.org new
mitigates the subdomain split, and provides a way to avoid splitting into any more.

It runs panels 2, views 2, feedapi. rips off netvibes.
my.drupal.org/ - customisable personalised home page
my.drupal.org/planet - souped up planet + internal .d.o news aggregation
my.drupal.org/developer - cool developer stuff (see webchick's original mockup for developer.drupal.org)
my.drupal.org/designer - ditto for designers.
etc. etc.

my.drupal.org/video - aggregates video stuff
my.drupal.org/foo- if 4-5 people are willing to maintain one, they get something similar to og panels collections to work with.
essentially my.drupal.org

Phase 2 of my.drupal.org might do this:
By using feedapi and feed element mapper, we make sure we get the uid of every node and comment into my.drupal.org. That way, rather than parsing 200,000 x4 tracker rss feeds (+ my issues), it can take four and process those. Then my.drupal.org knows about my issues, my tracker etc. fairly intelligently.
Once it knows this, if we install user relationships, and I make friends with cwgordon07, webchick and chx, then it also knows what patches they've got that need reviewing, which modules they just released, which cvs commits they just made etc. etc. This is one possible way to deal with the potential of a million or more posts a year across *.d.o within the next year or so. It'll also allow my.drupal.org to pull that information in and spit it back out as feeds - so on projects.drupal.org it could show me a block with 'recently downloaded by your friends' or something. But my.drupal.org does the donkey work for users who are logged in a lot, so higher traffic hit and run sites like drupal.org docs.drupal.org and projects.drupal.org don't have to (as much, anyway). We'd have to make sure that my.drupal.org/[nid] is masked some to avoid link rot since there's no need for it to accumulate information for years - it'll need to periodically clean out. We also want all activity to happen on the primary subdomains, with this just for convenience.

Additionally - my.drupal.org could potentially host my.drupal.org/your-user-profile - a configurable public profile for all *.d.o users - so this is centralised in one place (and probably takes advantage of panels/advprofile as well)

What's missing?
There's no obvious place for the forums to live, unless they can be folded into groups and issue queues (which I'd +1)
Single sign-on - actually this doesn't add that much to the number of places to log into, but we'd need open id becuase some people will need to.
Unified search - something like solr
Unified tracker - I don't want one tracker, I want 3-4 which I can view on one page, my.drupal.org handles this.

No cross posts anywhere - instead anything posted to the front page of a subdomain appears in a block on all subdomains to avoid unnecessary duplication and "wtf I just read this" moments. - my.drupal.org can be used to aggregate content and spit it back out again between the different subdomains

Drupal.org redesign plan for the Drupal Association

Roles and responsibilities for the Drupal re-design

Amazon — Wed, 12 Mar 2008 18:17:48 +0000

Hello, I've begun contacting individuals who've expressed interest in taking on a formal role in the Drupal.org redesign.

Here are some roles I am looking to have filled. The roles will take approximately a 12 month commitment, depending on the role.

Business owners - Business leaders from the community with proven track records of deliver solid business results of a major Drupal site deliverable
small consulting business representative: A person to represent the interests of small <= 3 person Drupal consulting shops
Hosting business representatives: http://drupal.org/node/233294
RFP team - handle the RFP and bidding process and recommendations to the Drupal association
Architects - People who specialize in translating business goals into Drupal architecture
Revenue team - people who will create a market place and manage relationships with people who wish to purchase services on Drupal.org such as advertising.
Lead programmer
Programming team
Project managers
Designers
Quality assurance team

These are all volunteer positions. Note, you will be working with organization that will be paid by the Drupal association to produce design deliverables. You should be comfortable with volunteering and working with paid organizations.

Kieran Lal

Drupal.org redesign plan for the Drupal Association

Drupal Dojo + drupal.org/videocasts = video.drupal.org?

Alex UA — Tue, 11 Mar 2008 14:56:09 +0000

During the Drupal Dojo Birds-of-a-Feather meeting at DrupalCon Boston we discussed two seperate items that I believe are interconnected: figuring out how to get more video lessons into the Dojo and doing a better job of attracting more potential teachers and students to the site. To address the first of these issues, I committed myself to doing outreach to individuals and companies who are creating video-based instructional materials to try and get them to submit their work to the Dojo. After that session I started to look around the series of tubes known as the "internet" and I found quite a few videos. But, what I also noticed was that a good percentage of those videos already are being shared with the Drupal community, but through drupal.org/videocasts rather than the Dojo, which oddly doesn't seem to appear on the videocast pages at all. This brought to mind something that I've heard Josh and others talk about, the idea that we should consider moving the dojo to something more aligned with Drupal.org itself, and I have to say that the more I think about it, the more sense it makes to me.

So, my question is this: does it make sense to consolidate our collective efforts in one location that is better connected with d.o. itself? Something like video.drupal.org, or possibly as a subsection of a tutorials section of the site (which is where the videocasts now sit), which could be called something like tutorials.drupal.org.

Another project I'm involved with, the Drupal Newsletter, has just announced that it is going to become news.drupal.org, and some have suggested merging the planet in with it, so there are already similar discussions and plans going on within the d.o. community of such moves.

But what do you think? What are the potential problems that we could face if we moved the site to something more aligned with Drupal itself and the Drupal brand?

Video

Community Segmentation, Bad News?

Robin Monks@drupal.org — Sat, 08 Mar 2008 21:31:53 +0000

What brings me to this topic is all the excited talk I've been hearing second hand about splitting groups.drupal.org and drupal.org into many separate chunks (documentation.drupal.org, news.drupal.org, groups.drupal.org, downloads.drupal.org, content.contributed.maintained.6.modules.downloads.drupal.org , you see where this is going). What worries me is that in such an implementation it may become too complex to get to key areas or discussions.

The way I see it, there are a couple major roadblocks for making such a system work (here comes the dreaded Robin-list, grab some coffee):

Continue reading and comment at my blog >

Usability

The Drupal Brand

evanleeson — Fri, 07 Mar 2008 07:26:15 +0000

I know I am weighing in on a sensitive topic. I found that out earlier today with my poorly received attempt at a humorous blog post entitled "Decapitate Drupal, please". I was unprepared for the negative response I received (though I did get some positive response as well). Someone rightly pointed out that Drupal Planet was not the right place for the discussion and suggested I come here. So, here I am.

The event that got me thinking about this issue went as follows: I will preface this by saying that I have no complaints about the Drupal update process. Many people thought I was complaining about that, but I wasn't. I think it is great. We did an update on a customer site yesterday and accidentally over-wrote the favicon we designed for them with the Drupalicon. We didn't notice. They noticed in the morning and we replaced it with the right one. No big deal and, yes, it was our error. We'll survive.

The interesting part came in the message from the customer. The customer thought perhaps they had been hacked as their icon had been replaced "with picture of a kid wearing a dunce cap". A dunce cap is an old grade school method of shaming kids who are not trying, in the opinion of the teacher. the teacher would make the kid wear a pointy hat. The hat was called a "dunce cap".

I believe this perception by my customer, who had never seen the Drupalicon, is of great value. I believe it would be shared by many people on first encountering the Drupalicon, which is in effect the Drupal "brand". Many people might not come to the conclusion that the Drupalicon is a kid in a dunce cap, but I assure you they would also not think of it as a professional logo. It is not. It is somewhat juvenile and hacker-ish. This does no good for the Drupal community. It means the Drupal community is succeeding in spite of the brand, not because of it. The brand does not have its shoulder to the wheel. It is a flat tire. Of course, there is no need to take my word for this. I have a proposition.

The d.o. redesign presents a great opportunity to talk about the Drupal brand. What is a brand? A brand is a customer experience represented by a collection of images and ideas; often, it refers to a symbol such as a name, logo, slogan, and design scheme [wikipedia]. We navigate our world to a certain extent by virtue of the syntax and semantics of brands. We also evaluate the viability of transactions and projects based on the brands associated with the participants in the transaction or effort.

Regardless of what we might wish to be the case, the brand does have an effect. First impressions are very important. In the course of negotiations and planning, a negative brand expereince can form a background noise and have a detrimental impact on your overall effort. "They seem good, but what's up with that logo?" It is something people take seriously on a very deep level because the mechanism of brands is so deeply ingrained in our psyches.

Now, it may be that I am just talking out of my assumptions and not the facts. What to do?

Rebrand Drupal.

I suggest that as an open community we put everything - even the name Drupal - up for evaluation. Don't be scared. re-naming projects like this one happens all the time, and if done right, it works well. I would like to begin the discussion by proposing a process.

Ask - survey a range of people including branding professionals, Drupal stakeholders, Dupal consulting and integration companies and the general Drupal community. Ask them all about the Drupal brand and see what we get back. My company hosts online surveys as one of our service offerings, and I would be happy to offer the facility in support of the effort. I will also commit to leverage my relationships with branding pros to get them to help design the survey so the information we get back is as useful as possible.
Evaluate - Allow the community to digest the results. It may be that no action is required, but I would find this surprising. I predict a rebrand will be suggested, perhaps not as fundamental as renaming the project, but that should be an on-the-table option, for the sake of the health of the community and project. I believe I read somewhere that Dries is calling his new Drupal-based installation project Carbon, so it seems that Drupal can go forward under another name.
Rebrand - the branding process as practiced in the commercial sphere may not be appropriate for an open-source, open community project like Drupal. I suggest we be as innovative as Drupal has always been and research and develop an "Open Branding Process" based on commercial branding but embodying the values of openness. The outcome should be an "Open Brand". I have seen some discussion online about the characteristics of an "Open Brand" and they mirror the general values of the open-source community and the various discussions going on about "openness" that have emerged from the growing global trend in this direction.

In my mind, the open branding process would differ from the commercial branding process in interesting and significant ways. There is a very ambiguous and blurred relationship between consumers, producers and other stakeholders in the totality of the Drupalsphere. This blending and intermingling has been well-documented in publications like the cluetrain manifesto and others. An opportunity exists for Drupal and its community to break more new ground in the way we do this. I would be very excited to be a part of the process. There are obviously energetic people fully engaged in this process and I am happy to lend my energy on this topic should people see it as a viable and desirable part of the process.

The opportunity seems to be here with the discussions and planning around the d.o. redesign. If I get a positive response to this post, I will put more effort into planning the process, and the first stage will be general approval (by the Drupal Association or whoever is required to be party to the decision) of the process involved in deciding if a rebrand is required or desirable.

Let's do something new and original...and open...by creating a new Drupal brand to launch with the redesigned drupal.org.

Drupal.org redesign plan for the Drupal Association

Drupal Home Redesign - A Project / Product managers POV

SharonKlardie — Fri, 07 Mar 2008 04:21:27 +0000

So this is my first post in the Drupal Community – I will warn you that this is LONG and may seem to be off-topic but I promise I will pull it all together (I hope)…

I was inspired to “bite the bullet” after attending one day @Boston DrupalCon. I think that my hesitation to post on Drupal or participate in any Drupal groups is an indication of the need to work on redesigning the home of Drupal.
You might now be wondering why I was hesitating…. Well the first reason was I was not sure how I could really be a part of this community. I run a development group – I have 5 Drupal Engineers as part of my team. They are the coders – the Drupal Gurus – not me.

I deal with project and product management. I work with clients on gathering requirements and manage the resources of the team to meet deadlines and budgets. I do have a technology background (in ASP – I know Bleck…) but I quickly realized that as much as I love technology and all of the benefits that can be gained from it – I did not enjoy the creations of the technology – it is the business side that interests me – what problems can be solved, how can efficiencies be gained, what would be ‘wicked cool’… So I switched sides.

So how does a project / product manager help out the community?
A. I don’t know how to write test cases in simpletest
B. I can’t create a module
C. I have no desire it run my own installation of Drupal (or a LAMP server) to install modules and test their usability

To me this is a problem – I would imagine that there are a lot of people out there like me – interested in technology, strong thoughts on feature sets and usability from an end users point of view, focused on organization of tasks and timeline and are willing to spend some of our own time being a part of a community like this – but have no idea how… I think that if the Drupal community is widening the reach of Drupal then people with the above skill sets need to be involved - Gaining the product/project managers vote goes a long way in a company.

The second reason that I was leery to about posting anything was the site can come across as aggressive. (Ok really for me it is the first reason I listed as I don’t have a fragile sensibility) but I did notice that the site is intimidating. I have read posts where there are “Strong” opinions stated and for individuals who are confrontation adverse – that will limit their contributions. I don’t like to stereotype but the site is very masculine and the mixture of masculinity in the look / feel, engineering focused organization of information, and tone of community interaction may be a factor for many women interesting in getting more involved in technology but not participating in Drupal. I think those factors may be enough to deter them from “biting that bullet” and joining in (Does that count as pulling it all together?)

Okay – that was a bit of a rambling but I am opinionated and wanted to “share” my thoughts on areas that could use ‘a little love’ during the redesign.

1.Showcase Drupal theme power on Drupal.org

When I am looking at a new product – visual display / organization of data counts for a lot – it either grabs my attention to dig in deeper or I get frustrated I can’t find what I want and I am not impressed by what I see thus I leave and go look somewhere else. Engineers typically don’t do this but us folks on the business side – it is a sad truth. There are a lot of great looking Drupal site on the web – I think that there is a lot of IA / UI changes that can be made to enhance the site greatly. A couple of examples are – left hand navigation – that is where my eyes want to go – but everything is top tabs or on the right. Many pages have second tabs under the first – as the usability assessment of the Drupal 6 admin showed (and this counts for me as well) those are not as well seen as left hand navigation. Users have been trained by the likes of AOL / Yahoo / MSN to look to the left for where to go next or see where they are, there are some pages that have a top, sub-top, left and right navigation – I am not sure where to look or what goes where. I can try to focus some more effort on this topic if there is interest… Has an IA site map been created for Drupal.org?

2.Don’t highlight the security issues as the first real content you see on the home page

I understand that software has security issues and I expect to update software – but on first look on a site – I don’t want to see critical alerts in BIG BOLD letters… If I did not know much about the software that might be enough to make me wonder if this software is going to be too hard to maintain for my company. I am not suggesting that there is no reference to security updates but can it not be the main focus of the home page?

3.Confusion of Drupal.org and groups.drupal.org and forums

I can say that the separation of these two sites confused me – I was logged into Drupal.org but went to groups page by clicking on a link in the right navigation and I was all of a sudden not logged in. I needed to sign-up again? Then I went to forums and there were working groups on topics – but there are also group groups on these types of topics – a bit of confusion for me.

4.Group pages for “feature sets” listing modules

I would find it really useful if in the social networking or performance groups – there was a list of all the modules tagged to those topics. I think that this would be the first step to gaining a feature focus approach vs. independent modules. When I start a new project for a client – I end up on the module page for a long time sorting through the categories listed – many of which are not feature focused. The ability to tag/group modules to display in a feature list by project vertical is something that I think would be a benefit to the community.

5.“Help Text”

In one of our client sites (a Drupal site) we implemented the concept of a “marketing block” that can be added to the top of any page via the admin interface – so that marketing can add a pretty image and text to help inform users on why they are at that page. It is useful and not nearly as cumbersome as creating full FAQ pages (which we are now in the process of doing for my client and I feel would be useful here as well). But those blocks are a start and helpful.

Sell –Sell – Sell

The Drupal.org site does not sell Drupal – there is one block at the top of the page but I couldn’t find testimonials on how great Drupal was for the different demographics – schools, Small Business, Non-Profit, Larger Corporations, etc.. And any case studies around them. Examples are the best way to introduce potential users of the software. I know that developers will go straight for the code and Drupal.org does a good job getting developers the information they need quickly – but with growth comes a new demographic on the site that needs information targeted to them.

7.Organization

It might be that my mind works a certain way and it is just different than Drupal.org or groups.drupal.org but I am often confused on where to look for things and get lost. After my day at Drupalcon – I tried to look up D7 Project Management – to see what was needed and if there was a way I could help out – but I could not find anything on it. This is beyond the navigation issue I discussed above – it is even categorization that I just can’t get my hands around – though as I use the site more – it gets easier – the beginning was a bit rough.

8.Search

The search takes a while and there is no advanced search options that would make sense to the non-drupal user (searching by content type of Book – I don’t know which items on the site are a book vs. a story vs. a project). I think that enhancing the search capability of the site will greatly benefit any user who are having a hard time finding information

Module Demos / Screenshots / Status

When looking at modules and getting all excited by the short title / description – you go an open the module page – and realize that you have no idea what this is really going to do for your customer without having a member of the development team install it in a sandbox for you. It would be REALLY useful if there were screenshots of end user and admin or even better a demo place to check out the module. I know that there are modules where this type of information would not be useful but there are many that would (some have this type of information but it would be great to see more of this). I also think that it would be beneficial to see stats on the modules – in the support section to see “Downloaded 5,000 times and Pending Bug Reports (5)” will give you a different opinion then “Downloaded 70 times and Pending Bug Report (65). It would also be nice to see somewhere on the main module page to see if test cases have been created for it, if it has been reviewed by other for usability, coding standards, etc

Tutorials

This was also discussed during the usability session for how to do admin things – but I think that a quick 5 minute flash tutorial on how to get the most out of the Drupal community would be engaging – I know that there is a lot of things out there for contributing patches / modules / reporting issues… But something quick and easy on the eyes may drag in people you may have lost otherwise.

Ok - well if you made it this far - Thanks for reading :)

Smile
Sharon

Drupal.org redesign plan for the Drupal Association

news.drupal.org

aaron — Thu, 06 Mar 2008 15:58:35 +0000

I only found out about this group yesterday. I've been involved for a couple of months in a discussion to relaunch the Drupal Newsletter as a stand-alone site, ideally on a sub-domain such as newsletter.drupal.org. I just spoke with Dries this morning, who liked the idea, but suggested news.drupal.org. He also suggested contacting members of this group, since you folks have already been working on the bigger picture.

You might want to take a look at my post about a proof-of-concept at https://groups.drupal.org/node/9432 and also http://drupal-newsletter.org (the proof-of-concept itself).

I have a lot to catch up on, since I was unaware of the d.o redesign discussion until recently.

Thanks,
Aaron Winborn

Drupal.org redesign plan for the Drupal Association

Search Engine Optimization

sprydev — Tue, 26 Feb 2008 04:58:30 +0000

How to SEO Drupal.org:

Better keyword selection. Phrases like "Community Plumbing" are cute/fun/interesting but do little to actually move our cause forward. We should change the title tag to: "Drupal Content Management System, an Open Source CMS"

There isn't an H1 tag. There should be an H1 tag (styled to match the theme) just beneath/near the logo that matches the Title Tag.

We should change "Drupal.org is the official website of Drupal, an open source content management platform." to this: "Drupal.org is the official website of Drupal CMS, an open source content management system."

We should put a 301 redirect from *.drupal.com to drupal.org. http://en.wikipedia.org/wiki/URL_redirection

Fix validation errors: http://validator.w3.org/check?uri=http%3A%2F%2Fdrupal.org%2F&charset=%28...

Install an XML Sitemap. There's a module.

Create pages specific to "CMS", "Content Management System", "CMF", "Content Management Framework", and other relevant commonly searched phrases.

Link Building Strategies:
Everything above is on-page. Link building is what is actually going to drive the site higher.

There should be a "Powered by Drupal CMS" or "Built with Drupal Content Management System" in the footer of every download of Drupal. The link should be on the keyphrase, not on the entire sentance, aka "CMS" or "Content Management System".

We should make sure that drupal is included in the top directories.

Search Engine Optimization

Drupal.org redesign progress to date

webchick — Wed, 20 Feb 2008 00:55:46 +0000

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.

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.

Drupal.org redesign plan for the Drupal Association

Agenda for DrupalCon panel about the d.o redesign

dww — Tue, 05 Feb 2008 08:46:07 +0000

Agenda for panel workshop at DrupalCon Boston about the d.o redesign efforts:
http://boston2008.drupalcon.org/session/drupalorg-redesign-panel

Panel presenters

Angela Byron
Tiffany Farriss
Kieran Lal
Daniel Zhou
Nedjo Rogers
Derek Wright

Revised agenda

Here is a revised agenda based on Tuesday evening's discussions with the modification that Kieran will be there. We'll leave the previous draft below because it contains useful details.

Aims and leadup – Nedjo Rogers, Drupal Association
Scoping – Tiffany Farriss, Palantir
Progress so far – Angela Byron, DA
Identified pieces
- Aiding module evaluation with pivots, Daniel
- Improving developer toolsets, Derek Wright
Fundraising – Kieran Lal, DA
Getting involved

Welcome and introduction [Angela] (5 minutes)

Goals of session
- Engage the community in the redesign of drupal.org.
- Identify remaining work for and potential contributors to a RFP for a site redesign.
- Help promote a fund raising campaign.
Drupal Association role
Existing redesign team

Design goals for d.o [Nedjo] (15 minutes)

Goals for drupal.org
- Increase Drupal adoption and market share
- Increase the capacity and quality of Drupal development, both core and contributed
- Produce a revenue stream to support Drupal Association work
Existing site: strengths and
Identified priorities
- Increase searchability of sites
- Ease identification of resources, e.g., modules
- Improve documentation
Questions needing further information and analysis
- How best can we meet the needs of prospective Drupal adopters?
- What will best facilitate a revenue stream?

Addressing priority Drupal user and developer needs [Angela and Derek] (25 - 30 minutes)

Identified personas (A)
Possible subsites design for identified user groups (A)
Specific objectives and proposed approaches
- Documentation improvements (A)
- Improve the ease of finding modules (D)
- Additional tools for developers (D)

Redesign process [Tiffany] (15 minutes)

What does a project this size look like?

RFP prerequisites
Scope
Management and oversight needs
Stages
Pieces and separate solution providers
- new theme
- specific new functionality, e.g., module browsing
- design, navigation structure

Funding the effort [Kieran] (10 minutes)

Budgeting needs
Potential funding sources

Helping people find modules [Daniel] (10 minutes)

The concepts of "pivots", and how they can be used in d.o. to help people find modules.
A short live demo.

Discussion, Q/A [All, Nedjo to facilitate] (15-20 minutes)

Questions for feedback
- How well have we identified the overall goals?
- What needs have we missed?
Identifying resources and volunteers for completing the RFP and beyond

Information in preparation for the session is being pulled together here: http://groups.drupal.org/node/9034

Drupal.org redesign plan for the Drupal Association

Improving online documentation from O'Reilly

kyle_mathews — Fri, 01 Feb 2008 17:18:21 +0000

Andy Oram recently posted a very interesting article on the O'Reilly Radar on how to improve online documentation. It's a very insightful analysis of the problems that face those writing documentation.

He suggests two tools should be implemented on any online documentation effort:

Quizzes
Cross-reference management

He recommends each documentation page include a simple quiz at the end. This is to help monitor quality. If readers aren't answering a question right, this probably means that section of the documentation needs improved.

His second point addresses the twin problems that documentation is hard to find, and when it is found, often times it is useless because you lack the necessary background to understand the material (an experience I'm very familiar with).

He suggests two solutions to these problems:

Making it easy for readers to suggest prerequisites and follow-up documents
Generating paths through documents so the potential reader has an entire syllabus

Read the rest of the article:
http://radar.oreilly.com/archives/2008/01/two_tools_we_ne.html

What do you think? Are his suggestions useful to our efforts? How could we implement them?

Drupal.org redesign plan for the Drupal Association

Drupal.org redesign plan for the Drupal Association

Drupal.org web analytics and key performance indicators web conference

Google search block offered when Drupal.org search module is throttled

Drupal.org redesign business objectives

Drupal.org Redesign Business Objectives

OVERVIEW:

OBJECTIVES (in no particular order):

Modernize the Aesthetics and GUI, Leverage the Power of Drupal.

Re-think of the Information Architecture and Usability

Contain Expenses and Generate Revenue

Increase user participation throughout all aspects of the project (documentation, testing, design, development, etc.)

Empower and Leverage Drupal Community Members (Crowdsourcing)

Facilitate the Product Evaluation Process

Increase Downloads and Grow the Install-base

Improved, Better Integrated, and More Comprehensive Documentation

Make it Easier to Setup, Run, and Support Drupal Installations

Improve the Performance and Availability of our Properties

Internationalization

MarComm - Promoting the Product and Brand

Insight and Analysis

Interested in bidding on Drupal.org redesign project?

Study: .gov web sites should focus on RSS, XML—not redesigns

Project taxonomy revamp proposal

Drupal Docs

Request for Proposal (final)

Groups.drupal.org local meet-up goals interview

A social strategy for Drupal.org

Pragmatist

Objectives

People, Objectives, Strategy, Technology

Line up backers

Userpoints/karma/slashdot style reviews

How to make it possible to contribute to the Drupal project with small tasks in a few minutes?

Redesign implementation step one: Test Views 2 Beta 1 so we can use it with the project module

services.drupal.org and themes.drupal.org

my.drupal.org

Drupal Knowledge Base

Drupal.org - the redesign (high level)

Roles and responsibilities for the Drupal re-design

Drupal Dojo + drupal.org/videocasts = video.drupal.org?

Community Segmentation, Bad News?

The Drupal Brand

Drupal Home Redesign - A Project / Product managers POV

news.drupal.org

Search Engine Optimization

Drupal.org redesign progress to date

Table of contents

Purpose

Initial analysis

Who uses Drupal.org?

What is Drupal.org?

How might drupal.org be restructured?

Redesign components

User interviews

Community-wide survey

Improving Documentation

Handbook landing page redesign

Advice from O'Reilly

Improving Search

Improving Module Downloads

Improving quality and recommendations

Module categorization

Other

Draft RFP

Agenda for DrupalCon panel about the d.o redesign

Panel presenters

Revised agenda

Welcome and introduction [Angela] (5 minutes)

Design goals for d.o [Nedjo] (15 minutes)

Addressing priority Drupal user and developer needs [Angela and Derek] (25 - 30 minutes)

Redesign process [Tiffany] (15 minutes)

Funding the effort [Kieran] (10 minutes)

Helping people find modules [Daniel] (10 minutes)

Discussion, Q/A [All, Nedjo to facilitate] (15-20 minutes)

Improving online documentation from O'Reilly