More on the new gazetteer

Work on the new gazetteer procedes apace, although I doubt it will go properly live until a month or two into the new year. But I hope to have a prototype up one side of Christmas or the other for people to play with.

I've made a few interesting design choices along the way. It's quite clear, for example, that the gazetteer could be a single HTML page that pulled all the appropriate information from the server using AJAX techniques. But that would really mess up search engines; there are a lot of interesting articles on the tension between AJAX and SEO around the web.

So I'm content that there will still be a separate page for each location (and I'll be making sure it remains compatible with mapping from cgi parameters to fake directories for the future). But each page will do a lot more with AJAX-like tecniques.

I'm using the rather nice tags from acme.com for selecting the map or the photos (or I intend to - this bit hasn't really been started yet), for a very neat way using nested tab blocks to show POI data without filling the page with endless items (which is part working - enough for me to be convinced that this is the way to go) and for links, including tagged links (which is working). What are tagged links you ask? Read on.

There are two entirely new features in this version. The first is a new way to select place - this is the default if you start the gazetteer without giving it a place. This uses the same selection tree as you get if you use one of the region buttons on the current gazetteer start screen, but instead of it being page by page, with lots of buttons, it is all on one screen with drop down lists for region, waterway, [optional] part of waterway, [optional] sub part of waterway and place. This is all done by AJAX-like techniques, so the transitions and changes of the drop-downs as smooth, but there isn't a huge delay because it doesn't need to download thousands of selection lists before starting.

The second new feature is tagged links. This allows users to associate a link to an external site (web site, page, blog entry, picture, sound clip, video, whatever) with a "tag" and the link will be shown on all gazetteer entries that match the tag. Tags exist for each place by itself, for waterways, for identified parts of waterways and for all the rings that CanalplanAC knows about. So, for example, the "Stourport Ring in 10 minutes" video can be linked to every location on the Stourport Ring in a few clicks of the mouse. At the moment tags are not user definable, but if someone comes up with a good use for user creatable ones it would be straightforward to implement them. Again, this is all interacive using AJAX-like processes to get and send data between the browser and the server.

Of course there is lots going on to support this. A full re-engineer of the POI data structures is only part of it. But I'm confident that I'm going to end up with a smoother, quicker, more functional and more attractive gazetteer that's a really good example of webv2.0 technologies.

One footnote. Why to I keep saying "AJAX-like" up there. We'll because while there is a lot of Asynchronous (which is a fun learning experience for me), Javascript (which I'm actually starting to like as a programming language) and an awful lot of And there isn't much XML. You might think this odd; CanalplanAC was an fairly early adopter of XML for internal data formats and has used them since The Great XML Port of Spring 2002. The problem is that when you start sticking XML into the Javascript DOM, you get into some fairly hairy browser differences stuff. So although I use the XML request methods to get stuff from the server, I've been using fairly straight forward text formats for - say - the drop down menus.

For the POI stuff I was expecting to have to knuckle down and get dirty with XML and DOMS when I came across JSON. According to www.json.org, JSON is based on data structures that "Virtually all modern programming languages support ... in one form or another." Absolutely right. Canalplan Basic certainly does. It took me only an hour to produce a "write this data structure in JSON" feature into the interpreter - it's a lot cleaner than the corresponding XML writer. And it works very nicely indeed. So we are certainly AJA here, but the X seems to be taking a bit of time off.