I just read Jeff Atwood’s Are Web Interfaces “Good Enough”? post. He explores why web (RIA) versions of desktop applications are “less satisfying” than the desktop versions. He makes some good points and I’d like to build on his post. I see it the other way around: Web versions have less bloat than desktop versions. Let’s state the obvious right up front: I am talking about good desktop and good web applications. You’ll find crappy versions of both.
Desktop applications have a tendency to go overboard with features and gold plating (bloatware) – trying to use every native UI widget/feature possible. They have to, because after the first or second version, the application has likely jumped the shark. The only way to keep people buying it is to upgrade the UI or add wizzy ways of executing commands (which already had a non-wizzy way). Desktop applications are released, deployed and installed less often. Deploying desktop software isn’t cheap.
Web applications have to work with less, which in most cases means the application has to focus on the problem at hand. Strong focus is a good thing. Web applications are cross platform and have a further reach than a desktop application. Web application are easier to upgrade and release.
What we are seeing today is a shift from desktop to web-based applications. For the majority of users (if your reading this, I am not talking about you) the ease and reach of a web-based applications is outweighing the lack of non-value add features. Even Jeff admits that he was able to do everything he needed with the web application. Do normal users have the “fit and finish” issues that developers have?
This trend will continue as browsers begin to enable more value add features, such as rendering, storage, and offline support. The trend is also why technologies like XULRunner and Apollo are interesting: Ways to create web-ish desktop applications.
One of the main problems I have with using web-based applications is that I happen to like the menu bar as a user interface tool, and most web applications don’t have them — or have funky custom interfaces that try to replicate it.
As a Mac user, I want my applications’ menus to be at the top of the screen where they belong. That’s not something that’s really feasible with a web application today (yes, it can be done with XULRunner, etc, but then it’s really a desktop application rather than a web application).
Additionally, I still like my apps to feel like they integrate smoothly into my work environment. That means abiding by the standard interface rules for whatever computer I’m using. Web apps generally don’t do this. It’s a very one-size-fits-most type of environment.
These are areas that I think need to be addressed in order for web applications to truly become mainstream.
I am currently involved in a project here where we are building a multi-tier architecture with a XULRunner based client browser as the user interface. This is something like Mark’s SSB (Site Specific Browser). The middle-tier is based on JSF (Java Server Faces) technology with a custom XUL Render kit responsible for kicking out XUL Markup to be rendered by our custom XULRunner client.
Essentially we are implementing remote XUL. Some of our goals are
* A very fast, responsive UI that feels more like a standard Desktop application than a web application (RIA or otherwise).
* Zero deployment (other than the obvious need to deploy our custom XULRunner client.
* The ability to switch out our UI layer if something better than sliced bread comes along.
* Separation of business logic from UI logic.
* UI implemented without the need to d/l tons of Javascript. i.e. Availability of a good breadth of widgets.
* An easily extended widget set.
* Minimal vendor lock-in.
* Etc.
The list goes on and on but hopefully you get a sense for what we’re trying to achieve. That said, there are still some significant bugs? being tracked against Gecko, XULRunner, Firefox with respect to Remote XUL that may end up being significant blockers for us.
It seems (and hopefully my perception is wrong on this) that any mention of using XUL remotely is met with a deal of resistance and questioning as to why you would want to do something so insecure (chrome access). While security is a valid concern we do have vastly more control over our LAN, WAN, and Intranet than you typically have over the Internet. Thus the ability to select to relax security would be one very nice to have.
I recall some blogging in the past couple of months on Planet Mozilla about the lack of visibility to such projects as our own. I too believe that there are likely a number of companies similarly implementing internal systems based on Mozilla Gecko and XUL as their desktop application framework. What can we do to bring these projects into the limelight? Would this help in shaping the future of XULRunner, WebRunner, SSB, RIA or ?
I’m in a similar situation to Tom – trying to implement some (mostly intranet-based) software using remote XUL. For me, XUL has two big problems:
1) The learning curve is a little bumpy:
Too many tutorials start off with manifest files and other things for local deployment, but luckily I can ignore much of that for remote XUL. Then you get to the UI part of the tutorial – nice and easy, and anyone can implement a basic UI mock-up quite easily. Then you suddenly find yourself on a steep part of the curve, up to your neck in RDF and XPCOM, drowning in confusion. All the time you saved with the rapid UI mock-up is now lost many times over as you try to do something more complex. I’ve lost count of the amount of time I’ve wasted on things that turn out to be impossible using remote XUL – which brings me onto the second point.
2) Remote XUL is a second-class citizen
There’s no clear documentation as to exactly what you can and can’t do with remote XUL – you just have to try it and see. As a deployment method it has a heck of a lot going for it – all of the advantages of a web-based application, with the speed and style of a desktop app. Yet for some reason it’s relegated to soemthing that you can do in theory, but which can be a real pain in practice.
I accept that there have to be some limitations in remote XUL – especially where it’s deployed on the web. But a better solution for lowering those restrictions on an intranet would be good, and at the very least a clear listing of what is and isn’t possible would make developing with remote XUL a whole lot easier.
Cool! Thats what I find the most interesting about technologies like XULRunner and Apollo as well, all the good things about web apps like:
– Relatively familiar quick development technologies (ECMAScript, Mark-up languages)
– *Potentially* easy deployment and updating of apps
– Integrating with the internet
Without the negatives:
– Inability to work offline
– Stuck inside the browser chrome
– Need to cater to every browser quirk under the sun
Unfortunately the easy deployment and updating possibilites seem to be kind of dashed to the ground with XULRunner. The original idea that is definitely floating around about Firefox 3 being a delivery vehicle for XULRunner is apparently tossed out the window.
In addition to the P3 priority, Brendan Eich mentions in the comment thread over on webstandards.org regarding that plan:
“We anticipate versionitis and under-use of any standard XULRunner shipped under Firefox 3. I’m not sure where that plan sits, but to me it looks like a malinvestment.”
(http://www.webstandards.org/2007/03/12/which-is-better-for-the-web-single-vendor-homogeneity-or-ossweb-20-style-innovation/)
XULRunner apps could be viewed as Firefox Add-Ons (Extensions) on steroids (Super Extensions). So really has the community seen versionitis or underuse with Firefox extensions? Quite the opposite.
And I think not being able to share a distributed runtime is a handicap. Take your XUL Explorer app for example. The Mac app bundle for that sucker is 48.8 MB! But your application code is only like 432 KB! (Talk about less bloat!)
So add together:
– Rolling your own distribution scheme
– Rolling your own installation scheme
– Rolling your own updating scheme
– XULRunner modifications to slim down the runtime to a size that you don’t mind duping for every app you create.
Sure, Joost and Songbird are doing these things, but they aren’t trivial for indie, single, web developers to tackle all on their own.
So if this webish-desktop idea is to take off, I find myself more and more leaning towards something like Apollo for a lot of stuff.
Maybe it will go something like this:
1. If you can get away doing it in Apollo, do so.
2. If you need some advance stuff not available in Apollo, graduate to XULRunner, but be prepared to consider the whole investment.
Hi Mark,
Nice meeting you today.
Avi and I are organizing a little mashup-enabler meetup to be held three weeks from now, as part of Web2Open:
http://upcoming.org/event/168803/
We figure it’d be great to bring together a small number of folks who are in a good place to push forward mashup-enabling technologies, and just share some stories, challenges, and other visions of some recombinant, programmatic web.
Join us, please, if you have the time!
~L