Working with information architects and designers on Drupal CMS sites I’ve found they canhave a difficult time creating solutions that work for the development team implementing a Drupal CMS solution. Drupal-driven web sites absolutely need to be architected and designed from within the development parameters that Drupal allows, which tend to be more architecturally complex and more constraining from a graphic design perspective than normal. I hope the following tips are useful for IA’s, designers and developers alike.

Information Categorization with Content Types

While establishing your content inventory and building a site map from that inventory, create a seperate document to record the Content Type -- or node type – of each page. In Drupal the Content Type is the fundamental discriminator of information categorization. As a general rule, establish a Content Type for each content container whose data to be recorded are irreconciably distinct. As a concrete example, Drupal provides the following common built-in Content Types:    

• Blog Entry – for blog sites
• Book Page – for multi-page articles
• Comment – user-contributed comments to any other node type.
• Page – the most common type, used for more static content not expected to expire
• Poll – voting poll
• Story – single-page articles for timely content expected to expire

Custom Content Types can easily be created from scratch and built-in Content Types can easily be extended using the popular Content Construction Kit module and it's associated add-ons. Additionally, third-party modules may add new Content Types to the system, such as:

• Web forms – simple web forms that email and/or record entries to a database
• Forum – a discussion board.
• Forum topic – topics within a specific forum
• Forum post – these are actually just the same as the Comments type

An ecommerce Drupal installation with Ubercart adds the following default Node Types:

• Product – an individual product
• Product Kit – a collection of products purchased together

Examples which do not need seperate content types include:

• Press Releases vs. News Articles -- these could be grouped into a common type called "News Items" which uses a taxonomy (see below) to differentiate.

Once you have defined your unique Content Types, list out the data fields and constraints on those fields for each type. Common field types available include:

• Date – human-readable date
• Datetime – human-readable date and time
• Datestamp – primarily used by database
• Decimal - number
• Float - number
• Integer - number
• Computed – custom string/math field written in PHP
• Text field – single-line text feld
• Multi-line Text feld – 2k limit
• Email – an email address
• File – for file attachments to nodes
• Image – uses the File type
• Audio - uses the File type
• Media – movies
• Flash - swf
• Rating – 1-5 stars
• Node reference – reference to another page
• User reference – reference to a site user

Understanding Taxonomies

Drupal relies heavily on user-created Taxonomies for any categorization or association of a piece of content beyond its Content Type fields, such as blog post categories, product categories, or music genres. Each taxonomy is a user-created vocabulary which can be flat (1-level deep) or hierarchal. Vocabularies contain terms. You have the flexibility in Drupal to decide if these terms are chosen from a pre-defined list or are submitted from user/administrator-created tags. They can be defined to be single-select or multi-select, either optional or required for each node. Each vocabulary can be assigned to one or more Node Types. Vocabularies can also be set to be displayed only to administrators (such as choosing product categories) or can be defined by users (as is the case when selecting product attributes for purchase, or adding tags to a user-contributed blog post). Taxonomies are also invaluable for creating search criteria for custom content types.

For each Content Type you've created above, define the Taxonomies that will be associated with it, including the parameters around that vocabulary and terms if pre-defined. 
 
Views & Content Templates

Once Content Types and Taxonomies are established, it's time to wireframe out all the "views" possible for each Content Type listing the node fields and associated taxonomies to be displayed or hidden. Each Content Type typically includes one or more of the following views and can have 0, 1, or many of each type of view:

• Summary page read view
• Detail page view
• Block views – sidebar widgets and callouts
• Search form view
• Search results view
• RSS Feed view

These views are largely implemented in Drupal through the appropriately named "views" third-party module (except for the detail page view), and additionaly the "Contemplate" module is a good slution to create a Content Type template for the detail page view of each Content Type. The Views and Contemplate modules provide much flexibility into content presentation, but i more is needed, this is where custom module creation comes into play.

Menus

A Drupal installation typically contains the following hierarchal menus which can be placed into pages:

• Development – for development use
• Navigation – deceiving name, as this is typically utilized in the real world for administrators/editors/authors
• Primary Links – primary nav
• Secondary Links – utility nav
• XML Sitemap – used only by Google and other search engines for indexing, not a regular Site Map (note there is no default “Site Map” menu)

Additional menus can be created at will and inserted into templates. These additional menus become “blocks” which can be displayed conditionally on a all pagesor a subset of defined pages. Each menu item can be a reference to an individual node, a view, or utlity function.

By default, there is no fancy AJAX in menus, menus display up to 9 levels deep, are collapsed/expanded by clicks, all parents and siblings are displayed but no siblings of parents, and children are displayed only 1 level deep.

Utility Content Considerations

In Drupal, built-in functional utility pages like “login”, "register", “my profile”, etc. require a little bit more time and effort to modify compared to custom content. The less the development team is required to modify the content and presentation of these pages the better!
 
Graphic Design Considerations:

Only 1 Template?

Many designers inexperienced with Drupal will be surprised to learn that by default, Drupal contains only 1 template! This 1 template has 2 views, a “front page” view for the home page and 1 “internal page” view for everything else (but again both views use only 1 template so there isn’t much differentiation in presentation).

In practice it will be much easier to maintain your Drupal site's look-and-feel if you use one very basic "master page" template, and use a tool like the "Contemplate" module to further customize the presentation based on Content Type, rather than page. That is, each Content Type should have 1 and only 1 design template to configure main content regions. The skeleton of each template should rely on the same “master template” containing the same number of regions for content areas across all node types, e.g.: “ad space in header next to logo, main column type, main column bottom, right column top, right column mid, right column bottom, footer”. Be aware that blocks used across node types will need to have a consistent presentation across templates. For the record, these "contemplates" can live in the database or filesystem depending on performance criteria and skill of your administrators.

If you require the same node type to have two or more completely different presentation layers, unfortunately the best solution is to separate them into distinct Content Types. The first temptation for most seasoned CMS developers is to build a custom Drupal module to allow template selection on a per-page basis. But again, for matters of long-term maintenance I strongly recommend avoiding this common hack and sticking to Drupal's preferred architecture and design patterns down through the presentation layer. Once you get are accustomed to this structure it will make more logical sense than most commercial CMSes.

Multiple Themes

It's easy to configure Drupal to allow users to select their own theme, but most commercial Drupal implementations will obviously limit this for branding and identity purposes.

However, there are a few very practical implementations. First of all is the admin theme. Most content administrators familiar with CMSes will take issue with the fact that Drupal uses it's default end-user theme for administration as well. There is by default no distinct look-and-feel for administration -- Drupal encourages the content administrator to log in, visit the page they want to edit, and click the Edit button to make revisions in a pseudo-inline mode. When you are authoring, editing, testing, and publishing a lot of content this can be a distraction and one of the first features clients or content administrators request is a separate admin theme. I recommend installing the "Root Candy" theme for this purpose to give admin-specific pages a different look-and-feel, and in addition install the "Admin Menu" module so that logged-in administrators still have direct access to all administrative functions when testing the end-user display of pages.

The second common implementation for multiple themes is browser-specific theming. UI developers working wit very intricate, complex designs in Drupal (which is absolutely possible!) sometimes find it easier to build different CSS/JS files and templates from scratc for specific browser targeting rather than bother with graceful degredation. Use the "SwitchTheme" module for this purpose and your IE 6 woes can all but disappear.

Additionally, microsites and geotargeting are other common reasons to implement multiple themes on a site. Create Content Types like "Microsite Page" and construct a file-based template for that Content Type to have a completely separate look-and-feel. Similarly, if your i18n or l10n requirements require you to not only change content but layout and presentation, you can create templates for these node types.