Many. There are SO many different audiences here. I can’t even imagine having the current groups site “Drowned” in what the forums have become.

But then, I love the expanded “wiki” functionality on groups, vs. the handbook section (although they are used for very different purposes).

Of course, there is everything from technology (tieing these things together, OpenID or other techniques for shared logins, a central hub for subscribe / notify) to process (different people run and administer and manage / admin these sites in different ways with different policies).

Can we rationalize these under one system? Yep, probably. But even then one would want “landing pages” for those items. It’s easier to say groups.drupal.org or docs.drupal.org.

OK, maybe I’m torn I think this is the FUNDAMENTAL decision from which flows so many of the other choices…

Beyond the general architectural/usability concerns Is linkrot being factored into these decisions? If a large percentage of legacy urls for Drupal is going to be deprecated that would be fairly traumatic for current users as well as for seo results.

Speaking of seo/pagerank, the more sites approach - all other things being equal - results in higher rankings. This is because google sees more inbound links from other sites to content. How so? Well, subdomains are counted as entirely unique sites by google. This means a link to a page that on Drupal.org which is coming from groups.drupal.org helps out the pagerank for that page (and the overall site, actually) more than if the link is just coming from a different page on Drupal.org.

[...] Go to the author’s original blog: Drupal.org - One site or many? [...]

I agree with Boris that Drupal community should encompass multiple sites to allow us to design the best spaces for the different actions that the different users should take. I love how g.d.o has helped the community. I really think having a site targeting people brand new to Drupal will generate amazing rewards for us in lowing the barrier to entry by make _what is drupal_ more digestible.

In client projects have benefited from a hub spoke system on other complicated projects before for the same reasons Boris said, feedApi and openID rock :). The has also helped in the past on upgrading decisions. Making tightly joined loss network can reduce legacy drag allowing different ’sites’ to move at different speeds based on end user requirements.

Keep up the good work.

eric

Many.

I believe that our best chance at useful web sites that respond to the needs of their audiences is to empower a single webmaster and his helpers. The webmaster answers to the Drupal Association and to the community once per quarter with a written report on progress/status. Otherwise, the webmaster is encouraged to change his site as he deems fit (infrastructure managers can reject any change though). Subsites should run the modules they need and upgrade on their own timetables.

drupal.org has no webmaster now and hasn’t ever had one. thats one of its main problems. good ideas are just left to die in the issue queue. the drupal association is supposedly in charge but lives in fear of substantial change. so we hired you guys! oops - moving on ….

So, I’d prefer Many because it I think we can be more nimble that way. I have committed to solving the unified search and unified login issues so no need to fret over those.

Leisa,

I think it should have many because these sites have a huge amount of content. Separated, I think it easier to remember and the enhancements can be pushed to the different audiences.

In Brazil, there is a portal called globo.com that goes this way. Their content is huge (very huge) and the separated sites make easy to navigate by the differents categories.

I am learning a lot with your thoughts.

Cheers.

Smaller and more manageable sections are preferable. The easier it is for any one section of Drupal.org to change and innovate, the better. This also means minimizing technological codependency between the sections. At the same time, things like single-sign-on and aggregation of information are highly desirable characteristics.

Leisa
I would tend to agree with you with regard to not building a family of sites. From my experience this tends to fragment the audience, to the point where separate communities form.
For example: “Oh you’re talking about api.drupal.org? I don’t don’t use that site, I only use groups.drupal.org”. I saw this recently during some user research, where users from a certain audience subset thought of the websites as completely different, whereas I and the owners of the site(s) definitely considered them one.
It became obvious that because of the loose coupling between the sites (even down to the use of subdomains) they had grown, or were growing, further apart in the eyes of users.
By the way, I really like how you’ve opened this commentary/dialogue for the Drupal project. It’s really good to see some of your thought processes and how you’ve made it such a collaborative activity, which is rarely the case for us UX consultants.

It’s more practical from our maintenance point of view to have separate sections of the web-family be separate web sites. Moshe has done a great job being agile in his development of groups.drupal.org, and we’d like to encourage more efforts like this. Furthermore, upgrading Drupal.org (and it’s all-important project management bits) from Drupal 5 to Drupal 6 is already turning out to be massively difficult and slow. Wrapping the functionality of g.d.o., a.d.o. into the main site would make this even slower. In fact, if I were to vote, I’d split Drupal.org into two: documentation and forums / issue tracking and build scripts.

You can, however, with enough inspiration, find an information architecture (combined with single sign-on) that is rather seamless.

