How taxonomy affects your Drupal website
It’s easy to be seduced by a beautiful Home page design. However, it’s only one page. To convert traffic and meet your business goals, all the elements of a website must work in concert. Drupal is content-centric, meaning that if you put effort into your information architecture, you’ll reap the rewards of Drupal’s flexible, powerful content-handling features. Taxonomy is one of the keys to good website structure.
In a previous blog, we provided an overview of how Drupal’s APIs, modules, and themes work together to deliver a rendered page of content. If you’re responsible for a Drupal project, here are some concepts and terminology around taxonomy you’ll find handy when you're discussing Drupal structure with project planners and developers.
Drupal Taxonomies, Content Types, Nodes
Understanding this helps you understand what has to happen before any design work begins.
In Biology class this meant classifying animals, plants, and minerals. In Drupal, it means classifying content. Taxonomy consists of terms (think of these as categories) and vocabularies (a set of terms). Taxonomy can be used simply to tag content (news, product, editorial, basketball, baseball, hockey) or to define hierarchies of information. A hierarchy such as: product category/ product line/ product type means a shoe might be classified as: footwear/ athletic/ basketball.
To help illustrate this, let's look at an example. The Louvre Museum uses Drupal with a clean taxonomy structure where the taxonomy for an event is categorized like this: Event Category / Event Type. The categories and sub-categories might look like this:
- External Venue
- Live Performance
Your taxonomy has a direct impact on the information architecture for your website; done well, it can simplify navigation and make it easier for developers to define views of information. Every Drupal web development project should include defining taxonomy and information architecture.
Content Types and Nodes
Drupal is content-centric. All content in Drupal is stored and treated as ‘nodes’. A node is a set of information that comprises a content type: a product description page, an article, a blog entry, or a forum topic. Each content type is defined by multiple fields such as: title, text, comments, creation date, author, tags, etc.
Every instance of a content type is a node. Therefore a 1,000 page website consists of 1,000 nodes, each of which can be a product description page, an article, a blog entry, or a forum topic. The number of nodes and complexity of content types affect how an experienced developer would structure your database.
On the Louvre Museum website, an Exhibit content page includes fields (marked in green) such as: Exhibit name, dates, description, acknowledgements, location, admission, hours, exhibition image, and image title. A defined content type ensures that every such page contains all the required fields.
This means that while other CMS support basic content types such as: blog, article, forum topic, etc., Drupal can deal with any content type you care to define. Drupal offers precise control and flexibility to: customize how fields display; build custom Views of content; even build Views that use a mix of fields from different content types; and set access controls on different content types by user/role. The way Drupal defines and stores content is one of its most powerful features.
Your business and marketing requirements should drive your decisions about content types. They impact information architecture as well as database design.
Drupal Regions and Blocks
In design terms, regions are the areas on a page that define its layout, while blocks are containers for content. Blocks are assigned to display in a region and the styling of the block (using CSS) formats the content assigned to the block. In the Louvre Museum example below, you can see that
- The page layout includes regions: Left Sidebar, Main Text, and Right Sidebar
- Acknowledgment, Exhibit Description, and Practical Information are blocks containing content pulled from the node.
Your business and marketing needs contribute to design requirements, which are not just visual, but tied to the content you want to present.
As mentioned in the previous section, Drupal is content-centric and handles well-defined content very flexibly. This means a developer can use modules such as View to create different presentations of content. In the example below, instead of displaying pages of content, Drupal can present a list with just a few selected fields from all the nodes for current exhibits.
Can’t we just buy a theme and save cost on design and development?
Hopefully, after reading the previous sections, you will know that whether you buy a theme or have one built from scratch, do not skip the work of defining an information architecture based on business and marketing needs.
Yes, the Drupal community contributes tons of free and premium themes. Most work well for simple websites – generally a terrific home page then mostly static subpages and a blog. This is because the theme designer has a generic business in mind, not your business. Your designer/developer needs to research the theme to make sure it’s reliable and suits your business needs. That involves more than visual aesthetics.
The good thing about Drupal is that it’s programmer-friendly, so an experienced Drupal front-end/theme developer can wrangle a theme to make it support your needs. On the other hand, if there’s too much wrangling required, it may be more cost-effective to just go for a custom-developed theme.
About Drupal Distributions
It’s worth noting that the themes available to you may depend on your Drupal installation. The Drupal core distribution is a bit Spartan for some; that’s why there are distributions – pre-packaged downloads of Drupal with additional modules, themes, libraries, and installation profiles. Think of these as starter kits with more features. Some address specific environments such as eCommerce sites or academic organizations. Panopoly, Drupal Commons, and OpenPublish are examples of popular distributions. If you end up using a distribution with content types already defined, it could constrain your content and content types and therefore, choice of theme.
Technically, the theme and modules (code) are distinct from the content (data) but conceptually they are integrated because your business needs should drive your information architecture, which in turn, should influence your design requirements.
Planning a website requires input from multiple stakeholders as well as cross-functional expertise in Drupal development, marketing, design, and information architecture. If you lack the time or resources to define your website requirements in-house, contact us about the Smartt Website Planning Roadmap service. Our methodology uncovers the business and marketing requirements critical to your website and delivers a Creative Brief and a Project Brief that you can take to in-house or external developers.