I've been asked by friends on how to make a web site. In addition, I've always wanted to write a guide on good web design practices. Being lazy, I've decided to attempt both in this single post. I've written this in a narrative manner since writing a technical guide takes too much time and effort. What follows is a personal account of my online experience in trying to become a web designer, from being a newbie to becoming somewhat better. It contains lessons along the way as well which I have tried to summarize into points in different places for those who don't want to read through the story.

Computers have always been interesting to me, and the WWW was a neat discovery when I first saw it in 1994. However, my skills with computers were quite limited back then and it was only in 1998 that I started learning web design. My first page was quite plain, had my personal profile and no real content. I had picked up my initial HTML knowledge from a course that my school conducted for free. The instructor taught us Frontpage Express and since all I had was a basic knowledge of software, I didn't search out alternatives. This site had my email openly displayed and spam filters and junk mail folders were almost non existent back then. Not surprisingly, I received so much spam that I abandoned my email account and moved to set up another. My first site was hosted with a FreeServers who offered the most generous space of 20 MB back then. Even Geocities offered lesser. The site was later redesigned using one of Freeserver's instant templates and looked highly unoriginal.

My next attempt at creating a site came two years later as part of a class assignment. The instructor required us to create a web site to display out essays and even gave us a free lesson on how to go about doing it. He showed up Netscape composer, which was way better than Frontpage. It didn't use any proprietary extensions and created better HTML but was not perfect. Certain tags it used only displayed correctly on Netscape browsers. By this time I had explored a bit more of computers and the WWW, and found 1st page 2000, an excellent IDE that supported a whole bunch of languages and tabbed windows. I still use this IDE sometimes though active development of it seems to have officially stopped. My essay site was completely hand coded. 1st page 2000 came with several free javascripts that I used. The site took 2 full days to complete and was the best in the class, though the essays were unfortunately among the worst. ;-) The second site was a turning point since it was after this that I became keen on trying to become a web site designer. Two days of continuous hand coding in any language, script or markup starts out being irritating but truly rewarding in the end when everything works as expected.

After this I briefly got down to trying to design the first serious site. This meant no under construction pages anywhere, only real content. This third site had a blue repeating image for a background. By this time I had decent experience with using Photoshop, so this page featured real good graphics, even better than my current layout. Unfortunately, this increased the loading time to roughly 78 seconds on a cable modem, which meant that I never got any visitors since no one wanted to wait that long to see a page load. I designed the site on a 800 x 600 resolution and automatically figured that it would look okay on higher resolutions as well, which I was wrong about. The few people who viewed my site on a 1024 x 768 cried out in horror and must have advised others to stay away as well. My third site was hence my biggest failure and lasted only two months before both my free host, Spaceports and I decided to pull it down.

Lesson 1

1. Never design a site from a designer's perspective, but rather from a user's perspective. You might find those background images and custom designed banners great and appreciate them, but most visitors just want to get to content fast. Hardly anyone except maybe your mom, sister or girl friend is going to stop, look and say "My, what a pretty site". And even they won't wait 78 seconds every time for it to load.

2. Always check your site at all resolutions your video card supports ;) And, the real lesson here is always give the site a test drive before putting it up online. Try different browsers, operating systems and use the various functions like polls and forums, if any. They should work in every case before you decide to publish the site online.

I used to keep copies of these older sites, but a hard disk crash killed of the data two years ago. The sites were also not archived by the Wayback Machine, for which I am thankful.

The third site made me realize the problems I faced in maintaining a set of static pages. The problem with static HTML pages is only too well known. Its hard to implement a central features like a search function, user database with login, forum, rotating ad banner, blogs, polls and so on. My third site used externally hosted scripts and services to solve part of the problem. Services like Bravenet and even Blogger allowed me to host the site elsewhere, but run a piece of dynamic content on the site. External search also existed, with Google and Yahoo offering site specific search. However, this caused the page loading time to increase since every time the site was loaded, a whole bunch of requests were sent through the javascript code on various portions of the page to various external services. The blog would have to be fetched from Blogger, the poll and visitors counter from Bravenet, the shout box from GS2 and so on. In addition, it also increased the risk of a page not appearing as intended. If Blogger went down, the page would load with no blog. If Bravenet went down, there would be no banner. Though these services were mostly reliable, there have been cases of their servers crashing as well.

