The Drupal way: manageable abstraction
Effective Web design is driven by the need to balance flexibility and simplicity. If a system is too simple, it can only be used for a single purpose - but if it is too flexible, it may be too difficult for new users to learn.
Drupal strives to reconcile these conflicting goals by providing its users with the tools they need to make their own content management solution, while still providing some prebuilt components to help them get started. Thus, it can be described both as a content management system (CMS) and a content management framework (CMF) - one system which strives to have the strengths of both, without their deficiencies.
Most CMS's are like a toy boat or toy truck - specific assumptions have been made about their use, assumptions it would be hard for you to override. Frameworks, on the other hand, provide you with raw materials only - you need to know a programming language, and have a clear design vision, to put them together.
Drupal is like a Lego kit. Skilled developers have already made the building blocks - in the form of contributed modules - that you need to create a site that suits your needs, whether that is a news site, an online store, a social network, blog, wiki, or something else altogether.
Drupal in action
To make the contrast between Drupal and other CMS's more concrete, consider the example of a news site. You want to be able to post news articles on the site, and you want the homepage to have a section featuring the five most recent ones. Next, you decide that you want to add a blog section, and put a list of links to the five most recent of blog entries on the homepage as well.
If you were using an ordinary CMS, first you would install a plugin that handled news articles and could put short blurbs on the homepage. Next, you’d install a plugin that would track the latest blog posts and put a list of those on the homepage. Each plugin would only be responsible for tracking and managing a particular kind of content, and would remain relatively isolated from the others.
But, what happens when you have that brilliant middle-of-the-night idea, and want to blend these two functions by showing a list of blog posts about the latest news items, ordered by most active contributor first? If you’re using a “toy truck” CMS, you may be out of luck, or need to hire a developer to write you a custom plugin from scratch. But through the power of the Drupal way, the way of manageable abstraction, you can whip out a kit full of parts and knock this together pretty quickly. (Hint: just use Views.) Since Drupal's modules do things in a standard way, and interface with a common underlying system, building all sorts of clever, customized features is just a matter of snapping parts together.
Of course, this flexibility comes at a certain cost. While a toy truck is instantly understandable and ready to use without much thought, a modular vehicle construction kit will by nature require you to read the instruction manual first. The building blocks are out there, but you'll need to learn how they fit together before you can take a paper prototype and turn it into a fully-featured website.
Drupal core, and the thousands of contributed modules that build on it, require an initial investment to learn, but mastering the Drupal way is immensely rewarding. Drupal's passionate community is a testament to its power to liberate site builders from the simplicity/flexibility dilemma. Once you've tried Drupal, you'll likely leave your toy truck and boat in the closet gathering dust.
How Drupal does it
Intrigued yet? Let's take a closer look at how Drupal works.
People often think of a website as a collection of static pages, with some functions (like a blog, or a news engine) thrown in to round it out. When they go to manage their site, they are thinking in terms of a tree-like hierarchy of pages that they will go in and edit.
Drupal, on the other hand, treats most content types as variations on the same concept: a node (more on this in a moment). Static pages, blog posts, and news items (some possible node types) are all stored in the same way, and the site's navigation structure is designed separately by editing menus, views (lists of content), and blocks (side content which often have links to different site sections).
It’s a lot like the separation you find in standards-compliant page coding—XHTML provides the meaningful structure of the information, while CSS arranges it for presentation. In Drupal, nodes hold the structured information pertaining to a blog post (such as title, content, author, date) or a news item (title, content, go-live date, take-down date), while the menu system, as well as taxonomy (tagging of content) and views, create the information architecture. Finally, the theme system, along with display modules like Panels, controls how all this looks to site visitors.
Since these layers are kept separate, you can provide a completely different navigation and presentation of your content to different users based on their specific needs and roles. Pages can be grouped differently, prioritized in a different order, and various functions and content can be shown or hidden as needed.
Nodes: The secret to Drupal's flexibility
We don't talk about "nodes" every day, but since they are at the heart of Drupal's design, they deserve further investigation. At its most basic, a node is a set of related information. When you create a new blog post, you are not only defining its body text, but also its title, content, author link, creation date, taxonomy (tags), etc. Some of these elements will be shown by the theme layer when the node is displayed. Others are meta-data that control when the node will show up at all - such as taxonomy or publishing status.
Since each item of content is stored as a node, and contains the same basic information, each can be handled in a standard way by both Drupal core and contributed modules. This allows site builders to choose exactly where they want content to show up, and exactly how they want it to look in each case. Most of a Drupal site builder's time is spent defining what kinds of information you want to store in your nodes, and configuring the structures (menus, taxonomy trees, views, panels) in which to display them.
As suggested before, you aren't limited to a single way of presenting your site's content. You can define as many navigation schemes, custom themes ("skins" for the site), blocks (small bits of content, such as the five most recent blog articles described earlier), and feature sets as there are distinct audiences for your site.
Comments are second-class citizens in Drupal compared to nodes, but they also illustrate the Drupal way. Comments aren’t just part of the blog system, since there isn't a separate "blog system." Comments can be enabled on any node type you choose - blog posts, news items, book pages (which provide basic wiki features) and any other you may create.
