Science fiction, fantasy, & horror - web design, graphic design, interactive media development by greententacles
2024-11-24 GMT
Science fiction, fantasy, & horror - web design, graphic design, interactive media development by greententacles
2024-11-24 GMT
My baby had become a monster. After years of publication, my web site Nuketown had grown into a time sink, drawing in ever-larger chunks of free time far more hungrily than any black hole. The webzine that had once took me a few days to publish now required almost constant attention. Something had to be done. The monster had to be slain.
My weapon of choice? A database. Specifically, a MySQL database that stores the site's content, PHP, a server side scripting language used to access that content, and good old trusty HTML, which serves in its time-tested roll as the mark-up language telling the Web browser how to display everything.
Like most of the guts comprising the Web it sounds like a jumbled mess of acronyms - throw in a flux capacitor and you're ready to jump back to 1955. But these words are more than just jargon spewed from the mouths of geeks: they are the underpinnings of the next great Net revolution.
I'm not alone in seeking solutions to the nine circles of content Hell that surrounded Nuketown. Web designers, programmers and engineers have been searching for ways to simplify and automate Web publishing for years, and they've created plenty of tools to aid them.
Every major Web site you might visit today is built using a database. It doesn't matter if its Amazon.com, StarWars.com, StarTrek.com, Google, or Yahoo - they all consume and serve up a tremendous amount of information, and its doubtful they'd be able to update their sites manually, even if they had that legendary legion of infinite monkeys so favored by Shakespeare fans. Monkeys aside, the current buzzword for these tools is 'Content Management Systems' or CMS but no matter what the techno-slang is, it all comes down to easy ways to update and maintain your Web site.
Numerous databases exist, from Microsoft's relatively low-end, but still Web accessible Access database; to mid-range solutions like Macromedia's ColdFusion, to the ultra high-end monsters like Oracle.
HTML is great at providing the building blocks of the net but its stone cold stupid when it comes to accessing a database. For that, some sort of active component is needed - something that can take a request from a visitor, query a database, and then return the results. And not surprisingly, there are plenty of programs that can do this including Microsoft's Active Server Pages, the Open Source Movement's perennial favorite Perl, and newer mutations like PHP.
I choose MySQL because it's very fast at serving up text content like that on Nuketown and it's free. Its open source nature meant that I could easily experiment with a database-driven site without having to lay out thousands of dollars, something that can't be said of the Microsoft option. The same goes for PHP, which like MySQL, is an open source project that's freely distributed. An added bonus was the fact that both would run on my Apple iBook, which runs the Unix-based Mac OS X operating system and comes installed with Apache Web Server and PHP.
So here I am. After long weeks of development and months of tinkering, the beast is in its death throws, blood pulsing from its gashing wound. The stories and articles can be added to the site in minutes, automatically appearing on the home page when scheduled, and moving to the archives at the appointed time. The bi-weekly newsletter can be assembled with a few clicks, turning a 30-minute job into a 30 second one. The almost-final result - a few more features need to be added - has been nothing less than revolutionary.
Here are the big reasons why you must convert to a database-driven site:
Most sites don't grow so much as spawn, and after several years of production even the best maintained site has its share of bit rot as links to external web sites break and redesigns orphan internal links. Moving the content into a database forces webmasters to look at the content that they have, assess what's still valid and update anything that's atrophying.
It also allows for the elimination of material that's unintentionally been duplicated in other sections of the site - such as always-troublesome company directories. Because databases allow you to store information in one place, and use it anywhere you want, you can have one central list of employees for your company. Then you can pull from that list whenever you need to display that information (for example, putting advertising folks on the advertising page, or editorial folks on an editorial page, or putting everyone on a directory page). The best bit is that because it's a centralized list, if you update the master list, the information will automatically be right everywhere else on the site. Now that's progress!
With traditional web pages, the content of the site was forever bound to the layout of the site. If you wanted to redesign your site, you had to redesign every single page on your web site - a daunting task if it has been around for a while and managed to accumulate a few hundred files. And if you wanted to use the content on your web site for something else - say a printable brochure or a PDA edition for hand-held computers, you would have to manually cut-and-paste the content you wanted to use, and then reformat it for its new purpose.
With a database, the content of the site is separated from the look of the site - so if you want to publish the last five news releases you added to the site in an e-mail newsletter, you can simply press a button, and the information you need is pulled from the database, and formatted for your newsletter (something I now do on a regular basis with Nuketown).
With the content in a database, suddenly building the physical web page gets a lot easier. Rather than have to build a web page for every single story, feature and article on your Web site, you just have to build one template. And when it comes time to make a change to that template - say a contact e-mail address, or a link to a FAQ - you only need to change one page, not hundreds of them.
It also streamlines your design - in theory you'll only need three kinds of pages: your home page, a section template, and a story template. In practice, you may need a few pages to accommodate features that don't quite fit the system, but its far easier to maintain site comprised of a dozen or so pages, than it is to maintain one with thousands of them.
With the old way of updating web sites, when you wanted a feature to appear on your web site, you had to put it there. That meant manually adding a link, and then uploading the appropriate files. By assigning a publication date for every story in your database, you can have the programs on your home page automatically post stories at the appropriate time - even if that time is midnight on New Year's Eve, while you're off watching the ball drop in New York City.
Just as importantly, it allows you to do all your work up front, and then sit back and let the database handle the updates. For a small business owner, who might only have a few hours here and there to work on a site (and most of those not during daylight hours) this is a god-send.
If you're crafting your site by hand using simple HTML, you're providing all the brains for your site: without you, it's as dumb as a rock; an expensive and perhaps nice-looking rock, but still a rock.
A database changes that. By entering in keywords for each story - heck, for each resource on your site, be it a lowly link or a full-blown feature - you start adding a few neurons of knowledge to your database - knowledge it can start using immediately through some simple scripting.
Take, for example, the page for a new product. You may have written several press releases announcing it, posted a frequently asked questions page supporting it, and created a discussion forum on your web site to talk about it. Normally, you would have to manually enter links to each of those resources. But with a database, you can write a simple search script and have the database automatically pull the resources associated with its subject matter, and build links to those resources into your page.
Amazon.com offers a perfect example of this: visit any product page on their web site and you'll find product information, reviews, customer comments, links to related products that other folks have bought, links to similar product categories and much more. And all of it's generated by a database.
When it comes right down to it, there is one overriding reason to covert to a database: to save time. Every single reason listed on this page will save you time, rescuing you from the monotony of day to day maintenance and allowing you to work on what you really want to work on, be that working on products or simply developing newer and cooler uses for your web site.
When this sort of content management system is done right: a miraculous thing happens: you're suddenly freed from your computer. You can update the site from anywhere you can find a Web connection, be it your laptop, your library's public computer, a browse-by-the-hour Internet connection at a convention, or your mother-in-law's house.
Nor do you no longer need to wait for your over-worked webmaster to find the time to handle your update - if he's swamped with myriad other tasks (or simply out sick for the week) you can take over and keep the site current with a few keystrokes and mouse clicks (and not a single line of MySQL code or PHP programming).
And it's not just you. Anyone in your company or organization - with the appropriate permission - can update the site from any place in the world that can access the net.
There's no doubt about it - database-driven sites can be investment expensive. Whether it's in terms of time spent learning to build the new site or cash spent paying someone else to do it, you'll be spending a pretty penny to get the database up and to get your content management system humming the way you want it. Done wrong, a database-driven site can be a nightmare and make you wonder why you ever ventured out of the HTML shallows.
So why spend the time and dedicate the resources to such a project? Because it's an investment, one that will offer you returns in terms of time and money. Consider a database-driven site's most immediate savings: the elimination of Web production drudgery. Upon implementing a database on Nuketown, I was immediately able to shave at least two hours a week off my regular Web chores. It was a tangible, noticeable savings, one that instantly allowed me to dedicate more time to the fun aspects of the site, namely writing new reviews and commentary and working on even more enhancements to the database.
The database's ability to schedule stories allowed me to complete editions ahead of time, set their publication date, and then forget about them. This proved to be especially helpful in December when I was on vacation for two weeks visiting family and generally deprived a net connection. I was gone, but Nuketown just kept on ticking.
This presents possibilities for the less-tech savvy as well. In most cases, when a business commissions a site - and doesn't have their own webmaster in-house - they need to rely on the firm they hired to make the changes, or spend the time to learn HTML or some Web-editing program to edit the site themselves. The bill for making changes to a site can add up, and the need to rely on some outside vendor to edit a site can limit how fast updates can be made. With database-driven content management system, those changes can be made by anyone who can turn on a computer and launch a Web browser.
As Nuketown's database continues to mature, new opportunities are presenting themselves that would have been impossible without this investment:
Each idea provides me with a new way of leveraging work I've already done, adds value to a site I've worked hard to create, and frees me to expand my business in new and hopefully profitable ways.