Why I'm Moving From Desktop Apps to Web Apps(kalzumeus.com)
kalzumeus.com
Why I'm Moving From Desktop Apps to Web Apps
http://www.kalzumeus.com/2009/09/05/desktop-aps-versus-web-apps/
20 comments
The section on "Phone Home vs. Google Analytics" is something I have been pondering for long time. I hack on the Arora browser. Now if I had Arora report back with what actions user use (File/Quit etc) I could answer questions like: Does anyone ever use View/Source or do they all just open the Inspector? But even though people are using a Browser I think they will still complain that it is reporting something back to a server which is exactly what every single webpage they go to does, but somehow it is bad because it is from the desktop app and not the webpage in the desktop app.
> But even though people are using a Browser I think they will still complain that it is reporting something back to a server
Not necessarily. The Office User Experience program has been very successful, and that's exactly what it does. Just open a little windows at the 3rd or 4th startup of the software (not the first) telling the user you'd like to make his experience better blah blah blah and to that end you'd like to collect a bit o' anonymous and non-personally identifying data (you can add a "view more" where you say which bits o' data you collect precisely) and would they be ok with that. And give the user a way to enable/disable it post-facto if they change their mind.
Not necessarily. The Office User Experience program has been very successful, and that's exactly what it does. Just open a little windows at the 3rd or 4th startup of the software (not the first) telling the user you'd like to make his experience better blah blah blah and to that end you'd like to collect a bit o' anonymous and non-personally identifying data (you can add a "view more" where you say which bits o' data you collect precisely) and would they be ok with that. And give the user a way to enable/disable it post-facto if they change their mind.
Yes, I think this is the right way to do it. Users usually aren't opposed to sending developers data to improve the product, so long as they explicitly okay it.
I'd go a little further and have the application collect data and store it locally. When it has enough data, it pops up a dialog asking if the user would consent to sending anonymous data to help improve the software. If they choose to participate, it sends the data it has collected locally at that time and that time only (until the next major upgrade). If they choose not to, it deletes the collected data and never bothers them again.
I'd go a little further and have the application collect data and store it locally. When it has enough data, it pops up a dialog asking if the user would consent to sending anonymous data to help improve the software. If they choose to participate, it sends the data it has collected locally at that time and that time only (until the next major upgrade). If they choose not to, it deletes the collected data and never bothers them again.
No, it is not "bad" because it is from a desktop app, it is bad because desktop apps generally do not tell the user if and when they send information to a remote server.
How about collecting those statistics locally and asking the user every couple of days if he would be okay with sending them to a server, mentioning the reasons for doing so? I think if users had the control over that they wouldn't generally mind doing so.
How about collecting those statistics locally and asking the user every couple of days if he would be okay with sending them to a server, mentioning the reasons for doing so? I think if users had the control over that they wouldn't generally mind doing so.
Mozilla are doing something similar with their Test Pilot project:
http://labs.mozilla.com/blog/2008/03/introducing-test-pilot/
"I think they will still complain"
Why not test your assumptions by trying it on a subset of your users?
Why not test your assumptions by trying it on a subset of your users?
I switched an app I'm working on from a desktop app to a web app after doing a similar analysis.
You also scratched at something that played a huge part in my decision: monthly subscription fees are a lot better (in terms of both recurring revenue and feature bloat) than an upgrade treadmill.
It's great to see empirical evidence (from the same app, no less!) that it makes sense to do so.
You also scratched at something that played a huge part in my decision: monthly subscription fees are a lot better (in terms of both recurring revenue and feature bloat) than an upgrade treadmill.
It's great to see empirical evidence (from the same app, no less!) that it makes sense to do so.
Oh, believe me, my next app will most certainly have a built-in recurring revenue component. I convinced 2,000 people to pay me money -- if a fraction of them were paying me even $5 a month...
Great article! I have been recently wrestling over the decision of whether to write my next application first as an installable version or as a web app. All of my experience, and my gut instinct, is to do the web app first but I just couldn't set that decision in stone, maybe now I can.
I see some assumptions here that need to be challenged.
- Click through six screens that no one in the history of man has ever read.
You don't have to have any screens. This is your fault for using a wizard based installer. The app could just display "loading" while it installs and prepares to start.
- Potentially weeks pass. Find your way back to the shareware site. Check out price.
Why doesn't your app prompt the user to buy the full version and open a url to your payment page?
I agree that desktop software has more opportunities to exit the funnel, but it also has more opportunities for retention and upsell. You can install a desktop shortcut, a system tray icon ...
Andrew Chen recently blogged on this same topic: http://bit.ly/pTJsE
Some more suggestions on how to improve a desktop app:
- Lost registration keys
Don't use registration keys. Sell a machine specific license with free upgrades. Vend the license from the app. Each license will be tied to a machine and can't be used on other machines (use the NIC as a machine id).
- bugs present in old versions of the software that are still floating around download sites
Have your software automatically update itself as soon as it is installed.
- Piracy
It is much harder for to pirate your app if you use machine specific licenses. It is still possible, but doubtful that someone is going to use a hex editor to try to patch your bingo creator app. They might as well exploit your web app, steal your source and put up a free version.
- Analytics
Mixpanel has a REST api. You can use it from your desktop app.
- Split Testing
Why can't you do this on the desktop?
-Long Cycles
IMVU redeployed their desktop app 50 times a day on the way to over 10M in annual revenue (http://bit.ly/CwJN4). They also heavily split tested.
I'm not saying that a desktop app is appropriate for his business. Just that there are more things to consider before writing them off.
- Click through six screens that no one in the history of man has ever read.
You don't have to have any screens. This is your fault for using a wizard based installer. The app could just display "loading" while it installs and prepares to start.
- Potentially weeks pass. Find your way back to the shareware site. Check out price.
Why doesn't your app prompt the user to buy the full version and open a url to your payment page?
I agree that desktop software has more opportunities to exit the funnel, but it also has more opportunities for retention and upsell. You can install a desktop shortcut, a system tray icon ...
Andrew Chen recently blogged on this same topic: http://bit.ly/pTJsE
Some more suggestions on how to improve a desktop app:
- Lost registration keys
Don't use registration keys. Sell a machine specific license with free upgrades. Vend the license from the app. Each license will be tied to a machine and can't be used on other machines (use the NIC as a machine id).
- bugs present in old versions of the software that are still floating around download sites
Have your software automatically update itself as soon as it is installed.
- Piracy
It is much harder for to pirate your app if you use machine specific licenses. It is still possible, but doubtful that someone is going to use a hex editor to try to patch your bingo creator app. They might as well exploit your web app, steal your source and put up a free version.
- Analytics
Mixpanel has a REST api. You can use it from your desktop app.
- Split Testing
Why can't you do this on the desktop?
-Long Cycles
IMVU redeployed their desktop app 50 times a day on the way to over 10M in annual revenue (http://bit.ly/CwJN4). They also heavily split tested.
I'm not saying that a desktop app is appropriate for his business. Just that there are more things to consider before writing them off.
You don't have to have any screens. This is your fault for using a wizard based installer.
I've stripped as many as I'm comfortable stripping -- it is three. Give me a bit of dramatic license -- unless you've installed a piece of OSS recently, in which case six is perhaps excessively nice. ;)
Why doesn't your app prompt the user to buy the full version and open a url to your payment page?
It does. Believe me, I've optimized that interaction to within an inch of my life. Regardless, it is hard to break users of their habits, and one of those habits is "When I want to go somewhere online, I go to Google." (Or, recently, "I type stuff into my search box" which is replacing the URL bar in modern browsers.)
IMVU redeployed their desktop app 50 times a day on the way to over 10M in annual revenue
IMVU has a hybrid desktop/web app. The continuous integration stuff affects the web portion. The desktop portion has a development cycle measured in weeks.
http://timothyfitz.wordpress.com/2009/03/09/cd-for-client-so...
I've stripped as many as I'm comfortable stripping -- it is three. Give me a bit of dramatic license -- unless you've installed a piece of OSS recently, in which case six is perhaps excessively nice. ;)
Why doesn't your app prompt the user to buy the full version and open a url to your payment page?
It does. Believe me, I've optimized that interaction to within an inch of my life. Regardless, it is hard to break users of their habits, and one of those habits is "When I want to go somewhere online, I go to Google." (Or, recently, "I type stuff into my search box" which is replacing the URL bar in modern browsers.)
IMVU redeployed their desktop app 50 times a day on the way to over 10M in annual revenue
IMVU has a hybrid desktop/web app. The continuous integration stuff affects the web portion. The desktop portion has a development cycle measured in weeks.
http://timothyfitz.wordpress.com/2009/03/09/cd-for-client-so...
from the post:
"We ship a pre-release per day"
"Despite the challenges Continuous Deployment for client software is both possible, and has the same return of Continuous Deployment elsewhere: better feedback, faster iteration times and the ability to make a product better, faster."
"We ship a pre-release per day"
"Despite the challenges Continuous Deployment for client software is both possible, and has the same return of Continuous Deployment elsewhere: better feedback, faster iteration times and the ability to make a product better, faster."
You make some good points. On this, though:
Andrew Chen recently blogged on this same topic
...I just read it. He gives tables of numbers and equations that as far as I can tell are completely made up. He also recommends practices that I think are pernicious, including:
His post is intellectually dodgy in exactly the way that a lot of this kind of software is dodgy. Which makes me notice something I never thought of before: web apps feel cleaner. As a user, I control when I go to the website and use the product; there is less opportunity for semi-scrupulous vendors to mess with me.
Andrew Chen recently blogged on this same topic
...I just read it. He gives tables of numbers and equations that as far as I can tell are completely made up. He also recommends practices that I think are pernicious, including:
Install itself on the system tray
Start up automatically when the OS loads
Run nicely in the background to pop up when appropriate
...and many other retention-happy features
His post is intellectually dodgy in exactly the way that a lot of this kind of software is dodgy. Which makes me notice something I never thought of before: web apps feel cleaner. As a user, I control when I go to the website and use the product; there is less opportunity for semi-scrupulous vendors to mess with me.
Agreed 100%. Also, for enterprise/vertical app's that usually seem to be released half cooked, releasing them as web apps gives the developers fewer ways to foul up the user experience.
A lot of programs are effective as web apps, and they should be web apps, but there are a few that cannot be web apps, or function much worse:
* Image Edititing * Video Player * Chat * Downloading/FTP/Torrenzt * Software Developmnent * Music Player
Such things need to start fast and be easily accessible. The web has that problem - it does not start fast, and things tend to get lost among all the tabs and windows.
* Image Edititing * Video Player * Chat * Downloading/FTP/Torrenzt * Software Developmnent * Music Player
Such things need to start fast and be easily accessible. The web has that problem - it does not start fast, and things tend to get lost among all the tabs and windows.
Aren't video players and chat more popular on the web than they are in standalone apps?
Of the apps you listed, only image editing and software development seem like they have a future on the desktop, and software development only qualifies if you don't think there's going to be a sea-change in collaborative development and application deployment which will make people give up their favorite editors.
Of the apps you listed, only image editing and software development seem like they have a future on the desktop, and software development only qualifies if you don't think there's going to be a sea-change in collaborative development and application deployment which will make people give up their favorite editors.
They're more popular when connected to a network, not the Web specifically. I know many more people use Skype for voice and video instead of Google Talk. Many people still download an MSN IM client and used web-based clients only when necessary (like at a school computer or if the desktop client is messed up).
software development only qualifies if you don't think there's going to be a sea-change in collaborative development and application deployment which will make people give up their favorite editors.
A few IDEs are already integrated with collaborative tools, and I'm sure someone could hack up some Emacs Lisp or VIM-script to add collaborative features to them.
The network, the Internet itself, is more important than any particular subset of it such as the Web/HTTP or SMTP.
software development only qualifies if you don't think there's going to be a sea-change in collaborative development and application deployment which will make people give up their favorite editors.
A few IDEs are already integrated with collaborative tools, and I'm sure someone could hack up some Emacs Lisp or VIM-script to add collaborative features to them.
The network, the Internet itself, is more important than any particular subset of it such as the Web/HTTP or SMTP.
I get that you can collaborate outside of a web browser, but it's so much easier to build collaborative tools that run in a browser that I think that's where the action's going to be. Compare SubEthaEdit to every online document editor.
Erm, it's not easier. The level of difficult is roughly the same. You're dealing with the same issues: user interface, network latency, etc.
I wrote my first non-trivial web app a while ago and my first reaction was "wow this is so much easier". Then I started getting into the finer details of actually getting useful performance out of the app with lots of concurrent users and faced all kinds of latency and bandwidth problems, plus problems with javascript behaving differently on different browsers. No longer so much easier.
While web apps seemed easier to start with and got me up and running a lot quicker than if I'd written a desktop app, I soon ran into the feeling that was programming on top of a bunch of different black boxes non of them actually designed to do what I wanted to do with them.
While web apps seemed easier to start with and got me up and running a lot quicker than if I'd written a desktop app, I soon ran into the feeling that was programming on top of a bunch of different black boxes non of them actually designed to do what I wanted to do with them.
You don't need to run in a browser for "collaborative development and application deployment".
All of those, except perhaps for FTP/torrents, exist as web apps. They might not yet be on par with desktop apps, but I think it is obvious that they will be. As for the web not starting fast, going to gmail is faster than opening outlook for me.
http://torrelay.com/
It works fairly well, though a while back (as I recall) they shifted from freemium to pay-based because they couldn't make enough money to operate otherwise (too many people using up limited bandwidth and not giving anything back).
It works fairly well, though a while back (as I recall) they shifted from freemium to pay-based because they couldn't make enough money to operate otherwise (too many people using up limited bandwidth and not giving anything back).
I think for a lot of people now, Chat and Video player are moving to the web, soon after image editing.
I think it will be a while for Video editing, software development etc... but the direction is clear.
And of course, some things have to exist on the device but can be embedded in the web app.
I think it will be a while for Video editing, software development etc... but the direction is clear.
And of course, some things have to exist on the device but can be embedded in the web app.
Image Editing
Given that Adobe is betting the house on flash and the web would now be a good time to start a startup to create next generation Image Editing desktop application? Photoshop seems like the app that the interns are getting assign to maintain while the "cool" devs are off working on some web / flash projects.
Given that Adobe is betting the house on flash and the web would now be a good time to start a startup to create next generation Image Editing desktop application? Photoshop seems like the app that the interns are getting assign to maintain while the "cool" devs are off working on some web / flash projects.
Image Editing still has to run locally, you cannot have a request sent to the server everytime you resize an image or apply a filter. Yes, you can make it download-on-demand, as per flash, but it still needs to launch quickly, have fast and complete access to the local filesystem as well as the web, and this is a bit challenging to the current crop of browsers.
Exactly my point. So Adobe is going to invest their best developers and gobs of money trying to make a web based photoshop. What if I were to form a startup that made a new next-generation Desktop Image Editor based on Qt (cross platform ftw) with the goal of being able to surpass Photoshop.
There is a market of at least 1, me, for a graphics editor that a smart (I understand the nature of graphics files), but non-trained (in photoshop) person can use. I've tried pixelmator a few times, but I have absolutely no idea how to use the damned thing. It looks simple enough. Yesterday, I opened an image and simply wanted to double the width, keeping the gradient "in tact". I couldn't even figure out how to select the area I needed (which was the whole of the image on the canvas).
So how about a "photoshop for programmers"?
So how about a "photoshop for programmers"?
I believe that has already been tried with Splashup
http://splashup.com/.
http://splashup.com/.
Your reply hint that Splashup is a desktop Image Editor that is set to take over Photoshop, but clicking on the link presents me with a POS flash app. Are you trying to say that Splashup already proved that Photoshop will fail to make a web app? It doesn't really matter because Adobe has drunk the Flash cool-aid and will make a Photoshop web app no matter how many have tried before because they will think they can do it better.
What makes you think that Adobe is abandoning Photoshop? Photoshop.com/Photoshop Express shares the branding, but it's an entirely different product targeted at an entirely different market.
Adobe isn't abandoning Photoshop, but reading the financial reports it is pretty easy to figure out where management is steering the boat, devoting time and resources.
there are of course applications like sumopaint.com that are quite good.
But they are a far cry from photohop, illustrator, 3Dmax, aftereffects and so on.
If anyone want's to create a WYSIWYG HTML/CSS editor that would use the browser's HTML as a canvas then I would be interested. Until that day, I am fine with apps like Fireworks for application and web design.
But they are a far cry from photohop, illustrator, 3Dmax, aftereffects and so on.
If anyone want's to create a WYSIWYG HTML/CSS editor that would use the browser's HTML as a canvas then I would be interested. Until that day, I am fine with apps like Fireworks for application and web design.
I've found http://pixlr.com/app/ to start faster that my Corel Paint Shop Pro and be more useful for quick touch ups etc. Only problem for me is the somewhat clunky interaction with my local files.
* Downloading/FTP/Torrenzt
The Transmission web GUI is actually very nice, but I suppose this method assumes a web server on a LAN, which for most people doesn't work
The Transmission web GUI is actually very nice, but I suppose this method assumes a web server on a LAN, which for most people doesn't work
These are all 'commodity' applications that exist on all desktops. It's inevitable that free/open source versions will gradually replace their commercial counterparts, actually this is already happening:
* Image Edititing - GIMP (ok, ok, it still a long road to catch up with Photoshop, but it's already good enough for most users)
* Video Player - VLC & Co
* Chat - Pidgin
* Downloading/FTP/Torrenzt - uTorrent, Deluge, etc
* Software Developmnent - most tools are already free
* Music Player - Banshee, Amarok... event iTunes is free
* Image Edititing - GIMP (ok, ok, it still a long road to catch up with Photoshop, but it's already good enough for most users)
* Video Player - VLC & Co
* Chat - Pidgin
* Downloading/FTP/Torrenzt - uTorrent, Deluge, etc
* Software Developmnent - most tools are already free
* Music Player - Banshee, Amarok... event iTunes is free
Really thoughtful post. I've never seen the debate framed quite this way and I'd imagine a lot of developers will be influenced by it.
Thanks. I didn't see much value in retreading the well-worn "With desktop apps you can use native APIs, but with web apps you can store data in the cloud" technical flamewar again. What really interests me is how the decision affects the 90% of the business that is not source code, so I wrote about that.
I think there should be a disclaimer somewhere in there...
Some problems can't be solved by a web app, or the web app solution will be far worse than the desktop app. There are many such problems, ergo this post applies to a subset of programming problems for which the web is a better model.
Thus, while I enjoyed reading this post, I don't think it says much that we don't already know.
Some problems can't be solved by a web app, or the web app solution will be far worse than the desktop app. There are many such problems, ergo this post applies to a subset of programming problems for which the web is a better model.
Thus, while I enjoyed reading this post, I don't think it says much that we don't already know.
Double the conversion rate says it all. Ease of development, support and upgrades are just gravy, although they free up time to make your product better.
I would add 5a to your funnel, "Is this real or is it a virus?"
Thanks for sharing.
I would add 5a to your funnel, "Is this real or is it a virus?"
Thanks for sharing.
I would add 5a to your funnel, "Is this real or is it a virus?"
Dang, I forgot to mention that. My target customers have been burned by BonzaiGatorCursors Incorporated and they now assume that absolutely anything that goes wrong on their computer is the result of spyware. So if something goes wrong within, say, six months of installing Bingo Card Creator, guess who gets blamed.
Remember the worldwide Google meltdown a few months back? No less than three people accused me of breaking the Internet.
Dang, I forgot to mention that. My target customers have been burned by BonzaiGatorCursors Incorporated and they now assume that absolutely anything that goes wrong on their computer is the result of spyware. So if something goes wrong within, say, six months of installing Bingo Card Creator, guess who gets blamed.
Remember the worldwide Google meltdown a few months back? No less than three people accused me of breaking the Internet.
So it was you, Patrick, who broke the Internet! If only I had known at the time, I could have told my customers.
I like it when someone changes his mind because of reality.
In a way, I find the arguments given here irrelevant. Sure they're persuasive, but not much more persuasive than the opposite arguments. What really matters is the fact that one option is just working better than the other in practice. It takes mental flexibility to try this, and be willing to see the results, when one's preconceptions run the other way.
In a way, I find the arguments given here irrelevant. Sure they're persuasive, but not much more persuasive than the opposite arguments. What really matters is the fact that one option is just working better than the other in practice. It takes mental flexibility to try this, and be willing to see the results, when one's preconceptions run the other way.
Your one-two punch of giving them access to both the web and desktop apps for one price shouldn't be undervalued. Do you have any data on how many users consume both products?
I'm a web app developer, but I still think desktop apps can be compelling to buyers. There's use cases for both. Having access to both versions is perfect - I can use the desktop version when I've got a lot of work to do or don't have online access (e.g. when flying). Similarly, I think Microsoft has it right with their upcoming web based versions of Office. I wouldn't want to do heavy spreadsheet work in a web app (as they exist now), but its perfect for quick tasks.
Thought provoking post, as always. Keep 'em coming!
I'm a web app developer, but I still think desktop apps can be compelling to buyers. There's use cases for both. Having access to both versions is perfect - I can use the desktop version when I've got a lot of work to do or don't have online access (e.g. when flying). Similarly, I think Microsoft has it right with their upcoming web based versions of Office. I wouldn't want to do heavy spreadsheet work in a web app (as they exist now), but its perfect for quick tasks.
Thought provoking post, as always. Keep 'em coming!
Do you have any data on how many users consume both products?
Getting data on who is using the desktop version has always been a challenge for me, since I am reluctant to phone home. My one data point: 30% of people who use the web app buy a CD. I'm not sure if that is because they want to use the desktop app too, because they consider the web app the trial and the desktop app the main event (at least one person has demonstrated that understanding), or if it is because they mistakenly think that the software they are using is somehow on the CD.
Getting data on who is using the desktop version has always been a challenge for me, since I am reluctant to phone home. My one data point: 30% of people who use the web app buy a CD. I'm not sure if that is because they want to use the desktop app too, because they consider the web app the trial and the desktop app the main event (at least one person has demonstrated that understanding), or if it is because they mistakenly think that the software they are using is somehow on the CD.
I think this is a great argument for web apps. It only persuades me to focus on web apps for certain categories of software, though. For things like high-end games and video or audio applications, I think desktop will continue to dominate... at least until the web and desktop meld. At some point I'd love to see the distinction go away. That's probably a long way off, since it would mean Apple and Microsoft and the FOSS world agreeing on a standard. Hmm... this comment gives me lots of ideas...
Some food for thought:
Writing an iphone app as a "desktop app" v.s. writing a iphone web app.
If web apps are so much better why are people making fat apps for the iphone left and right?
Writing an iphone app as a "desktop app" v.s. writing a iphone web app.
If web apps are so much better why are people making fat apps for the iphone left and right?
If web apps are so much better why are people making fat apps for the iphone left and right?
The way iPhone apps are distributed mitigates many of the leaking funnel difficulties with desktop applications. There's exactly one place to buy them, and OH MY GOD would I kill to have one click buying for all my customers.
However, the mindshare iPhone apps have on HN is tremendously disproportionate to their utility for the developer vis a vis other opportunities to sell software for money. I will happily explain why on another day.
The way iPhone apps are distributed mitigates many of the leaking funnel difficulties with desktop applications. There's exactly one place to buy them, and OH MY GOD would I kill to have one click buying for all my customers.
However, the mindshare iPhone apps have on HN is tremendously disproportionate to their utility for the developer vis a vis other opportunities to sell software for money. I will happily explain why on another day.
I eagerly await your analysis.
He listed 17 different ways for a user to not convert to a paid user with a traditional desktop app. The iphone mitigates many of these reasons.
Let's compare his 17 reasons why a consumer wouldn't buy a desktop app to what happens with the iPhone:
With an iPhone app,
1. Go to iTunes and search the app for that 2. Read a little, discover it's what you want 3. Click purchase 4. Enter AppStore password to confirm
At this point, the app is bought.
X. Start your web session on Google, like everyone does these days.
X. Google your pain point.
X. Click on the search result to the shareware site.
4. Read a little, realize they have software that solves your problem.
X. Mentally evaluate whether the software works on your system.
6. Click on the download button.
7. Wait while it downloads.
X. Close your browser.
X. Try to find the file on your hard disk.
X. Execute the installer.
X. Click through six screens that no one in the history of man has ever read.
X. Execute the program.
X. Get dumped at the main screen.
X. Play around, fall in love.
X. Potentially weeks pass.
X. Find your way back to the shareware site. Check out price.
17. Type in your credit card details. Hit Checkout.
With an iPhone app,
1. Go to iTunes and search the app for that 2. Read a little, discover it's what you want 3. Click purchase 4. Enter AppStore password to confirm
At this point, the app is bought.
But for the iPhone/iTunes you will have the following downsides, not in any order:
1. Give up control and predictability of your deployment cycles, and hence can't time and plan marketing effort as well.
2. Be in a closed market which does not allow you any alternative to better discovery of (your) apps.
3. Be in a closed market which provides high visibility for top-X apps. i.e. hits-based, and very low visibility for non-hits apps.
4. Due to (2), your pricing strategy is much constrained. And there is downward pressure applied to pricing due to (3).
5. You can't charge for upgrades (vs. desktop apps). You can charge for "content subscriptions", but the audience aren't trained for it and there is also policies on what you can charge for.
6. Because of (5), you have lose a major incentive for doing upgrades, but because of (3), unless you have a very successful initial launch, you may need to proceed with free upgrades anyhow.
7. No way to provide trial software, although many have adopted free software as an alternative.
8. Can't track analytics for iTunes. Of course you can do it for your own website, but after users click your link to open iTunes, you don't know if they convert.
1. Give up control and predictability of your deployment cycles, and hence can't time and plan marketing effort as well.
2. Be in a closed market which does not allow you any alternative to better discovery of (your) apps.
3. Be in a closed market which provides high visibility for top-X apps. i.e. hits-based, and very low visibility for non-hits apps.
4. Due to (2), your pricing strategy is much constrained. And there is downward pressure applied to pricing due to (3).
5. You can't charge for upgrades (vs. desktop apps). You can charge for "content subscriptions", but the audience aren't trained for it and there is also policies on what you can charge for.
6. Because of (5), you have lose a major incentive for doing upgrades, but because of (3), unless you have a very successful initial launch, you may need to proceed with free upgrades anyhow.
7. No way to provide trial software, although many have adopted free software as an alternative.
8. Can't track analytics for iTunes. Of course you can do it for your own website, but after users click your link to open iTunes, you don't know if they convert.
The author over-simplified his case, it should have been "Windows desktop software vs web apps", not desktop software overall.
Developing iPhone software has a very different set of advantages and disadvantages, as does developing Mac desktop software.
Developing iPhone software has a very different set of advantages and disadvantages, as does developing Mac desktop software.
I'm pretty sure the author does develop Mac desktop software.
This is a very one sided view. One major problem that web apps have over desktop apps is the ambiguity of purpose. If you alt+tab or use exposé and see the window for Word, you know that's a word processor. It's much less defined as a browser window with Google Docs open. Regardless of what the web browser can do, its main purpose is still to browse the web. It's a main reason why I use Pidign/Digsby/Adium over using Meebo (although Meebo is great for checkup on someone else's computer). Different strokes for different folks.
Desktop apps are also not limited within the browser window and in hardware configuration such as 3d acceleration, keyboard shortcuts, mouse clicks (right click on Flash?), etc.
Desktop apps are also not limited within the browser window and in hardware configuration such as 3d acceleration, keyboard shortcuts, mouse clicks (right click on Flash?), etc.
Very well thought out article. It's great insight for guys like me who aren't sure whether they want to focus on desktop apps or web apps in the future (I write client/server at work and web at home).
The part about the shareware funnel reminded me of a scene from Tina Fey's 30 Rock.
Dennis: One word: coffee. One problem: where do you get it?
Liz: Anywhere! You get it anywhere!
Dennis: Wrong! You get it at my coffee vending machine. 38th & 6th in the basement of the K-Mart. You just go downstairs, you get the key from David and BOOM! You plug in the machine and...
Liz: You're done.
Dennis: One word: coffee. One problem: where do you get it?
Liz: Anywhere! You get it anywhere!
Dennis: Wrong! You get it at my coffee vending machine. 38th & 6th in the basement of the K-Mart. You just go downstairs, you get the key from David and BOOM! You plug in the machine and...
Liz: You're done.
You mention the ease of updates as one reason to prefer webapps. I've used Google Chrome and have never noticed an update - it just does it in the background. If you had something like that in place, what other issues would you run into that would make the web app easier to update?
"the number of people who purchased backup CDs and then proceeded to only use the webapp is downright distressing to me"
If the web site goes away (the "you're hit by a bus" problem) then people still have the software. Not so much for a one-person web shop.
That's why I like Adobe Flex/Air , you can write a desktop app
and with minor modification it can be web app.
And hopefully in the near future I would be able to run it on Android/iPhone as well.
Great post!
I don't agree with "You can keep your Google Docs, Excel is superior in almost every way." Google Docs allows concurrent editing on the same doc by multiple users.
One question to ponder: if Web Apps is so great, why everyone is busy building iphone/android application?
I don't agree with "You can keep your Google Docs, Excel is superior in almost every way." Google Docs allows concurrent editing on the same doc by multiple users.
One question to ponder: if Web Apps is so great, why everyone is busy building iphone/android application?
I wish Google Docs was better, but that's exactly one point and one point only where it beats Excel. I can't understand why Google isn't putting more resources into Excel -- if they want to beat Microsoft they need to beat MS Office and Google Spreadsheet isn't cutting it.
How about converting your desktop app to a single-purpose browser that displays the webapp? Steam does this pretty effectively in their UI.
If your application requires 3GHZ of CPU, and 256MB of RAM, it simply won't be economical to host it on the web.
The argument that using 3GHZ is too much? Then why do Intel sell 3GHZ chips...
The argument that using 3GHZ is too much? Then why do Intel sell 3GHZ chips...
Because people are watching videos using the CPU-intensive Flash YouTube player rather than their desktop media player...
Now you have me confused. People are watching videos on the Web, so they need 3GHz chips. Applications which require 3Ghz chips are not economical for use on the web and should be on the desktop. I think there's been some disconnect here, because it seems like a totally nonsensical discussion from my point of view.
Anyway, the definition of a "Web app" can be stretched quite a bit with special plugins. People are apparently satisfied to stick a plugin in the browser and call their desktop application a "Web app." The defining feature of these "Web apps" is that they do not require installation. A native-code plugin can make quite effective use of system resources.
Anyway, the definition of a "Web app" can be stretched quite a bit with special plugins. People are apparently satisfied to stick a plugin in the browser and call their desktop application a "Web app." The defining feature of these "Web apps" is that they do not require installation. A native-code plugin can make quite effective use of system resources.
Why so many words. Modern browser (webkit-based with optimized js runtime and hardware-accelerated rendering) now is what java ought (and failed) to be - portable desktop application platform, but without installation, additional training or special support required.
Almost everyone are familiar with browser - can click on links, hit the back button and have some assumption what they would see on the screen and what to expect.
There are already obvious trends, like an end of desktop mail apps (yahoo and gmail are leaders), desktop chat programs - they were evolved into voice/video communication technologies or replaced by social networks and so on.
Tell me one reason why not take advantage on this situation and remain attached to previous century's "desktop" technology from MS. (sure, special cases, such as heavy 3D games or CAD/Video-editing tools will stay long.)
Almost everyone are familiar with browser - can click on links, hit the back button and have some assumption what they would see on the screen and what to expect.
There are already obvious trends, like an end of desktop mail apps (yahoo and gmail are leaders), desktop chat programs - they were evolved into voice/video communication technologies or replaced by social networks and so on.
Tell me one reason why not take advantage on this situation and remain attached to previous century's "desktop" technology from MS. (sure, special cases, such as heavy 3D games or CAD/Video-editing tools will stay long.)
The mobile industry puts you closest to your customers' wallets, so I think that's the place to be right now if you're in it for the money.
That is less consequential at HN than elsewhere, since most of the community here already is in web apps. However, even if you'll never touch desktop software, you may find the points about AdWords and conversion math worth your while. (They're about halfway down.) The short story is that anything you do to increase your conversion rate has a side effect of increasing your ability to win the AdWords "auction", which means you get additional benefit (increased volume) above and beyond the base increase in conversion.