Tag Archives: desktop

Is desktop software dead?

desktop vs webIt’s rare that I chat to other software developers without someone asking me when I am going to do a web version of my seating planner software. Because the market for desktop is dead, right? SAAS apps is where all the action is!

I think the web is a great platform for some products, not so much for others. Let’s look at the advantages of web apps over desktop apps.

Web advantage 1: No installation

You can access a web app from any device that has a browser. No need to install. There is no doubt this is a major convenience. However most desktop utilities can be downloaded and installed in 1-2 minutes with a decent broadband connection. Also you don’t have to keep logging in to most desktop apps, once they are installed.

Web advantage 2: No upgrades

End-users are always using the latest version. This is definitely an advantage for technical support. But it does take away some choice from the user. Perhaps they weren’t ready to upgrade or preferred the old version?

Web advantage 3: Better user insights

You can analyse how users are using your software. This allows you to improve usability and send out tailored lifecycle emails. It is possible to gather similar information for desktop software, but it involves a lot of extra work.

Web advantage 4: Distributed architecture

If you are writing web apps, you get a distributed architecture for free. No need to do socket programming.

Web advantage 5: Less piracy

Cracks and keygens are a fact of life for desktop software vendors. It is easier to protect against piracy with a web app.

Web advantage 6: Cross platform

In theory web apps are cross-platform. Write them once and they can run on any device with a browser. But browser compatibility issues mean it isn’t that easy in practice, especially if you are still forced to support the dreaded IE6. Also there are solutions (such as Qt) that allow you to deploy to multiple desktop devices from a single code base.

Web advantage 7: Subscriptions

Web apps lend themselves to subscription based payment. This is great because you get a more predictable monthly income and potentially get more money from each customer over the lifetime of the product.

So what about the advantages of desktop apps over web apps?

Desktop advantage 1: Responsiveness

Native apps are more responsive than web apps, partly due to lower level access to the machine and partly due to not having to talk to a remote server. However this advantage is eroding as bandwidth and JavaScript performance improves and more work is carried out by the client in web apps (e.g. using Ajax).

Desktop advantage 2: Reduced hosting costs

The costs of hosting a website for a desktop app is minimal. Typically you just need to serve a few pages and a download file to each visitor. They then won’t need to come back until there is an upgrade. But hosting costs can be significant for a web app, particularly if the app requires large amounts of bandwidth or compute power.

Desktop advantage 3: Better access to hardware

Desktop apps can make better use of the hardware available. For example, you can generally do printing a lot better from a desktop app.

Desktop advantage 4: Better development tools

The old joke is that JavaScript is to Java as the Taj Mahal curry restaurant is to the Taj Mahal. As a C++ developer I am used to working with a fully fledged IDE, debugger, profiler, static analyser and runtime coverage analyser. I tried some JavaScript development recently. Ugh. The development tools seemed very primitive and  JavaScript is a language so hideous that surely even it’s mother couldn’t love it. No classes, no strong typing, no templates and broken scoping. However frameworks such as jQuery have made JavaScript much more accessible over recent years.

Desktop advantage 5: Psychological

Many people feel that anything web-based should be free. Psychologically customers seem more ready to pay for desktop software. Perhaps they feel a greater sense of ownership. This perception is gradually changing for B2B, but I think it is still prevalent for B2C.

Desktop advantage 6: Privacy

Many customers don’t feel confident storing important and confidential information on third-party servers.

Desktop advantage 7: Availability

You can’t use a web app unless the server is up and you have an Internet connection. A desktop app installed on your local machine is always available. You can continue to use it, even if the vendor goes out of business.

Desktop advantage 8: Up-front payment

Desktop apps lend themselves to a single, up-front payment. This is great because you get all the money straight away, improving your cash flow.

So I have come up with similar number of advantages for web apps and for desktop apps. Which is better? It depends, of course. For my particular application, I think a desktop app still has significant advantages:

  • My software can render and zoom in and out of large floor plans better than my web based competitors.
  • I use a genetic algorithm to assign guests to seats. It makes more sense to use under-utilised desktop CPUs for this, rather than me having to pay for a beefy compute server. The thought of writing a genetic algorithm in JavaScript is too awful to contemplate (although Atwood’s law dictates that someone will, if they haven’t already).
  • I can do printing better than my web-based competitors.
  • Most of my web-based competitors seem very feature-poor. I am sure that is at least partly due to poor tooling for web development compared to desktop development.
  • Most of my web-based competitors give their product away for free in the hope of making some money back on ads. I charge for mine.
  • Seating plans can contain sensitive information, particularly for events with celebrities, royalty and heads of state. Some of my customers don’t want this information transmitted to and stored on third-party servers.
  • If my server goes down then I lose sales. But my customers can continue to use my software. Imagine if they were dependent on my server and it went down (or I went out of business) the day before their big event. It brings me out in a cold sweat to think about it.

