Forking the community, not the code
Over the last several months -- especially as Drupal 4.7's beta period has dragged on -- more and more people in the community have weighed in on the platform's direction, the growing pains it is facing, and the best course for the future. I'm no different -- I'll put my two bits in here.
It's obvious that the last year have been big for Drupal. High-profile web sites rolling out Drupal based designs, coverage on tech sites like Slashdot and Digg, funding from Google, thousands of dollars in fund raising, mentions in The Economist, and dozens of thousands of sites now answering the 'are you running Drupal?' question positively. It has been a smashup success of a year and I feel grateful that I've been here in the community (though only visibly for the last six months or so) to witness it.
With that success, though, comes a lot of pressure. Until this point, Drupal has been (mostly) programmers and hobbyists, or 'true believers' who decided to base their web work consulting on the framework. Now, more and more newcomers are joining the fray. The post count on the Drupal.org discussion forums is climbing in a nice logarithmic curve, and every day there's a little more friction between hardcore devs working on building great software, and end-users who want a turnkey web app.
There's always been resistance to subdividing the Drupal community into 'groups.' Beyond 'people who contribute code and those who don't', everyone is lumped into the same crowd. I think, though, that the time has come to identify three key groups of Drupal users, and address them individually on Drupal.org.
First, there are software developers. Many want to build a site of their own, or have a programmerly itch to scratch and are hunting for a web framework they can use as a jumping-off point. These people want to know about APIs, the framework philosophy, and other under-the-hood stuff.
Second, there are site builders. They're usually experienced webmasters or consultants who need to build a custom content-driven site, and recognize the foolishness of 'rolling their own.' They're most interested in tying contrib modules together, putting together custom themes, and how well the whole mess scales once their client starts pounding on it. Experience levels can vary a lot in this group, but most are savvy folks who are drawn to Drupal's flexible module system and content organization tools.
Finally, there are task-focused users. These people want to set up an art potfolio, or a blog with software downloads, a web site for their church, or a site for their fledgling web comic. Sometimes, they're tech-savvy web geeks who want something cooler than Bloger for their personal home page. Other times, they're small business owners who want to sell pottery but don't know HTML from a ham sandwich. They don't really care about the details as long as it gets done, and gets done well.
These three groups of people are all important to the Drupal community. They ARE the Drupal community. But their needs, their experiences, and their frustrations are all very very different. Trying to fill all three sets of needs with a single solution will always be very, very problematic. Drupal is probably best suited for the first two groups right now -- its emphasis on Lego-style site construction ensures most sites will need customization, tweaks, and third party addons. CivicSpace, with its streamlined installer and bundle of pre-installed modules, is great for users in the third group who want to set up community oriented sites for nonprofit and political groups. The now-defunct Drupal4Bloggers is another great example, though it required hacks to Drupal's core that made it tricky to support.
Others have blogged about the idea of streamlining Drupal's core even more than it already is, and I'm in favor of it. Stripping out many of the current 'core' modules like Book, Forums, Blog, and so on would leave us with a pure 'developer core' that emphasises APIs and framework development. Helping site builders with information on combining modules and themes to create a 'recipe' for their site leverages Drupal's strengths. For users who want a turnkey solution for a site, packaged distro's of modules and themes could be bundled up to provide focused sets of features, customized interfaces to common admin tasks, and so on. There's nothing, for example, that would keep us from offering the 'extra' modules Drupal currently includes as a special 'Drupal Classic' dristro.
As we in the Drupal community move forward, I think that managing expectations for each group, pointing them to contextually helpful resources, and admitting when Drupal isn't yet ready for their needs, is extremely important.In my dream world, Drupal would have a splash screen of sorts, channeling them in the right direction before they get swamped in newbie questions, theming tutorials, or geeky arguments about optimizing tree sorting algorithms that really belong to another group entirely.
This doesn't mean "splitting" Drupal's community. Those three groups of users will have overlap, obviously, and there's no reason they can't all coexist on the same site using the same resources. It's more about how we think of Drupal, and how we approach it.
Exactly!
I would love to work on on a redesign of Drupal.org that incorporated this notion. I think that to scale the community it is critical that we start coming up with effective ways to form groups, find people in the community who share the same focus area, and figure out more focused way to get work done. I will be blogging about this later.
Redesigns
Actually, I'm not sure a visual redesign of the site is the best step or completely necessary. I whipped up that graphic in a moment of brainstorming, but it's only a reflection of the idea. More important is how the hardcore Drupal folks -- the ones who are on the site, in the forums, on the mailing list, in irc, etc -- think about and talk about Drupal.
The layout of the site is something that reflects a mental model of the Drupal community. For newcomers, that's important -- but it's doubly important that the people that are part of the community have a model that matches what we're "presenting."
You're right, though, that grouping is important. Right now, the best approach is to get a project going -- even a stub -- and keep important discussions in the issues queue for it. As traffic on the forums increases, many kinds of discussions simply scroll out of the tracker in an hour, never to be commented on again.
wonderful
a-freakin'-men, Jeff. Nicely done.
Amen
Thats all I got to say to that!
Great post, I think this will lead somewhere. Ber
Thanks!
I still have a short-list of some general-interest distros that I'd love to see built, or help build. I even took some time to think up nifty little names for them...
Scribbler -- Drupal for webcomics
Jot -- Drupal for Bloggers (aka indite, d4b)
Glimpse -- a Drupal portfolio tool for writers and artists
Nexus -- Drupal tools for real-world communities (not quite the same as purely online communities)
Scribbler in particular has HUGE potential. Many webcomic authors are currently struggling trying to wrangle MovableType or WordPress into CMS land, or using shared communities like KeenSpace. If an open source solution were out there that provided things like delayed publishing, forums, author blogging, nice content organization, and things like 'premium content,' I think there would be a huge wave of interest.
Sympal is tremendously promising, too -- a collection of modules, utilities, and add-ons for developers building sites with Drupal. Like a scaffolding that can be used during construction and removed after the work is done...
Don't ask me, man. I'm still
Don't ask me, man. I'm still figuring out WordPress.
Cheers,
Shig
Jeff -- well done. I'm the
Jeff -- well done.
I'm the staff manager who works with our non-staff consultant web designer for a non-profit that has a pretty big web site. Our web designer is a PHP MySQL person and over the last year we've been converting a site of about 750 hmtl pages into 4 main databases, reducing the number of files to about 75 html pages and 75 php pages even as we've increased content over the year. But we are at the point where we want to pull it all together and it doesn't quite make sense to "roll our own." Our web designer is just at the point where she wants to learn a CMS well and the Drupal reviews are great. She hasn't started yet, it will be interesting to see what her learning curve is. She is definitely in your group 2.
I'm in your group three, but probably a grouup two wannabe. I've been teaching myself CSS, php and MySQL in my "spare" time. But I'm smart enought to know that I'm doing that learning a.) as a hobby and b.) so I can be smarter in talking to our web designer.
The Drupal home page and support pages is not well organized for someone like me. I know WordPress is much simpler than Drupal and their site has support problems as well, but I do think it is better organized. The "Handbook" section of the Drupal site isn't really a handbook, except for maybe the installation piece. For using Drupal, isn't really a coherent starting place.
If support docs were written in a style suiting group three people (non professional designers, non programmers), I think it would help everyone. You'd have fewer newbie questions on the forums and better places to send folk when they do post on the forum. Also, by writing a manual in an orderly and simple way, the community might learn new things about what Drupal does best, and what it doesn't do well.
Writing a simple manual doesn't mean teaching people PHP and MySQL. You can say at certain points in the manual, "here is where you'll need a php/MySQL person if you want to go in X direction or perform Y custimization."
Though I haven't found the documentation great, I've found the support forum really interesting. I've also headed the advice that I need to be patient on my learning. I can "feel" elegance in Drupal and don't demand that it instantly do what I want it to do. In my initial test site, an Intranet for our staff, I was frustrated that the book posts for a staff user manual were posting to the home page where I just wanted news articles. But I figured out how to add a menu item just for the book I'm working on AND used the "demote" function to get book off the home page. I still don't really understand "demote" but the success was satisfyin! I really get that with all good things, patience pays off.
I agree that it might be a good idea to limit focus of the core ap even further and provide extra functionality via modules or bundled modules.
Thanks again,
Shai "kelev"
Thanks!
Shai, thanks for the feedback. I think it's pretty acknowledged inside the Drupal community that help and hand-holding for 'group three' folks is lacking. The documentation team is definitely a great set of people, but as many have mentioned -- they are few and the topics are many. To some extent, I think task-focused tutorials, and drupal "distributions" that focus on a particular need, like blogging or group collaboration, will help too. It's a LOT easier to document how to use "a blogging tool" than "A flexible content management framework you might want to use as a blogging tool." :-)
Regarding the 'promote/demote' issue, here's a quick explanation the touches on how flexible Drupal is, and also the importance of 'selective revelation' of details depending on how much someone really needs to know.
To a 'level three' user, the simple answer is: the front page of your Drupal site displays the most recently posted stories, blog entries, etc. If you don't want a piece of content listed on the front page, edit it and uncheck the 'Promote' checkbox.
To a 'level two' or 'level one' user, the answer might be: Drupal can display any valid path as its "front page." Drupal's built-in "node" module is used by default, and it displays a list of the most recently created nodes whose 'promote' flag is true. If a node's 'sticky' flag is set, it's also sorted to the top of the list. By default, all content gets promoted -- but you can change that by going to Administration > Settings > Content Types > (your content type here) and turning off the 'promote' flag there.
It sounds like your web designer (soon to be PHP tinkerer!) has her work cut out for her. I helped manage a conversion from 1000 or so HTML files to classic ASP pages a number of years ago, and it was definitely an adventure. If she's looking for some baby steps towards more PHP usage, she might also check out the 'PHP Snippets' archive on Drupal.org. Most of them are very short chunks of code that can be stuck into a Drupal node to display custom information. Lists of nodes written by a particular author and filed in a particular category, for example. It's a good way to start tinkering with Drupal's data and PHP without diving into full module writing/etc.
Stuff
The solutions proposed in the post only scratch the surface and are not particularly helpful, except for being a good summary of what people have repeatedly suggested for years. Writing them down, once more, is not likely to change things. (I'm still trying to have people contribute small project.module improvements so we can proceed with the drupal.org upgrade.)
While there are many different target audiences, this post appears to assume that they are equal in size. I don't think that true, and therefore, having 3 entry blocks might not be the best solution. Out of the 55.000 drupal.org users, 53.000 are probably users. The remaining 2.000 users can probably be split on two; 'developers' and 'consultants'. Most of them are both developer and consultant. If we assume that these numbers are accurate, it is clear that we should optimize the site for users. I'd like to believe that, currently, drupal.org is focused towards users. Changing the site to your proposal, requires nearly all users to click more.
These 3 categories make more sense to me:
1. Drupal prospects -- looking for information about Drupal to evaluate Drupal
2. Drupal users -- looking for support, a manual, etc
3. Drupal developers/consultants
(Seen CivicSpace's homepage? It does exactly what you propose.)
Good points
Dries, thanks for taking the time to read and respond.
I agree that what I'm saying isn't particularly new or novel, and whipping up a pretty .png doesn't accomplish much. I half-regret even mentioning the Drupal.org front page in my post, as that aspect was a bit of an afterthought. I saw the CivicSpace home page (as you mentioned) and wondered what Drupal might look like with a similarly goal-oriented introduction.
The three categories you mentioned -- prospects, users, and developers -- are one way of segmenting information that's presented, but I think it's still flawed as a way of looking at the community. Those groupings are really about one's relationship with Drupal, not one's eventual goal. A 'prospect' could be evaluating Drupal because they want to develop a family tree management system and heard Drupal was a good starting point. They might be evaluating Drupal because they want a blog for their mother and heard it was 'cool.' Both of those are prospects, but their goals and their needs are wildly vastly different.
Part of my post, I suppose, assumes another shift: away from 'Drupal Core as a turnkey web app' and towards 'Drupal core as a framework for web apps and web sites.' You've written before about the need for improvements to Drupal's UI and the user experience -- you're definitely forward thinking in that regard and recognize the importance of it. Drupal, as it stands, though, can't really be optimized for any of the applications that really need it. Bloggers, community moderators, ecommerce store maintainers, and so on need to look at things differently and some workflows that make sense in one context are needless cruft in another.
Right now, Drupal Core's user experience is good for developers building a new site. Optimizing it for anyone else, I believe, will really require focusing on the end goal rather than tweaking widgets and verbage in core. Stripping core of a number of exteraneous modules, and pointing more end-users towards specific Drupal 'packages', will do more to help this situation in the long term than any other specific changes. Right now CivicSpace is the only currently shipping example of what that looks like, but Ber's work with Sympal demonstrates another direction it can be taken.
I did toss a patch to project.module into the mix at Adrian's prompting, though I'm still puzzling through integration with project's grouping and sorting. :-) I think the "phone home" changes to Drupal.module should be very interesting, as they may provide us all with some useful statistics in the future about how people are using Drupal. Do most people install a pile of modules? Is 90% of the installed base running an unmodified core with nothing but blog.module and forum.module? It's not perfect but I think that will help increase the amount of information the community has for decision-making.
Marketing
After using the Drupal.org site for a month, it definately frustrates me as well. When the site upgrades to 4.7 and the new search is available, this will help. But it doesn't address your point - people are coming to the site with very different needs, how do you address them?
May day job is marketing, and more relative to this conversation, in positioning of of complex concepts/products to multiple audiences.
I would recommend as a first step that the demographics of visitors to the site be measured. We all may have opinions or even educated thoughts, but you should always start with facts.
A follow-on recommendation is that the collection of the demographic information should not try to classify the user into a pre-defined group. The groups come out of the facts, not vice versa. You have to be really careful not to lead the answers.
This probably can't be accomplished by a single set of questions.... I'd imagine in this case, you'd need a few
- What do you use Drupal for?
--- Nothing yet, evaluation
--- Personal Blog/Website
--- Commercial Website
--- Platform for Consulting
--- Platform for Business
--- etc....
--- and of course "Other" - please tell us more
- What are you here to do?
--- Learn more about Content Management
--- Learn more about Drupal
--- Evaluate use of Drupal
--- Figure out how to make Drupal do something
--- Fix a problem
--- Access the development documentation
--- etc....
This type of information could then be interpreted for potential redesign of the drupal.org site and for how to "package" drupal for different uses.
Cheers,
Mike
Post new comment