Building static web sites
While I’m counting my weeks here in India, I am trying to build a website, to represent a highly functional and useful network, with a global outreach within an organization.
It’s a concept. (I am not working on this to get paid or be recognized. Frankly, I never do. In fact, I haven’t even been asked to.) The sole purpose of this excercise is demonstration and possible implementation if my proposal finds a footing. That in itself would be a reward for my work. (And no, there won’t be any unveiling here, although I’ve completed a lot of work already.)
The web is still an unfamiliar territory in the corporate world. They typically employ consultants, agencies and experts to maintain company’s content. Without really knowing that they could easily do it themselves in better ways than they imagine possible.
Zeldman didn’t write the book for the money but, probably, out of frustration and to bring clarity of thought, not only to practitioners, but also to clients, to expect things in certain ways. And those ways would be both positive and beneficial, to not only their organization, to their users, but also to the overall health of the web.
So, my self-imposed aim for this pilot has been simply: to bring functionality, usefulness, lower costs, ease of use in updating information and maintenance. All this while hammering out the learning curve, for newbie content contributors, to a flat line.
The present scenario is that the network is vast, spread across continents, nations and cities. Its stations are highly fragmented, discontinuous, heterogeneous, lack harmony and limping with old-school methods of updating content i.e., raw markup.
I haven’t really spent my time thinking about why there hasn’t been any improvement from what was considered a pioneering work when it was started way back in the 90s. I suspect it could have been going from an excellent concept to a mediocre implementation, lack of the right kind of professional help and some such in seeing it through.
If content contribution requires a certain amount of editorial expertise, knowledge of html markup, then, the team is already thinned out. The point is that building a website is easy, subtle education without overwhelming the interested is the difficult part.
I got a hang of this when I was working on Gateway, a good lesson learnt in building editorial groups. Sometimes what comes as a second nature to you could be so difficult to put it across to someone very new to it all.
So, I spent more time on how best to brace for those out-of-the-blue questions, and compiling them in a FAQ for editors and newbies. The FAQ needs to be devoid of techno mumbo jumbo, unwanted jargon or abbreviations, explaining topics or matter purely from their functional aspects and with visual demo (Someday, I’ll publish it here for feedback.)
Because I often involve myself in building sites with a lot of static content, due to the nature of my work, this post will discuss about building sites with static content.
Following are the key aspects I decide upon while building a static site.
Findability — Users have low tolerance for static content sites. They don’t care about its presentation, unless it hurts them bad, in accessing the information they seek.
So, obviously the site needs to be lean, fast and out of the way while having all the most accessed links at one-click’s reach. (This is what I tried to achieve in Gateway, by populating sidebar with most used links.)
On reference sites and static sites, it’s always about the least number of click-hops to the topic of interest. That’s because people are looking for specific information, and they are really not here to read the news.
What I found in Gateway was that users were using much less of the search bar. Most didn’t even try in the first few months. This was both surprising and disappointing to an extent, because Gateway had an excellent ajax search built-in. And then, slowly but surely, search became the springboard of the portal.
My conclusion about this behaviour has been that users were so disappointed and fed up of using broken search bars in so many sites that they had lost faith in one (with exception to search engines like Google, Yahoo!, et al).
When sites are big, when there are a large number of categories or tags, when posts and articles run in hundreds and thousands, searching makes sense.
Categorization — For static content, heirarchial categorization help lower seek times. As a user myself, I have often found categorization to be most useful.
Categories, unlike tags have an order. So, I know where to look. Sub-categories work like a filter on the main category. This is not possible in tags because they are at just one level. Categories can span many levels down.
Simplicity in maintaining and updating information — While Findability, categorization and load times are meant for the users, I am yet to talk about editors.
When you have a read-write web, it is imperative that it needs to be easy, simple and useful to both the audience and content generators. Trouble at either end would definitely bring curtains down on the project’s longevity.
Having a simple method to add content, image upload, categorize, edit older posts, update content and preview goes a long way in helping contributors concentrate and churn out better articles than struggling to write their articles with need to remember and use inane markup for presentation.
Presentation in an editor should come like a second nature to a writer. Only then, a writer can continue to write his thoughts without interrupting his thought-train. Therefore, right choice of the backend system is important in keeping it simple and stupid.
Once the learning curve is out the window, enthusiasm sets in and we begin to see people pouring their experiences and interests out on the familiar tarmac that we call the web.