I think the question you’re identifying, one site or many, isn’t easily answered. There are indeed many use cases that would be better served with separated sites, but equally many by a single site. But as a user, I really don’t care if they’re technically separated, as long as the navigation to the information I require is logical and fluent (I think Jared Spool calls this “designing for the scent of information”).
As a Drupal themer who tries to use Drupal.org and related sites for information retrieval, I think it’s very cumbersome to have so many places to go to. Trying to answer simple questions, such as how to override the HTML markup of the primary links menu, will lead you from the fora to the theme handbook and to the api. From my point of view, any effort into improving the information architecture might be better served by starting with identifying common navigation paths, and see if that leads you to creating multiple sites or a single one.

Many.

Others already noted the technical reasons: multiple responsible maintainers of the subsites, possibility to upgrade the underlying Drupal version on different schedules, etc. The drupal.org site is still on Drupal 5, because it is dependent on running the project management infrastructure which is not yet ported to Drupal 6. The more we put into one website, the more dependency we put in there to updating or managing the inner workings.

I’d also like to bring up another point. Not all subsites are equal. I am in the process of building up the translate.drupal.org subsite, which is going to be a web application to translate the Drupal interface. The underlying software is already used in many translation teams (look at http://drupal.org/project/l10n_server ), and we are about to unite them on translate.drupal.org to have a universal workspace and release/distribution infrastructure. While setting that up, I was asked to use the bluebeach theme/layout drupal.org and its subsites currently use. While this defines the *.drupal.org brand right now, I am not sure the same layout/information architecture/user experience applies to content heavy and web application functionality oriented sites. This is part of the reason, because it might not be a good idea to integrate this translation server functionality to groups.drupal.org even though both of the subsites will use organic groups functionality.

A possibly better organization might be to break out the project/software management (and translation) functionality from drupal.org to a common subsite and merge in groups.drupal.org to the main site (avoiding link rot and all of course in the process) to “separate” the human community from the software community. But I am not entirely sure about this even.

thanks all for your comments - it has really helped to clarify my thinking on this issue to put the focus onto other important issues for consideration. Two things which all too easily get overlooked when we’re thinking about IA are:

a) will we be able to implement this incrementally? this is ideal because it means we can get some stuff up quickly and start getting value back from the project quickly. It would be great to see *some* of the redesign work up sooner rather than having to wait for *all* of it to be completed (as would be the traditional approach. I’d love to help break this up into an incremental redesign project rather than one enormous nightmare project! (There’s a great article about this here if you’re interested: http://www.uie.com/articles/death_of_relaunch/)

b) how can we design a space that allows the community and the project to evolve - we need to create a structure that will help the site(s) remain usable and content to remain findable over the longer term, but we don’t want to constrain the community’s ability to do what they want within the drupal.org environment. That’s a tricky brief, but I’m starting to agree that contrary to my first opinion, multiple sites might be the way forward (esp. with some nice openID integration, as you’ve suggested).

@Caleb G - there has been quite a lot of discussion re: link rot on the redesign group (ref: the link I gave in the post above) so that is definitely being considered.

this has all be very interesting and useful… I hope to have something to bring back for your consideration shortly, and in the meanwhile, do let me know if you have any other thoughts.

Gabor mentioned merging groups.drupal.org with the “community” part of drupal.org. I sort of agree. But actually, I think the community part of drupal.org (i.e. forums) should be migrated to groups.drupal.org. We can make forum like UI for folks. But I do think the groups model will work well. So, to a merge but in the direction of gdo. d.o should be mostly an intro/marketing site IMO. The issue queue moves to own site, forums move to gdo, and handbook moves to docs.d.o.

My .02

Leisa asked about incremental redesign. Yes, I think thats doable and desireable. The key is right beneath our noses - “many” sites.

Pick a subsite to focus on. It could be:

code.drupal.org (project pages, issues, …)
docs.drupal.org (handbook)
groups.drupal.org

The first two are new sites. They have the benefit of moving pages off of d.o thus making d.o. redesign simpler.

One other subsite I have not yet mentioned is my.drupal.org. This is an aggregated, teaser view of all the information that a user cares about. It is an activity stream, like the facebook news feed. See http://groups.drupal.org/node/10476

Many, and for all the reasons that other drupallers more seasoned than me have suggested. But, I also think there could be a real possibility of dilution in mindshare for the d.o brand with so may sub-sites floating around.

Personally, despite any number of sub-sites, I would always prefer to type in drupal.org and then be guided to the content of any of the sub-sites I may be interested in. I will have a very hard time getting to love api.drupal.org (not because I am not a programmer ;-)) or any other sub-site. My brand identification will always be with d.o and never with groups.drupal.org, my.drupal.org or any other sub-site. And, dare I say, many others may feel the same way too. Can you imagine anyone identifying themselves with codex.wordpress.com?;-)

