Tim Bray’s second, very short notice, prediction for 2008 is that Windows is going to “look bad”. It’s probably a good prediction – Vista simply didn’t do enough to make Windows competitive for the next 3 years or so they’ll take to get the next release out. Obviously Windows isn’t going to disappear but there is already a strong trend towards alternate platforms, mostly OS X, which is very likely to increase over the next 12 months.

Michael Krigsman sticks it to Nick Carr and includes an interesting assertion: that how good software is can be decided by how much revenue it drives: Nick, please let the market decide whether enterprise software is “good” or not. There’s a simple metric for measuring this: it’s called revenue. Just for kicks, compare the revenue of enterprise companies, such SAP or Oracle, to consumer-oriented firms such as Twitter (click to follow me).

The conversation around enterprise software goes on, with a couple of good responses to my last post that I want to highlight. Firstly, ddoctor (aka Dylan Just who recently started working here at Ephox) in the comments: I’m thinking of making this one of my career goals – making enterprise software not suck. Then you’re very much in the right place – that’s what we do…. He goes on to give some very good advice on designing good UIs, but it misses a key point that I was trying to make in my last post:

I original skipped over Robert Scoble’s post, Why Enterprise Software Isn’t Sexy, it just seemed too obvious to be worth reading in much detail. I’ve been working on software that sells to enterprise customers for the past 6 years or so and no one cares about it, but release a poor version of that software for the consumer space and everyone goes ga-ga over it. EditLive! and eWebEdit Pro have been bringing WYSIWYG editing to the browser for years and no one cared because they were sold to the enterprise, but when Google put out Google Docs everyone went crazy about it, even though it has half the functionality and twice the bugs.

A huge amount of the items that flow through my news reader come from Robert Scoble’s shared items feed. Most I skip, but there’s enough good stuff in there that makes it well worth reading. It keeps me abreast of a much wider range of topics than I would normally read. The trouble is, Robert doesn’t seem to have as low a tolerance level for crap in feeds that I do.

Technology is a funny thing – we spend so much time and effort trying to make things as simple and efficient as possible for our users that we sometimes lose track of the big picture and wind up making things worse. This is particularly a problem when developing components for other’s to intgrate, rather than a product that ships directly to end users. When another developer is between you and the end user a few fairly unique dynamics come into play:

I’ve been keeping an eye on OpenSocial since it’s initial annoucement with some interest but also a healthy dose of skepticism. I’m still wondering why anyone would want to support open social. It doesn’t give you any integration between systems – all it provides is potential access to the OpenSocial widgets that 3rd party developers make. Now, if we look at the 3rd party widgets from FaceBook you’d be doing your users a great favor by not supporting OpenSocial.

Maybe I’m just a spoil sport but I think project code names are the most ridiculous concept. I’ve never seen a code name help clarify things – they only ever cause confusion. Compare: Hey Joe, how’s the schedule looking for futzbist? with: Hey Joe, how’s the schedule looking for the next EditLive! release? The argument is of course that everyone gets to know the project code name so it’s a nice shorthand for the project – but for how long do they remember them?

Is it just me (quite possible) or is the standard JSON validator for JavaScript unable to handle quotes (") in strings? Specifically, shouldn’t the JSON below be considered valid? {“name”:"""} It throws a parseJSON error when run through the validator but executes perfectly as JavaScript and seems to match the specification for strings in JSON. It’s frustrating because even though the data is coming straight from the server so it’s as trustworthy as it can get, I still think it’s incredibly poor form to execute data without first validating it.

With all the complaining about Apple not having shipped JDK 6 with Leopard it’s nice that someone has actually stopped whining and started coding. So kudos to Landon Fuller for actually doing something useful. Of course, he hasn’t really gotten anywhere because porting Java is an awful lot of work, but if nothing else he’ll understand why it takes Apple so long. It also means we can start the timer to see if the open source model can actually bring Java 6 to OS X faster than Apple can.

For those who both use EditLive! and were very quick to upgrade to Leopard, you might want to grab the latest early access build of EditLive! With old builds on Tiger, our toolbar didn’t respond well to the darker background color: (Click for full size version) Fortunately, Apple introduced some new rendering styles for buttons with Leopard that we could leverage to get a much nicer, much more OS X look:

The rumors of Java 5 being horribly broken beyond all usability on Leopard are, quite frankly, bullshit. It’s faster, has better integration with the OS, the Aqua L&F is significantly improved, it has full support for 64 bit and a huge raft of bug fixes and miscellaneous improvements. Everyone’s pointing to an uninformed rant on JavaLobby which as it’s key example actually highlights a major improvement to the Aqua L&F – the JOptionPane icons should use the application icon, not some obscure artwork that’s not used anywhere else in the system.