Regardless of your deployment decision today, it will change tomorrow.
by John B Smelcer, MBA, PhD
A client is considering converting a desktop application to the web. Creating web applications for instantaneous deployment and universal access is very popular. But are there business considerations, given the types of tasks completed by users and their limited access to the Internet?
Web applications mean effortless deployment. IT managers love this because updating hundreds or thousands of PCs when a new version of desktop software comes out can be a major headache. Conversely, web applications are automatically updated when users refresh their browser. For users, web applications mean that software is universally available, whether at the office, at home, or on the road. With data stored in the cloud, there is hardly any need to worry about where the data is.
But web applications are not perfect. Everyone has a different version of the browser – Internet Explorer version 7, 8, 9, or 10. Not to mention different browsers - IE, Firefox, Chrome, Safari. Testing your web-based app on all on possible environments is a major effort. In addition, developing a web application is more expensive than developing a desktop application (or a client-server app).
Desktop apps are widely used, and for good reason. The desktop platform is mature and stable, and the desktop applications are full-featured. Experienced users can continue to take advantage of their knowledge of Excel, or Photoshop, or QuickBooks Pro to get their work done quickly. The business also benefits when employees are productive.
Let's step back and look at the different reasons for choosing one platform versus another, desktop vs. web. But we'll do this from the user's perspective, since we are firm believers in optimizing the interaction among people, systems, and processes. As pragmatists, we also look at this from IT's perspective.
What Do Users Think of Desktop Apps?
Here's a hypothetical monologue from a desktop user:
"Oh, are you talking about Microsoft Excel, QuickBooks, Photoshop, stuff like that? They're great; I use them almost every day. You aren't taking them away from me, are you? It's nice that my co-workers use them, too, so when I get stuck they can help me. Or I can always call the Help Desk if I really get stuck.
"Every few years I need to install an upgrade or new version - what a headache. Something always gets lost, or I get lost.
"Evenings are tough, since I sometimes need to go to work after dinner to finish an important project. Having a laptop sure is nice. Unless I need to access shared files on the server, then I need to drive to the office."
What Do Users Think of Web Applications?
And a monologue from a web user:
"Yahoo! Mail is great. I like that I can share my calendar with colleagues and family, so they know when I'm busy. Helps me plan my week, so I can make Susie's soccer games - they're never on the same day. When they add new features, it's no big deal, I can adapt pretty quickly. Best of all, I can get to my email and calendar from anywhere. Is that what cloud computing is all about?"
Framework for Applications: User Interface, Business Logic, and Data
Most software today falls into one of several (confusing) categories:
● desktop software, e.g. MS Word, MS Outlook, TurboTax
● client-server applications, e.g. Sage BusinessVision for accounting, SalesLogix for CRM
● cloud-based software as a service (SaaS), e.g. FreshBooks for accounting, Salesforce for CRM, Basecamp for project management, iContact for email marketing, NetSuite for ERP
But memorizing these categories is not useful for understanding deeper principles that affect development decisions, like "How should I develop my corporation's next application?"
Ask not what category the software falls into, ask where the presentation takes place, the logic resides and where the data lives.
For these layers to communicate with each other, a standard protocol is needed. We show this simply as arrows between adjacent layers, though in a more complex n-tier architecture, this communication is handled by middleware software.
Mainframe applications from the '60s and '70s had all layers on the mainframe. However, to interact with users, information was exchanged with a CRT display.
Just like mainframe applications, a desktop application, circa 1980's, had all layers on one machine. Back then they were probably not separated as layers, but good software development grew to appreciate the virtues of layering.
When individuals work together, they need to share information. The graphical user interface (GUI) of the PC world had so many benefits for users that mainframe and minicomputer developers wanted to use it. The result was a client-server application. The client, the user's PC, presented information and sent commands back to the server, a larger, more powerful computer. The server handled the logic layer, data layer, and the database.
Figure 4: Typical 3-tiered architecture for a software application,
a.k.a. client-server application, e.g. QuickBooks Pro
So what does a web-based application look like? It's nearly identical to a client-server application, except that the presentation of information on the user's PC typically takes place inside a browser.
Most web applications that run on desktops/laptops work this way, though there is a variant that exchanges the web browser for client software which runs on the user's PC. This latter variant is similar to apps that run on your iPhone. The ebay app and the Amazon app are locally installed client software for the iPhone/iPad that connect over the Internet to servers that make sure you buy a matching shirt for the slacks you need.
Adding a browser and the Internet to create a web-based application add more layers. Some say these add complexity, others say they add standardization and connectivity. And from that paradox come the pros and cons, both for users and for IT managers.
The User's Perspective
With web applications
● all my data is available, wherever I am
● my smartphone usually gives me access
● any machine's browser gives me access – PC, Mac, iPad, even Linux
● some applications are not powerful or feature-rich enough for me, e.g. word processing, graphics editing
● sharing data with coworkers is easy
● sometimes the browser crashes
Although this is a mixed bag of blessings and curses, more and more web applications appear in the market. It seems that the advantages outweigh the disadvantages, certainly for software vendors and for IT managers.
The Software Vendor and IT Manager's Perspective
When we create web applications
● we need to hire software developers with more current technical skills, or train existing staff
● deployment of new versions is easy; there is no need to create distribution CDs or to go to each PC and install new software
● our users get the latest version of the software
● software bugs get fixed faster, which should increase user satisfaction
● everyone with a browser on any machine – PC, Mac, tablet, Linux – can use it
Caveats: Reasons Not to Deploy In a Browser
As mobile devices with universal connectivity become ubiquitous, the trend is to think first about meeting that growing demand. However, there are still important reasons to consider stand-alone applications. Many users do not have persistent network connectivity. They need a stand-alone solution, whether it's a desktop app or a mobile app. Think airplane, Timbuktu, or when users want to unplug and get some work done without constant interruptions from email, Facebook, etc. Reliability is also an issue with browsers. They do crash, and users hate to lose the last 30 minutes (or more) of their work.
This error occurred while I was writing this article, using Google Docs, a popular web application. So, I exported my work to my desktop PC, and another surprise awaited me. Once inside Microsoft Word, the drawings I had made were no longer editable. So there's one more reason to use dedicated desktop applications.
Here's another web deployment story. We developed a music sharing website for independent musicians, for uploading and playing non-commercial music. Our QA testing revealed that it worked just fine across multiple browsers. However, it failed to work on some Firefox browsers – the music player would not play. In fact we have two PCs with the same version of windows, and the same version of Firefox and the same Adobe Flash player. One plays music, the other does not. Debugging browsers certainly adds an unwanted layer of complexity. No wonder developing web applications is more expensive than developing desktop applications.
Reasons to Deploy On the Desktop
Desktop applications are ideal in some situations. If the application will be a power tool that is heavily used, then you need the power of a dedicated machine for computation or storage (or complex graphics as in FPS games). Sometimes your users want good integration with the desktop, particularly to save information locally for security and ready access, even when not on the Internet. Finally, if you need to have complete control over the user's experience, regardless of the browser differences, then deploy to the desktop. However, this is less and less an issue as browser development tools advance.
A Compromise: Hybrid Apps
If you don't want the limitations of a browser-based application, but still need connectivity to server-based information, develop a hybrid application. Hybrid apps are installed on the user's PC, but they connect over the Internet to data stored centrally. This is essentially what smartphones offer with the thousands of apps available in the app stores. With an iPhone or Android smartphone, installed applications often access data stored on remote servers in the cloud. Mail (Gmail, Yahoo! Mail, Hotmail), readers (Kindle), music (Pandora, Spotify), Documents (Google Docs) are examples.
Regardless of your deployment decision today, it will change tomorrow. For this reason, it is a good practice to develop software in layers – presentation, logic, data – so that each layer can be moved to a different hardware environment in the future.
The trend toward web applications is clear. More and more applications that everyone thought had to run as desktop applications are now commonly web applications. Email is a common example, whether you are using Gmail, Hotmail or Yahoo! mail. Desktop clients for email are losing market share to webmail and mobile tools. Google Docs continue to mature. Flash-based editing tools for non-professionals are emerging (but Aviary.com is retiring their flash-based tools), whether you are editing audio (Myna) or images (Phoenix, Pixlr, Sumo Paint) or video (Mixmoov, WeVideo). Remember that audio, image, and video files are large, so size is less the issue. Salesforce.com commands a growing share of the CRM market. Most enterprise resource planning systems (ERP) come with a cloud-based version that run in a browser. Power tools are a different matter.
If users spend lots of time doing a specific task, then that task tends to be done with a desktop application. Graphics editing by professionals is done with Photoshop; serious desktop publishing is done with Adobe InDesign or QuarkXPress. Financial analysts rely on MS Excel, while accountants use QuickBooks Pro daily. These tools are mature, full-featured, and best of all they are stable, not prone to the regular crashes of a browser.
Stewart, Ryan. (2007) ZDNet, Desktop vs. Browser - when to deploy applications for each
Valums.com, Web apps vs desktop apps, Feb. 10, 2010
Matzner, Ryan. (2012) Why web apps will crush native apps.
Justine Jordan (2012) Email client market share