I believe the information design for the d.o home page will be critical in tying these diverse strands together and weaving a smooth and seamless path for different audiences through a mountain of content. The sub-sites themselves will also need to function as if they are integral parts of the whole rather than feeling like isolated silos. Merely solving single-sign on (although that would be great in itself - it’s the one reason I rarely visit groups.drupal.org) will not bring that feeling of connectedness.

As a relatively new drupal user, I like the idea of one cohesive site. And as Jeroen, I don’t mind if the parts of the site are technically separated as long as I can find everything from everywhere.

For an example there is the jquery.com site, where the main navigation has links for different subsites.

As a comment, I found out about groups.drupal.org after a year of using drupal, and api.drupal.org even after, it is not obvious for the newcomers that there are several subsites.

Also, on jquery.com, the docs.jquery site is a wiki, the plugins.jquery site is a drupal page, the blog.jquery.com is something else and so on.

Of course, on drupal, everything will be drupal.

Many. For the reasons already given. Having smaller sites allows us to split the work for revamping each one. However, we’d absolutely need unified login and search, and they should act pretty much seamlessly as almost one site.

I agree with Moshe about moving the forums to groups.drupal.org - d.o itself should ideally be a window through which the other sites are viewed - with important content pushed to the front alongside landing pages, but not too much more than that.

Many subsites for the many different types of Drupal users.

Different types of Drupal users may require different User Experiences at Drupal.org. So, you shouldn’t expect a new Drupal user to know how to track project updates in the issue tracker.

Let’s bust this up for the different user types and offer them a different UX.

Types of users:
content creators
site maintainers
module developers
module users
snippet developers
themers
theme users
Drupal evangelists
others?

Many sites is probably best for all the reasons people have already outlined.

However, in addition to single sign-on and unified search, I’d like to propose that we aim to have a unique node id space across all the sites. In my ideal world, if you saw #501212 in an email message, CVS commit message, release note, forum post, whatever, you could go to *.drupal.org/node/501212 and get redirected to the appropriate site where that node actually lives. IMHO, it’d be a huge usability bug in terms of how the site integrates with everything else (revision control, email, etc) if the node ids were no longer unique, and everyone would have to qualify nids with the subsite they belong to. This is already a little bit of a problem between g.d.o and d.o itself. It’s not a problem on api.d.o since there aren’t really any nodes there, and it’s less of an issue on association.d.o since there’s a) much less content and b) it’s rarely referenced by anything other than other websites.

However, issue nodes are referenced all over the place, and if those all move to code.d.o (or whatever), and those could start conflicting with d.o forum node ids, etc, it’d be a big mess.

In summary: I’d love to see many sites with single sign-on, unified search, and a unique node id space with magic to redirect users to the appropriate site where any given node actually lives.

