Sunday, 27th March 2011Atomised Web Design - Going Beyond Responsive Web Design with Drupal

For the past six months I have been following Jeremy Keith's pursuance of the Responsive Web Design technique with interest - not because I too live in Brighton and had the opportunity to attend his barcamp Brighton talk on the subject; nor because he gave a keynote on the design of HTML5 at DrupalCon Copenhagen which I attended, or even because he recently gave an HTML5 workshop at DrupalCon Chicago followed shortly thereafter by comments on his journal:

It [Drupal] doesn’t appeal to me simply because it outputs any markup at all

furthermore:

Rather than focusing on the kind of sites for which Drupal is particularly well-suited, the goal appears to be nothing less than total domination of the web. I’m not sure that’s such a good idea. If you try to please literally everybody, I think you’ll probably end up pleasing nobody.

No, I've been following with interest because whilst I like the concepts, I believe they make some pretty big assumptions about the users of their design, and it was only when I read his latest journal entry on context that it hit me as to what the problem is in a nutshell: 

Designers, in most cases, design for websites, not for web systems

In Jeremy's journal entry on context, he alludes to this issue when he says:

The context problem - figuring out what a person is doing at the moment they visit a site - is really, really hard.

This is where Drupal enters the equation and works towards providing the flexibility to cope with an arbitrary number of use cases, with the ability to take into account what a person is doing before the site is even there, or indeed after it is there and they want to change how it works.

By providing some markup, Drupal and its thousands of extension modules effectively atomise design and provide a way for users to be able to modify and extend the functionality of their websites without necessarily needing to have specific programming or design knowledge.

The benefits of this atomised design of software became even more apparent to me whilst attending a Birds of a Feather session at DrupalCon Chicago on OpenAtrium, a distribution of Drupal which provides an out-of-the-box intranet solution. The guy sitting next to me in the session was using OpenAtrium to help ex-prisoners who were on a 12-step programme. Others around the table worked at Universities, and a few used OpenAtrium in voluntary organisations. None of them had the budget for developers or designers, however all could freely use Drupal, and when I mentioned the MindMap plugin feature for OpenAtrium their eyes lit up, and no doubt some are using it right now - without the need for developers or designers getting involved at the point of use - i.e. the context of which Jeremy talks of in his quote above.
 
This, for me, is a winning formula. Sure, I build websites for people, but I don't want to dictate that they have to come back to me every time they want to change something or extend their site - or to a specialist much like I had to when I owned a Triumph Spitfire car - Ford cars worked out much cheaper to maintain plus my father worked there so I got a nice discount! Many of my clients do come back to me for further developments, but others make the most of their freedom to dive into Drupal themselves or hire an in-house person or team depending on their own needs. As for which sites I use Drupal for, well it is everything - Jeremy's quote "Rather than focusing on the kind of sites for which Drupal is particularly well-suited" simply does not come into the equation as I do tend towards the "total domination of the web" he mentions, but in a much less hostile manner than he implies - I believe in building open, sustainable systems - Drupal provides the vehicle for me to do this.
 
I see similarities to when IBM brought out the PC, and Microsoft similarly when they unleashed Windows on the world, but this time with a big injection of freedom to boot. Sure, we bemoan Windows and Microsoft, but the fact is they enabled computing for the masses - I see Drupal in a similar space with web systems. Before the PC we had numerous home computer systems, all requiring specialist parts and dedicated software. After the PC was introduced we benefitted immensely from commodity hardware bringing the price of computers down - I see this happening in the website world, especially with companies such as Microsoft supporting Drupal.
 
By using a standard system such as Drupal, I provide a starting point for my client's web presence which they can build on, whatever the kind of website it is I am building - and they range from small sites like my blog right up to multilingual, multimillion pound projects. Dries Buytaert, the founder of the Drupal project, explains the scenario well in this blog post about his company Acquia's product strategy and vision.
 
The Developer's Dilemma
 
In his journal, Jeremy points to an article which is a call for arms for A Real Web Design Application which I agree with, and the point of me writing this blog post is to say there is much more we could be doing if we integrated web systems with web design, not just by adding forms into the equation but a whole load more functionality, atomised. Ten years ago I was working in a software house called RemoteApps in London where we were building a product which was much along the lines of, and with similar principles to (eliminating the middlemen) Drupal, however it wasn't Open Source. RemoteApps had modules for the three C's of the Internet: Commerce, Collaboration, and Content Management, along with a central web admin system called TeamView - much like Drupal has today.
 