But other products are a better fit for the web. If I was writing a collaborative CRUD app, I would almost certainly do it as a web app. I have recently been working on a couple of new products. One is a web app and the other is a desktop app. Horses for courses.

A lot of the money I have spent on software over the last few years has been for desktop software. When I had to choose bookkeeping software, I chose a desktop package because I didn’t want to:

  • pay every month
  • store sensitive financial information on a third-party server
  • risk losing all my data if the vendor went out of business

If I look through the list of useful tools and services on this site I see that 51 of them are web-based and 35 are desktop based. Peldi of Balsamiq reported in 2009 that 77% of their revenue comes from the desktop versions of their software. I asked him if that had changed much and he was kind enough to send me the following graph (myBalsamiq is the web version). You can see that it is still nearly 70% 4 years later.

desktop vs web

The line between desktop and web apps is also becoming more blurred. Many desktop apps now use web protocols and embed web browsers. For example, the Qt toolkit allows you to easily create applications that are hybrids of desktop and web. It is also possible to sell a web app that companies host on their own servers. This adds some of the advantages and disadvantages of a desktop app compared to a web app installed on the vendor’s server (SAAS). Perhaps desktop and web apps will converge to the point where there the whole desktop vs web debate becomes meaningless.

So I think reports of the death of desktop software have been greatly exaggerated. There is no doubt that long-term trends ( e.g. increasing bandwidth and attitude to paying for web apps, for B2B at least) have been changing the balance in favour of web apps for some types of product. Particular those where collaboration is more important than graphics or computer power. But I think there will continue to be plenty of markets where a desktop app is a better choice than a web app for the foreseeable future. In the final analysis, customers care a lot more about how well your software solves their problem, than how it happens to be deployed (if they even understand the difference).

Boostrapped.fm podcast

I was a guest on episode 21 of Bootstrapped.fm, the podcast of Andrey Butov and Ian Landsman. The discussion was very wide-ranging, touching on SAAS vs web, the Qt development environment, the royal wedding, A/B testing, capoeira, Adwords, the history of shareware, my new training course and lots more besides. I really enjoyed it. Boostrapped.fm also has a thriving discussion forum at discuss.bootstrapped.fm.

Free computer wallpaper

I got bored of looking at the standard Windows and Mac desktop wallpaper, so I decided to re-purpose some of the photographs I have taken on my travels. I have created standard and widescreen versions. They should be high enough resolution even for most developers’ monitors. Happy Christmas.

Licensing

