Living in a state of accord.

Auto Update And Privacy

Here's a really simple golden rule for anyone thinking of adding auto update to their products – never ever include any user identifiable information. There's simply no reason you need to know who is checking for updates, you only need to know what version they have. Given the infrastructure of the internet you will wind up getting their IP address, your policy should be that these aren't stored.

It comes as no surprise to me that the WordPress mob broke this rule with their new auto update – they always seemed shifty to me. Tell me why exactly you need the URL of the blog to determine if a new version is available? Exactly what use to you is blog.ephox.intra going to be? Oh well, I'm already removing all the pointless blog entries they spam the dashboard with and those weird technorati partner parameters so I guess I'll be asking for updates from or something too….


UPDATE: I posted this before the inflammatory and completely wrong slashdot article. I'm aware it only sends your blog URL and I've already patched my version so it doesn't. Of course they can still identify me by the static IP and the replacement string I put in instead of my blog URL but it's the principal of the matter more than anything, at least it's clear that I don't agree with deliberately adding personally identifiable information to an update check.

Bloggers And Pictures

Apparently someone told bloggers that adding pictures to your posts helps make things easier to read. Unfortunately, what they forgot to mention is that the pictures should actually be part of the message or at least tangentially related. Take for instance this post by Joel Spolsky about UI design and alarm clocks. Scattered through the article are pictures of random buildings, including for some unknown reason one with a sign reading "Cemetery for Soldiers' Dogs". Wouldn't pictures of alarm clocks make more sense? What about a frustrated old woman? A sleep deprived man? All these things would actually relate to the content and perhaps enhance the message the post is trying to make. Buildings however only distract from the actual message – particularly quizzical things like a cemetery for soldiers' dogs.

Of course, Joel isn't the only one, his post is just what pushed me over the edge to blog about it. It doesn't matter how cool you think the shadows or reflections are, if the image isn't related to the actual content it's just wasting bandwidth.

Struts2 Documentation

Where is it? Clearly I'm missing something here. There's a wiki with some good getting started overview stuff and some other chicken scratching but I'm yet to find an actual reference telling me what's actually allowed in struts.xml. Shouldn't that be pointed to in a big neon sign? The struts.xml page on the wiki isn't exactly comprehensive and while the DTD is listed on the examples page it's not exactly commented..

Oh and did I mention that wiki's are a horrible way to write documentation?

Improving The Applet Startup Experience

We've been looking at ways to improve the experience for end users when applets first start up. It's unfortunate that the worst experience with applets is always the first one since that's when the JVM has to start up and the applet has to download. Once all that happens subsequent usage of applets tends to be lightning fast – particularly with the latest JVMs.

Sadly, that awful Java coffee cup graphic just doesn't make users happy while they wait for the applet to download. Equally sadly, there's no good option to get rid of it. You can specify an image of your own to load, but then it replaces the progress bar and it can't be dynamically resized to fit the applet. Heck you can't even center it. Worse yet, by the time the graphic downloads and displays the applet is just about ready so the user winds up seeing an empty box for a while then a brief flash of the image and then the applet's ready.

You can't overlay a DIV on top of the applet because most browsers will render the applet on top regardless and there's no way to show the applet's download progress from a DIV anyway.

The only vaguely plausible option is a light-weight bootstrap applet that displays while the real applet is loading, but that suffers from the same problems as the image in that it takes too long to download and be ready to display – you'd be better off just loading the applet. Plus it breaks LiveConnect functionality because all of a sudden the public methods on your applet are hidden behind the loader applet. You could delegate through but you'd have to do it via reflection or the class loader will demand the main applet be available before if will load your loader class.

Java 1.4 was a little better in that you could have the progress bar showing with your own custom image in the top left hand corner and you could customize the background color of the rest of the applet. Still ugly but at least workable. With Java 1.5 and above the option to display the progress bar is gone, the default animation is distracting and ugly and the Java 6 animation is going to become even worse with the next update.


If It’s Not Documented, It’s Not Done

I was quite interested in a few of the new features listed for WordPress 2.1, since they look like they could be quite useful to build into the plugin I have to use EditLive! as the editor for posts. In particular

  • Image and thumbnail API allows for richer media plugins

sounds very interesting, since I've not gotten around to doing anything much with images and EditLive! has a lot of support for media that is currently going to waste. Sadly, browsing through the WordPress documentation lists nothing about how to actually go about using these wonderful new APIs. In fact, it doesn't mention them at all – it seems the documentation is still for the 2.0 release.

I'm sure there's someone out there that knows where to start looking for these things, and I'm sure I could work it out if I invested enough time, but why should I? Why should I waste my time helping to build plugins for WordPress if the developers, who are running a business based on the product, can't be bothered even writing down some brief details about what the new APIs allow, let alone how to use them.

I hate writing documentation as much as the next developer, but we need to start thinking about our users a little instead of just expecting them to waste their time working it out. In the end it means more users and happier users of our products and thus more money for the developers, whether it be directly via sales or indirectly via advertising, partnerships or whatever way the business' bills are paid.