We had numerous clients including Volkswagen, B&Q, Umbro, USL Soccer League, The 365 Group and a host more, and just before investors pulled all their stock out of software houses in the dotcom crash we had signed a deal with Macromedia to integrate RemoteApps into their Dreamweaver web design software so that designers could simply drop functionality into their designs. Imagine how gutted I was when I saw the full-page Dreamweaver RemoteApps ad on the back of the Macromedia Magazine which arrived just a few days after we had all cleaned out our desks! I believe systems could be built using Drupal to provide the functionality - design should not just be attributed to pages but to components, and as Jeremy points out, currently:

Far too early in the design process, a tool such as Photoshop or Fireworks gets opened up and a new file is created with an arbitrary width (960 pixels being the current width du jour). That process lends itself well to creating paintings of websites but it’s not a great first step in creating a living, breathing website

I do not see how A Real Web Design Application could not exist without both the Yin and Yang of Development and Design, thus appears what I like to call The Developer's Dilemma. We, as developers, are not designers. But if we do not provide some design, then we do not get the benefits atomised web design provides. Danish Drupal themer MortenDK is working to improve this situation with his CSS Cleanup Initiative which will enable designers and themers to more easily modify or remove completely any design which is contained within a Drupal module, and Jeremy's friend Jen Simmons is spearheading much of Drupal's HTML5 support, but without any markup, Drupal is simply not Drupal. In Drupal 7 we (developers through API and others through UI, then bake to Features) can easily create different build modes for data display depending upon the context they're used and it's becoming easier every day to do anything you want to do on the web with Drupal - and leave your clients with a system they can build on themselves with relative ease and low cost when compared to proprietary alternatives.
 
Drupal as Lego
 
One memorable quote from the Drupal CXO event in Brussels I attended last October was:

Drupal is Lego, Joomla! is Playmobil, Wordpress is Duplo

If you consider Lego for a minute, the bricks are delivered in particular shapes and colours - Drupal modules similarly. Think of Drupal distributions as ready-built Lego kits which you can still build on, and paint over if you wish. Like Lego, painting your blocks isn't necessarily the best thing to be doing, and I think this is the point at which the designers have an issue with Drupal's modules, but again that is at the point of delivery once you know what it is you're building. 
 
Lego has lasted the test of time and is still as exciting and entertaining to play with today as it has been - I should know after spending some time in the Lego store in Chicago recently buying a present for my nephew (don't let on.... he hasn't got it yet!). Sure, there's other players out there in the market, so we're not saying it's total World Domination, but a fair amount would make it much easier for people to swap pieces and knowledge.
 
Think of Drupal as a Linux for web systems. It has a core set of modules and a whole Wild West of contributed modules out there - 7,000-odd at the last count. Sure, there'll be cut-down distros to deal with specific needs, such as where web admin interface isn't needed, but to set a standard at a level which attempts to please both developer and end user is not an easy task, and something which I think Drupal increasingly does very well indeed, especially with the new UX improvements in Drupal 7.
 
Finally, Jeremy says:

Different frameworks will appeal to different people—the trick is in finding a framework that matches the way that you approach a problem. A framework is, after all, supposed to be a tool to help you get work done faster. No one framework is suitable for all projects and no one framework can possibly hope to appeal to everyone.

As pointed out above, Lego's done pretty well for being a framework to build no end of different things, so I don't really agree with the statement above. I simply couldn't build the stuff I do in the time I do without building on the shoulders of others, and my work certainly lasts longer as a result of adhering to Drupal's API and Coding Standards.
 
I spend a lot of time learning and giving back to the Drupal community where I can - at the end of the day no client has ever come up and asked me for Rocket Science, so I'd rather spend my time building cool stuff and using DRY (Don't Repeat Yourself) principles so that every day is different and I build upon yesterday's learning rather than sitting here coding another webform. In Drupal we are moving on from web forms and working with end users producing such wonders as the new Workbench suite of modules I've recently implemented for one of my clients. It's webforms for sure, but webforms which provide a much higher level of end-user use than anything any other piece of software can provide me, now, and for zero licence cost, and with a plan of growth for the future and a ready-made community of developers and end users to join in where I can, and if I want to.
 
This sort of software API can always be built on, optimised, even rewritten in a different language - once we've surpassed the initial cost of research and development, we are building knowledge not just code, and with software being the major cost of most if not all technical projects (yes, I'm thinking Rocket Science here), I think this is a pretty good way forward for humanity right now so we can spend time on more interesting things like working out how to populate other planets ;)
 
There are huge benefits on all sides to using Drupal for websites, and the only way of making sure it suits your needs is to simply join in the community in any which way you can. Perhaps one day Mr. Keith will dip his toes further into the water and see more of Drupal's Awesomesauce!
 

tags: Drupal PlanetHTML5drupalResponsive Web DesignAtomised Web Design