What I needed was a single system that could provide everything, both static non-changing content like normal HTML pages and dynamic pages with a system to push older posts to the bottom and the newer ones to the top. I also needed inbuilt rating system for each article, maybe a poll for visitors, a guest book and forum, inbuilt search capability and so on. After looking around for a week, I came across several solutions. The first thing I learnt was that dynamic pages use a scripting language like Perl, ASP and so on to fetch data from a backend like mySQL or Oracle. So, I decided to start learning a scripting language, following which I planned to write my own dynamic system. I found a lot of PHP scripts on the internet, mainly at Hot Scripts, that provided the various functions I wanted, like guest books, polls and contact forms. My plan was then to learn PHP and mySQL, build my own dynamic pages and install these various scripts to get a custom all in one solution. The idea sounded great, so I started off enthusiastically. This was May 2001. Back then, PHP looked alien to me, I was a real bad coder and couldn't grasp any programming concepts. Though all open source projects were well documented, it was too technical to make sense of immediately. I estimated that at that rate, it would take me maybe a year to learn PHP and mySQL, followed by another year of regular coding to familiarize myself with the language. It was only after this that I could write my own custom solution and proudly display my web site to the world.

Then, to actually make my web site useful, I would need content. Something useful, not just mindless ramblings. Some folks are naturally talented and even their mindless ramblings sound like poetry. Mine mostly sound like garbage. Content was more important than design and functionality and I knew that from common sense as well as reading several web design guides.

Seeing the 2 year plan was not too encouraging. I have never been very good at staying focused and to regularly spend at least 15 hours a week on PHP and mySQL was something I knew I would never do. Going back to the web, I searched out other options. Still the best thing I found was a blogging tool like Blogger or Crimson Blog. While most of my friends were happy with blogging, I was unhappy with its limited tweaking option. I've always liked tweaking everything, whether software or hardware. I designed over a dozen Blogger templates, but always felt that they were all alike. There was no way to implement all those features like logins, static pages, forums and polls on a blog. I found slash, the system used to run Slashdot, but it made no sense. It also required learning Perl. When I tried reading the documentation, it looked harder than PHP.

Then, I stumbled upon PHP-Nuke, my first experience with a CMS. The name was certainly sellable, and the first thing that came to my mind was C&C Red Alert. Blame that one on gaming addiction. PHP-Nuke had received good reviews and I found several local organizations all over the world : PHP-Nuke Australia, Israel, Italy and so on.

Lesson 2

One thing to always bear in mind when looking for a software solution is an active online community, especially in free software where often no paid official support is often available.

PHP-Nuke described itself well, as a story telling system, blog, web site or whatever you wanted it to be. While theoratically anyone could hack the PHP code and make the site whatever they wanted, PHP-Nuke was designed more for a single purpose: Community Interaction. I did examples of sites using PHP-Nuke to accomplish several tasks, from blogging to online classifieds.

I also saw other CMS, including Geeklog, e107, Drupal and Mambo. I tried Geeklog and e107, but they were really just the same as PHP-Nuke, with the same three column layout like a newspaper. The three column layout worked great for community sites like the ones PHP-Nuke was aimed at, but a personal site usually doesn't have enough material to fill three columns. It needs simplicity. Drupal promised a lot but delivered little. Drupal was supposed to be malleable like clay, being formed into any shape the person wanted. The community looked strong but upon installation, I was greeted with a spare layout. There was a option called administer and a blue round face for a logo. It was simple. Too simple. I couldn't figure out how the hell to customize it. I tried reading the official Drupal Handbook, but being lazy as usual I stopped after a couple of pages.

One of the reasons I disliked PHP-Nuke was the limited customization it offered. Every PHP-Nuke site used the same three column layout, no matter how different the colors and themes were. In other words, my site was going to be YAPNS - Yet Another PHP-Nuke Site. Mambo looked nice, but like Drupal, it didn't give a out of the box solution and instead gave the tools to build the solution. I realized that Drupal and Mambo would take time to master. I over estimated the difficulty, thinking that learning Drupal and Mambo would be like the attempt I made to learn PHP itself. Making a decision was starting to get frustrating, so I chose PHP-Nuke, just to get a start somewhere. It went well and in 2003 I designed two sites, both on PHP-Nuke. Both those sites are gone now, but the experience gained was not. I explored PHP-Nuke thoroughly and saw it pros and cons. Both my sites were run on a free host, ineedhosting, who don't offer free hosting anymore. But due to receiving low traffic, the sites got shut down. I tried earnestly to drive traffic. I joined a web ring, told all my friends about the site and put it in my email signature. It received about 700 page views the first month and only 80 in the second. The web site boasted several features like polls and forums, but little content. The only real information was the article on computers which I had tried writing for a school magazine. It was then that I realized :

Lesson 3

1. No amount of functionality can match content. Unless the site is a interactive application like search engine, games or social bookmarking, people will only come to it for content. I had learnt the importance of content in theory, now I saw first hand that content was really important.

2. When there's no more content to read, visitors leave. So, you have to keep providing content, not just a set of good articles. What is needed is a way to keep writing on a topic to supply the web site with content.

3. Additional features like polls and forums are only good if there is a need for them and you have people using them.

I had added polls, forums and guest books on all my sites, mainly being driven by influence. Every site seemed to have these features and it seemed to be right thing to so. PHP-Nuke even came with a poll and forum. Every personal site had one of those site meter icons and a whole bunch of tiny icons on the side of all sorts: Blog associations, GeoURL, imood, the lot. Few people seemed to thing whether these icons would add any functionality or improve the user experience.

I decided to step back from the whole idea of making a web site I spend the next year developing content. I looked at web design guides and other sites. I saw neat features and mistakes made by other designers. I must have read over a thousand guides. Most of them repeated the same ideas, mostly dos and don'ts. Not all the guides were good, some of them were written by total amateurs worse than me while others were advice from professionals. I joined several web design forums and newsgroups, mostly reading and observing what others said rather than posting. I saw people making the same mistakes over and over. I also saw people come up with new ideas.

To develop content, I thought of various topics: politics, environment, academics, religion, music. I tried to see what topics popular sites focused on and then writing about that. I wasn't a naturally good writer and needed several edits to make my content sound sensible. I had a tendency to deviate a lot from an idea when writing. This occasionally led to new ideas for topics but also interrupted my flow of thoughts on an existing subject. I did find myself helping people a lot on computers, from fixing hardware to setting up various OS. Articles on technology also interested me instantly. I realized that I had to focus my writing on technology. Even if I deviated, it would be to another related sub genre of technology which I could use to develop another article. At this point, I understood the next lesson :

Lesson 4

1. Don't write about what is popular, but what you know best. Every topic has an audience on the WWW. Write honestly with interest and people will pay attention to what you have to say, crazy as it might initially sound.

By the end of 2004, I had written 7 articles. Not much, but at least better than my initial effort. I distributed my articles to friends, family and even people on the internet asking them to read and comment on I could improve. Everyone said they would look at it, but no one gave feedback. I spent my free time reading the articles myself over and seeing if I could improve it. I tried to think from the perspective of a site visitor and how they would judge my content. Self criticism is often the hardest thing to do. Since we always take each step after deciding that its the best move to make, to be self critical requires a person look at those decisions along the way and label it a bad decision based on the present outcomes. Its often like calling yourself an idiot for having done that step.

Lesson 5

1. Never be discouraged by a lack of response to help. People are often busy and if they can't help you improve, look for ways to improve yourself.

2. You are often your own best critic and judge. While its hard to notice your own mistakes, your own drive to better yourself is also the strongest reason to study your own work.

In 2005, I decided to jump back on the web design track, this time with Mambo. I was more experienced now and decided to keep strict rules on choosing a CMS. I didn't want to adjust my plans to suit the CMS, I wanted a CMS that could carry out the plan I wanted. Mambo seemed to fit the bill. The CMS had won several awards and had a strong community with plenty of additional add-ons that Mambo called components. Mambo could provide me with all the functionality I needed while having a customizable interface. But before jumping onto Mambo, I gave Drupal a try once again. They had just a new version and promised several new features. After the install, I came face to face with the blue face icon again. Not only that, the entire setup and layout was exactly the same as it was two years earlier when I had tried it! It seemed like the CMS had never developed at all and only the version number had been incrementing. Of course, my judgment there was wrong. The change log showed several features that had been added over the last two years, but somehow I didn't quite see the change.

I went ahead with Mambo and designed my test site. Mambo came with extensive documentation, over a hundred and twenty pages. And it was available as a pdf file with a contents menu for easy offline reading. I spent three months reading and learning Mambo, from the user guide as well as reading the forums. At the end of the three months, there was a major change in the Mambo project. Mambo had always been open source and relied on Miro, an Australian company which marketed and financed the development wherever necessary. Mambo had however been extensively developed by volunteer efforts in the community. A difference of opinion between the lead developers and Miro caused the Mambo project to break up. Mambo was still held and developed by Miro, but the developers left and started their own project called Joomla. Since it was based on the Mambo code base, I expected Joomla to have the same stability as Mambo. I was wrong and found out shortly. I had agreed to create a web site for my local chapter. It was to be a large site, with forums and plenty of community interaction. Joomla seemed perfect for the project. I designed the entire system, with menus and sub menus in Joomla and even demonstrated it on my laptop. But there were problems. To begin with Joomla had bugs, mostly minor but still troublesome. It did not have Mambo or even PHP-Nuke's stability, though it had far less security problems than the latter. I was unable to move my Joomla installation to another site flawlessly. Despite having all the right settings, some pages failed to load and occasionally users were unable to login. Joomla and Mambo had the most difficult to comprehend directory structure. If I wished to edit some aspect of my web site, like the default text being displayed to administrators, for instance, I would need to edit a bunch of PHP files. It was difficult to understand which PHP file held which data. Mambots, Components and Modules were another confusing statement. Joomla followed their own convention of labeling menus displayed on the side as modules. Almost every others CMS in the industry called them blocks or menus. Components were sets of PHP programs that could be installed in your site for added functionality. And mambots was something that worked together with components. There were so many sub directories that it got confusing beyond a point. Joomla was also slow to load. I anticipated this, given their graphics rich menus and administration back end. My instructor tried logging into it from a 28.8 kbps modem and had to wait over two minutes for the administration screen to load. I tried enabling Gzip compression and caching, which improved performance to some extent.

By July, I decided to drop Joomla. Project development was moving at a slow pace and customizing to develop a new theme took days, even using the special Mambo template developer plugin for Dreamweaver. Once again, I was back on the WWW, looking for a CMS. I found a few: Typo3, Plone and Drupal, once again. Typo3 looked great, so I started downloading the video tutorials and learning. They seem to be the only CMS with such extensive documentation. I went along learning Typo3 quite well, but to actually make it do what you want, you have to have some knowledge of PHP. I decided to keep learning Typo3 on one hand, but it couldn't be used for my immediate production purpose. In fact, the Typo3 officially says that a person will have to invest a month or more for learning Typo3. Plone was a great product and just like Typo3, it had been used to develop major commercial web sites. The problem was it used Python and the Zope application server. It was also quite resource intensive, needing at least 256 MB of RAM and a decent processor. I was looking for something that would run on PHP + mySQL since that what most free hosts provided. I also needed something that would not eat up server resources, even under a heavy load. Both Typo3 and Plone were simply not for creating personal web sites., but rather tools for enterprise projects.

So, it was down to the last option, which was Drupal once again. This time though, I was not put off by the plain screen. Since so many people were recommending Drupal, it had to have something good. I wanted to try learning this CMS completely before deciding whether to dump it. I had spent the last few years working on several CMS, so I just played around with the settings. I read the handbook occasionally, mainly for a reference rather than learning like a textbook. What amazed me about drupal was that it was amazingly simple at the core, but very scalable. Drupal was a 'one size fits all' solution for any web site, small or big. It had been used anything ranging from blogs like this to sites like Spread Firefox and Participate. Customizing Drupal was also simple. The directory structure was extremely straightforward. Modules did what they were supposed to do, provided functionality. Installing and uninstalling was cake, just uncheck the box and delete the .module file and its gone. If I need to customize some part of the site, all I had to do was identify whether it was being controlled by a module or the page template. Then, simply open that file and edit the PHP code as needed. Customizing Drupal was almost like editing HTML itself. With a decent IDE that gave syntax highlighting, Drupal could really be made into whatever the designer wanted. Drupal was also amazingly low on resources and loaded fast even on a modem speed connection. In addition, a throttle module helped to automatically control how much resources the web site used. If the user load was intense, some unnecessary modules would be automatically switched off to reduce resource consumption. Drupal also supported extensive hierarchy of classification. This means that I could classify the sites content into categories, sub categories, sub sub categories and so on till infinity. Cross relationships were also possible, meaning a content item could be part of two or more categories at once, even if the categories were on different levels. Drupal's taxonomy, as this classification system was called was among its greatest strength.

The story ends here. I went ahead and used Drupal to develop two sites in addition to this site. Its only been 5 months since I used Drupal, so maybe its too early to tell whether I have found the solution. There may be certain very complex projects that Drupal would not be suited for, like a university web site or a designing a portal like MSN and Yahoo. Complex projects are often given to Typo3 or Plone or custom coded. I can't say whether I'll keep using Drupal, but given that they have an active community and dedicated people working on the project, its likely I'll probably encourage others to try Drupal as well.