Author: mike

Ryan Stewart this week was Looking at the Strategy of Rich Internet Applications. He hits a lot of points there, but also takes a stab at the fundamental differences between Web Applications and Desktop Applications. Clearly, if you read other parts of his blog, you’ll know that Ryan very much thinks the Desktop Experience has a much richer experience to offer than the web does.

As a Microsoft employee, I’m supposed to say, “he’s right”. After all, we Microsofties have a vested interest in proving this true – if users don’t need the desktop anymore, we’re in serious trouble! I’ve personally wracked my brain trying to prove this is true, hoping this to be true. But alas, I think he will ultimately be proven wrong. I’m not saying that Web Applications today have knocked out desktop apps yet. They certainly have not. But I also have no doubt that they ultimately will. Web Applications are fundamentally cheaper than Desktop Applications to build, install, administer, maintain and support.

The Problem with Desktop Software:

1) The Cost of Deploying Software
It is incredibly expensive to maintain software deployed to every machine. Take any large corporation, and they’ve got a fleet of IT professionals who’s only job is to make sure that the deployed software still works. Can you imagine managing 100,000 desktops that are in use by 100,000 different people, each sitting at desks in varied locations? Users break it, and the IT guy has to fix it. If the software weren’t deployed in the first place, this cost goes away.

2) The Cost of Conflicting Software
It’s the Operating System’s job to manage the resources of the hardware. To date, we have yet to see an Operating System that can prevent conflicts between two software packages. It boggles my mind, but somehow installing an Antivirus program can affect the way your Email client works. This is a sad fact that each and every one of us has experienced. In today’s world, installing two software packages on a single box means you’ve got bugs. It’s impossible to test every combination, and we software professionals inherently suck at it.

3) The Cost of Patching Software
Patching software is tricky. You need to communicate to the user that you have a patch, how important the patch is, what the fixes are, what the side effects are, as well as any gotchas. You may need to upgrade the data formats the user is using, depending on how big of a difference the new patch is when compared to the old one. Microsoft does patching better than anyone with it’s Microsoft Update product, but it’s taken years to get right, and it takes more process to update a product than it does to get the Space Shuttle off the ground. Why? Well, if you are going to update 500,000,000 desktops, you’d better damn well know it works. Frankly, unless Microsoft can both reduce the process cost and also make this technology available at zero cost to every other software maker, patching of most software continue to be a serious gamble for the end-user. And even if the patch does work, don’t forget about the patch causing new instances of Cost #2 mentioned above.

4) The Cost of Supporting every Platform
Once you deploy your software, your new applications need to support the old ones. This adds exponential expense to building software. If you don’t think it’s too bad to support Windows 98, Windows 2000, Windows XP, Windows Server 2003, and Vista, how about writing an application that needs to work with 4 different versions of Office (Office 2000, Office XP, Office 2003, and Office 2007) on each of OSes? (now you’ve got 20 combinations) But wait! Don’t forget that the world is changing from 32bit to 64bit architectures, so you’ll need to build both 32 bit and 64 bit versions of your code for each of them! Now you’re looking at building software to be tested on 40 different platforms. Seriously, who for a minute thinks that software makers don’t take shortcuts here? Maybe now you realize why your Windows Server 2003 breaks so much (it get’s tested the least).

For platform support, I haven’t even mentioned those noble apps that want to build for both the Macintosh and the Windows environments. Doing that is such a daunting task that nobody expects applications to be concurrently released on both anymore. That’s just crazy talk.

5) The Cost of Integrating Web based and Desktop based software
Building Web-based applications means you have to build out a server infrastructure and employ a whole set of technologies which is fundamentally different from what you use when building desktop based applications. Unfortunately for the desktop apps, almost all modern apps need to use some sort of server-side infrastructure to build the latest features. Both Quicken and Money, which are classic Desktop Applications now integrate with sophisticated server-side applications for tracking your investments, doing online trading, and more. Over time, it will prove too costly to build both the Desktop portion and the Web portion of these applications. Software providers will need to consolidate. Unfortunately, you can’t move the web content (real time stock quotes, news, banking services, etc) onto the desktop. So, if you want to consolidate your technologies, the only way you can consolidate is to move to the Web-based application.

6) The Cost of Going Mobile
Jonathan Schwartz (CEO, Sun Microsystems) wrote about this just the other day. While here in America we haven’t gone as crazy about mobile as other countries have, there is no doubt it is coming. Which application is better capable of moving mobile? The Desktop-based application or the Web based one? Desktop apps need to be completely rewritten to work on mobile devices.

