As most of the world begins changing from traditional static websites to CMS (Content Management System)-driven websites, the way we think about these websites must change as well. This is especially important for people who are new to CMS concepts in general, or who are in transition from a static site to a CMS site.
If I could give my clients one piece of advice it would be this: Forget about "web-pages". Why? Because the concept of a "page" no longer exists when your website is a database-driven content management site.
You see, back in the day, when we were building static websites using Dreamweaver or Front Page, we built them a 'page' at a time. If we wanted an "about us" page or a "worship times" page, we fired up our page-building software and created a new file called "aboutus.htm" or "worship_times.html". It was a self contained document that included the information we wanted people to see on that particular topic. This approach put an idea in our minds that each display of content on a website was a "page", which was contained in an html file.
When we move from a static website to a CMS and database driven website, this deeply ingrained thinking is going to confuse us really quickly. In database-driven sites, a "page" no longer exists. Each time we call up a different url on our site, or click on a menu item, we're actually never leaving the "homepage". Instead of clicking on a link because we want to "go to a page", we need to start thinking about link clicking as the user saying "show me this particular information".
The reality of a database driven CMS site is: All information on your site is actually being displayed on a single page...it's just the content that's changing (hence the term "dynamic website"). So, here's a typical process when visiting a link on a CMS website:
So, on our CMS websites, there's really only one "page", no matter what you do. So, let's stop thinking "pages" and start thinking "content". The idea here is that "content" is stored in the database, and can be displayed anywhere and anyway we direct it to. We can have multiple content show up in multiple places. Content is not tied to a location on the website, but instead is simply information that we want to display in one way or another.
When we start to ask ourselves "what kind of content do I want to add to the site" instead of "what kind of page am I going to build", we begin to understand how our website works in a much clearer way.
So, in the process of using the Drupal CMS for building my client's sites, they wonder why I never let them use the "page" content type. They say "I just want to add a page to my site"...the problem is, this is, again, the old way of thinking. They're thinking about content as "pages" that are in particular places rather than about pieces of content that can be reused, listed, and searched.
Creating "pages" on CMS sites becomes troublesome really quickly. (hang in with me here, as this may be hard to explain) If you build a 'page' everytime you want to add a new piece of content, your site will spin out of control very quickly. The reason is that pages in drupal are a very generic content type. Unlike an event or a blog entry or a news item, pages have no descriptive quality about them. They could be a news item, they could be an image, they could be anything...and this makes organizing the site VERY difficult if we want things to happen automatically.
Normally, with "content" we identify what kind of content it is, then we assign certain actions to that content when it's added to the site. Maybe we assign a URL to all event content that looks like: yoursite.com/event/december/2007/event_name (allowing us to organize the site by automatically generated URLs), or maybe we want all News items to automatically show up when clicking the "news" menu item. None of these automatic actions can happen when we're creating generic "pages" on the site, because the system can't possibly know what kind of content you're creating. Again, it's always better to stay away from generic 'pages' and focus on content types.
Usually this whole issue is avoided with proper pre-planning. When starting a website with a client, I always try and find out each and every type of content that will be added to the website in the future. If I get an accurate answer, there's never a need to create 'generic pages' that don't fit a particular content-type-setup because they never have a need to create content outside of the designated setup on the system. Planning for the future is key because having proper content types at the beginning avoid a confusing and non-organized site at a later date.
What happens if it's too late? What if you've started creating content types which weren't in existence when you started your site? Maybe you want to add "special events" which weren't planned for when starting your site. The solution isn't to create them as 'pages' and dig yourself deeper into the hole of an unorganized, non-user friendly site. Instead it's to slow down, re-organize, and learn a lesson in the process. If your site was created quickly and didn't have time or budget for pre-planning, you may have to pay the price down the road to re-plan and re-organize the site. Otherwise, confusion will pile up and eventually, your site will just be a mess.
So, again, think about 'content' on CMS or database driven sites...not "pages". If CMS designers can explain this concept better, and database-driven site-owner-newbies can start to grasp this concept, ministry sites will become more organized and last much longer than their static, out of date, predecessors.