Power to the people: a new approach to Drupal
Late Friday afternoon, the first news broke about a project that I've been working on for the last few months. Internally, the Lullabot folks have been calling it "Project Codename," because we like recursively cheeky names. The goal is pretty ambitious: build a dirt-simple hosted service that lets people with great ideas leverage the power of Drupal.
For the past couple of months, a lot of cool things have already come out of the project for the Drupal community, though we haven't been able to say much about what was going on behind the curtain. SimpleViews, my new task-oriented front-end for the Views module, is one example. Rather than constructing content listings bit by bit, it lets site-builders make a few simple choices and get quick results. Nate Haug has been building similar tools for the CCK module; Angie Byron has been working with user experience experts to streamline Drupal's administrative interface; and Jeff Robbins has been hard at work on some amazing tools that allow site builders to customize a site's layout and CSS skins with point-and-click, drag-and-drop simplicity. Subtler stuff, like John VanDyk's recent improvements to the Views Bulk Operations module, have grown out of the tools we're building for simple, customizable administration panels.
All of these things are really exciting, but they share a deeper connection that's at the heart of our project. Getting a new Drupal site is pretty easy now -- Bryght's turnkey hosting, Acquia's new support network, and one-click installs on a host of ISPs make the initial hurdle a lot less daunting. What comes after that -- turning a great idea into a fully implemented web site -- is still tough. Drupal is all about combining lots of small pieces into an awesome package. Views, CCK, custom field types, Organic groups, UberCart and eCommerce, Rules... harnessing that power requires learning a lot! The toughest part isn't the technical stuff (how to sort a Views or how to add a field to CCK) but the conceptual aspects of what these things mean, how they work together, and how the abstract pieces can be combined to achieve the goals a site builder is working towards.
Over the past year or two (especially while working on our upcoming O'Reilly book, Using Drupal) it's become more obvious to me that making Drupal accessible to non-gearheads requires a new approach. Rather than dumping all of those tools in front of people, and sweating bullets to make each one a bit simpler, we can build new kinds of tools on top of them, bridging the gap between hardcore developers and idea-oriented folks who just want to build a great site.
Some of these things are part of Drupal's core push towards better, tighter user experience. Others are specific to our project -- carefully calculated decisions to hide Drupal's more advanced capabilities from users who won't need them. Still others require new tools like SimpleViews, tools that provide users with concrete task-driven ways of achieving goals without revealing the underlying complexity of Drupal's building blocks.
The folks we've been working with on this project are awesome: genius folks like Karen McGrane, Josh Rubin, Jenny Ng, and others from Bond Art + Science have brought tons of experience and talent to the table. They designed the New York Times web site and they're passionate about bringing Drupal's power to more people. Ed Sussman, who was at the helm of FastCompany.com's conversion to Drupal, has just joined the team as CEO: his understanding of the tech industry and his excitement about the project is awesome.
That's what Project Codename is about: leveraging the power of the tools we've built as a community, putting choices that make sense in the hands of creative users, and giving them a simple hosted platform to run it on. In a lot of ways, it goes back to How Drupal Will Save The World., Jeff Robbins' opus on the platform's potential. It's a lot of work, but the payoff for the Drupal community is really exciting. In the coming weeks and months, it'll be great to see how the stuff we're building can be fed back into the community, too.
Making it easier to reach Drupal's potential.
We all know how powerful Drupal is, but if you haven't already spent a year or two working with it, it's not obvious to reach its full potential. I think this is one of the reasons why the launch of OnSugar was heartly welcomed, by insiders and outsiders alike.
I think we're facing a new Drupal era where we're paying more attention to make it so much easier and clearer for people to reach Drupal's potential. I'm very excited about your new project and I'm looking forward to hearing more about it in the near future. Good stuff!
Simple configuration + package functionality
This is exciting. I am looking forward to checking out the product that you are cooking up here.
Right on. That's why it would be great to see more modules where configuration/build UI and API is separated cleanly (I'm not excluding the ones I'm responsible for :)
In a way this development is curious because it marks a point where Drupal's configuration possibilities have become so complex that we need a new layer between end user and site builder to make Drupal as simple to configure as it has been at some point.
I'm missing one big building block for making the life of the not-so-experienced site builder easier: a possibility to package functionality that consists of modules+configurations into units that users can turn on/off. E. g. think of all the modules and configuration bits that make up an event section on a site.
Bingo!
Absolutely. The slow transition from monolithic modules like "Image" and "Event" has brought us tons of flexibility, but as mentioned, it's made the conceptual model that site-builders have to manage a lot more complex. You're absolutely right when you say that the separation between robust APIs and admin UIs is a critical part of it. Views is an inspiration in that sense: it really blazed the trail, as far back as 2006 and 2007. We're reaping the benefits today.
Yeah. That's definitely a huge challenge. There are a lot of tools out there but most are experimental and have shortcomings that would need to be resolved before they become "core-worthy". Version-specific module dependencies and better dependency tree walking are all essential, I think.
For Codename, we've built a tailored solution to this problem that is very focused on the kind of user experience we're building for the admins and the kind of capabilities that we're going to be exposing. It would be awesome to put our heads together and see if we can iron out the pieces needed for Drupal 'package management'. I know Boris Mann has been talking about the need for it for some time.
context + spaces
Over here at Development Seed we're doing some of the "packages" with context and spaces modules. This isn't packaging in the sense of download+install but in the sense of giving users very high level options for configuring organic groups ("For my group, I want a public blog and an event calendar that only group members can see").
I'm aware that this is not exactly what we're talking about here, but loosely related.
For creating packages on an install+configure level I'm thinking "Let's start simple - with a module that requires other modules + some glue." I'm sure somebody has already gone down that route and many have spent more thoughts on this problem than I have.
You see - I need to do some homework here, but I'm definitely interested in where the train is going. Let's keep in touch on this.
Use a module for managing a package
This is an interesting post in regards to using modules for installing other modules: http://www.starbowconsulting.com/node/105
DrupalCon DC - related sessions
DrupalCon DC is coming up and I wanted to update this thread with some sessions that will be interesting in the context of configuration management:
http://dc2009.drupalcon.org/session/paradigm-reusable-drupal-features
http://dc2009.drupalcon.org/session/drupal-patterns-managing-and-automat...
http://dc2009.drupalcon.org/session/staging-and-deployment-panel-discussion
All that sounds really
All that sounds really interesting.
It is great to see how modules like Views and CCK that already were highly flexible in their Drupal 5 versions did huge steps during the API refactoring for their "versions 2" for Drupal 6 towards separating the API and UI. This made stuff like SimpleViews not only simpler, but merely possible, I guess.
Following this paradigm, and working on the several ideas that exist about "building blocks", "glue modules", "installation profiles v2" etc, I see Drupal shine and shine and shine.
Is it planned to release the final result of Lullabot's current efforts as a installation profile or something comparable?
I mean, I guess the main modules will most likely be published, as SimpleViews already is, but it would be great to have the "glue code" or whatever also shared.
Anyway, it is just great to see the Lullabots working on such interesting projects.
Drupal is fantastic, as the
Drupal is fantastic, as the years go by it won't take us a year or so of working with it to hit its potential.
Re: Drupal is fantastic, as the
Sure, Drupal is best.
> Drupal is fantastic, as the years go by it won't take us a year or so of working with it to hit its potential.
I use it about last 5 years.
I use it about last 5 years.
s it planned to release the
s it planned to release the final result of Lullabot's current efforts as a installation profile or something comparable?
Drupal v Wordpress
I have been hearing so many good things about Drupal lately, I'm still wondering whether I should make the move over from Wordpress. What do you think?
The field API is very good,
The field API is very good, and is definitely a step in the right direction. It actually handles allot of situations that I have seen but have not been able to come up with a solution for. It is actually a valuable resource. I must Admit, that I do not know much of D7. I am so busy working on projects that I have not been able to code.
The concept expands beyond the issue of adding fields to comments. Its about about working towards a unified data and code structure. There is many reasons for this, Some of these reasons will become apparent as more topics emerge.
Examples:
1. On Drupal.org, the document team rolls comments into the document. After we add the comment to the Document, our only option is to Delete the comments. Now there is discussion about unpublishing nodes over deletion of nodes. There is no way to un-publish a comment.
2. Eventually even the API section of Drupal will have "comments". However, what we might want is "examples". Essentially comments but that are customized for adding code to the database. Now we may also want to include the revision system on these examples.
3. On YouTube a user can "comment" with video. The comment system is not based on a text or description. What the comment based system is built on is a reference from a video content type to another video content type. (I will address adding a relationship system to views and CCK in the future)
Essentially by unifying nodes and comments you get all of the features of Nodes within comments.
Now there is the issue of Speed. In my proposal, on a site like Drupal.org, Forum Posts, Book Pages (Documents), and the many other pages are all within one table. However in my model, Books, Forums, Events each get there own table (along with comments).
Post new comment