Fishpool

A topic which I've run tests with before (long time before), apparently has come back with Apple's Safari for Windows release. Jeff Atwood finds Mac OS X fonts wonky - well, they're certainly soft. Apple has never been too keen on strong hinting, perhaps because it messes inter-glyph metrics in favor of contrast. Windows is wonky in its own way - ClearType has good contrast, but letter spacing is sometimes a bit annoying.

Just for kicks, here's what Fedora 7 with FreeType autohinting and subpixel rendering (equivalent of ClearType) looks like. This is just one of the modes, but the one I personally prefer:

Comparing at 200% rendering to Jeff's examples; Safari/Windows, IE7/Windows, and Firefox/Fedora

I guess it's up to everyone's preferences, but I think Fedora wins this one. Spacing isn't perfect here either (in particular "b est" looks a bit ugly), but overall, contrast is excellent and paragraph spacing is very close to what it would be without hinting.

With all the fuss recently about Adobe's Apollo bringing Flash to the desktop, Microsoft's Silverlight bringing .NET to the browser, and Sun's JavaFX bringing scriptable Java to the desktop and mobile devices, I've had to give some thought to the question of what might be the role of these platforms in the future of rich Internet applications, and whether the time might be getting closer for us to reconsider using Director and Shockwave to develop the things we can't develop using AJAX. Lets just say I'm not going to jump on any one of these quite yet.

However, I'd missed one thing Sun apparently is finally working on, that made me rather sceptical of JavaFX's potential - there is a project going on for fixing the consumer usability of Java in a browser environment called Consumer JRE, which might even be released as an update to Java 6. Wow - that'd make me really happy just as a daily user of all kinds of desktop Java applications, let alone that I might actually count Java as a viable option for developing something for consumer deployment. Good luck, guys. I'll be watching you closely.

OpenID is one of the technologies I've been coming across repeatedly in the past year or so, that very much feel like the right kind of response to things that are a constant ache in today's internet. In particular, it's a pain in the butt for a consumer to manage six thousand logins to individual services, and as a result, it's almost as much of a pain for a consumer service (like Habbo) to demand logins; no one really wants to create yet another. I'm pretty convinced that we don't really need to have a database full of passwords, and that we'd be better off without it.

What we need is a way to identify that whoever visited us before and wanted us to call her PrettyGirl87 last week is the same person who wants to be known by this name this week - and we need to know that because our other users might care about a thing like that. We also want to be able to reach the users later, so we'd like to know their email address, or some other means of communication.

Neither of these things actually requires us to ask her to come up with and remember Yet Another Password, if some other means of identifying the user existed. OpenID might be an answer, or at least part of one. So I'm one of many considering whether to support OpenID. I'm also thinking whether we should provide OpenID identity for those users who'd actually like to use Habbo to identify themselves (which would be wonderful for completely different kinds of reasons). But both of those questions really are quite clear: yes, we should. The difficult question is, should we do that instead of something else? Because that's the question that faces anything we might want to implement. And I haven't seen an argument convincing enough to put OpenID on the top of the pile yet. The demand probably isn't going to come from users - but what would be the thing to swing the balance?

Peter Van Dijck has collected a bunch of good presentations about developing scalable websites to his blog. Good stuff there, Cal Henderson in particular is always worth a read. I really should sometime collect some of our own learnings about the topic, in particular regarding how scaling challenges change when you're dealing with lots of interactive users with real-time messaging. It certainly has entirely different bottlenecks compared to a typical web site - but the profile of a typical web site is migrating in that direction, too.