Posted by webchick on April 22, 2007 at 4:01am
Attached is potential information architecture redesign based along functional/user persona lines. This needs work, however it's one method of organizing content.
Whether or not these are actual different sites or not remains to be seen... there are pros (could install specific tools for each site -- ex diff module on the docs site, project module on the dev site) and cons (link rot o-plenty, lack of cohesive search) to both.
| Attachment | Size |
|---|---|
| information_architecture.jpg | 109.84 KB |
Comments
The concept...
As it's probably not clear from this alone... the concept here is to have various different 'landing pages' in Drupal... a "one stop shop" for whatever specific thing you're trying to do on the site.
So for example, the "developer" landing page would likely contain things like:
- Developer-specific news (important bits from the developer mailing list, newest commits...)
- Countdown to code-freeze
- Patch spotlight
- Links to coding standards, API, CVS documentation
- etc.
Where the front page would be more 'marketing' focused, etc.
Loose ideas about this matter
Angie, people:
Here's some ruminations about all these things. Hopefully they might act as seeds to further discussion and work.
More to come...
Users could define profiles
That sounds similar to netvibes - would probably require a massive extension to the mysite module though.
also look at it from the knowledge perspective
One way to clarify our general objectives is to look at it from the knowledge mgt (KM) perspective. We can treat drupal.org as a center for sharing, finding and generating new knowledge about Drupal.
From this perspective, we see that we need both specialized pages (via subdomains or whatever we later decide) and general pages . The specialized community pages allow experts to thrive in their respective fields of expertise. This is similar to the communities of scientists who each have their own venues for sharing knowledge.
But then we also need pages that cater to generalists -- people who traverse the various expert communities like bees who cross-fertilize flowers to form new breeds of thinking. The generalists help further enrich and cross-pollinate the knowledge.
As Angela said, we need to have enough balance so that specialist and generalist knowledge still needs to intersect somewhere. This could be via search, via tagging, and/or via special pages that integrate various different content together.
Hope I'm making sense :)
benc
"Work smarter, not harder."
http://digitalsolutions.ph
User Experience Design
A Podcast for Mac Switchers
downsides
I can see a downside to this that if I only go to the developer site, I'll pay less attention to the support form. I don't know about others, but I do look at the "new forum topics" block and generally only respond to posts I see that way. Especially since the site-wide tracker is so painfully slow.
Yes, we'll definitely need generous cross-linking...
One thing I really love about the way our site is integrated right now is that the developers and "users" DO interact with each other, and I think this contributes a lot to the cross-over from users to developers. So while I'm loathe to split it up too much, I do think that we could be organizing all the information we have a bit better.
Btw, I've updated the diagram to add a "my.drupal.org" ... neclimdul and I were talking on #drupal and he brought up the point that it'd be nice to have one place to go to look at all your stuff, and I whole-heartedly agree. :D
If there's going to be a
If there's going to be a major redesign, then maybe the forums could be reorganised a bit as well. I reckon a lot of people who post in support don't realise there's an issue tracker at all and that's something that could change when this happens. Something like an additional taxonomy for modules in forum posts which allows for feeds on project pages? That could be a killer to maintain though.
great!
I really like and agree with where this is going!
drupal.org becomes an umbrella for all drupal.org subsections! great, love it!
now. i dont know how people would like it but i think its worth considering.
why not add 1 block in the menu that the user has full control over and that block is shared across all the above listed sections of hte site!
now the key point here is that i can add links to it that link back inside drupal, and add notes to those links so i dont forget what they are.
this will give people more controll over cross linking to pages that are relevant per user basis!
this could ultimately lead to link profiling! meaning a combination of links could be grouped into a link profile and then shared.
this could be used for things like profilename:easy theming. and this will get you all 1-n links that you have to follow to get all there's to know about theming!
this idea could be taken as far or nowhere at all, i am eager to hear what the readers think and how people could benefit from this.
------------------
Sometimes interesting things appears on http://litwol.com
Initially I wasn't sure
Initially I wasn't sure about all those subdomains - the links rot I mean. If you guys can make this work technically then I'm all supportive. I used to get very confused about where I was on the site, so this would be a big improvement.
Hehe, actually I almost wonder if this should some sort of multisite based on the "eat our own dog food" philosophy.
integrated search
i like the multiple sections concept with one caveat. this should all be one drupal site so that search results span all sections. no more search silos. same for recent posts, profiles, etc.
Critical
Absolutely agree, this is critical.
search scope
It would also be nice to have each of the subdomains appear as tabs at drupal.org/search to allow optional limited-scope searches. I think this would help the signal-to-noise ratio of searches for noobs. Being able to search the controlled/approved documentation without the guessing in the forums really helps. [Of course, there's always Google site:, too; especially easy with subdomains. :) ]
I also support this, as long
I also support this, as long it is properly integrated, and as long one can move from one site to another without having to authenticate. Content should also be able to move freely from one site to another. For example, if something is marked as 'developer' and 'public announcement', we might want to show it on two sites. Having to duplicate announcements, would be a pain. That doesn't mean that all sites need to be linked, but at least some of them will have to.
Another section might be: events.drupal.org (event calendar) but that can be added at a later stage, I guess.
Dries said what I wanted to say, but that won't stop my mouth...
This would have to have real single sign-on, or distributed authentication that just works without the user noticing.
"Type in your Drupal name followed by @drupal.org" worked for groups.drupal.org, whereupon I and I think most people changed their username to be the same on both sites. This becomes inconvenient fast– Agaric's and I think others' donations on association.drupal.org are not linked to a user account due to this apparently arduous step!
This is quickly getting to be a long comment, so the useful feedback up front: this should probably start with better integration of drupal.org and groups.drupal.org, and expand site by site once user and some content sharing capability is achieved. My take-it-slow approach also relates to a fondness for the everything mashed together approach, and a belief that making issue queues, forum posts, groups, and project pages connect more closely to one another where appropriate is a bigger usability problem.
Multiple related sites that have separate looks, that know which node belongs to which site, and maybe even know where a user originally signed up, but that allow users to move seamlessly between sites and content also to be exposed to various sites... that's the dream. With openID or something and RSS or maybe new content sharing modules, could this be done without sharing a server or a single database table?
I have more than an altruistic interest in better "collection of related sites" capabilities. I'm doing this now for Free Speech TV and COA News (test site at http://com.freespeech.org/ ) but unfortunately it's 4.7 so I'm very far from the bleeding edge on this for now: we're using the very serviceable single sign-on module, shared user-related tables, and RSS feeds between the sites.
I would also hope that the sites would be sufficiently linked (or my module will be good enough) that they could all use my forthcoming "Related Items" module which will just try to make it really, really easy to have human-made connections between any two pieces of content– connect this forum post with a page where I just was, or from computer-suggested nodes based on similar terms, or even put it in a shopping cart to connect to something when I find it...
Oh, and might a "sponsor.drupal.org" be considered in your grand plan, Webchick?
~ ben, http://AgaricDesign.com
benjamin, agaric
too big
drupal is too big to serve everyone's need. having subdomains (either as proposed with fqdn or in roles) is something we really need
--
bert boerland
--
bert boerland
Not sure about sub-domains
I have my doubts that having sub-domains will make things less confusing. For example, I'm constantly surprised by the groups.drupal.org site. There are lots of interesting (and relevent) conversations that happen here that contain information I couldn't find on the regular drupal site.
To play the devils advocate for a minute, can we really cater to how people actually work by trying to force everything into a silo?
Consider this venn diagram:
(drag it to your desktop to see it larger)
This is just a quick thumbnail sketch of how I percieve the various interest groups interact. Some areas are still silos: drupal.org and the drupal association because they serve very particluar needs (for the sake of argument, lets say marketing and fund raising).
"My drupal" is unique to the user, so probably a silo in some sense.
Which leaves the rest, which I would describe as the workshop area. Like any good work shop, the tools are arranged and tidy, but things are near each other. In my experience, silos are good for storage, but not for actually working. When I work I have all my resources laid out so I can see them as I progress. When I'm done, I put my tools back in the silo.
All of which begs the question, what are the tangible goals of the redesign? I'm sure that making things easier for users is part of that list, and as webchick points out, one of the great things about drupal is the connection between the users and developers. (Today's users are tomorrows developers, if users can be engaged)
btw, I'm all for a redesign, but having clear goals can really help formulate a new IA.
forums and duplication with groups
I think one thing that might help with this would be removing all non-support forums, or all but a couple, from http://drupal.org/forum - since most of these are duplicated by groups.drupal.org (and in some cases mailing lists as well). That'd be a lot less places to look for similar information, and less total forums could allow for more specific support forums so everything doesn't end up in post-installation - currently a similar size to the other 20 or so combined.
Awesome feedback!
The goal I have in mind for this proposed redesign is to make it easier for the various profiles listed at http://groups.drupal.org/node/3761 to find information that they are looking for, and perform tasks that they need to do. The developer landing page mockup at http://groups.drupal.org/node/3777 is one example. I'm hoping to get time in the next little while to mockup some ideas for other landing pages (or if anyone else wants to give this a try, go for it :)).
You're right that developer/download/support/groups all do overlap in what they need to provide. Maybe it makes sense to only break out the front page as the "Marketing" section... but I'm not sure. I still think we could organize our overlapping information better. Although I agree with the concern of making them "silos" ... the last thing we want is for developers to be off in a corner never interacting with users and vice-versa. One of the real strengths of the mish-mash of stuff our current site is is that people can transition more easily from "newbie" to "regular user" to "power user" and to "developer" since there are no hard lines separating them. This would create some, and that brings pros and cons.
docs / handbook
I am not sure that support.drupal.org is intuitive for people looking for documentation/handbook. I am not sure it's not either. I will try and look at other sites (open source and closed) to see what they are doing. I realize that you may have already done this as part of your research too.
Nice initiative on the
Nice initiative on the reorg.
Since subdomains really don't cost money, we can probably use both support.drupal and docs.drupal or help.drupal for this. they all go to the same page.
benc
"Work smarter, not harder."
http://digitalsolutions.ph
User Experience Design
A Podcast for Mac Switchers
Hi Angela, Don't forget to
Hi Angela,
Don't forget to devote a prominent block that displays the current Drupal download.
"Work smarter, not harder."
http://digitalsolutions.ph
User Experience Design
A Podcast for Mac Switchers
Regarding the separate sites
Regarding the separate sites vs one site issue, I feel pretty strongly that all of the pieces of drupal should feel like a cohesive whole. I hate going to a site and then when I want to read docs (or whatever) I'm shunted off to some "other place" that looks and feels totally different, and especially if the URL changes (subdomains are OK, but not different domains - for me at least). It makes me uneasy and I don't trust it as much. Maybe that is wussy voodoo on my part but I don't think I am alone in that feeling, especially for someone new to not just a site but an entire product or community. That said you can have sites split out all over the place and still create a sense of connection and flow by using things like consistent top-level navigation and basic branding (like druplicon)/theming. So, to me the separate sites issue has more to do with our backend functionality/architecture desires more than anything. My biggest concern about splitting things up is user experience consistency (i.e. login and tracker type stuff) and comprehensive search. If we have dev docs here and forums there and I can't search them both at the same time, I'm gonna get cranky. ;)
As for peeps silo-ing off (did I just make that up?), honestly I already do that on d.o as it is now. I have a shortcut to my issues page and pretty much live in the areas that are my primary interest. The only time I go to certain sections of the website is when I'm giving a tour to someone new. I don't even see the front page of d.o anymore and only get a glimpse of forums when I make myself go there for karma practice or because someone is reporting spam. (Yes, I know, I am embarrassed to admit it but I might as well come clean in the interest of making d.o a better place. The fact that my issue queue doesn't have the recent forums block on it pretty much did that in. ;)) So, from my perspective I'm not sure that the "separation" that is being proposed really introduces that much more isolation. For me personally, if you have a dev section and a support/docs section I will most likely spend all of my time there (since I am a docs maintianer too) and if those sections are designed to make it easier for me to have a variety of info about those sections I dare say I will be more likely to engage than from my current lonely issues queue screen that is essentially my current home page.
Learn Drupal online at Drupalize.me
I hate to draw this comparison, but...
PostNuke went through a very similar restructuring before/while the community imploded. The main page of the site became well polished, marketing material, association.drupal.org = http://noc.postnuke.com, groups.drupal.org = http://community.postnuke.com. There used to be separate sites docs.postnuke.com and maybe themes.postnuke.com? as well, but those no longer exist. Of course there is the equivalent of install profiles in http://openstar.postnuke.com/.
I'm not saying that what you are suggesting or what they tried to do is/was wrong, only that a reorganization is a BIG deal and that CMS/community didn't really survive the redesign.
I wrote about problems with Drupal's search, documentation, issue queue vs. forums, and handbook issues after OSCMS. I've talked with Steven Peck at length about some of these issues at SacDUG. I'm also convinced that something needs to be done, but I'm not sure this is it.
+1 for RMattB's search scope. Trying to find useful information on drupal.org turns many new users off. With a mix of searching Drupal, Google, and having a pretty good idea of where to look I can find what I need, but the grad faculty, grad students, and newspaper folks I work with don't have as much luck.
+1 for pwolanin too. I think the active developer's desire to get away from the noise is driving much of what's going on with groups and the dojo.
In response to hsalazar's, "Newbie", "Regular", "Expert", "Dev" landing page suggestion... I think most people would be happy with 2 roles...
1) I don't know how to apply or create a patch
2) i know how to apply and create patches
I stand by most of what I wrote after OSCMS...
handbooks.drupal.org - This should be Wikipedia style documentation that is tagged and searchable by version and difficulty level.
themes.drupal.org - This isn't enough. We need designers.drupal.org that takes a very different approach to introducing designers to Drupal and documenting Drupal for their needs. Good design is so much more that theme'ing. I'd love to see designers.drupal.org modeled after what skinnyCorp (the Threadless folks) has going with http://www.yayhooray.com/. Requiring CVS for themes really limits the number of designers that get involved. designers.drupal.org should allow browser based uploading of .zip'ed folders. I don't think any feature added to 5 made getting new users or people familiar with another CMS to consider Drupal easier than the work Stefan Nagtegaal and Steven Wittens did on Themetastic/Garland. I'd love to see a place where graphic designers can easily upload icon sets for others to review... where UI designers can get feedback on new design patterns for common interface elements.
I'm not sure where that leaves the general support forums or how search could be structured to deal with this, but that's my feedback.
User needs evolve. The fact
User needs evolve. The fact that there is clamor to reorganize Drupal.org hints that there is demand. Like the scientific and engineering communities, a thriving community like Drupal eventually grows and creates different fields. Some of these niches will be active and some will die out.
"Work smarter, not harder."
http://digitalsolutions.ph
User Experience Design
A Podcast for Mac Switchers
designers.drupal.org
I think kreynen provides a valuable insight that should be taken into account for themes.drupal.org or designers.drupal.org (I prefer the latter, by the way):
Of course it's frowned upon to take a module and hack it to suit your needs, but it's common practice to download a theme and tweak it until you're happy. And this is not something frowned upon. Themes are nowhere near as volatile as modules, are much more easily updated, and hacked as common practice. Hence, once a theme is downloaded for use, a majority of the time, I'd imagine, it's customized to the point where having a distant relative in CVS isn't important or valuable.
Thus, one feature of themes.drupal.org/designers.drupal.org I'd like to see (and would be happy to help spec) would be to lower cost of doing business for themers. That is, as Kreynen suggested, CVS-less sharing of themes.
There should always be a selection of CVS'ed themes - maybe just those in core - but for contributed themes, is it really necessary?
level is realative
The problem is level is relative. Beginner to one is advanced beyond belief to another. Setting up a Drupal site can possibly involve an insane amount of disciplines and expertise. From php coding, to javascript, to AI, to usability, to theming, to documentation.
On improving specific sections of the documentation? All you have to do, per the several conversations, the documented method in the handbook itself and your own post, is request doc maintainer rights to be able to edit it. You have consistently mentioned TinyMCE docs and the Theme docs to which I have replied 'go for it'. If no one is willing to actually spend time writing because "they don't have time", then I am not willing to go "do it for them" if I am doing something else.
handbooks >> Contributing to documentation
We have had 'wiki' style documentation for years. It has added to the bulk, not necessarily the quality. I am tired of people saying we do not have this when we do (sure, we do not have a wiki filter added but as a result we have html code when we update drupal.org and not some weird non semantic yet another language to learn wiki thing). anyone can add content, just not edit it unless it is theirs. The amount of spam posts in the handbook on a daily basis alone are enough to terrify me regarding the damage giving everyone edit access would do. As to using a wiki for our documentation? No. If we need better tools, then we will only discover that when we use our own. The one better tool I thought was needed was improved moderation, guess what? NO ONE WORKED ON IT, so that was removed from core and reduced some options for dealing with the handbooks. Maybe some folks can help put it back in?
As to why every project doesn't have it's own forum? It's because they do. Each project has their own issue queue for these questions and answers. We do not necessarily have good signs pointing to them. Also many modules work in concert as a collection so having issue queues for many would be silly and having an additional 200-300 forums would simply kill drupal.org in of resources.
As to just having drupal.org without branching off into these other things? I am good with that myself. Better sub sections and such perhaps? drupal.org/developer drupal.org/docs drupal.org/support with the front page being the launching point to those sections.
Using advanced search can narrow down searches to just the book type content, maybe someone can work on that? If so, we can put a block on every handbook page Search the handbook
Search engine
A good search engine can cover up a lot of IA sins. I like to use Clusty because it gives the appearance of an ad hoc Information Architecture. A redesigned architecture could be married with a new/improved search engine that would give the best results for both.
Postscript 2006-06-01:
This may become the new search engine I wished for
http://drupal.org/project/faceted_search