Just a quickie to say that I’ve upgraded to WordPress 2.0.1, and moved things around a bit. Things are bound to be a bit screwy for a while – bear with me while I get them sorted out.

The home page is at plain old thinkdrastic.net as opposed to /journal/ now for a start. You should get redirected cleanly, but I can’t promise anything.

So far, WP2 looks quite nice. The wysiwyg preview is a great little addition.

Update (Monday 20th Feb)

OK, so I might have ever so subtly redesigned the place aswell. I still need to do loads of tweaking, aswell as find somewhere to put my interesting asides.

The really bonkers bit? It’s needed approximately no tweaking for Internet Explorer so far. Crazy biscuits!

Update II (Sunday 26th Feb)

‘Photos’ and ‘Interesting Asides’ make a return to the sidebar. Is that better Matt? You may need to hit ‘refresh’ to get the latest version of the stylesheet or things might look a little odd.

Man, it’s taken me over a week to write about this. Slacker extrodinaire. Anyway, I got up very early indeed last Friday morning and made my way across the country to the Victoria Park Plaza Hotel for Clearleft‘s Ajax Workshop. I wasn’t quite sure what to expect, but what I got was very good indeed.

So the Clearleft crew took a bunch of web designers and developers and threw them together in a room. I had a few wierd moments where I looked around and recognised various faces from my travels around Flickr and the blogosphere [1]. I also felt ever so slightly jealous as a variety of Powerbooks were unfurled onto the desks around me.

Jeremy Keith spent the morning taking us through Javascript, DOM Scripting, the basics of Ajax and how it’s done (JSON looked particularly interesting). If you’re scratching your head and asking “WTF is Ajax, man?” Suffice it to say that it lets you refresh only the parts of the page that you want to, rather than fetching a whole new page from the server every time a user clicks a button.

All good stuff, but not the main reason he had gathered us there at all. No, that came after lunch:

Hijax

Hijax is a best practise methodology for building web applications. It basically says:

• Build your pages in a completely modular fashion.
• Build it such that it will work for users without Javascript enabled.
• Add the AJAX functionality in once you’ve got the pages working without it.
• Only add the AJAX in once you’ve thought very carefully about the usability and accessibility issues involved with them.

It takes it’s name from the fact that you hijack the default actions of a web page and bend them to your will. Clever huh? Jeremy does a much better job of explaining it, so I’ll leave the rest to him. One more comment though: When Google built GMail (one of Ajax’s poster children), they delivered a complete Ajax application first, then months later managed to produce a completely separate plain HTML version. They had to do all of the work twice: If they’d done it the Hijax way, they could have had both versions of GMail at once and in the same application. Makes you think, doesn’t it?

Ajax: The downside

Ajax is a fantastic technology which has far reaching implications across the web. However, it has some major issues: Usability and Accessibility to name but two.

Say the user clicks a button and something updates elsewhere on the page. How do we inform them that something happened? There’s a number of answers to this question: Animations and special effects are just two of them. But what if they have a low-resolution screen, they’re using big fonts, or they’ve simply scrolled too far, leaving the vital animation or effect off-screen? What about screen-reader users – how do you tell them that only part of the screen has updated?

Then there are the problems with bookmarking and the back-button. In a traditional web application, every move you make is added to the browser history. Ajax apps suffer many of the same issues as Flash and Frames-based sites: Because you aren’t refreshing the page every time, you aren’t updating the browser history. Hitting back will likely take you right out of the app and bookmarking simply doesn’t work. Jeremy’s answer was that if the user felt the need to bookmark, maybe you’re changing too much of the with page using Ajax?

There is currently no clear answer to to a lot of these issues, but a lot of good work is going on in that direction. Recent work by the likes of Mike Stenhouse and Robert Nyman is showing us the way. Some people are advocating that we should get screen-reader users to disable Javascript. Others disagree and say that improved software will come in time. I share the latter point of view – besides, what about those in-between cases, like low-res screens, big fonts, mobile users and so on? There’s definitely lots to think about when you’re putting together Ajax apps.

Coffee Break!

On top of all this, I found the time to chat to the likes of Adam (from the DiH mailinglist), Molly, Mike and Paul about IE7, it’s implications and how Microsoft are changing, then later to Jeremy, Bruce and others about haircuts, earrings, Flickr and social networking.

