As you may have guessed, I didn't know much about Oddpost until recently. But since they're now part of the collective, I had the opportunity to meet with a few of the Oddpost folks on Friday.
Aside from the getting an idea of how all their server-side stuff works (it's a classic example of "do the simplest thing that could possibly work" and I love that aspect of it), which was the real point of the meeting, I got to actually see the product first hand. And I left the meeting in amazement at what they were able to do using only a web browser and a lot of fancy DHTML wizardry. I mean, this thing looked and mostly acted like a real, native desktop application.
Really. A few times I caught myself thinking it was a "fat" client, only to look at the title bar and realize it was an IE window. But other than that, it was hard to tell at time. It's really that good.
The only downside to this I can see is that as the gap between "desktop" and "web based" applications closes, users won't understand the difference. The Oddpost client, for example, feels like a fancy mail and RSS application. But take it offline (such as cross-country flight) and suddenly it does a lot less that one might expect. Knowing that it's a web-based system with most of the data stored on the server, this comes as no shock to most anyone reading this. But to average folks like my Mom, well... that's probably a whole different story.
This makes me wonder how we're going to bridge the gap or if that gap will become irrelevant as the odds of having an Internet connection in any random location continue to increase.
Posted by jzawodn at July 17, 2004 09:23 PM
It’s already happening. I do some small IT work for a farm equipment dealership. They deal with several different vendors for parts and equipment. Many of the parts books for the implements they sell now use a web interface as opposed to being sent quarterly on CD. The parts guys can't understand why it takes so much longer to look up parts when their broadband is down. Who knew dial up was slower?
Too bad Oddpost is IE only. I have wondered how Yahoo! plans to handle this, given their history of supporting the lowest common denominator when it comes to browsers and access speeds.
Too bad Oddpost is IE only.
I'm not very familiar with Oddpost, but based on Jeremy's description, it certainly sounded like an IE-only app. It sure would be nice to see something like this built in a way that would work on both IE and Firefox.
it's already happening with email at my company:
We use a netscape IMAP mail server combined with Outlook on the PC. My employees, who haven't been trained to use Outlook at my company don't realize that unless they actually download their mail to their local machine, they won't have a copy of it when they're not on the network... Thus, when they're sitting in front of a client and want to 'find an old email' they never can... which makes them look 'not-so-smart' about the internet in front of a potential client...
At least if they were looking at something in IE, they're know that they had to be online to look at it in front of a client...
I agree that there is a trend to the intelligent network, moving data from local to the net.
And it makes sense. Hybrids with enough horse power to high-end gaming, and yet with access to - and fully integrated into - the super computer called evernet. That's my dream.
But I really don't think it starts with DHTML stuff that runs on only one OS even.
With regard to Oddpost being IE-only, one of the co-founders answered this question in an interview:
http://www.unraveled.com/archives/2003/07/an_interview_with_ethan_diamond
It seems to come down to the resources that a tight-with-money start-up has: IE's near dominance makes it feasible to only support it in a version 1.0 product. Later, when the money starts flowing in, they can go after the other 5% of the market (though I'm guessing that Oddpost's more tech-savvy audience has a higher proportion of non-IE users than the general browsing public).
Presumably, if Oddpost's architecture is similar to Gmail's (XmlHttpRequest to fetch small snippets data from the server combined with JavaScript DOM manipulations) then there are no fundamental reasons why it shouldn't work in Mozilla, Safari or Opera. Now that they have access to Yahoo's resources, it should only be a matter of time.
As for supporting off-line modes in web apps, this won't really be feasible until there's better ways of storing data on client (cookies, with their 4K maximum size, don't quite cut it).
Jeremy,
Good point about no offline access, however, it could be done....create a local cache that the thin client could read from when it cant read the server. make it store copies of the last 20 emails locally, with constant updates while connected.
As far as connectivity, heck even planes are getting internet access:
http://www.jamesmcmurry.com/archives/000070.html
jm
Adam Bosworth of BEA had some interesting posts on the topic of accessing web apps offline awhile ago...
I think the connected / disconnected issue could be addressed pretty well with desktop web server / proxies that provide a local cache / snapshot of the "live" web application / data. (Maybe Y! could stick this in its toolbar app, even.)
I think this has some similarities to occasionally connected network-deskop apps (e.g., client/server) that use local databases on the client-side, but sync them with server-side databases at the end of the day.
Palm's HotSync seems like another example of this kind of issue--with good UIs and good sync-ing, people seem pretty comfortable with migrating between disconnected and connected.
Ethan Diamond demo'd Oddpost running on Firefox at last Tuesday's BayCHI.
"This makes me wonder how we're going to bridge the gap or if that gap will become irrelevant as the odds of having an Internet connection in any random location continue to increase"
That's exactly what I've been keeping my mind on recently.
I suppose, it's a question of time. Though the gap is going to exist as long as it is not a global concern.
