On web interfaces…

Stu doesn’t like Oddpost. My knee-jerk reaction is to tell him to harden up and get with the dhtml cluetrain. Then I thought about it for a bit. The whole Oddpost-Yahoo-GMail thing has me thinking about the future of webmail in general. Then Stu brings up the issue of a “well behaved webmail service”, including things like proper IMAP behaviour.

On top of this, there have been discussions recently on the future of Internet Explorer, and also HTML4. People like Joel Spolsky are calling for more dhtml and api options so he can write more app-like web interfaces. The issue I have is that the current web-page/web-form idiom has become so engrained in user society that I wonder if it wouldn’t be better to embrace and extend this idiom, rather than throw it away in favour of dhtml/javascript.

Let me explain this using Oddpost (and equally GMail) versus Fastmail. For now lets ignore any non-interface features like RSS integration (Oddpost) or conversation threading (GMail).
Using Oddpost feels just like using a desktop app. The upside of this is that you have all the windows idioms available to you – drag-n-drop, keyboard shortcuts, right-click context menus etc. This is so much the case that one also expects desktop app-like performance and availability, which is where the illusion breaks down. When there is an outage, Oddpost at best displays an error, and at worst simply doesn’t load or displays some cryptic html. Fastmail on the other hand looks and feels like a web page. Yes there is dynamic data on the page, but the user is under no illusion that they have entered some sort of transient desktop application fairyland. Thus when there is a delay loading a page, or the user receives a 404 or 500 error, there are no real surprises.

So my thought is: use dhtml and javascript to enhance a web form. Don’t go overboard and rebuild an interface entirely in javascript – there are better alternatives like Java applets, (cough)ActiveX or (cough).Net.

So it is with a bit of surprise that I found myself liking Fastmail’s interface. I guess I convinced myself that Oddpost was the shit, without really thinking about why.

So then we get onto non-interface issues:

Point one is Oddpost’s broken IMAP implementation. This is just not good enough. I can understand their IE-only interface decision, but a non-standards-compliant IMAP implementation is not cool. I trust Stu’s call on this, because he’s recently written an IMAP stack for Snappermail.

GMail doesn’t even have an IMAP interface to test.

Oddpost’s RSS integration is cool, but I stopped using it soon after I started reading more than 3 or 4 RSS feeds. It was simply too slow to retrieve more RSS feeds than this. Bloglines is my aggregator of choice.

I’ll still be very interested to see what comes from the Yahoo-Oddpost buyout, and am pleased that as an Oddpost user I’ll likely get a bit of an early peek at any enhancements, but don’t be surprised if something like fastmail becomes my email interface of preference.

Share this:

Related

4 Replies to “On web interfaces…”

Different design stand-points I guess. I’m of the Fastmail school myself (could you tell?). If it’s a web-interface it shouldn’t try to hide normal web-browser functionality imho.

And as for web-mail services that have broken IMAP interfaces don’t get me started. I don’t think there’s an IMAP server on the planet that actually completely adheres to RFC 3501. For god’s sake some of them don’t even support SEARCH which is a mandatory function!