Audience Dialogue

Thoughts about this site

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.

23 Feb 2006. Three days ago we fixed the broken links on this site. At least, we tried to. According to Xenu Link Sleuth (the best link-checking software we've found so far) of the 806 URLs mentioned on this site, 806 are working fine, 23 have various problems but still work, and 30 are just plain gone. The annoying thing is that most of those 30 are not really gone at all. Looking at what they have in common, a few patterns were obvious. Many of them were on big websites, such as IBM, Amazon, and OECD, from huge companies that probably couldn't care less whether anybody links to them or not. Most of them (to judge from the URLs) are using a content management system. They tend to have huge URLs, that don't fit on a single line and have to be manually joined together. (We just found some new Firefox extensions that might help with the latter problem.) Some of them, like IBM, seem to redirect themselves around in circles. Makes you wonder if these sites have got so big that they're totally out of control. I think we might just stop making links to sites that change the URLs too often.
21 February 2006. Every month or two, we that all the links from this site are working properly. Every time, of course, some links have changed. It's rare that page we link to will actually disappear; most often, the directory changes, due to corporate redisorganization. Now what type of links would you expect to change most often? Some fast-changing field, such as software, right? Actually, no: the page that changes every time is our other glossaries page. Wouldn't you think that once somebody had gone to all the trouble of creating a good glossary (we don't link to bad ones), they'd leave it alone, apart from making minor corrections and additions? But that's not what happens. The logic seems to be "We've made a really good glossary here. That was a serious mistake. We'd better delete that page!" And so our never-ending quest for supplementary glossaries continues. (End of rant.)
18 February 2006. Finally found a solution to the main menu of this site - the standard division is

(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.

16 August 2005. After a long break in trying to fix problems with this site, I had another go at the problem of vertical alignment in tables - specifically, items aligning themselves in the vertical centre (the dumb default of HTML) instead of at the top where any sane person would want them. The most annoying example of this is the sitemap page.Tried the CSS vertical-align command again (which hadn't worked in the past) but this time it worked, in IE5 for Mac, #others. One of the endless mysteries of CSS.
2 November 2004. Breaking a long silence in this site blog, because nothing much has been happening lately on this site, as far as design is concerned. But after reading a Pew research report last week saying that smaller type is more conducive to readability, we've decreased the text font size from a nominal 12 point to 90% of that. All it took was a single command in the stylesheet. The problem now is that on a high-definition monitor, the text lines are too wide. Other research has found that with more than about 70 characters per line, you tend to read the same line again. If over-wide lines annoy you when reading pages on this site, just make the window narrower - about 600 pixels should do it.
29 March 2004. Spam is getting more and more out of control. This morning I came to work to find 160 new email messages, of which about 150 were spam. This is despite our ISP's spam filter, and our abandoning the "info@" email address, which is too standard. Well, maybe some of the 150 weren't spam, but if somebody we've never heard from before sends a message with a title that doesn't seem relevant to our work, and with an attachment, that message goes straight into the trash. If that was you, we're sorry - please try again, but without an attachment (first time), and with a subject line that doesn't include "Viagra", "free", random nonsense words, and the like.

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 - not sure if this is more like a listserv or more like a discussion board, but it looks very straightforward.

26 March 2004. A new client of ours wanted some advice on what was involved with getting a website. What factors should they consider, in deciding how to set up a new site? I thought there would be hundreds of web pages on this topic. A few minutes with a search engine should turn up some of the best, which we could then recommend - and even make some links from this site. Surprise! Trying a lot of synonyms turned up very little that was useful. Plenty of technical pages on FTP and HTML, but we wanted something non-technical, discussing all the main decision choices that have to be made. After half an hour's fruitless search, I remembered something I'd written a few years ago for a client in a similar situation. In fact, it turned out to be 1999. Way out of date now! So I changed a bit, added a bit, and now we have a set of 4 pages on How to plan a website. (As always, comments are welcome).

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.

16 Feb 2004: Looks like we fixed the font size problem on this website. The font appeared much smaller in Gecko browsers (Netscape, Mozilla, Camino, and Firefox - formerly Firebird) than with Internet Explorer. We fixed it (at last) simply by commenting out the line that specified the font size. Weird, but worth noting.

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.)

13 Feb 2004: While writing a new page on how to find dead links I [DL] realized that the text of a link should be the title of the page linked to. Then, when a link is dead, the user can quote the linked text in a search engine, with some hope of finding the lost page. Why didn' t I think of this years ago? And why don't I remember reading anything about this in usability books or websites - having read everything I could find on usability? (A big part of our business.)

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.

Let's have more interactivity - somehow

7 Feb 2004: this log begins. Our site is not nearly as interactive as we'd like it to be, but our local ISP, (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]

Making published email addresses spam-resistant

We've given up on the email address - 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 (ha ha, gullible spambots!) we'll have and change the unguessable every few months.

Our new sitemap

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!

The CSS nightmare - episode 859

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.

Web development books: Design of Sites

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]