7) The Cost of Synchronizing Data
Once you’ve managed to deploy your desktop app, you start to use it. You write a few Word documents, save away some QuickBooks data, and get some good work done. But then you need to travel to Phoenix. Yikes! Now you need a laptop so you can take your data with you. But wait – you left your laptop in the taxi, and now you need to get the client’s phone number so you can tell him you’ll be late. Shoot – that was on the laptop too! The problem is that you haven’t synchronized your data between all your desktop-based software packages. So, in addition to the desktop and laptop, you’ll now be buying services and software from one of the mobile carriers to try to sync all this data for you. Getting expensive!

The Solution is Web-Based

OK – so if you’ve read this far, you may not yet be convinced of the inevitable doom for our desktop applications. Just to make sure nobody says I left anything out, let’s recap the above 7 costs with the Web-based application.

1) Cost of Deploying Software. In the Web-based model, the IT department does not deploy anything except the browser itself. Once that is deployed, new applications can be added without deployment costs to the desktops. (Server side deployment or data deployment, such as hosting email data still exists, but that exists in the desktop arena as well with Desktop Server applications like Exchange)

2) Cost of Conflicting Software. The web is designed around a set of pages which are partitioned. This partitioning ensures that unrelated applications don’t conflict. (e.g. Yahoo can’t change a page on their site which breaks Microsoft’s site)

3) Cost of Patching Software. Patching software exists in both models. However, in the desktop-model, your patch has to work for any desktop, which could be running any platform, or have been modified by the user in any way. The user could have deleted registry keys, moved disks around, or added new gizmos like USB drives, printers, and network cards. In the Web-based world, the application provider controls all of these things. Further, the patch can be scheduled to run at times when the user is known to not be using the system. Because you know what you are patching, Web Applications patch much more easily. You only have to support the new version, and the version one prior; there is no need to support 10 year old systems.

4) Cost of Supporting Every Platform. This problem does not exist in the Web Application world, except for supporting various browser features. IE, Firefox, and Mac each have somewhat different features, and this can be tricky to build software for. Nonetheless, it is infinitely simpler than the myriad of combinations created with the desktop.

5) Cost of Integrating Web-Apps and Desktop Apps. Ironically, the Web-App world already does this. There is a very clear line between what is done on the client (HTML, JavaScript, etc), and what is done on the server. Web Apps specifically design for this fact, and don’t usually need to modify the desktop.

6) Cost of Going Mobile. Web Apps need relatively small changes to work on mobile devices, and for the desperate, even generic browsers can do a functional job on mobile devices.

What it Takes for Web-Apps to Finally Conquer the Desktop

Alright. Now that we’ve established that Web Applications truly are cheaper to maintain and richer in features, why haven’t they taken over already? Clearly something is missing?

Better UI & App Platform
HTML & JavaScript are pretty flexible, and it always amazes me what some people can do with it. But, most UI’s are pretty poor when compared to what the desktop can provide. Graphics rendering is pretty much unavailable, and accessibility and navigation metaphors are often broken.

We need a few more generations of markup to allow Web Apps to better utilize the client and create more consistent user interfaces.

Ability to Save Data Locally
Today, going to a web-based application means that you are storing your data on the Web. This is a big tradeoff in terms of security and bandwidth. I want my photos to be mine – but I want the application on the web.

I fully expect web browsers to be capable of doing this in the future. I also expect web browsers will be capable of storing data on USB or flash devices. Instead of each of us having a desktop with a big hard disk, we’ll have a set of small compact flashes that we can plug into our cameras, our phones, our computers, the kiosk at the airport, or all of the above.

Note that the ability to Save Data Locally is specifically what weakens desktops for the “Cost of Going Mobile” and the “Cost of Synchronization”. It’s these private data stores which are costly, and using flash or USB devices re-introduce part of that. The difference, however, is that the application is able to write to any place; instead of only being able to write to “C:Documents and SettingsJoeMicrosoftFoo Application”, applications will write to where the user wants the data. And, if that is a mobile storage device, it will go mobile, decreasing the costs of mobility and hopefully eliminating the need for much synchronization.

Ability to Provide Internet and Intranet Solutions
Moving the storage for the consumer is one thing, but companies will still need and want to control their email and other data. Web App providers will need to provide ways that the backend portions of these applications can either be hosted by an IT department, or be hosted on the Intranet. Let the consumer decide.

More Bandwidth
We need more broadband penetration. If you don’t have broadband, you want your desktop apps. Sooner or later, this will be realized. Some thought we’d have enough bandwidth 10 years ago. Who knows, maybe it’s still 10 more years away.

Conclusion

For me, the conclusion is obvious. Users will ultimately elect the pains that come with remote-managing their data over the pains of doing system administration. It’s just easier to delegate system administration tasks (deployment, backups, etc) than it is to do it yourself. As soon as technology takes us far enough, we’ll jump.

