Seeing as I'm stuck in a hotel room with nothing else I want to do, I thought I'd talk a little bit about how I made this site. Why? A few reasons. First, I know that at least one of my readers is mildly interested in Drupal (the software that powers this site). Secondly, I've put a lot of work into this site, and I'm proud of the result and want to brag. Lastly, I have this vague hope that some of my academic colleagues will wander by the site and be inspired to make one like it for themselves. So... How I Made This Site (short form): I stopped hand-coding HTML, thank god.
For those of you who don't know what that means, HTML is the language that computers use to describe web-pages to each other. If you've never seen it before, you can take a peek at it by finding your browser's 'View Source' or 'Page Source' command in its menus somewhere. Go ahead-- take a look. Ugly, ain't it? Well, as I said, it's really a language for computers to use when they talk to each other. But back in 1994, when I made my first website, you had to write the HTML yourself. Your webserver would send the HTML to clients for you, yes, but you had to give it the HTML to send on your behalf.
By modern standards, hand-writing the HTML for your website is like silk- screening your own business cards. It looks ugly and amateurish, and should really be left to machines. (It also exposes one's complete lack of talent in the area of graphic design.) But there's another problem with this approach, one which also applies to website design software like iWeb: the resulting websites are a pain to maintain and update.
To see why this is, it helps to pick apart the different parts of a good website:
- First, there's the content: your blog posts, your pictures, etc.
- Then, there's the structure: whether you are going to allow your readers to browse your blog-posts by date, by tag, or both; whether you are going to sort your pictures into albums; whether you present your pictures by thumbnails or slideshows, etc.
- Lastly, there's the style: what fonts you use, what colors you use, the graphic elements like banner images, etc.
When you hand-code HTML, or use a tool like iWeb to build your site, all three of these things get combined to make the final site and that final site (as a monolithic final product) is given to your webserver to serve on your behalf. And that seems like a logical way to do things, until you start to think about what you will need to do to update it.
Consider: how do you add a blog post? Well, you need to write it. And then you need to style it. Lastly, you need to manually make the rest of your site link to it in the right way. Or what do you do when you want to switch from sorting blog-posts by date to sorting by tag? You need to scrap your old HTML and manually write all the pages-- one for each tag-- where each new page links to the right blog entries. And what if you want to change from one style to another? You need to go in to each page and change the styling on each and every one of them. (Well, okay. A tool like iWeb makes this last part easier. But you get my point.)
This is why modern website construction uses content management systems (CMSs) like Drupal, Joomla, Wordpress, and MediaWiki. These tools will separate all of these layers. It will store your content (with meta-information) in a database. Your website-structure defines the database queries necessary to get the relevant content. You create presentation-formats (thumbnail-grids vs. slideshows) by providing templates, and the system uses these templates to transform the content into HTML. And lastly, a style-sheet tells the client what colors/fonts you suggest for maximum reading pleasure.
This arrangement makes it very, very easy to change and update your site. Want to add a blog-entry or a photograph? Put it in the database, and it will get automagically captured by the next relevant database query. Want an entirely new way to slice-and-dice your content (like sorting your blog entries by tag rather than date)? Simply create a new view (database query) and it is done. Want to change the way your content is presented? Then you need only change the templates or the style sheet (usually both). Because you've broken things out into separate and independent layers, both routine changes (adding a blog entry) and large, sweeping changes (a complete re-org) become easy.
Oh, and you can use any of the hundreds of professional-quality themes (styles) that come with the tool. In other words, your site will look good.
Another nice aspect of a system like Drupal is that I can maintain and edit my website through the website itself. Previously, I had to copy my website to an off-line location, make my changes, test my changes, and then copy everything back to the 'live' site. Now, I add a new blog entry to the site by typing the entry into a special page... on my site! That is, I can administer my site entirely through a special web interface to my site. This makes website maintenance amazingly convenient-- much in the same way that webmail is more convenient than having to do all your mail from a client on your desktop.
So, what's the downside? Well, these tools have to be installed, of course, and then you have to learn how to use them. From this perspective, I may have chosen my tool poorly. Had I known that this site was primarily going to be a blog, I would probably have chosen a CMS designed for blogging, like Wordpress. Had I done so, I would probably have finished crafting this blog a lot earlier than was actually the case. But I didn't actually know what I wanted, and so chose a tool that could support anything: Drupal. Drupal really does seem like it can be used to make any kind of website, and contains some very flexible tools to store any kind of content and to display it in any configuration I want. It's also kind of neat to know that I can add forums to my site, should I see the need, or to add webforms or polls or calendars or what-have-you. But because Drupal can do anything, it doesn't really come set up to do anything in particular. You really have to decide what you want your website to be and then wrestle Drupal into that form. It took a surprising amount of work, for example, to make this site into single-user blog with some static pages on the side. And to fully take advantage of Drupal's power, it would help to know the programming language PHP (which I don't).
But now that I've got the site set up, and know roughly how to use Drupal, I see no reason to switch to a less powerful tool for this site. You never know what you're going to want to do with a website in the future.