So I’ve finally – FINALLY! – moved from the WordPress theme I’ve had on this site for nearly FIVE years. For now I’ve just got a very standard Thematic-based child theme, but I’ll be working on that shortly. At least I can move some widgets around now!

Watch, as they say, this space…

IE6 CSS – let them eat cake?

An interesting idea is presented on “for a beautiful web” regarding how best to deal with IE6 and its many failings. Universal Internet Explorer 6 CSS proposes that IE6 always gets sent a standard look and feel, so that the experience for its users is not bad – just not the full shebang. It’s clear it has been designed, rather than sending plain CSS-less HTML, but it’s very sparse.

Personally, I like the idea. I have done something similar on more than one occasion. I haven’t taken it to the same level, possibly, but I’ve treated IE6 in a similar way to how I treat screen readers for example: make sure all the content is available, and is usable. What follows are a couple of screen shots of, first from Safari 4, then from IE6. (The Safari 4 shot is representative of all modern browsers, though.) The design basically revolves around having all the content on one page, in nicely scrollable boxes. In IE6, this was not well supported, and the decision was taken to make the layout more “blog-like”. All the content is the same, however.

First, Safari 4:


And IE6:


Development Standards: Intro

I’ve decided to write an occasional series of articles on coding and development standards. It will be how *I* see them – the standards *I* myself follow – so it might not be for everyone. What it will be is a guide to what to expect if I’m working for you, and what to expect if you’re working for me.

I’ll write separate pieces for CSS, HTML, PHP and possibly for server administration-type stuff too – Apache configuration, and so on.

Expect the first instalment in the near future…

Screencast as development tool

I’m in the middle of the first phase of building a new webapp and like most web developers (I would bet) when I show someone what I’ve done, it’s not apparent what marvels of engineering I’ve pulled off! So, in order to actually give a quick run-down of where we’re at with the application, I thought about making a screencast of the login, profile creation, module, video upl– well, I’ve said too much already ;)

After thinking about that for a bit, I wondered if any methodologies, agile or otherwise, use screencasts specifically as a tool. I could just Google it, I know. In any case I think it’s a nice way of showing progress on the development – or bugs in the app.


This is probably an oldie-but-goodie to a lot of web devs, but as search indexing bots don’t always send `HTTP_ACCEPT_LANGUAGE` to the server with the request, it will cause an error if you depend on its presence, which can and will be reflected in the search results, even though not in “any” browser.

AJAX and all that jazz

I have to say, as a long-time non-fan of Javascript, the idea of depending on it to make things *nicer* didn’t really appeal. I think my subconcious was successfully preventing me from following those tempting links on Webreference, Sitepoint and of course Adaptive Path, promising me the ability to take my web apps to the next level, create amazing interactivity while retaining compliance and generally making my life worth living.

Of course, apps like Gmail, which I still remember being amazed by when I first got a look at the beta about a year and a half ago, drag you inexorably toward wanting to get some of the same interactivity action. My old school usability head was still in control though. Then I showed an admin app I’m building to a friend and top notch web geek and he said it’s a lot like AJAX and that was it: I was turning to the Dark Side.

So, what’s the big deal? Can you have funky load-in-the-background stuff and keep the usability? Does losing the back button damn us to interface hell? And can you get all the niceness without going insane from coding Javascript anyway?

Well, so far I think you can. Yes, you lose the back button – that’s one of the main things you can’t get around or easily build any nice alternative. You could have an in-page “back” button (or “undo”, whatever) but that could be interesting to code. In any case, can you normally trust the back button in a web app? I’m pretty sure I wouldn’t trust it when I’m taking a look at my bank account. Of course, that doesn’t apply in the case of things like Google Maps, where going back is a useful feature or would be.

Something I really hate in this kind of app is that you can’t bookmark specific pages (or “views” I suppose we should call it, as there usually *is* only one page.) Google Maps gets this right by having a simple “Link to this page” to get a URL that will take you right to the same view. (Here’s where I’m sat right now…)

At the moment, I’ve tried a couple of toolkits, both of which seem pretty nice: Sajax and xajax. I like the latter’s way of working slightly more, but there’s not a lot in it. More soon, once I’ve given these a proper going over.

So, while this is a *completely* incomplete (can I say that?) look at AJAX, I’m going to be investigating further…


Just a few days ago, I moved over to using Subversion for version control instead of good ‘ol CVS. Although it’s basically CVS evolved, it somehow *feels* different. Anyway, so far so good. I’ll report back here if there’s anything interesting to report.