And then things became a little fancier and you could host a form on your site to allow people to send others links to your site. By email.

Plug-ins soon came along, and you could embed content from other sites in your site. And let visitors provide their own content (comments, etc) on your site.

All on your site. Or sent by email.

The great thing these days is that you can easily provide tools to allow visitors to share your content on other sites for you, and to follow your site on other sites. Its about moving the conversation.

Two tools which really illustrate this are Twitter and Add This. I’ve written before about Twitter and how I’ve integrated it into London for Free. I’ve already attracted quite a few followers – people who now don’t need to come back to my site to see info I’ve added about events. Instead, they will see my twitter post on either twitter itself or a twitter content aggregation site.

Add This is an excellent plug-in to allow visitors to London for Free to share it on other sites such as Facebook, delicious and more. And every time they do, it doesn’t just benefit them. It benefits my site. The more times my site can be linked to the likes of Facebook and other popular sites, the better. Though these links aren’t treated as proper inbound links by search engines, they help to advertise my site.

Two simple ways to promote your site on other sites and support conversations by visitors about it anywhere.

Specifically the idea of them building client side code which complies with standards such as XHTML 1.0 Transitional, CSS 2 (probably the two most commonly followed ones at the moment) and, dare I suggest, WCAG 1.0 (Accessibility).

Whereas most good books (such as Bulletproof Web Design and so on) not only recommend that standards are followed but also give lots of tips on how to do it, most developers I’ve ever worked with see standards compliance as another overhead, in the same bucket as doing their timesheets and attending team meetings. The code would work just fine without them, no one will notice if they didn’t do it and what value does it really add. Etc.

I can see why they might think this way.

There are loads of examples of high profile, hugely popular commercial sites that are clearly not standards compliant – even at the technical code level, as any simple check using the W3C Validator will show. It doesn’t appear to have harmed their search engine rankings or affected their ability to display correctly in various browsers. (Though the additional costs of making such “non-standard” compliant sites achieve this must be enormous.)

And almost all of them gets away with it. Though now and then, some site owners are prosecuted the cases are sadly few. Naturally, this therefore strengthens the case for the non-standards compliance school. If the big guys don’t comply and they don’t suffer as a result, why should anyone else bother.

Yet standards compliance is so simple to achieve and really doesn’t take much more time to do, so it shouldn’t be seen as such a burden. It basically amounts to producing clean, tidy and efficient code and using html properly – ie. semantically – which is what any good developer should surely be striving to do. I often use the analogy of a journalist complaining if they are asked to spellcheck their stories – surely it should be something that they do as a matter of course in the quest for quality.

Accessibility is a little different. Accessibility does require going that extra bit further, tagging up titles, using tabs and hot-keys to aid navigation, providing non-javascript versions of key content if you’ve also used javascript for it and so on. Being standards compliant takes you a long way to having an accessible site, but not completely.

But even then, it really doesn’t take too much more effort. And there are loads of tools to help check for compliance. I discovered a very good one recently – Total Validator. You can use it to check your code against the various html standards at the same time as you test for code-based (as opposed to content-based) accessibility compliance.

At the end of the day, whether its a legal requirement or not, it makes good sense to produce neat, clean standards-compliant code. It loads faster, works across more devices, is easier to maintain and ultimately better for users.

There’s really no excuse not to do it.

Why? Because they are crucial to driving forward their adoption.

Peter Kim recently did some research into Social Media Predictions for 2009 – here is his paper if you want to have a browse. Interestingly, there was little mention of these 3 areas but probably because it was more of a marketing and social paper than a technical “how to” guide.

But these areas are essential to delivering some of the changes predicted in that paper.

Firstly, html 5.

Though the standard is still in development, quite a bit of information has already been released about it. This article provides an excellent snapshot of what we can hopefully expect to see when the standard is finally delivered – and more importantly, supported by all browsers.

The new set of elements and attributes should go a long way to encouraging developers to produce more semantic, better structured html. And that’s essential for social media, mashups, RSS, enabling user-generated content on pages, providing better searchable blog entries and so on.

Three examples: HTML5 introduces a range of “structure” elements such as <footer>, <nav> and <aside>. This will greatly help developers mark up the content of their pages more accurately for use by search engines, content aggregators and social media tools.

Second example: HTML5 provides various elements for developers to use in place of the ubiquitous <object> element. New elements such as <video> and <audio> will enable developers to more accurately tag content so it can be more easily consumed by other sites, tools and so on.

I also read somewhere – though I can’t see it in the current draft standard – that an element will be provided to enable developers to mark up some content sections as being editable by users. If so, this should result in the explosion of user-generated content on all sorts of pages – basically, “instant” wiki pages. And potentially I guess make it possible for users to narrow searches by “user-generated” content.