After the workshop, we all trudged upstrairs to the hotel bar and indulged in a couple of beers. At some point my sister, Alice, phoned me and demanded that I go and see her. We met up with Angus and dined in a very good turkish restaurant, before hooking up with various friends of hers for the evening. I think we left Tru Thoughts @ Cargo at about 3:30am. A long day, but a good-un.

Oooh, that got a bit stream-of-consciousness there for a while didn’t it?

[1] Did I just write “blogosphere”? Gaaah… shudder.

I’ve been wanting to redesign this place for ages, but I’ve never really found the time or indeed motivation to do it properly. I needed to change the look with absolute minimum effort for me: I figured a new header image was probably the easiest way to do it, so that’s exactly what I’ve done (it should look like this – you may need to hit reload or clear your cache if you’re not seeing it).

G-Dog gets his five minutes of fame this time. You can tell the pictures are quite old – he’s riding an Orange 222 (You’re my bike now Dave!). They were taken back in July of last year up on Leckhampton Hill , then amalgamated in Photoshop. Yes, I know it all needs a bit of tweaking – especially the navigation. I’ll get around to it at some point.

Oh and a completely unrelated HAPPY BIRTHDAY BAGGUS!

I felt I had to point this one out: Joe Clark’s excellent Failed Redesigns.

When teenagers’ hobbyist blogs (short for “Web logs”) have better code than brand-new Web sites, somebody’s doing something wrong. And that somebody is you, the developer. In a just society you would simply be fired; in an Orwellian society you would be sent to a reëducation camp. Failing either of those, you could at least read a fucking book and upgrade your skills to a point where you are no longer a total laughingstock.

100% of brilliant, and absolutely right. If you’re making money from building websites (i.e. you’re a web professional), bloody well do it properly you lazy sods.

…you’re not the only one getting to the end of your tether.

We had a major website release to put together the other day. We’d fixed every possible bug we could find in the C#, HTML and JS code, bar one: A CSS bug in Internet Explorer was breaking something vital.

I don’t get visibly angry very often, but on this occasion I was absolutely steaming. People were waiting on me to find this fix so we could do the release and go home, but I just could not figure it out. I tried margins, padding, heights, widths, overflow, even obscure positioning techniques. Everything I could think of – all to no avail. I was getting more and more frustrated as time went by but that wasn’t helping either. The handy developer toolbar wasn’t helping – it pointed out that element had the right amount of margin, padding and their wierd hasLayout property.

Ahhhhh, all of them except that seemingly completely unrelated one. I hadn’t fed a specific height to one element and the whole thing came crashing down.

Once I figured it out, that anger faded away to relief and we got the release out of the door. But it made me think: a CSS designer/developer’s profession requires that they pander to a product that despite being vastly technically inferior, is the most popular on the market.

Despite all of this though, I could never contemplate going back to the old way: Using <table> and spacer.gifs to lay out and style a page. I’d need to retrain all over again for a start – I really can’t remember most of the old tricks we used to use back in the day. There’s one particular (internal) website at work that’s horrendous in that regard – it uses every trick in the book so the slightest change takes hours. What’s more, it limits you in so many ways: Would Sir like to position this box over there? Or perhaps Sir would like a slightly different layout when he comes to print, or when serving to a handheld browser? Sorry Sir, no can do.

Yes, the pain of pandering to Internet Explorer is definitely offset by the advantages that the standards-based methodology offers.

I’m sure I’ve mentioned this before. Internet Explorer 6 is quite possibly the worst bit of software I have ever encountered.

The thing is, from the front end it’s not really too bad. OK, so it’s looking a bit dated, but as far as the user can see, it renders web pages without complaint, it’s not too slow, it’s got a fairly easy to use bookmarks system. It’s simple. We can’t get people to upgrade because (as far as they know) it does the job perfectly well. They simply don’t know that they can do so much better.

From the other end though – the point of view of the developer – it’s a complete nightmare. I’ve sure already covered the myriad ways in which the HTML, CSS and caching parts of the engine are fundamentally broken. Now, it seems, the Javsacript engine is completely borked aswell. I won’t go into the details (I’ll only end up getting angry and dumping a truckload of slurry on Micorsoft’s doorstep), but suffice to say that it runs like a dog on IE6, though every other browser executes it like it’s Thrust SSC on speed. Great. Some resources to help if you’ve in a similar situation:

• Optimizing JavaScript for Execution Speed
• A compendium of JavaScript optimization techniques
• Javascript Closures
• JavaScript Memory Leaks
• PPK on Javascript memory leaks
• DHTML leaks … not so much, actually
• Fixing JavaScript memory leaks for good.
• BeeByte’s JS Links

Someone remind me, just how did IE6 get through Microsoft’s quality control program? Roll on IE7, I say.

I had a bit of geek pleasure this week. I took an in-house web-application and tidied it’s output up. What was once a pile of tag-soup junk is now clean, accessible, sentatically correct, valid HTML. This was relatively easy, once I’d got my head around the way the app works. It’s quite nice now – but it sits on our intranet, so you’ll never get to see it unless you happen to work in the same place I do.

Then I got cocky. I thought If I can do that for that app, why can’t I do it for this ever so slightly more complex one?

So I started looking at the source files. Holy crap! It looks like the code was written by a gibbon jumping up and down on the keyboard! As soon as I started trying to tidy it up, things got squelchy. Undo, undo undo! Put it back exactly how it was! Phew. Making that one look nice is going to be an interesting experience.

Still, I think it’s worth doing, even if it’s “just” an in-house intranet application. Your in-house customers are just as important as the outside ones. If you don’t keep them happy, the products and services that they produce for outside customers won’t be as good. Keeping the interface and the code clean and accessible means that it’ll be nicer for user’s to interact with. What’s more, it’ll be easier for the next set of programmers and designers to work with next time around.

I’m currently working my way through a sample chapter Sitepoint‘s DHTML Utopia book – partly to see if I want to buy the book, and partly because I’m trying to get my head around event listeners. I got some way through the chapter, testing my work in Firefox as I went, and it was all going swimmingly.

What happens in Internet Explorer then?, thinks I. Precisely nowt. It was at this point that my colleagues looked around to see what the swearing was all about. From the book:

Naturally, making events work cross-browser is not as easy as just following the DOM standard. Internet Explorer doesn’t implement the DOM Events model very well. Instead, it offers a proprietary and different way to hook up event listeners and gain access to event data.

What’s the point in having a standard if the most popular sodding browser is going to completely ignore it!?

Luckily, the book explains ways around Internet Explorer’s Javascript deficiencies in a calm and friendly manner (e.g. This is inconvenient but not catastrophic; it just means that you have to take different actions for different browsers.). It’s entirely possible that I’ll buy the book, simply because it’ll help dig me out of some big holes.

WARNING IE USERS! STROBE EFFECTS LIKELY!

So, I decided to try applying the lessons learned to one of my own projects. It was all going fine, up until I went to test it in IE. This time, the scripts were working perfectly. No, IE had to find some other way of buggering it up. Now, every time an event was fired, IE decided to re-load all of the background images in the elements effected. Flickerytastic dude! Does this mean I have to put an epilepsy warning up on the page? I navigate away, click ‘back’ and all is fine again.

A bit of googling, asking around on mailing lists, and tearing out of my fast-greying hair reveals that are two ways of fixing the problem:

1. Get every single one of your visitors using Internet Explorer, AOL, or indeed anything else that uses the IE engine, to alter their Internet Options: Go to Temporary Internet Files, then Settings, then choose Automatic. Realistically, that’s not going to happen is it?
2. Get your server to add the Cache-control header to the images on your server. Doing this works differently for different servers: ASP.net Resources has the fix for IIS, Dean Edwards has the fix for Apache. If you’re using something else you’ll have to rely on google.

It’s really frustrating that every time I try to do almost anything on the web, Internet Explorer jumps in front of me and holds up an enourmous stop sign. It’s good in a way, in that it forces me to find an acceptable way around the problem. I just wish finding that answer didn’t usually double the time it takes to complete a project. If IE7 really has improved as much as Microsoft say it has, I can’t wait for it to arrive. It’s just a pity that IE5, 5.5 and 6 will continue to linger for as long as they inevitably will.