The process of Drupal web design has moved to the front of my thoughts recently. I am not necessarily talking about the graphic design but instead the information architecture component of the design. I started thinking about how much has changed since I was creating basic HTML sites. What constituted planning back then seems a far cry from what is needed for a content management system (CMS) where the number of pages can be significantly larger.
Fortunately, I didn’t have to make the leap from basic HTML to CMS over night. I started automating the management of my sites using include technologies (e.g., server-side includes and Dreamweaver libraries and templates). From there I started connecting to databases in order to dynamically create pages. The next step was a CMS. Along the way, I learned how to think ahead in the design phase. I wasn’t just thinking about where to put my menu but instead, I was planning how many aspects of the site could be automated and the pros and cons of such automation when it came to the maintenance and scalability of the site. So, when I jumped into Drupal version 4.6, I was well along the learning curve that it didn’t seem that hard.
My experiences weren’t just focused on my own projects. I also designed and built sites for clients as well (from HTML to Drupal). Each time I sat down with a client, I found I needed to help the client understand the processes used to design and build sites as well as the processes associated with maintaining sites after I was gone. I have found that a knowledgeable client makes a valuable member of the site design and development team.
It wasn’t until I started working on upgrading and updating my own Drupal site that I realized that there is a lot of information out there regarding the implementation of a Drupal site but not a lot about the before and after. When it comes to the “before,” many books say “plan your site.” They glance over the process and then dive into installation of the site. But if you don’t understand what Drupal can do and how it does it, the “planning” process can become very nonproductive and repeat visits to the “planning” board become routine and costly. When it comes to the “after,” many books talk about managing Drupal upgrades and don’t spend a lot of time on site operations.
What I don’t see is the information that enables a non-Drupal coder to plan a Drupal site that not only can be built with limited technology experience but can also be maintained by the same non-Drupal coder. After exploring this topic in a series of blog posts, I was asked to put them into a book — Drupal: The Guide to Planning and Building Websites.
Cindy McCourt 