December 2005 - Posts
"Six Apart Ltd.'s TypePad blog hosting service went down for the day last Friday following a failed storage upgrade. Affected customers included Major League Baseball's MLB.com site, which hosts all of its blogs with TypePad. In addition, the del.icio.us bookmark-sharing service that Yahoo Inc. just bought suffered days of problems last week after its data center lost power." -- Infoworld.
The interesting thing to note is that many of the AJAX dazed tout centralized deployment and management as one of the driving factors behind browser based web apps. But as we can clearly see, centralized deployment means that you create a centralized point of failure for all users.
I think it was The Wrath of Khan where we learned that "The needs of the many outweigh the needs of the few, or the one". Apparently some organizations didn't see that movie.
SalesForce.com is a hugely popular web based CRM application boasting more than 350,000 subscribers. They are also often touted as an example of the resurgence of Internet based applications and are the poster child for the mythical "Web 2.0". But like other strictly browser based applications they have a rather significant flaw; they require connectivity at all times.
Recently the SalesForce.com application was unavailable for more than five hours leaving its users without access to their own data. One person quoted in this Infoworld article apparently couldn't even access his contacts because they were stored online.
With the ubiquity of WiFi and Broadband Internet access, many people have started to question why "Offline" capabilities are so important. Simply being connected to the Internet isn't enough. DOA attacks, Global DNS issues, and many other network gremlins can conspire at any time to separate people from the data and applications they need to do their day-to-day jobs.
Had SalesForce.com been created as a smart client application, the downtime they experienced would have been more of a nuisance than a major catastrophe, one which they have yet to even acknowledge. So Thank You SalesForce.com, for proving my point so well. And also thanks to alert reader Jeff Combs for bringing this to my attention.
In Rob's summary of the story thus far, he further "refines" the criteria for our bet to include that the application be installed via Click-Once. While this may be a tough criteria to meet given the current FUD about installing the .NET Framework, I'll take that challenge. Okay Rob, you're on! Who's with me?!?!
My list of smart clients did miss your earlier point, while compiling it my thinking was to actually see just how far I could stretch the definition of "smart client". I may have strained it once or twice, but I think overall it still fits all of those items if not your specific criteria for the bet. And don't be too quick to rule out media as a smart client. While Media Center may be a stretch, I would add Rhapsody to the list as an excellent smart client for music and video.
Much like the "Space Race" from the 60s, the end result of this bet will be of less overall consequence than the knowledge and experience that comes simply from having tried.
Since posting my response to Rob's blog in the wee hours this morning I've gotten some pretty good feedback including a response from Rob himself asking me to "Show Him The Money" pointing out that nobody is doing smart clients, at least for consumers. Before I get into that though, let me try to dispell another web application myth.
4. Web Applications Don't Require Installation
What exactly do you consider an installation? If an installation means copying files down from a server to your local hard drive and then executing them, web development definitely requires installation just check your temporary internet files folder. If you mean registering an application in the Registry and on the Start menu, then web applications still require installation only rather than being specific for your application you have the browser application already installed. So how do you get a zero installation? You don't. Instead you download scripts in the form of Javascript and/or HTML and you execute them on your machine in your browser, hoping and praying that the browser application will save you from letting that code wreak havoc on your computer. As we all know, browsers can't be trusted to catch everything. Since zero installation doesn't actually exist, I would definitely prefer my downloaded scripts to run in the .NET CAS sandbox instead of an application written before most current hackers learned their ABCs.
Okay, on to Rob's reply. He starts with a quote from PC Magazine, the premiere source of relevant information ads on the computer industry. Industry "journalists" see trends wherever that month's issue says they should be. Very few of them looked into Windows Live Services beyond the mesmerizing affects of an AJAX portal to see that the really useful services all involved smart clients. So I wouldn't put too much stock in what they consider a trend.
As for showing you the money, I'll list out the smart client applications that consumers can use but you are right that there aren't many to be had. The question is "Why not?" The anser is Time. Rome wasn't built in a day and it's going to take a long time for people to get over the pain they felt distributing old installed applications to see that new technology has enabled them to build something better than a browser application. AJAX is just a Band-Aid, while it might help in the interim only time will actually heal the wound.
So here are some Whiz-Bang Smart Client Applications you can download now based mostly on what I have installed on this computer. If there's any confusion as to why I consider them smart client apps, I'll address it. Anybody reading this should feel free to point out the ones that I've missed as I'm sure there will be some.
- Trillian (my favorite IM tool)
- RSS Readers (Any of them that cache the entries to read later will do, I'm currently using Pluck)
- Multiplayer Games (America's Army being one of my favorites)
- Visual Studio
- Media Center (Guide updates are downloaded and stored locally)
- Microsoft Antispyware (Beta)
- BitTorrent
- Folding@Home/SETI@Home
- Remote Desktop Connection
- Any FTP Client Software
- My wife's MLS System
- DriverGuide Toolkit
- Adobe Products (Photoshop, Acrobat, etc.)
- Quicken/Quickbooks
So Rob, I'll take that bet. 1 year from today we'll blog about the best consumer applications and then I'll let you take me to lunch. I'm thinking Del Frisco's!
My friend and colleague Rob Howard recently posed the question on his blog, “Are Smart Clients a Dumb Idea?” In his post he recanted his earlier statements regarding the adoption of smart clients and now is convinced that web based applications written with the magic of AJAX are indeed the future. In this post, I hope to bring him, and the rest of the AJAX Hip-Mo-Tized world back to some semblance of reality.
Let’s start by dispelling a few myths about web based development.
1. Web applications are easier to develop
Easier than what exactly? Faster than light space travel? Mapping human DNA? Or perhaps just figuring out why people watch Reality TV? It might be easier than these but it’s certainly not easier than Windows Forms based development. Here are a few bullet points of where web development, even in ASP.NET falls far short of “easy”.
- Number of technologies used. It’s not enough to know VB or C#. To create an even remotely useful web page you have to know HTML (tags and DOM), CSS, Javascript, and at least one programming language. Put ASP.NET WebForms architecture on that and you add the concept of server controls, postbacks, and XML. Now throw in multimedia or applets (Java or ActiveX) and it gets significantly worse. Heck, I still haven’t figured out Flash and thousands of sites use that.
- Most applications don’t work in a strictly request-response paradigm. ASP.NET goes to huge lengths to overcome the basic obstacle of web development which is that it is a request and response based communication. We’ve added ViewState, SessionState, Application Caching, SqlDependency, Output Caching, and lots of other things all because centralized server based processing doesn’t hold state between requests. To create a robust, enterprise scale application a developer has to take on the burden of wiring together all of these various services just to be able to recognize that the user has already logged into the application. Now I will grant you that ASP.NET does a fine job of making it easier, but easier doesn’t mean easy.
- Web based interfaces are incredibly difficult to build accurately. Any developer who has written a widely deployed web based application has gotten that call from a user saying that some piece of the web page isn’t showing up or isn’t showing up in the correct way. Even on the same browser and version (more on that later) dozens of settings from screen resolution to font sizes can change the way an interface looks between users. This leaves the developer with either having to test the interface on as many browsers as their PC will hold or simply aim for the middle and hope for the best.
To summarize, consider this. If Windows Forms development was so hard, why did the ASP.NET team go to such huge lengths to make Web Forms work in EXACTLY the same way? The easiest web development architecture I ever saw was Java Servlets. You get a Request Object in and you spit out a Response. What happens in between is entirely up to you.
2. Web applications are easier to deploy
This myth is based on the concept that it’s easier to deploy an application to a server or web farm than to 1000 desktops. But that concept is another IT slight of hand that has people looking the other way while the same deployment issues that exist with local installations get solved through different means. Specifically here are some examples of the issues involved with web based deployments.
- Without the browser on those 1000 desktops, your web application is useless. Why then does it seem like no big deal to deploy a web browser? Simple, for the most part it’s already there. Windows (the ubiquitous desktop platform) includes Internet Explorer of some version or another. So many companies can leverage that browser and concentrate on the apps, or so they think.
What web based application fans might not understand is that this same argument is also why .NET based Smart Clients are a good idea. It wasn’t too long ago (and yet not long enough in my mind) that you couldn’t predict which of the various browsers your clients, even corporate desktop clients, would be using. Netscape ruled the world and IE was coming up quick, but there were others. I can still recall having to make sure that our applications worked with Links Lynx, a text only based browser (Man, I’m old!). But since Microsoft started pushing out IE with every version of Windows this has become much less of a problem. The same thing will happen as the .NET Framework is included with every new version of Windows and on Windows Update. And here’s another thing that many people haven’t considered. Other companies, I won’t mention any specific names but one of them has the initials HP, distribute the .NET Framework on their new PCs because the custom software they use to annoy you with advertising is written in it. Windows Media Center, which is growing more popular every day, requires the .NET Framework. With more than 120,000,000 installations, it’s unlikely that you really need to worry too much about the fact that a Smart Client application requires the .NET Framework be installed. So relax, it will be there when you need it and if not, it’s a pretty simple install.
- Browser incompatibility. I’m not just talking about the differences between Internet Explorer and FireFox, which is a big enough problem. I’m talking about the differences between IE 5.5 and IE 6.0 or even IE 6.0 with HotFix A versus IE 6.0 with HotFix B to say nothing of Windows XP SP1 versus XP SP2. These can be hugely time consuming to track down and fix and require you to get deeply acquainted with the innerworkings of your client PCs. This is not easier deployment, you simply have shifted the issue from one of application deployment to that of browser deployment.
- Production servers are usually all or nothing deployments. Many organizations prefer to release their software in a controlled manner through one or more pilot releases. Pilot releases with a web based application can be extremely difficult. You have to either give the users a new URL, thereby breaking any saved links they might have, or you have to play DNS/Routing games on your network. Then, when the application is ready for widespread distribution, the pilot group has to change their URL again or more network settings have to be changed.
- Development is rarely done on production servers. Most ASP.NET developers create their applications, from web interface to database, on their local machine. Then they go through whatever deployment and testing process they go through and the application ends up on the production server, where it promptly stops functioning. This can be for a number of reasons such as:
- Incorrect Server Configuration
Between IIS and web.config there are dozens of ways to misconfigure an application. A seemingly simple change like forgetting to bump the max System.Net connections or using different MachineKeys in a web farm can cause a web based app to crash that worked fine in development.
- Performance was not adequately tested
Too many web applications are developed only to have to undergo massive overhaul when put under production loads. During development it is difficult for a developer to simulate how an application will react to things like 90% of the users signing into the application within the first half hour, or users leaving their browser windows open when they go to lunch only to find out that their session has timed out when they come back.
3. Web Applications Cost LessThis is another one of those statements that doesn’t require any actual numbers to back them up. It, like the earlier myth, is based on the concept that one big-time server is cheaper than 1000 desktops. This argument would make sense if the desktops weren’t already out there in corporate America, waiting to be used. But they are. Most of the desktops being used by your average business worker get less exercise than I do (which is damn little exercise, but I’m planning to change that). And yet, companies continue to buy new quad CPU servers with SANs and clustering for every new web application they deploy while relegating the desktops to dumb terminals that know how to run Outlook and IE.
Getting back to Rob’s comments let’s look at a few other of the things he says while under the influence of AJAX.
“The only offline application I care about is email and that problem has already been solved in Outlook.”
Okay Rob, so consider this. You are in your offices at Telligent working away and you lose network connectivity. Not just Internet, but the internal network too. What can you accomplish? You can still continue to develop CommunityServer, your award winning ASP.NET based CMS. You can still write articles for MSDN or even TheServerSide.NET (Please, Please!!!) While a nuisance it won’t slow you down all that much. Now consider a branch loan officer. He’s got a line of people waiting to complete applications for new loans and is thinking about the boat he’ll buy with the commissions when he loses network connectivity. Unfortunately his company decided to go for the “ease of development and deployment” myths and created a loan application system that is web based. He can kiss that boat goodbye to say nothing of the customers.
We computer nerds are not good examples to use when thinking of the “online/offline” question. Most of what we do is offline. I’m even writing this rather lengthy blog post offline in Word. If I lose network connectivity I can save it and post it tomorrow. But it’s companies that are building applications that rely on the browser and network connectivity that will suffer if their decision makers don’t understand the importance of being able to continue working while offline.
“Watching someone like my wife use a computer makes me realize that she, as a pretty typical user, does about 95% of her computer usage through the browser”
Why is that? It’s not because the browser is the better solution it’s because the technology to allow Amazon to create an interactive catalog that you can browse while offline hasn’t existed long enough for them to see how useful it would be. Imagine if JC Penney decided to create an application that would let you scan in a picture of yourself and then shop for clothes by superimposing the image of the clothes onto the picture of you? That would be a very cool application (Hey Chris Anderson, if you ‘re reading this how about a nice XAML demo of this?).
“and then read about some of the new "web enabled" offerings coming out of Microsoft like live.com”
See my earlier post and you’ll notice that Microsoft’s Live services are more about smart clients than browser based applications. Web 2.0 (a name so cute it makes me want to hurl, but they’d just name it Dinner 2.0) isn’t about a resurgence of websites that almost mimic functionality of Windows 3.1. It’s about the services that can be offered over the Internet and delivered through a number of means, with smart clients being (IMO) the best possible platform.
“Why should you care about writing smart clients. You probably shouldn't. If you can write it as web application do it.”
The reasons listed above are why we as computer geeks care about browser based applications versus smart clients. But the real reason that organizations should care about smart clients is for their users. Users want and deserve the best applications that we can give them. Applications built on technology from 10 years ago (even if it does have a snazzy new name) won’t keep them fooled forever.
So for any of you readers out there who may be wondering how to decide which type of application to write, here’s my advice. Think about your user and Do What Works Best For Them. I’m betting it will be a smart client application.
While doing a bit of reading in preparation for a rather lengthy blog post I'm working on I found this hilarious site that lets you generate your own VC friendly company name and product. I'm pretty sure this is what the Vonage guys used to come up with their spiffy new name.
http://andrewwooldridge.com/myapps/webtwopointoh.html
There has been quite a bit of noise lately over Microsoft’s recent “Live Services” announcement, most of which was caused by Microsoft’s choice to use AJAX, a cutting edge technology if you happen to be stuck in 1998. Those of us currently residing in reality, also known as the end of 2005, remember that client-side Javascript is more browser slight-of-hand than an architecture on which to build enterprise applications. But the fanfare went on and the browser addicts once again felt justified in killing off usability in the name of a myth called “ease of deployment”. Even Rob Howard, a generally very smart guy, is ready to call for the end of Smart Clients. But if you take a closer look at the functionality of Microsoft’s Live Services what you’ll find is that the real power comes from Smart Clients, not AJAX.
| Site/Service | Description | Technologies |
| Windows Live (Beta) | This is Microsoft’s portal page allowing you to install your own gadgets from www.MicrosoftGadgets.com. The Gadgets site has a pretty good collection of portlets but the two I tried to install came complete with Javascript errors. As for a general portal page, I have found that www.CodeZone.com is MUCH better, at least for .NET developers. | HTML, AJAX |
| Windows Live Mail (Beta) | This is Hotmail in new CSS styles with functionality taken directly from Outlook Web Access, which is still a better email implementation. Oh and by the way, OWA has had Async Javascript for years. Yet nobody seemed to notice until Google used it (poorly). | HTML, AJAX |
| Windows Live Safety Center (Beta) | This site has three services; virus checking, disk cleaning, and disk defragmentation. While these apps are browser based, they don’t use AJAX. Instead they use that other old Microsoft technology, everybody’s favorite security hole ActiveX. Why? I truly don’t know. This so clearly should have been a smart client application. | HTML, ActiveX |
| Windows Live Favorites (Beta) | This site allows you to save your favorite links in an organized list. It also allows you to import and export your links to your desktop. | HTML, AJAX, ActiveX |
| Windows Live Messenger (Beta) | This will be the next version of Windows Messenger and will include lots of new features including shared folders (P2P) and VOIP client software. While the nature of this application is Internet communications, it does function in a limited capacity without a connection, therefore it qualifies as a Smart Client application. | Smart Client |
| Windows Live OneCare (Beta) | This is an application that combines antivirus, automated backups, performance tune-ups, and automatic downloads of updates from Microsoft for Windows and Office. This application installs on the desktop and runs with or without a connection, so it is clearly a Smart Client. | Smart Client |
| Windows Live Search Beta – Mobile | This is a specialized version of MSN search that returns movie listings, restaurants, etc. based on a mobile phone user’s location (as entered, too bad they can’t use the GPS from the E911 service to do this). This is a specialized web page that while it isn’t a smart client, it’s not AJAX either. | xHTML (WAP 2.x) |
| Office Live | Contrary to what many people are thinking (or dreaming), this is unlikely to be a web based version of Word or Excel. This will be a site that allows small businesses to create a web presence (web, email, DNS). It will also offer some business services such as customer and project management (collaboration ala SharePoint I would assume). Most of these features will require Office installed on the desktop. | HTML, Smart Client (Office), ??? |
| Xbox Live | This is an online gaming platform for the Xbox console. While not traditionally considered a smart client, an Xbox game that has multiplayer features through Xbox Live is in fact a smart client application. | Smart Client |
If you take the time to see past the AJAX parlor tricks, there’s actually something really important going on. The promise of web services, or software as a service, is starting to actually be realized. Much of the software in the future, in my opinion the most useful software, will be smart client applications; applications that provide a rich UI while leveraging the power and resources of millions of desktops (and laptops) all over the world. Those applications may use the Internet as a means of deployment but more importantly will be able to extend their functionality through the use of web based services. And that is what is at the heart of Microsoft’s Live Services.
More Posts