Why I'm Moving From Desktop Apps to Web Apps
kalzumeus.com
kalzumeus.com
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.
Why not test your assumptions by trying it on a subset of your users?
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.
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.
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.
http://labs.mozilla.com/blog/2008/03/introducing-test-pilot/
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.
- 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.
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...
"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."
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.
* 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.
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.
So how about a "photoshop for programmers"?
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.
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
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).
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.
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.
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.
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 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
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.
I would add 5a to your funnel, "Is this real or is it a virus?"
Thanks for sharing.
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.
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.
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!
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.
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?
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.
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.
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.
Developing iPhone software has a very different set of advantages and disadvantages, as does developing Mac desktop software.
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.
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.
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?
The argument that using 3GHZ is too much? Then why do Intel sell 3GHZ chips...
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.
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.)