Drupal - Using Content Types

With over 22,000 downloads per week in 2011, Drupal has major support in the US and over-seas (2011 OSCMS). Huge companies like AOL, Sony, and Warner Bros trust and use Drupal to "build everything from personal blogs to enterprise applications." Together with Joomla and WordPress, it makes up the "Big 3" open-source (free) content management systems.

I have worked with all three CMSs to varying degrees. I have built custom Drupal and Joomla websites from the ground up and customized many WordPress templates. Drupal has emerged as my CMS of choice due to its powerful ability to create custom content types.

Let's discuss how to use this power responsibly by combating one of the biggest challenges both technical and non-technical Drupal users face: adding content.

Drupal Content Types and CCK

The problem associated with adding content in Drupal stems from the various "Content Types" a developer may create when building a Drupal website. Drupal 7 was built around the idea of a content construction kit (CCK). Drupal.org states that the CCK "allows you to add custom fields to custom content types using a web interface". Basically users can define their own content types to house, format, and display content; unlike WordPress and Joomla which have predefined content types (Joomla and WordPress have modules which provide CCK functionality).

By default, Drupal 7 comes with two content types: Pages and Articles (which can be edited). Pages create content that stems off of the root of the website. For example, you can create a Page titled "about us" to create a web page called "your-domain.com/about-us". Articles create snippets of information that can be displayed however you like. These content types mimic WordPress's defaults "Pages" and "Posts".

CCK in Practice

Drupal does not come with a "Gallery" content type by default. So how would you create a photo gallery? Well, you could search the Drupal website for "photo gallery" modules, which returned 271 results, or you could create your own!

As a developer (or user with appropriate permissions) simply create a new content type called "Gallery" and add the necessary fields such as a "description" text field and "image" upload field. Finally, using views, create a "view" of that content type to be displayed in a slideshow format. A user would then simply add content of content type "Gallery", give it a description and upload an image. The content they created (aka node) would be automatically formatted and displayed the way the developer set it up.

The Problem

Unfortunately, many developers do not take the time to give content types and fields understandable labels and descriptions.

For example, a user might click "Add Content" and be presented with 8 different content types:

  • page
  • post
  • article
  • story
  • event
  • news
  • banner
  • slider

Yikes! Without a description, users might be too scared to select a content type, and who can blame them?

If they make it past this point and select a content type, they will be presented with the "add content" page. The "add content" page consists of a form containing all the various content fields. Remember our "Gallery" example? It had a "description" text field and an "image" upload field. Pretty simple, but it is much more common for content types to include numerous fields.

Some of these fields may have specific uses such as filtering. For example, our "Gallery" content type might have a required select box field with 2 options: people and places. The selected option may be used as an invisible filter, displaying two different galleries (one of people and one of places) on different pages. However, if the user is unclear on how to correctly fill out these fields, or simply deterred by the daunting number of fields, they may give up.

Fixing the Problem

Luckily, Drupal gives developers the ability to label and describe both content types and fields. Avoid jargon! Chose labels users understand and provide helpful descriptions. A content type labeled "Blog Post" with a description that reads "select Blog Post to add new posts to the blog found on page: your-url-name.com/blog" is much clearer than "post" with no description.

Similarly, label and describe fields. Include what the field does, how it is displayed or why it is needed. If your content type has a lot of fields, use the Field Group module to separate the form into digestible sections - remember good usability practices.

Consider removing redundant or excessive content types. For example, maybe your blog, article and story content types produce similar pieces of content all containing a title, body and date fields. Instead of 3 separate content types (with the same 3 fields), create one content type and add a select box field with the options blog, article and story. Then, use views to filter the single content type based on the select box field's value.

Conclusion

Drupal's CCK gives Drupal a ton of power. It is up to us to turn that power over to the users. Clearly labeling and describing content types and fields, eliminating redundancies, and providing usable forms will make the Drupal user's experience much better.

Tags: