Suppose you are building a site with content -- primarily a place where people come and read articles / columns, and not primarily a database-backed ecommerce site. How might one think about this?
My first comment would be to closely study two good role models: the New York Times and the Economist. Learning deeply from both of them is a very good idea. In particular, The Economist has the print edition, web related additions such as audio interviews, a front page that has the latest content, cross-linking to old stories and background articles etc.
Do use CSS for a three-column layout, as shown here here and here.
Layout should be liquid, and should adapt to the screen-size of the user.
Do take care to separate the look of the website from the content. That way, you can always update the look and feel of the site without a complete overhaul of the website. This is achieved by having HTML content and CSS presentation. Lots of good sites have CSS which can be read - do study it. CSS has grown far beyond what you think: e.g. see this website.
You can have all kinds of `access channels', such as the front page of the day, search facilities, and so on. But in the end, the user ends up reading the content, an article. Every article must have a fixed absolute URL, that doesn't change over time. An example of this is (say) Financial Express, where every piece of content has a unique URL such as http://www.financialexpress.com/fe_full_story.php?content_id=110692 and this unique URL stays with the story for life.
This is desirable because people can email URLs to each other; people can link to this URL; the web search engines will find this content; users will come back in the future. The URL should be short, otherwise stupid email programs (e.g. Apple Mail) tend to break it up over multiple lines.
The ideal path to follow for URLs is OpenURL, where each article would get unique `library card' forever. E.g. see http://www.openly.com/1cate/basics.html
When the user does get to the content (the fixed absolute URL discussed above), the entire article should be on one page. Don't torment the user by making him press "Next" to get to the next few paras, as Economic Times does. Very often, people with transient Internet connectivity have brought up a page in a new tab, and are reading it later when they do not have connectivity. You lose such readers if you break an article over multiple pages.
Deep in the future, it's extremely confusing when someone lands up at an page of ancient news. The top of every page should clearly show the datetime of the story.
As far as possible, the name of the author should be clickable, and it should lead to a page with everything written by him, in reverse chronological order.
Most inexperienced web development teams - particularly those that use GUI tools for writing HTML and do not actually know HTML themselves - produce awful HTML. Every page of the website should pass HTML and CSS validation tests such as http://validator.w3.org/ or those offered by the free program `weblint'.
Equally important, see these web development guidelines --
The Web Standards Project is a grassroots coalition fighting for standards that ensure simple, affordable access to web technologies for all. Their stuff is great.
Test with three browsers -- Firefox, Safari and MSIE -- and three machines -- Windows, Linux and Apple. All feasible combinations should be used in testing (Firefox on all three, Safari on Apple, KHTML on Linux, MSIE on Windows and Apple). However, do not write dirt to accomodate any one browser - it is more important to hug standards than to hug specific browsers. Over the years, browsers will evolve, but if you hug standards, then you will come out okay.
Use images only when absolutely necessary. Section headings should be text, because you want the font size to be resizable. Don't use images to display text. Follow usability advice.
Links that have been visited should be colored differently. There should be visual feedback of what the reader hasn't read. Links should not open in new windows.
Make life easy for the search engines, and for some kinds of users. At all times, expose well-linked pages which link to all content. It helps to think like a crawler -- plan that you are compatible with a not-so-subtle crawler program -- and make your website convenient for simple crawlers.
Do publish RSS feeds. Exhibit a tree structure of RSS feeds, whereby the user can select what level of detail (or undetail) he wants. You will need to choose a tree-structured classification system of subjects in order to correspondingly exhibit a tree-structure of RSS feeds by subject.
While you do RSS feeds, there may be a good case for utilising the services of feedburner.com. The framework is that you produce an RSS feed, but don't exhibit your feed to the world. You setup a feedburner.com feed (which, in turn, reads your feed) and then show your users the feed from feedburner.com. You get many benefits from putting feedburner.com as a middleman in your RSS setup, e.g. good information statements.
Plug into google webmaster and learn more about how google sees you.
Setup with google and run a google search for your website. Setup with google analytics, and carry their four-line fragment on every web page. There is now a host of measurement facilities on the web: study them.
Learn from the blogs. Setup a mechanism through which we acknowledge (and link to) someone who links to us. That is, each page should carry a table (at the bottom) of people who link to it. That will help readers jump to related materials and commentaries, and stoke the enthusiasm of people who might like to link to you.
Advertising must be non-intrusive, clearly marked as distinct from content and relevant. Google ads rocks.
The ads should be confined to only the top and the sides. Ideally, you should refuse to accept animated or flash advertisements, but if you have to, you can run flash/animated ads on the top. Do not tolerate these anywhere else on the page.
Analyse the logfiles, and produce statistics about usage in each month, organised by page, subject and author. You'll need a subject classification index for each story, the same one which will be used for giving out a subject-classified set of RSS feeds.
Ajay Shah, 18 December 2005.