Moving on to microformats. Though some may perhaps be replaced by new html 5 elements, microformats give developers the option to provide greater granularity when marking up their content.

This is all good stuff when it comes to making content more searchable and better able to be shared. Many people are probably already familiar with the geo tag for marking up location details of content so that it can be displayed for example of location-aware devices.

You can see some microformats in action if you install the Operator Firefox extension and look at any wordpress-driven blog including this one through the firefox browser. WordPress comes with the microformat rel-tag inbuilt so that whenever you add a post to a category, this microformat tag is populated.

If you’ve got the extension enabled, when looking at this post have a look at the toolbar and you will see “tagspaces” highlighted. Look at the drop-down list and you will see a list of sites that consume the tags on this post and let you search by them.

Microformats have huge potential for social media, next generation search and content sharing – once they become more widely adopted.

And finally, the 3rd new friend – next generation search.

As .net predicts in this month’s issue, “google’s 10 blue links will soon be history”. This site gives examples of new, more relevant ways of searching.

You know, the types who’ll sell you a “custom” website for £4k (5 pages only, template-based, and SEO advice extra, of course).

It made me think of my dad and how he goes bananas when I tell him how much it costs to service my car, and what they actually do for it. “£xx for an oil change!”  and so on. But he knows a thing or two about cars – don’t most dads??

But cars are as alien to me as the web is to him. I’m sure he’d think £4k for a website was a bargain. Even £10k.

And there lies the problem when it comes to these vendors. If you don’t know enough – just enough – about what service they are actually offering you, how much work they will do, how can you know whether you’re being ripped off or not. How would you know whether you are paying for something that is very difficult, or something that is quite straightforward (and therefore really shouldn’t cost as much).

So I thought about how someone could become better informed about the web. Not enough to be a developer but enough to know when you’re being taken for a ride.

In my view, its simple. Make use of all the free tools out there and build yourself a basic web site.

For example:

• get yourself a free web editing program, some cheap web space and a couple of good books (Bulletproof Web Design, for example), and create a simple web site. It doesn’t really matter what it’s about. The aim of this is to get an idea of standards-based design, html and css.
• Before starting, spend a little time doing the excellent free tutorials about html and css on w3cschools first
• Once you’ve created your site, upload it to your web space, stand back, be proud and have a cup of tea!

• then, check your site’s code by running your site’s live pages through the w3c markup validation service. This is a great way to learn more about coding and how to debug your site, which makes it work better across different browsers, load faster and be easier to update.