You can freely use these images as wallpaper on your computer. However they may not be modified, used for any other purpose or distributed (except via http://www.successfulsoftware.net) without my explicit written permission. I retain the copyright and all other rights to these images.

Instructions

Left click on a thumbnail of the appropriate size/aspect-ratio for your monitor.

Right click on the full-size image and select:

  • FireFox: Set as desktop background
  • Internet Explorer: Set as background
  • Safari: Use image as desktop picture

1920 x 1200 wallpaper

These images are suitable for wide screen monitors (aspect ratio 8:5) including:

  • 1920 x 1200
  • 1680 x 1050
  • 1440 x 900
  • 1280 x 800

Stirling Falls, New Zealand.

Window reflection.

Peak 43, Nepal.

Palm, Queensland, Australia.

Lenticular clouds near Mount Sefton, New Zealand.

Kalahari sand at sunset, Namibia.

Heron Island, Queensland, Australia.

Waves, Hawaii.

A MiG-29 Fulcrum performing the 'cobra' manoeuvre.

Dead Vlei, Namibia.

Dead Vlei, Namibia.

Boyd Falls, New Zealand.

Great Barrier Reef, Queensland, Australia.

Great Barrier Reef, Queensland, Australia.

Aquarium, Plymouth, UK.

1600 x 1200 wallpaper

These images are suitable for standard monitors (aspect ratio 4:3) including:

  • 1600 x 1200
  • 1152 x 864
  • 1024 x 768
  • 800 x 600

Stirling Falls, New Zealand.

Window reflection.

Peak 43, Nepal.

Palm, Queensland, Australia.

Lenticular clouds near Mount Sefton, New Zealand.

Kalahari sand at sunset, Namibia

An MiG-29 Fulcrum performing the 'cobra' manoeuvre.

Boyd Falls, New Zealand.

Great Barrier Reef, Queensland, Australia.

Aquarium, Plymouth, UK.

Notes

Creating wallpaper wasn’t as easy as I thought (nothing ever is). You need images that are in landscape format, are not too saturated, contrasty or busy and are cropped and resized to exactly the right width and height. Thankfully I had some tools to help – I used PicCrop to do the cropping, BatchPhoto for batch creation of the thumbnail images, Xplorer2 for batch file renaming and Photoshop Elements for everything else. Some of the images are only available in wide screen format as they didn’t work as well in a 4:3 format.

All the photographs were taken by me with a Minolta Dynax 7D digital camera or scanned from slides taken by me with a Minolta Dynax 700si. Goodbye Minolta cameras, I miss you.

Choosing a development ‘stack’ for Windows desktop applications

beauty_parade.jpgI have have heard plenty of people saying that desktop software is dead and that all future development will be done for the web. From my perspective, as both a buyer and seller of software, I think they are wrong. In fact, of the thousands of pounds I have spent on software in the last three years, I would guess that well over 90% of it was spent on software that runs outside the browser. The capabilities of web based applications have improved a lot in recent years, but they still have a long way to go to match a custom built native application once you move beyond CRUD applications. I don’t expect to be running Visual Studio, PhotoShop or VMWare (amongst others) inside the browser any time soon. The only way I see web apps approaching the flexibility and performance of desktop apps is for the browser to become as complicated as an OS, negating the key reason for having a browser in the first place. To me it seems more likely that desktop apps will embed a browser and use more and more web protocols, resulting in hybrid native+web apps that offer the best of both worlds.

So, if Windows desktop apps aren’t going away any time soon, what language/libraries/tools should we use to develop them? It is clear that Microsoft would like us to use a .Net development environment, such as C#. But I question the wisdom of anyone selling downloadable off-the-shelf software based on .Net [1]. The penetration of .Net is less than impressive, especially for the more recent versions. From stats published by SteG on a recent BOS post (only IE users counted):

No .Net: 28.12%
>= .Net 1.0: 71.88%
>= .Net 1.1: 69.29%
>= .Net 2.0: 46.07%
>= .Net 3.0: 18.66%
>= .Net 3.5: 0.99%

Consequently deploying your app may require a framework update. The new .Net 3.5 framework comes with a 2.7 MB installer, but this is only a stub that downloads the frameworks required. The full set of frameworks weighs in at eye watering 197 MB. To find out how much the stub really downloads Giorgio installed .Net 3.5 onto a Windows 2003 VM with only .Net 1.0 & 1.1. The result: 67 MB. That is still a large download for most people, especially if your .Net 3.5 software is only a small utility. It is out of the question if you don’t have broadband. Microsoft no doubt justify this by saying that the majority of PCs will have .Net 3.5 pre-installed by the year X. Unfortunately by the year X Microsoft will probably be pushing .Net 5.5 and I dread to think how big that will be.

I have heard a lot of people touting the productivity benefits of C# and .Net, but the huge framework downloads can only be a major hurdle for customers, especially for B2C apps. You also have issues protecting your byte code from prying eyes, and you can pretty much forget cross-platform development. So I think I will stick to writing native apps in C++ for Windows for the foreseeable future.

There is no clear leader amongst the development ‘stacks’ (languages+libraries+tools) for native Win32 development at present. Those that spring to mind include:

  • Delphi – Lots of devoted fans, but will CodeGear even be here tomorrow?
  • VB6 – Abandoned and unloved by Microsoft.
  • Java – You have to have a Java Run Time installed, and questions still remain about the native look and feel of Java GUIs.
  • C++/MFC – Ugly ugly ugly. There is also the worry that it will be ‘deprecated’ by Microsoft.
  • C++/Qt – My personal favourite, but expensive and C++ is hardly an easy-to-use language. The future of Qt is also less certain after the Nokia acquisition.

Plus some others I know even less about, including: RealBasic and C++/WxWidgets. They all have their down sides. It is a tough choice. Perhaps that is why some Windows developers are defecting to Mac, where there is really only one game in town (Objective-C/Cocoa).

I don’t even claim that the opinions I express here are accurate or up-to-date. How could they be? If I kept up-to-date on all the leading Win32 development stacks I wouldn’t have any time left to write software. Of the stacks listed I have only used C++/MFC and C++/Qt in anger and my MFC experience (shudder) was quite a few years ago.

Given that one person can’t realistically hope to evaluate all the alternatives in any depth, we have to rely on our particular requirements (do we need to support cross platform?), hearsay, prejudice and which language we are most familiar with to narrow it down to a realistic number to evaluate. Two perhaps. And once we have chosen a stack and become familiar with it we are going to be loathe to start anew with another stack. Certainly it would take a lot for me to move away from C++/Qt, in which I have a huge amount of time invested, to a completely new stack.

Which Windows development stack are you using? Why? Have I maligned it unfairly above?

[1] Bespoke software is a different story. If you have limited deployment of the software and can dictate the end-user environment then the big download is much less of an issue.