Nick Lewis gave this talk about what's happening in Drupal's Design and Architecture at DrupalCon San Francisco 2010. You can find him on Twitter at nicklewisatx
The Kitten Methodology
When I first encountered Drupal, it was a weird box that I didn't really understand, and I just pawed at it for a little while. Now I'm a Drupal expert, and I got here by just playing around with Drupal like this.
Spy on the natives
- Understand the Drupal Culture. Get on IRC and pay attention to what the contributors are saying.
- Use existing sources of data, see what modules people are using by usage statistics, for example.
- Read the markup of the big sites to figure out how they were built
The original plan was to collect design elements from 25 major Drupal sites. I was interested in whether they were using Panels, for example.
I found that most sites were built the same. The only thing that stands out about the designs are that they are simple. I suddenly realized that it's impossible to put out a bunch of screenshots and try to invent a narrative. It doesn't really tell a story, but there is a pattern there that's kind of interesting.
Jeff Eaton gave a session called Architecture is for Everyone saying that we are all architects, and we need to start thinking like architects. Architecture is both an art and an engineering discipline. But as soon as you apply the standard metaphor of architecture to a Drupal site, it falls apart.
When metaphors like this fall apart, it usually means that they're wrong. I think of Drupal as a complex system that is grown, rather than built.
So what is Drupal?
Some people think this is an appropriate definition of Drupal:
Drupal is a platform for software that builds webpages.
But really, Drupal is an application, and web pages are just the output.
A complex system that works is invariably found to have evolved from a simple system that worked.
There are two systems out there: there's your personal software ecosystem, and the world-wide Drupal ecosystem. Humans have always been good at working with complex ecosystems, and we need to work with Drupal in the same way. Instead of architects, we're more like doctors.
Be a Good Doctor
- Don't prescribe treatments until you're able to diagnose the problem.
- Know the difference between a symptom and a diagnosis
- Be aware of interactions between modules
- Know when to get specialists involved
Trends in Process
I hate talking about methodologies generally. The standard methodology is the Waterfall methodology, where we plan what we're building before we can imagine it, and then blueprint before we know what we're working with. You'll get requirements like "Needs to be easy to update" along with a crazy complicated design.
Here's what I recommend:
- Define a one sentence goal for the site
- Start solving the basic problems first
- Meet the monster at the start of the project, not the end
- Add design as needed
- Design parts, never design a whole
Thanks to Nick for this talk. You can find more from nick at his website, nicklewis.org.