• then start exploring the world of plug-ins available for your site, starting with something simple such as a google adsense or an amazon affiliate plugin. (And maybe make some money

• while you’re at it, include some code from google analytics

By the end of all that, you’ll know a little about how easy it is to build a simple web site.

And when it all boils down, a simple site isn’t really that much different to how big CMS systems work. They still use css for design layout, they still use html / xhtml for content rendering, they still require metadata to be added to each page (keywords etc, which are important for SEO) and they still use javascript (and sometimes also iframes) for inserting plug-ins and pulling content through etc.

So you’ll also know at a basic level about how CMS systems work at presentation layer level.

(They also use design templates, content wizards, user permissions, application script calls and so on but the fundamentals of css, xhtml and javascript remain.)

You’ll still be a long way from being an expert but hopefully you’ll feel more informed about just how “difficult” some of this web stuff really is.

The web equivalent to being able to change your car’s oil yourself or at least know if you’re being ripped off!

Recently, I discovered an excellent script from GentleSource, which seemed to do the trick nicely. All I needed to do was to set up a mysql database from my webhost and download, install and configure the script. Then add it to some pages.

Simple – but there was of course the small matter of 150 code validation failures once the code was embedded in my site.

<rant>

Why can’t developers write validated code? If I can do it – and I’m not a developer – why can’t they. Or is it that they won’t or can’t be bothered. Don’t see its importance, etc etc.

Its the equivalent of writing a letter filled with lots of spelling and grammatical errors and they ought to be slapped with wet fish. Honestly.

</rant>

Faced with more failures than the X Factor panel, I ended up pulling the script apart, re-writing the include.php file and, instead of including the comments form as an SSI, sticking it into xhtml pages as an iframe. At least this way, I removed all the reported code failures and also had more control over the look and feel of the comments form through being able to edit the style sheet for it.

I’ve managed to get it working for two walks sections: cultural and royal walks and hope to get the rest done over the weekend.

At least I’ve now included a better comments tool – and with valid code, more or less.

So finally today, I started creating the first mobile version of the site.

Now the good thing I discovered is that my current site is already accessible via mobile. I’ve checked it on a blackberry and also on my new phone, and it doesn’t look too bad. But it’s not optimised for mobile use.

After all, there’s a load of stuff on there that you probably wouldn’t want to try and read on your mobile. Or can’t view at all even if you did want to – e.g. the YouTube video clip on the home page.

So I did a bit of thinking about the sort of content on london for free that someone on the move might want to see. And I figure that’s basically directions and info for the most popular walks and bus tour, and links showing the locations of landmarks on them. Content they can refer to while they are actually doing the walks or tour.

Then I needed to rethink the current page layouts from a mobile angle. The average mobile screen size is – doh – loads smaller, and anyone who’s tried to navigate around a website on a mobile knows its not easy, so I knew I needed to create narrow content and lots of internal site links that are easy to get to.

And, of course, I had to consider page weight. No one probably gets the promised 3G speeds touted by mobile phone companies, so I needed to provide lots of pages with tiny bits of content, making them quick to download.

Putting it altogether, it meant identifying the most popular walks (via google analytics), chopping their content up into pieces, embedding style info within the xhtml pages (rather than using separate css files), shrinking the image sizes and including lots of nav links.

But using the same London for Free logo to try and retain the relationship with the main site in case anyone wanted to check out the full site on their computer.

Finally, like any good web site, it had to be accessible – so the code had to be totally validated.

Here’s my first attempt. I based it on the templates provided on dev.mobi.

Though the normal W3C Validator works for validating mobile sites, there is a much better alternative called readi.mobi.

It not only validates your mobile pages but it also gives you info like the speed of download to an average mobile, the cost of download in various countries, and crucially screenshots of what the page looks like in different mobile phones. For example, here’s the info they gave me for my mobile index page.

I’ve still got a way to go to get the site fully up and running for mobile – lots of content to modify, for starters. But at least I now know what I need to do.

Recently I had started to receive spam emails through the web forms dotted around the new site. Thinking back with horror to the time a few years ago when I was receiving thousands of spam messages a day, I knew I had to do something to stop them.

Then I recalled reading about Captcha apps – they generate those images with either words, numbers or letters in them that you sometimes see on the web say when registering for a site, aimed at stopping spambots in their tracks.

A quick search showed loads of apps that required payment. Then I found a free app called Securimage Captcha. And it was a dream to install. Just a few lines of code in each page and formscript.

Hopefully no more spammers for the moment, at least.

All the content is now done apart from one page which I need to give a bit of thought to – the sitemap for visitors (not to be confused with the xml “sitemap” file that I will need to generate after the site goes live and upload to google to help them find my pages for indexing).

And I’ve managed to crack the problem of the map polylines not showing in IE7. Seems they don’t like KML format colour codes – no idea what they use but through a lot of trial and error I’ve found some 8 digit codes which work. Thankfully.

Other prep stuff I’ve done this weekend includes checking all internal and external site links and fixing quite a few, adjusting some of the sidebar content to make the site flow a bit better, fine tuning of section widths and changing a few images.

I’ve looked at the google analytics for the site and it seems it gets the least site traffic on Saturdays, so next Saturday will be the day I finally put it live.

Should be fun – and then I can get into doing something else for a change, like reading books on agile project management!

This led me to discover KML (a file format and schema based on XML) – though initially developed for use with Google Earth, it is now able to be used with google maps.

And by recreating my maps using KML and various tools (see below) I now have this instead of this.

Previously, I needed to struggle with javascript and the Google Maps API to feed data from XML files.

Now it’s as simple as this:

1 – create your KML file in the format, and using the elements, described by Google

2 – upload your KML file to some server space

3 – if you use your own icons, upload them (as 32 x 32 size thumbnails) too

4 – go to Map Channels and create a free account

5 – generate your map by creating a map channel and inserting the url to your KML file

6 – Map Channels will then give you some code to paste into your web page in order to embed into it a google map based on the data in your KML file

Very easy!

And here are some tools to improve the quality of your maps:

* KML Tool: a tool for finding the KML Point co-ordinates and KML polyline co-ordinates of any given location

* Feed Validator: for validating your publicly hosted KML code

* KML Colour Converter: A downloadable tool for converting a html colour code (in format “#9E7658″) into a KML colour code (in format “7d58769e”)

Google does it again – nice and simple.

Instead of users having to print out exactly what they see on screen, you can get rid of stuff like nav, sidebars and plug-ins from pages, enabling them to print out only say the main content.

Great! So there I was, merrily creating a print-specific stylesheet for my site ……. only to find that I then had problems getting the printouts to flow across more than a single page in – of all things – Firefox!

Yes, Firefox – the poster child of open source software -has a print bug in it. Sad to say, it all worked fine in IE6 and IE7.

The details and thankfully the solution are described on Jaffer Haider’s blog

The simple answer, it seems, is to add the overflow:visible property to any of the div elements you want to appear in your printouts for users.