Don’t let Drupal design your website.
Drupal is an excellent content management system. It provides far more than just content management. It provides well thought out and time-tested functionality for user management, security, page caching, and the ability to easily extend your Drupal website with custom code (along with many, many other features). Drupal, however, does not design your website. So, why do most Drupal themes look alike? Great question!
A vast number of Drupal themes available for download on Drupal.org look strikingly similar. Perhaps it's the general notion of 'blocks' and 'regions' or the oh-so-obvious login form. Perhaps it's the typical 3-column layout that gives it away. In any case, there's a clear problem within the Drupal theming community.
Themers are letting Drupal decide how the theme should look. Why? Because the way Drupal's theme layer handles themable output is unique, and many designers look to the common theme practices to decide what will go where to prevent additional work down the road. When a designer begins work on a website that he or she knows will end up in Drupal, and that designer has worked with Drupal before, he or she has preconceived notions about how the content will be laid out by Drupal. The designer knows that the least amount of resistance from conception to completion is to eliminate as many roadblocks in between as possible. Since every piece of output from Drupal comes with 'default' HTML output, why re-invent the wheel by changing the default? Well, that is precisely why we're in the predicament we're in.
As a designer, you're responsible for building a user-friendly application which your users will use to do things. This is user experience design. As a content management system, Drupal is responsible for providing safe, secure and easy access to the creation and management of content, be it a blog post, a user account, or any number of other pieces of content. There needs to be a clearer separation of responsibilities here.
Here are three websites. Without looking at the source code, or using trickery, pick which one is a Drupal website:
You probably picked 'thebatavian.com'. Why? Probably because of one of these clues:
- The three-column layout
- The login form
- The style of page numbers at the bottom of the page
Well, the truth is, all three of those websites are Drupal-powered. Each of them also happened to be designed by myself (shamefull plug). The Batavian was an experiment that merited a very, very short development-to-launch timeframe. Thus, little time was spent on UXD.
The other two websites were designed from the ground up without Drupal in mind. That said, I knew that the websites were going to be powered by Drupal. What I also knew was that Drupal can be built to do whatever you want it to do, if you take the time to do it.
So, folks, stop letting Drupal design your website. Let Drupal do what it does best. Let it provide an awesome framework for building robust websites and web applications, and let it keep your users and content secure, and your page load times short, but don't let it steer you away from usable design. After all, without users, who's left?
I'm outta steam, but this will probably stir some feathers within the theming community, so let me know your thoughts, and I'll grab my flack helmet.
22 Comments
So you're saying that the main inhibitor to well-designed Drupal sites is lack of UXD? I sort of agree.
I think that this boils down to the one of the most common and miserable habits of web developers/designers out there, and that is their *desire to start coding!*
Planning and preliminary problem-solving are required for an amazing-looking/functioning site, and people are all too eager to jump into the programming phase.
It's understandable, of course, because coding is what fuels our interests. It's just that Drupal makes it easy to CODE interfaces, and so that's what's happening.
Kind of. The biggest inhibitor to well-designed websites is not the lack of UXD, but the fact that it's far too easy to 'let Drupal handle the output'. That's really the problem here, right?
Drupal provides the designer / developer with every tool possible to build an excellently designed website with a focus on UXD.
In my opinion, it really comes down to laziness and the fact that every project deadline is several-months too soon.
Perhaps the real solution is to educate our clients on the importance of UXD, and make damn well sure that phase of the design is not forgotten about.
Nick
I agree w/the laziness factor.
Does this change your idea of what the 'designer' role encompasses on a team project?
It's not really just about the look and feel.
Definitely. IMO, the designer should be responsible for not only the graphical look and feel, but also the user experience: what happens when I click this?
The designer handles that, and the developer makes it work with Drupal, right?
Well, that brings up a good point - another weak link in the Drupal community is the emphasis on the developer providing the raw data, along with default theme functions, for the designer to then theme. The default theme functions can surely be overriden by the developer to match the theme, but what if the raw data doesn't reflect what the designer had in mind?
It appears that Drupal has made great efforts to support the separation of content presentation from functionality, but in the real world, design and functionality go hand-in-hand when it comes to the user experience. Thus, perhaps Drupal's emphasis on separating the two is simply the opposite of what should be done. The developer and designer need to be best friends.
Nick
Cool - that is great advice. Drupal is best for providing the framework for your content. Design --- leave that to the designers!
-Eric
And when you're soloing a project, acting as both designer and programmer, don't let the programmer in you boss the designer into making bad decisions!
Friggin programmer alter-egos think everything revolves around them!
On a very related note, this module looks extremely interesting, and definitely on the road to better Drupal UI patterns: http://drupal.org/project/context
Nick
Nick, great article that has sporned some interesting comments. Clearly every Drupal implementation comprises some degree of consideration for design, configuration and possibly programming. You acknowlegded that for The Batavian website you worked with constraints that impacted on the amount of time available for design effort and you make the point not to let the Drupal standard configuration dictate the deisgn. Others have commented on the need to harmonise design and programming to achieve the desired outcome.
So how does all this relate to the customer's expectations and gathering the initial user requirements and project specifiacations?
Should we work with the requirements dictated by a customer even though we may not believe the outcome will provide the "best" outcome, eg. a customer is concerned about function and not about design. Alternatively should we use our expertice to guide and attempt to convince our customers that all of these issues are important to achieve the "best" outcome for the money spent?
Also, I'm interested to know what others think about the "typical" time breakdown of the various functions for a Drupal implementation. In other words, what is the typical ratio of time spend performing various tasks such as requirements definition, configuration and design?
Isn't this another view at the old "custom vs contributed" problem? You can't compare. When you do a custom theme for a specific project you know how much time/effort/budget you can spend on design. Which can range from Garland-with-a-logo to The Batavian to Belle Scena.
When you design a contrib theme you can theoretically do anything, but it's an awful lot of work because you want it to be useful to lots of people so you have to maximize flexibility. Or you target a specific audience, say a techy-manga-bloggy theme, but only a handful of people will use it. Or anything in between, basically you define the constraints yourself.
Simple use-it-anywhere themes have their place, but I have to agree there are already tons of them ^_^
Also, I don't think Drupal's default html itself is the culprit. It's a good base and you can go far with just page/node.tpl and creative CSS. After all, whatever the markup, any web page is just a bunch of rectangular containers. But of course it requires a deep understanding of CSS not everybody has. Problem is, few designers and few developers are comfortable with html/css beyond the basics, and advanced Drupal theming requires more than that. Hybrid profiles are still not a common breed.
Very interesting post indeed. I dare say, i have t agree with you :-)
But, let me ask you a different question. All 3 sites run on Drupal, yet the 2nd one is the most drupal-ish. So, what about the other 2? What strategy or path did you take on designing them? Would love to know your take on them please!
I completely agree. 2 good ways to not end up with a Drupal look:
* Copy a simplistic theme and get rid of all CSS files and PHP logic until there's only HTML, then slowly add layout markup and styles as necessary.
* Start with reasonably functional HTML/CSS template that doesn't look like Drupal and slowly decide what needs to be taken over by the framework and how.
Thanks for the comments everyone.
Allan,
> So how does all this relate to the customer’s
> expectations and gathering the initial user
> requirements and project specifiacations?
I think as developers, it's our responsibility to convey to our clients the importance of any particular piece of the project. They're simply interested in a successful and functional website. Rarely do clients truly have a sense of what they need, only what they want. Since we know that good usability plays a large part of building a successful website, we should definitely be selling them on it.
> Should we work with the requirements dictated
> by a customer even though we may not believe
> the outcome will provide the “best” outcome,
> eg. a customer is concerned about function
> and not about design. Alternatively should
> we use our expertice to guide and attempt to
> convince our customers that all of these
> issues are important to achieve the “best”
> outcome for the money spent?
The latter, for sure. As mentioned above, in the end, it's our responsibility to build a successful website or application. Crucial to that is good usability.
> In other words, what is the typical ratio
> of time spend performing various tasks
> such as requirements definition, configuration
> and design?
I'm not sure. I think it really varies by project. There's no real 'magic ratio' that I know of. I think if one were to attempt to put some time guidelines on these tasks, they'd almost immediately be up for debate depending on the project. A colleage of mine, Pete Karl, just wrote an excellent blog post touching on some project management guidelines for a project we're currently working on.
####################
Elv,
> Simple use-it-anywhere themes have their
> place, but I have to agree there are already
> tons of them ^_^
Exactly. The 'all-purpose' themes have been written, and serve their purpose. More often than not, website builders are looking for a theme that best fits their specific website's needs. In my opinion, there should be more 'genre-specific' themes than there are 'all-purpose' themes.
> Problem is, few designers and few developers
> are comfortable with html/css beyond the
> basics, and advanced Drupal theming requires
> more than that. Hybrid profiles are still
> not a common breed.
Sure, but I think for the purposes of this blog post, I'm focusing more on firms and companies large enough to have the resources to follow a fairly detailed development / design process.
####################
Pratul,
> All 3 sites run on Drupal, yet the 2nd one
> is the most drupal-ish. So, what about the
> other 2? What strategy or path did you take
> on designing them? Would love to know your
> take on them please!
The other two projects that are least-Drupalish were designed from the ground up in Photoshop, then moved into HTML / CSS. From there, I integrated Drupal functionality piece-by-piece as I needed it from the CMS. This assures a prime focus on only pulling what you must from Drupal, and not designing around the framework already given to you. That said, I was aware that 'Drupal themes menus like this' while I was coding HTML, so I used some Drupal-specific class names to avoid work down the road. In this regard, Drupal catered to my design only when it meshed 100% with what I had invisioned in the original design.
Nice article, and nice point.
BTW, all of three mentioned sites look like drupal sites (and they are drupal sites ;-) )
Thanks, and yes, I kind of realized that after I posted - I should have been more clear. The non-Drupalish style of the other two sites is really only on the homepages.
The styling of forms and whatnot leave a lot to be desired (gotta love unrealistic deadlines).
Nick
Nick, I've just come across your blog via Drupal Planet. You make some very valid points about the samey quality of most Drupal themes. The community needs to take up the challenge to create some inventive new Drupal themes, and not just variants of the default themes or ports of WordPress themes.
Loved your other post on customising the user profile pages, by the way. Any other helpful tips would be gratefully appreciated!
Hi,
Very nice article and ofcourse very good site designs. I especially liked the http://bellascena.com
But I still think there is some limitations in Drupal, when we get set to design a design. I don't know whether I am right on this point but I think Drupal doesn't allow us to use diffferent images/ backgrounds for diff menu item. Or does it allow? Second thing on the menu, is the rectangular region. Ofcourse we cud have a diff shape fot background. But does Drupal allow, curved positioned menu items (Primary Links)? I doubt whether it does.
Interesting article, and some good advice in the comments.
Isn't it that case though the generic Drupal example you gave pretty much look like most CMS'? Three columns... header...
But your message is essentially right : experiment with layout and design...
Yeah, you're right. I think it boils down to the fact that CMSs are forced to cater to all, but themers and designers are not, and the themes should reflect a more diverse selection of genre-specific layouts.
Nick
I think design is underrated, but it is an important factor in order to draw and maintain new visitors. But designing these themes can be time consuming and laborious. This is most likely the reason why so many themes look the same. Take vBulletin for example. I am having a hard time finding a theme that looks unique enough from the rest of the designs, which is why I am considering getting a custom design for my skin.
Nick, I've just come across your blog via Drupal Planet. You make some very valid points about the samey quality of most Drupal themes. The community needs to take up the challenge to create some inventive new Drupal themes, and not just variants of the default themes or ports of WordPress themes.
I have to agree with the statements about the lack of "desire" that some designers face when creating templates. It takes time and efforts to make something different, and not all have the same skill levels. I'd even say that that's probably one of the main drawbacks of Drupal when compared to Wordpress (I know I'm comparing apples to bananas). But from the aesthetic standpoint the Drupal community needs to turn it up a notch.
My first programmer actually built my site did a disservice to me too. After the fact I found out he actually copied the same look and feel of a website that was already on the web. The thing is programmers will do exactly as state above. To someone who is just getting their first site built for them there is really not much you can do. I find it very important to find a developer who understands your needs and concerns. Make sure everything is in writing.
Post new comment