01 June 2007

Online/Offiline Web Apps: Why Does the Browser Matter?

For a few months now we've been seeing more offline web app support. This includes technologies like Apollo, some of the tricks people are using with Firefox (like ), http://www.blogger.com/img/gl.link.gif, and lately .http://www.blogger.com/img/gl.link.gif

What amazes me is how much people want to seem to stay within a web browser. They're trying so hard to cram a feature into a space that wasn't designed for it, not to mention is just a crappy solution. No doubt there are a few nice uses of offline support for a pure browser-based app, but why haven't more people started to realize how much better they can do by going beyond the browser? Why do you want the browsers UI to be your dominant surrounding UI? Why do you want to be constrained to the browser's window, and force your user's to have your app running in another http://www.blogger.com/img/gl.link.gifapp, that doesn't have it's own dock/task bar icon or ability to interact with the OS?

I also don't think it's an all or nothing situation. I value having a browser-based UI available to me, so that when I'm not using one of my computers, I can still view my data. I don't expect the experience to be as good, and it can lack features, but I can get to the data in a pinch. But, I would much rather have dedicated applications for the "web applications" I use a lot. Examples of this would be Backpack, project tracking systems (currently I use Scrumworks, which has a Java desktop client that works with their web app, and Basecamp), music players, weather watchers, GotAPI, Twitter, and many others.

There are some examples popping up. Twitter has Twitterific, and FineTune has their Apollo player. These are both excellent examples of how deficient the browser is for many web applications, and how much better you can do outside the browser.

I admit that Apollo is really what took my thinking on this to the next level. You no longer have the excuse that you don't know native code or native code toolkits and such. Building an Apollo app can be done the same as you'd build a web app, and even gives you the choice of Flex or HTML, or a combination (this gets very powerful). You can even simply pop an existing web app into an HTML view in an Apollo window, and thus have a dedicated application (doesn't give you much more but at least you aren't just a tab in your browser, and can display it on a different virtual desktop or size the window differently than your browser window, etc.).

To make this more positive, this is a call to all web developers to think hard about this. Even if you don't need offline support, or you don't need it right away, think about the user experience and how you might create that much better of an app by not being constrained to a browser. I won't have anything in the next week, but yes, I'll be eating my own dogfood, and having some apps out soon enough (watch this space).

4 comments:

Bill said...

I just got to Ruby on Rails, so missed your presentation on using Apollo and Rails. I read on one of your posts that you were thinking of posting your presentation online. When do you think that might happen and do you have any suggestions for getting started with Apollo and Rails?

Nice to see you have moved to town here (Eugene,OR). I don't know why it seems different to ask you this question when you are in town than if you were in Palo Alto or some other distant city.

John said...

I think you make some good points. What is challenging is that many users expect, prefer and want apps in the browser. I see this with the product I work on (Google Earth). Many users are not interested in firing up an application outside the browser, even if it has superior features and functionality. So you can lose out on a larger user base even if you are creating a better product.

Chris said...

Bill: we're working on getting the presentation online and providing more than the slides. We showed a bunch of code and talked on more than what the slides cover.

To get started with Apollo and Rails, if you don't know either, then you're jumping into two relatively significant/large technologies at once. One good place to start is Peter Armstrong's Flexible Rails electronic book. It's not on Apollo, but it's on Flex with Rails, which is similar (although with Apollo you can also take a more pure HTML/JS approach if you prefer).

The beauty of combining these things is that it's relatively easy, and really, just knowing each technology separately will allow you to combine them with relative ease (using Rails as a backend for Apollo is not that different than other languages).

So, I would start by simply getting up to speed with each technology on its own, and then use things like Peter's book, or the myriad of samples out there to tie them together.

Our presentation will then help in that we talk about some of the tricks you need to employ in some situations with say RESTful API's and so on.

p.s. I just moved to Eugene/Oregon, about two months ago, but am loving it so far.

Chris said...

John: good point. I think it's a mindset change not just for developers, but also for users. But, to do it for user's will be different, it will be showing them why the external app is better, and to do that, we have to build apps that are indeed better than what can run in a browser.

Google Earth is probably a little trickier, because your typical user may not realize that doing the kind of graphics you guys do is hard (or won't yield as good results) in the browser, etc. Other apps will be more obvious because they'll have various integration with the underlying OS, or use non-rectangular windows and transparency, or whatever.

The unfortunate thing is that user's in general don't realize what the constraints of the browser are, and as cooler and cooler web apps arrive, it makes it that much harder to discern what can/can't be done in a browser. Bummer for us I guess :)

Oh, say hi to John Gardiner for me.