One important part of avoiding link rot, if we rearrange what parts of the d.o family are on what domains, is forwarding. Others have also mentioned the possibility of a unified keyspace. That would offer the quite interesting potential of having, say, drupal.org/node/12345 *always* work, but redirect you to groups.drupal.org/node/12345. drupal.org/node/6789 would redirect you to project.drupal.org/node/6789. That way, not only will all links continue to work indefinitely (using permanent redirects) but we could continue to reference a single keyspace for nodes; that makes the new [#12345] syntax in issue queues much more powerful.

Of course, doing that requires having a unified nid keyspace across an arbitrary number of sites that do NOT share a database. I don’t know how we’d do that, especially with Drupal 6 now moving to auto-increment IDs rather than Drupal-generated IDs. That is, I think, a much more difficult problem to solve than single sign on, where OpenID gives us a clear way forward.

I would have to agree that many sites would be ideal. I do also agree with moshe and Gabor that the Forums on d.o should be merged with the g.d.o. When I need to find something regarding Drupal I usually Google it and I end up with tons of stuff across all sites.

Handbooks should definitely become it’s own site and make a little more sense. I find it rather confusing to find what I’m looking for.

I’m a fairly new Drupal user, but feel that many sites would be great. If they could be “re-launched” as soon after each other as possible than that would be ideal. Probably not realistic though.

Hi, thank you for reading through out opinions.

I will begin by saying I think you should take a few minutes to wrap your brain around how Ubuntu (doc, downloads) and Launchpad (site projects) work. That’s super cool. I think it would be cool if we did the same thing, except we would have our site projects still linked to our DO usernames.

Currently we have a documentation and API site. The API site (http://api.drupal.org) does it right, it gets rid of the superfluous right-hand bar. 2 sidebars is TOO much. We’re reading information, we don’t need a HUD in our way like we’re in a space ship!

And this really gets to me in the Drupal handbook documentations. I am like, “Why do I need to have these annoying sidebars getting in the way of these tutorials!?” I want reading space, and the writer’s need space because we want to help people! (http://drupal.org/getting-started)

Keeping the top bar up there is cool. Leisa — I will end how I started, look at how http://www.ubuntu.com and http://www.launchpad.net work. That’s what would be awesome.

I think that having several many sites makes a lot of sense in terms of search results and that sort of thing.. Newcomers probably aren’t looking for API information right off the bat, and I think, like Moshe was saying, this sort of segments this huge scope of things into clearer, more manageable bits.

That having been said, the way we are going about things using the multiple sites is not very accessible and as usable as it should be. For one thing, there’s the hurdle of having to create multiple accounts for sites such as g.d.o. which causes us to lose people in terms of local participation, which is very important for adoption of Drupal. I know that when I started using Drupal the first thing I did was start looking a local user group to just go to and get a feel for things. It was confusing as to why I would need to create another account - I thought perhaps something wasn’t working “right.” I think synchronizing the users across the drupal.org domain and the subdomains makes a whole lot of sense, though I realize this will be quite an undertaking.

In addition to that, moving between subdomains should be seamless as far s the look and feel of the sites. That serves to not only make understanding how to use different aspects of the sites right away, it lends credibility to the other sites by having a unified look and feel (and user base.) This is largely the case with d.o. and g.d.o. but api.drupal.org is a bit sparse and the navigation is a bit too disconnected from the rest of the domain, I think.

-=- christopher aja purrin on d.o., g.d.o., etc

@Caleb G:
Link rot concerns have already been brought. There will be any link rot in any case, whatever the architecture we decide to implement. That’s why people invented HTTP 301 redirect code: to redirect stuff, without any kind of trouble for users or search engines.

Usability: For users’ sake :-)…

*******************************
Problem: As mentioned above, creating and maintaining different accounts for different sites is confusing and cumbersome.

Suggestion: 1 sign-in. 1 account. 1 profile.

*******************************
Problem: There’s 1 Drupal, but the basic navigation & site header differs on every site. This decreases the connection and continuity between the sites. It’s not clear (on any of the sites) that there are other sites to explore, how I can move to them, or why I’d want to.

Suggestion: Decide on the over-arching areas into which you want to divide the d.o site universe and have one consistent primary navigation (e.g. tabs or similar) that is the exact same across all sites, with secondary navigation (e.g. subtabs or similar) for site specific navigation. That will both remind people of the major areas of the d.o universe, make it crystal clear where they currently are within it and enable users to move between the different areas with one click.

*******************************
Problem: Account basics, like “My account”, “Logout”, Sign in, and register, are difficult to find because they’re buried in other somewhat unrelated content, don’t stand out, and are in different locations on the different Drupal sites. (in the right side bar on d.o; in the primary navigation on g.d.o).

Suggestion: Extract the most basic account tools (i.e. the most used): “Sign in”, “register” (for anonymous), “My account”, and “Logout” (for authenticated) and place them prominently on the page, perhaps horizontally at the very top right, and make that consistent across all Drupal sites/areas so that they’re easy to find of where you are in the drupal site universe.

I prefer 1 drupal site for all.

I haven’t read all the responses so sorry if it’s been said… I like having multiple sites but I think they need to be tied together more. Too many people don’t even know g.d.o exists. And when you search on d.o you don’t get results from g.d.o or api.d.o. So separate but tightly connected is what I’d like to see.

Michelle

I think there is a distinction that would help clarify the question slightly, defining information architecture and visual appearance vs. systems architecture.

The Drupal.org group of sites could appear to be different sites visually (and have different subdomains) while at the same time being one site installation and database.

On the other hand, the site could appear to be visually the same across the board so it appears as one site, but be served by multiple sites and databases.

From an information architecture perspective there should certainly be separate sections/sites and landing pages for the various audiences and uses. From a visual perspective they should be coherent and conistent across the board so that the user never feels they have left the Drupal site/community when moving between the different components.

From a systems architecture perspective the sites should (ideally) all be one install/database. Having the users, roles, permissions, blocks, content types and views all available to any of the different sections/sites would be invaluable, providing the capability for more advanced features and better user experience.

One critical example is having 1 user account across the board. Also, it would allow much closer integration between projects and groups. A project page could have a view block listing of posts in groups that relate to that project. A group page could have a list of related projects, issues, patches and other important information to help users keep updated and get involved.

The downside is that it becomes a much more complex site and more difficult to manage and update. Because of this it makes sense for the sites to live as separate installs that can grow and evolve more quickly.

If that is a necessity then it’s critical to have plans and a framework in place for APIs/Services between sites (Services module and XMLRPC?) so that the sites can have more control over sharing users, content, views, etc.

@Larry in comment #20:

“doing that requires having a unified nid keyspace across an arbitrary number of sites that do NOT share a database.”

What says they can’t share a DB? They’re all going to be talking to the same DB server at OSUOSL. Why can’t they share some tables if necessary? If it was all D5 and we still had the nice {sequences} table, that’s the only one we’d have to share. D6 does indeed make this problem much more difficult to solve.

I guess a big problem with sharing any tables at all is that you have schema skew across version skew and you can’t have both D6 and D7 using the same table (at least not core tables). However, we certainly *could* have a shared custom table that wasn’t part of the core schema if that somehow helped us solve this problem. I’m not intimately familiar enough with the D6 autoincrement changes to know if it’d even be possible to solve this without patching core. Maybe it’s a lost cause. But, I really think it’d be so much nicer for usability if we could maintain a unique key space.

@joaquin - i love the jquery site.

i should say, until i read this thread of comments i was resistant to ‘diluting’ the drupal site, and dispersing the community, segregating developers from end users, making it hard to find content in hidden sections. those were my main concerns (as an end user). i had seen the drawings by catch about my.drupal.org but i wasn’t convinced.

comment 18 by eric atkins sounds like the kind of dispersal i was worried about.

now i see that instead of the forums (talking to an empty room) users will be encouraged to connect locally (local groups, like DrupalUK) and find like minds with similar needs tasks (Drupal in Education, Profiles as nodes, Zen theme users, etc). then they are finding solutions.

the docs would be managed in their own tidy area (i love the friendly ‘edit’ links of jquery’s wiki). that sounds like a huge improvement!

if moshe can solve the unified login and unified search- then we’re golden.

i get it now!

It’s been beaten to death so I won’t repeat that we should go multi-site. To keep everything cohesive, it would be great to see each site with a shared header or side block to bind the separate sites together. Each site can have a distinct design but share a common language as Mark Boulton mentioned about the BBC site.

I understand he will be creating the graphical widgets so it can be reused while still maintaining consistency. I think this is a great approach. As long as each element doesn’t come off as too generic, I think that’ll be enough to tie each site together while giving some flexibility and variation between sites.

There should still be limits and guidelines so each site doesn’t have to be relearned. Some of the ideas mentioned above on services to further connect each site is also great.

Another idea is to work out parallels where possible between different installs to allow linking back and forth. For example, the handbook pages can become a jumbled mess with comments.

If each page in the handbook can link to creating an issue queue or a forum post, it would be a lot cleaner. If there’s a mistake on the page, one click can create the issue and alert doc contributors. If an issue is already created, it will link to it. When the issue is finally closed, it will automatically place a log in the history and revert to a link to create a new issue. Forum posts can just link across the installs.

If there are other areas where connections can be made, it would really help in making everything feel seamless. I’m sure this won’t be easy but we can try.

Well, as far as I understand there is a technical need (distributing server load) to create many subsites. But maybe this would not need to be reflected by the original drupal.org (a menu that links all the sites)

At the moment you cannot get to groups directly in the primary Links main menu. If we have subsites, it definitely needs a clear Navigation to link them all.

Type your comment here.

[...] have been following this process you will know that the overwhelming response to the question of ‘one site or many’ has been - many. And for many very good reasons, covering issues from technical and implementation [...]

As a user of a few of these sites/sections I personally don’t care if they are structurally bound but I do want them experientially bound. Currently I have to log into drupal.org and groups.drupal with a different account… that doesn’t make any sense to me. Identity management can easily be federated to make this happen (openId could even be used to provide sso). I also think that there may be some advantage to being able to manage/track my own activities across these diff sites in a profile dashboard of sorts. It would be cool to see what contributions I have made, where, etc.

I think a single site (from a user experience point of view, not technically) with a single login that provides easy navigation to all the (sub)-sites would strengthen the Drupal brand while providing an easy way to navigate to around the Drupal world.

Groups.drupal.org are just as much an integral part of the Drupal experience as is the api or Association site. Drupal provides enough tools for different groups of people to manage the content of different areas of the site independently. This should provide enough independence to different groups to run an area to best serve its visitors.