Don’t conclude that I’m totally absolute here. This is an evolution that will take many years. There will always be some desktops out there. High-performance games may demand it (or maybe dedicated consoles like XBox and PlayStation will take that), or other vertical apps will demand it. Developers will need their own boxes. Video editors and graphics designers will probably need their own machines to do their specialized work. For mainstream use, though, we’re heading pure web. And increasingly, even these specialized work environments will move to the web too.

Finally, Some External Resources

Paul Graham
I don’t agree quite with the words, but mostly I do agree. Keep in mind that Paul wrote this in 2001, “There is all the more reason for startups to write Web-based software now, because writing desktop software has become a lot less fun. If you want to write desktop software now you do it on Microsoft’s terms, calling their APIs and working around their buggy OS. And if you manage to write something that takes off, you may find that you were merely doing market research for Microsoft.”

If you want to have backward compatibility and support for environments as far back as 10 years old, and you are going to deploy hundreds of millions of copies of it, you are going to be left with something that seems like “calling their APIs and working around their buggy OS.” It’s not Microsoft that is the problem, it’s the nature of the beast.

Om Malik
Om teamed up with Niall Kennedy recently to discuss this topic, and they concluded that there is a lot of life left for Desktops. They are probably mostly right, but I think their long term vision is a little short term. Om created a poll on this topic, with 64% of respondents wanting “both desktop and web apps”.

Paul Kedrosky
Paul’s interesting viewpoint is to look at history, “Way back when there was a time when people would have said that editing text in WYSIWYG was a CPU-bound task that required a desktop application, but times have a-changed. I have no doubt that the same thing will happen, sooner rather than later, to many tasks, like audio-editing, that are currently deemed now-and-forever desktop apps.”

Peter Rip
The real problem with desktop apps is no one works at their desktop anymore.

If you blog, you need to use Windows Live Writer.  I wrote about Writer once before, but didn’t do a full review.  This time, I am so hooked, I have to write more.

I recently switched over to WordPress from Movable Type, and with my first few posts I sincerely tried to use the WordPress AJAX, web-based editor.  But, the web-based editor is so primitive compared to writer that I had to switch back. 

There are a few problems with the web-editors.  First, you really do have to know HTML.  Although WordPress tries to be WYSIWYG, it has lots of bugs, and I often had to switch to HTML mode to make my posts look right.  Worse, sometimes I simply could not get the editor to format posts the way I wanted.  Everything was difficult and I was constantly fighting with the editor rather than writing my post.  Finally, the WordPress and Movable Type editors give you a tiny little window to compose your post.  It is functional, but it hardly lets you see your post as it will be shown in your final blog.

Writer solves all of these problems and goes way beyond.  The editor really is WYSIWYG.  It even uses the templates from your blog so that as you type you see exactly how your entry will work.  Native controls a-la word are a button-press away to make your posts look great.

But the biggest feature for me is the way Writer seamlessly integrates image handling.  WordPress does okay, but both WordPress and Movable Type force you to do a lot of work to insert an image.  Movable Type even makes you go through a special upload process not too dissimilar from using FTP.

With Writer, images are incredibly easy.  First, you can just drag-and-drop content from the web into your post.   I prefer to insert from a file because you have more options with manipulating the image afterward.  Here are the 3 panes of options provided by writer (click to see larger image):

Imaging features include:

• One button positioning to Left/Right/Center in your content
• Add Drop Shadow or PhotoPaper backgrounds to the image
• Automatically add margins to the image
• Have the image link to itself in a bigger form
• Add watermarks to images
• Add effects to images (black/white, emboss, blur, sepia, etc)

Outside of imaging and basic editing, Writer knocks out all the basic features too.  It can manage multiple blogs for you so that you can post to many sources from one simple app.  This is far better than having to navigate to multiple web-based admin screens.  Further, you can edit offline, perfect for composing those posts while you are on the plane or away from the net.  Writer even bundles a spell checker.

Finding drafts, prior posts, creating new posts is all a snap.  There is also a plugin API which I haven’t toyed with, but if you’ve got content, you may want to check it out so that other bloggers can more easily write about you.

All in all, it’s so much easier to work with Writer than it is to work with the Movable Type or WordPress web-based editors.  You’ll save a lot of time and everything will look a lot nicer too.

In the movies, you’ll watch the hero covertly enter someone else’s office, quickly hack into and navigate the computer system, drop a cd into the drive, and wait impatiently for 5-10 seconds while all of the data copies.

In reality, I fumble with the disks, can’t even get the DVD drive to open (keeps closing automatically, almost as if it knows its toying with me), discover my Windows 2003 server doesn’t software for doing a backup to DVD even if I want to, go through 2 or 3 reboots, have to figure out the obtuse software, write the first disk and fail, do it over, and finally, about 2 hours later, I have a simple backup.

If only life emulated art…..