Since I talk so much about browser applications versus desktop applications, I thought it would be a good idea to blog about some thoughts I have regarding when to choose one delivery mechanism or the other. In a lot of ways, it isn’t even a matter of richness anymore. Most people associate “browser apps” with Ajax, but technologies like Flex and “WPF/E“, as well as XAML Browser Applications (XBAPs) all run in the browser and bring the richness of the desktop. So if it isn’t about richness, what is it about? I don’t think this is the final answer, but hopefully it spurs a conversation, and I’m hoping to cover this a bit in my panel at the Web 2.0 Expo.
5 Reasons to Deploy Applications in the Browser
- You need the barrier of entry to be low. Browsers are convenient, you browse to an address, and the application is right at your fingertips. When you want users to try something out, or get started quickly, a browser application is the way to go.
- You need a central place for deployment. With the browser model, you can store the application in one place, and when you update it, it’s updated everywhere. That’s convenient, and easy for users and administrators alike.
- You absolutely have to be cross platform. Adobe Apollo will probably make this obsolete down the road, but for right now, if you have to have a cross platform application, the browser is the way to go. There are browsers for devices, all major operating systems, and televisions. They may not all work the same, but they are cross platform.
- You want to take advantage of people’s “browser knowledge”. It’s safe to say that almost everyone knows how to use a browser. In some cases, building an application that takes advantage of that knowledge is good. Having back and forward buttons, having a URL to access, all of those are things people understand, and can be programmed to take advantage of.
- You know you won’t have access to machines. In some environments, users are restricted from downloading things on their machines, or you could need to access an application on a computer that isn’t yours. In that case, the browser is the way to go. It doesn’t leave (much) of a footprint, and you don’t have to worry about what privileges you have on the computer.
5 Reasons to Deploy Applications on the Desktop
- You want your application to be front and center for your users. Browsers crash, often times users have multiple tabs open and there’s a lot of clutter in the browser. When your application has to be accessible outside of that, a desktop application is the way to go.
- You want to take advantage of system resources. For raw power, nothing beats the full capabilities of the desktop. Hardware acceleration or anything taxing on the computer can be handled better by applications specifically programmed to take advantage of those. In the browser, you’re mostly stuck with that memory manager; outside you have more room.
- You’re building a “widget” application. Widgets are becoming bigger and bigger (in terms of capability) and you just can’t run a widget platform inside the browser. Widgets need to be accessible from the desktop where they can take up a small space and be easily moved around. The browser restricts that too much.
- You need to integrate closely with the desktop. This may sound like a no brainer, but if you want your application to feel like a desktop app to your users, that’s how it should be deployed. Do they need to be able to drag files to it from the desktop? Save things locally? See it in the add/remove programs area? Have a shortcut and icon in the Applications directory? If those are important to your brand or if having that functionality is important, the desktop is the way to go.
- You need a consistent user interface and/or brand. Deploying applications in the browser requires you work inside their interface. Oftentimes that means you have a two interfaces running side by side. You may also have to worry about things like toolbars or other browser addons that affect how your application looks and how your users interact with it. By deploying desktop applications, you have full control over the interface and brand. You can make sure your users see only what you want them to see.
There are two big omissions I wanted to note, security and offline access. For me, security was a bit of a toss up. On one hand, with desktop apps, your data is on your hard drive, so you know where it is. But that also leaves it open to spyware and viruses. I think storing data online is a bit more secure, even though someone else can potentially see your data. Offline access has gotten a lot of buzz lately, but it’s not just a desktop-only technology anymore. Companies like Dekoh, Zimbra, and Scrybe have found ways to take browser applications offline. It’s a very difficult thing to program, but they’ve done it, so I left offline access off the list.
So what did I miss? Are there things here that don’t belong? Any glaring omissions? Let me know.
Quoted from: zdnet.com