We thought it would be interesting to have a sort of site blog, on the development of this website - and maybe also useful for us at the loose coalition of Audience Dialogue to remember why it's done this way. So here goes - though with a misgiving or two about how narcissistic it is for a website to include a page about itself. We haven't seen any other sites do this - but somebody has to be first (sigh). As usual with blogs, the newest entries will be at the top. The entries will be separated by horizontal lines.
(a) Home | Tools | Techniques | Cases | Sitemap | Search
The trouble is that most of the pages on this site come under Tools and Techniques, and the distinction between them often isn't clear. After thinking about this problem on and off for two years, trying to carve up the pages in other ways in numbers of categories between about 2 and 20, I finally hit on the solution. Like most solutions, it's screamingly obvious when you think about it, and was arrived at by eliminating unconscious assumptions. The assumption in this case is that every page on the site must be linked to the top-level navigation hierarchy.
Realization: Since there's a link to the sitemap and search on every page, there's no need to link to top-level Tools, Techniques, and Cases. Nor is there any need for the navigation to be identical on each page. As long as we keep links to the home page, the site map, and the search page, the other ilnks can be anything - or even nothing. So instead of format (a) above, the menus will be like this:
(b) Home | xxx | yyy | zzz | Sitemap | Search
- where xxx,yyy, zzz (and as many more will fit on one line) are links to the other pages most related to the page you're on. Some pages already do this, but from now on this principle will be gradually extended to the whole site.
A related worry is that some of the emails we send don't seem to be getting through. Maybe some of the anti-spam services are blocking our messages for some reason we haven't suspected. I think I'll go ahead with our long-delayed plan to set up a discussion board. I've been meaning to do this for a couple of years, but when I found about 200 alternative pieces of software it all got too hard. We tried Discus on another site, but after an initial flurry, people stopped using it. Maybe the threaded discussion was all a bit too difficult. Recently I discovered Quicktopic, which looks nice and simple. Let's try that.
February 2006: Just discovered 9cays.com - not sure if this is more like a listserv or more like a discussion board, but it looks very straightforward.
I still suspect there are lots of such pages out there - the problem is how to find them. Search engines still have a long way to go. Google was great 5 years ago, but it has really sat on its laurels, making minor tweaks. Let's hope the much-trumpeted Microsoft search engine will be a significant advance on anything we've seen yet. Hope is harmless, but on Microsoft's track record, they don't usually get software working well till about version 3.
Today I was showing somebody how good Firebird is, and found it had changed its name to Firefox. From Phoenix to Firebird to Firefox - Mozilla had reasons for changing the name, but it's a great way to shake off new customers. At least they didn't change "Mozilla".
The prize for the bad website of the day goes to the Australian Bureau of Statistics, which is near-impossible to find any data on, even if you know the site well. A specially neat touch is the way the green side menus spring out over the links you want to click on, preventing you from clicking on them. And if you can't get the data off the website, you can buy their exorbitantly priced CD (16,000 AUD) - so expensive that only libraries have it - and they probably don't pay anywhere near 16,000 dollars. And if the ABS website seems confusing, just try its CD software! But, with the help of several librarians and our search expert Bhanu - not to mention the usual contortionist, policeman, and organ-grinder - we finally managed to get the numbers we were after. If anybody needs postcode population data for Adelaide for the 2001 census, we now have it. (Why did we need it? To check the geographical representativeness of a survey sample.)
This is one of those things that's really obvious when you think about it. But you don't think about it - except when writing quite a detailed page to tell people how to find dead links. Specifically, two things to avoid in link text are:
(1) Nonspecific descriptions like "click here for more details".
(2) To have the URL as the link text (because if it changes, the reader is lost).
The overriding principle is to have two ways to find a link: the "a href=[URL]" and the page title, or something similar that will enable it to be found easily by a search engine.
What sort of conclusion can be drawn from my ultra-slow realization of the obvious? Maybe that the way to reveal your own unconscious assumptions is to write them down as a series of instructions, and get a few people to try to follow them exactly. So a new task for this site will be to review every link label on this site (about 400 of them) and to check that typing the link text into a search engine will find the link, regardless of its URL.
7 Feb 2004: this log begins. Our site is not nearly as interactive as we'd like it to be, but our local ISP, www.bold.net.au (in Adelaide, Australia) is a bit paranoid about site security etc. That's quite understandable, but at the same time it reduces our chances for interactivity.They say the solution is for us to learn PHP and use that. Well, maybe one day, but we have a lot of other things to do as well. Maybe next year. (Isn't that what we also said last year? Hopefully, not next year as well.) In the meantime, I'm wondering if it's possible to use the RSS "text input" command for feedback. Maybe we can set up an RSS feed just for that. [DL]
We've given up on the email address info@audiencedialogue.org - 90% of our inbox was spam, after a huge influx of spam in the last few months. The new address is... - but I'm be crazy to write it here. If you want to contact us, do it through our new spambot trap at reach.html on this site. Any crawler would have to have to be pretty smart to work out what address the email goes to after clicking on that button. And if any crawler does figure it out, there are endless ways to rewrite the javascript. Unfortunately, though, this is a lot less convenient for users than having an email address at the foot of each page.
A tip: we also realized that from a spam-reduction point of view it's a dumb idea to use standard email address prefixes like info@. If you were a spambot writer, all you'd have to do is make a crawl for domain names, and prefix them with common addresses like info@ and sales@ and so on. So instead of info@thisaddress.org (ha ha, gullible spambots!) we'll have unguessable@thisaddress.org and change the unguessable every few months.
What do you think about the Tools / Techniques / Cases division of topics on the main navbar of this site? Confusing? We're not entirely happy with it either, but now that our sitemap is redone, those categories might make more sense if you take a look at the sitemap.
Our old sitemap was way out of date. It looked nice (we thought so, anyway) but wasn't too functional. So the other day I did a web search on sitemap designs, found little that was relevant (as usual), and eventually decided to go for a multi-column layout. The principle was to fit as much as possible onto one screen. We thought our new layout was mildly original - till the next day, when somebody asked "Did you copy that format from the Google sitemap?" How annoying! The good thing about the new layout is that it's much easier to keep up to date than the former one, which was a complex table, and usually not right the first time because somebody forgot to change a far-from-adjacent COLSPAN or ROWSPAN. That's the downside of writing a website in plain HTML - but at least it's quicker than fighting with Dreamweaver (ugh!) or GoLive (uuuugh!) or FrontPage (uuuuuuuuuuugh!). Filemaker Homepage: all is forgiven - bring it back, please, Claris!
We wasted a few hours getting the pale background colours on the sitemap just right. On the Imac that we use for website development, the sitemap looked really nice in IE5.2 (Mac) and in Icab - lovely subtle colours, with the most important links "above the fold". But then we tried it on a PC with IE6 (our visitors' most common browser) and it mucked up the vertical alignment in the left-hand column. Also, the PC was running 16-bit colour, which lost the subtlety of the 24-bit colour the sitemap was designed for. Then we tried it on the PC on the excellent Firebird 0.7,and it not only had the same vertical alignment problem, but as usual on the Gecko engine all the type was too small. But we don't want to get into the nightmare of having a different version of the CSS file for every browser. Audience Dialogue is too small for that, and this site changes too often - so it has to be one version for all.
So it's back to the nightmare of CSS to work out a way of getting the type to render at about the same size on the Mozilla/ Netscape/ Firebird/ Camino platform as on IE. I don't want to lock in the size that users see (e.g. by specifying pixels or points) but our default font-size: small command isn't working too wall. Suggestions will be gratefully accepted - even acknowledged! In the meantime, if you're using a Gecko browser (Mozilla, Firebird, etc) you might need to increase the displayed font size for this website. But if you're using IE, the font size labelled "small" may be too big, so you could go View > Text zoom > 90% to make it more readable. Hold it! That's a Mac command - IE menus are different on the PC - it's (go to the PC in the next room, wake up Win 2000...) [DL]
Later: what if we simply don't specify the font size? Let's try that.
If you're interested in web development, take a look at the book The Design of Sites by Douglas van Duyne and a few others. This is easily the best book I've seen on web design. I borrowed it from a library a month or two ago, then just had to buy it - despite the office bookshelf overflowing onto the floor. This is an essential book. The 800-page monster cost 38-odd US dollars from Amazon - who sent it to us, in Australia, from Hong Kong. (Since when did Amazon have a Hong Kong branch? Maybe the postage is extra-cheap from there - though the cost of books in HK is sky high.) Anyway, van Duyne's approach is based on Christopher Alexander's A Pattern Language - one of my all-time favourite books. Instead of the usual rigid prescriptive approach, van Duyne covers design patterns, across a wide range of scales - just as Alexander covers architectural design patterns. "Here's a pattern" it says, "here are considerations for that pattern - now fit this pattern into others."
After discovering the dead link problem described above (on 13 Feb), I checked what this book had to say about it. They don't actually mention the problem (but as I said, I don't remember anybody else mentioning it either). However, they almost get there in section K9 - "descriptive, longer link names". [DL]