Post comments to this article.
Download PDF version.

In reality, I have been writing this document in my head for over 7 years. It was the demo I did in Bill Gates Keynote at the launch event for .NET 1.0 and the First Version of Visual Studio .NET in San Francisco in February of 2002 that “woke me up”. I was slapped in the face with the “issues” around solution architecture decisions for application developers. It’s a long interesting story that I call “my 3 days with Bill Gates”. But, it culminated in me getting an hour backstage to build an application in ASP.NET and then getting 3:47 (yes, that is exactly 3 minutes and 47 seconds – in a Bill Gates keynote, let’s just say, there is significant “structure”) on stage with Bill Gates to demo it in front of an audience of 5000 and another gazillion watching it on the internet. My buddy Jon was tasked with doing the exact same thing – in .NET Windows Forms. To make this long story shorter what could be done in Windows Forms in an hour back then was dramatically more than you could do in ASP.NET and I got stuck with the “Silver Medal”. And that is still the case today: Typically it is much less effort to build an application for Windows (like Window Forms [WinForms] or Windows Presentation Foundation [WPF]), than it is for the browser. Even now, 7 years later, there is still a chasm in

developer productivity between the Windows Client developer technologies and Browser based developer technologies. I thought these issues would go away – that the Darwin Theory of how you manifest your application as a developer would just become clear through time. It has not become clear and huge mistakes are still being made. In fact, if anything, it is even more complicated and daunting for the solution architect. Now, I am looking back at the 7+ years I have dedicated myself to the application development ecosystem for the windows client. This is why I write this long overdue document that I am intending to exist as a “living document”, frequently updated, as time passes and “things change”. This document targets developers, architects, technologists and application decision makers who: Are confused about User Experience Design (UX) options and want to know when you would implement the Windows Client – if at all. Are searching for guidance on solution architecture guidance for applications built on the Windows Client. Are already “smart” on “Rich Client” applications and looking for more guidance.

WPF 3D Data Visualization Annotations on the 3D surface of a CAD drawing

WPF Fast Food Restaurant Kiosk Video, animations, touch

WPF in Healthcare A 3D view of the human heart linked to the actual 2D patient images

Don’t get me wrong. ASP.NET is beautiful from every way that you look at it. It is elegant below the hood in terms of the .NET framework classes and its integration with Microsoft Internet Information Server (IIS). And it’s elegant above the hood from the perspective of how darn easy it is to build powerful and functional web applications. It truly has revolutionized web application programming. Having said that, ASP.NET is limited when contrasted to Windows application development technologies like WPF and WinForms.

Like it or not, TCP/IP is not an elegant protocol (when compared to those beautifully efficient binary protocols of the past). TCP/IP is a disconnected protocol which results in the “stateless programming” handicap. In one of the greatest innovations in technology history, Cisco made a bad thing worse when they created those original 2500 series routers. This culmination of a connected world resulted in a spaghetti mess of router hops. When I make a landline telephone from Singapore to San Diego it’s 3 hops. When I use a browser in Singapore to hit InterKnowlogy.com in San Diego it’s close to 75 router hops. It’s not efficient nor is it fast. But, it works. And we are stuck with it for the not so distant future.

The other problem is that there’s just so much you can do in HTML. HTML was never designed to do the contortions’ we do to it. HTML is not declarative programming either; it’s simply a tag based markup “language”. Most would argue it’s not even a programming language. There is more on declarative programming later in this document.

Conditional Rule Number 1 – If your application needs broad reach, outside the firewall, then, at a minimum the solution architecture is going to include some form of a browser based ASP.NET application. This is the scenario this document is NOT about. But it deserves some explanation to “set things up” properly.

There are never absolutes in software architecture. And the above scenario is as close as you’ll get as a general rule for “platforming” your application. In broad reach scenario, where you cannot authenticate your users in a Windows domain, the majority of the time you are going to have to be a browser based application at a minimum. Good examples of this are the giant auction site and the giant book selling site and the large social networking sites. For these companies (and the gazillions of other internet based businesses) you need to reach the lowest common denominator if you want the largest group of people to buy your “stuff”. The browser is the lowest common denominator. And it is very limited in terms of what you can build into your application. The good news is that there’s virtually no client install so there’s no worries about “platforming” or running the most current version of the software. Grandma Huckaby, with her AOL 1.0 browser and her dial up internet access fits in this scenario.

The world's leader in internet retail: Static and 2D; cluttered with ads and pictures; desperately needs an offline experience.

The world's leader in internet auction: Limited in terms of what you can do in HTML trying to target the user. Non-technical users really struggle with this site.

One of the leaders in Social Networking: Drab and barely usable. All the social networking sites should have rich client versions.

I fit in this scenario too and so do you; it is the lowest common denominator. But, I don’t want to fit in this scenario. I need something more. I have a powerful Windows computer and high bandwidth access. I’d prefer to shop the huge auction site and book selling site and social networking sites in a highly graphical, wildly functional, rich with multimedia & 3D, beautifully styled “Rich Client” application. Again, there’s only so much you can do in the browser. Here’s where it gets a bit complicated. Microsoft Silverlight has brought life to the marketing term, “Rich Internet Application” (RIA). Silverlight has its limitations too; which I will drill into in detail later in this document. But, it’s bold promise is really starting to get realized.


So, why isn’t there more than the simple web applications for these goliaths of the internet? I am most certainly not unique in my needs. My friends, therein lies the problem and the reason for this document. There is just so much more you can do in .NET in the Windows platform when you are not confined to the browser.

I am going to continue exploring the problem from above on why the major internet retailers do not have Rich Client Versions of their software. But before I do that it’s important at this point to take a stab at defining just what the heck a Rich Client Application is.

Defining the Rich Client Application - Ultimately the term “Rich Client” (which for this document’s purposes can be interchangeably used with the term “Smart Client”) is just a marketing term; but, there are very important technical aspects to the term “Rich Client” that every software developer should be cognoscente of. Defining “Rich Client” is an age old heated argument worthy of getting alcohol involved. Since I have been fighting the “Smart Client Jihad” for so many years, I have personally seen arguments turn into emotional battles when arguing over what the heck a “Rich Client” is. I am not that “religious” about the definition, though. To me, it is the technical concepts that are important. So, with trepidation I will tell you that my simplistic definition of “Rich Client” is any application that does not run inside that browser. Yes, Microsoft Silverlight and its worthy competitor Adobe Flash are legitimate “holes” in my definition. And one can most certainly argue that AJAX is a “Rich Client” technology. And there are most certainly more technologies one can argue. The good news is that the simple fact that we can argue about things like this means we are starting to think about and understand the complications. That is a good thing. For now, let’s just group the three technologies Silverlight, Flash and Ajax in to the category “Rich Internet Application” (RIA) and move on to bigger and better things.

A stab at defining the Rich Client Application. Remember that there are no absolutes in software architecture. So, with that in mind, my definition of a Rich Client Application is the culmination of some (and sometimes all) of the following attributes:

• Deployed Locally to a Computing Device
  • Utilizes local processing power – because a rich client application is deployed locally to a computing device (ie: a Windows 7 desktop or notebook computer) it uses the power of that computer to run the application as opposed to running within the confines of the performance of the browser. This makes a Rich Client application the most “performant” interface for end users where user responsiveness is a “given”.
     
• Providers a Rich User Interface
• Most intuitive interface for end users – without the limitations of writing html based applications for the browser, the designer / developer combo can easily build powerful applications that any user can immediately become natively effective in without a huge amount of training.
• Greater control over user interface – Without the limitations of the browser the developer / designer has ultimate control over the user interface. XAML based technologies like WPF overcome the hard limitations of the browser.
• 3D, visual effects or graphically intensive applications are possible in Rich Client applications and limited, if not impossible within the confines of the browser.
• The developer has programmatic access to desktop UI controls. (ie: Scroll Bar or Date Picker controls)
• Rich support for Printing and print previews. Layout text in terms of printing is simply impossible to do in the browser.
   
• Provides a number of features to the developer that is just impossible to do in the Browser
• Local device interaction - device, system and file access are all possible in a Windows application. For security reasons you just cannot do this type of thing in the browser. Since you are typically domain authenticated or have rights on your local machine in a Rich Client scenario local device interaction is possible. Silverlight, a browser based technology has some local device capability because of the magic that Microsoft has done to have Silverlight behave in a security sandbox, but simple things like interaction with a USB device like a headset microphone are still impossible.
• Great Localization / globalization support - comes natively in Windows since Windows ships in 36 languages. So, the developer support for localization / globalization is elegant and powerful. That same statement cannot be said for developing browser based applications.
• Better Packaging and Security – when contrasted to Web Applications, Windows Client applications have better packaging and security. Again, since you are typically domain authenticated or have rights on your local machine, a Windows client application is easy to secure as contrasted to a web application.
• Consumes any data access methodology - including direct data APIs, data access layers and/or web services. A web application is limited to web bases data access strategies and the security limitations therein.
• May support online / offline scenarios – This is a big one. A huge feature of a Windows Client application is the ability to use it offline and then have it sync its data automatically once it gets a network connection. It is impossible to secure an offline browser application. The hybrid between Windows Client applications and browser applications is Microsoft Silverlight. Silverlight has rudimentary offline functionality built in for the developer.

Ultimately, the most simple definition of a Windows Client / Rich Client / Smart Client application that all developers can agree on is: That it Is NOT a browser based application. The assumptions of the limitations of a browser based application are just a given in this definition.

Now that I’ve made a stab at what the heck a Rich Client is, let me go through my list of the top problems and issues surrounding and in many cases delaying the Rich Client Revolution. And pay special attention that many of these problems share an incestuous relationship.

Problem: It’s often times not a technical decision. You have heard many times that the world is run by “C Students” and many software projects are driven by “Marketing people”. This is reality which is not going to change in our lifetimes. Deal with it. Decisions around software (and many other places in life) are made based on rational and irrational thinking; they are made on “time to market” and on cost. Like you, I want to live in a world where everything is about elegant software too. That world doesn’t exist yet and until we get closer to Star Trek where there’s one world federated government and money is insignificant, it’s not going to happen.

What’s the point? Frequently, the “right technology” for a software project is WPF and it ends up as an ASP.NET app purely because of an irrational decision. 8 years of fighting this war and I still lose battles like this. It is frustrating.



Problem: Humans inherently have problems with change and wandering out of their comfort zone - Even developers. Humans (which include software developers) are basically lazy by nature. That is a gross generalization and may not be fair in your case. But, it is prevalent. The old adage, “It’s hard to teach an old dog new tricks” is prevalent, if not predominant in the human psyche. If a developer is good in ASP.NET because of the last many years of the internet boom and has literally memorized the ASP.NET API then you can understand why it’s going to be hard to get him/her to jump into other areas of .NET – especially a rich client technology like WPF – even if he/she knows it’s the right thing to do on a project.



Problem: Lack of Guidance and level of difficulty. I might as well group these two together because even though they are unique problems, they are so often intertwined. Really one of the main tenants of this document is to be an aggregation of guidance. You’ll find that in the guidance section later on in this document.

Problem: Adoption. Back in 2001-2002 when the United States Department of Justice (DOJ) had its eyes laser-focused on Microsoft, a political decision was made that really hurt the developer community and the software industry in general. And we are still suffering from that decision 8 years later. This Microsoft decision was to not automatically install the .NET framework on Windows client / desktop machines. Although there were a plethora of opportunities, the technology world was reduced to a conscious decision and effort to install the .NET Framework on Windows client / desktop machines. I have had the plea / argument many many times over the years ultimately ending up in some network guy saying to me, “You are not installing 80 mbs of dlls on my client machines.”

Problem: The Scars of the deployment past. We are still living a 10 year hangover from deploying COM applications. Without going into gory details, frankly, because it’s so painful to look back on, COM applications were really fun to write and an absolute nightmare to deploy and version. So bad that it resulted in IT organizations (in companies large and small all over the world) mandating the “we will never deploy a desktop application again.” rule. Many of these companies still have this rule in place. In fact, I know of one fortune 100 company that is predominantly running the Microsoft platform that has a “web only” application development policy.

Problem: It’s not a 100% Microsoft world - and not only that there are multiple versions of Windows and multiple versions of the .NET framework. As developers we live in a world where platforming your application is a huge architectural decision.

Problem: the amount of legitimate developer technologies is directly proportional to time. When I first started doing solution architecture on the Microsoft Platform it was pretty simple because there just weren’t a lot of developer technologies. Now, I’m told there are more than 20 developer technologies for Microsoft Office alone. Solution architecture is now difficult. Good guidance is badly needed.

Problem: The Microsoft Rich Client Developer Stack is not really cross platform. Technically speaking there’s no reason why we don’t have versions of .NET on all platforms. The Common Language Runtime (CLR) was submitted to the open standards body ECMA making it technically possible to port it to any other software/hardware platform when .NET was born. Unfortunately, Microsoft historically has taken the stance, “We encourage ISVs to port the CLR, but we are not going to do it.” The Mono project is exciting, but ultimately as an open source venture without a revenue model I don’t have a lot of confidence in it becoming anything more than “neat”.

Problem: Some of these Rich Client developer technologies are difficult. Being different makes WPF inherently difficult. Declarative programming where the UI (XAML) is truly separate from the programming logic (C# or VB) is a very different programming paradigm than we have ever seen. It’s also the future if it’s not your “now”.

All Microsoft platform developers agree that there just has not been enough good guidance for building Windows Client applications. The following is a living list of what I call the best guidance for designing, developing and deploying Windows Client applications. It’s my list which doesn’t mean it’s wrong, right or all encompassing. Everyone learns differently. This is a list of some of the resources that help me learn. I will frequently update this list as I run into good guidance for Windows Client Development.

WindowsClient.net - this is the official Microsoft community portal for WPF development, and is chock full of great resources such as the forums and downloads sections.

Learn WPF page - this page on WindowsClient.net links to podcasts, labs, and the very popular "How do I?" videos

MIX University's WPF Bootcamp - Contains a full 3-day video training course on WPF, in which expert instructors guide you from the surface into the depths of the technology stack

Windows Client Development Samples, Guidance, FAQs and Blogs - Contains an aggregation of a ton of great stuff on the Windows Client Development platform.

Windows® API Code Pack for Microsoft® .NET Framework is the successor to Vista Bridge, wrapping SDK APIs including Taskbar and Libraries, Explorer Browser Control, Task Dialog, Common File Dialog, and Shell support. The current alpha (0.85) is for the Release Candidate of Windows 7. Expect Code Pack revisions with each pre-release of Windows 7. On the home page for the project are links to some videos demonstrating the wrappers in use.

Windows Presentation Foundation Unleashed (WPF) by Adam Nathan, Daniel Lehenbauer I love this book for a number of reasons: 1. It is the perfect book to start on. The author, Adam Nathan, does a fabulous job of explaining what the heck XAML is and why we need it right up front. 2. It doesn’t get too heavy into advanced topics or too “referency”. Again, in my opinion it is the perfect book to start on. 3. But, mostly because the publisher (Sams) busted out the cost to do all the code listings in the colors they appear in Visual Studio. All publishers should do this. It makes the code so much easier to read.

Essential Windows Presentation Foundation (WPF) by Chris Anderson This is a fantastic book and perfect as the 2nd one that you read if you are a beginner. If you are already a bit savvy in WPF this is a great one to start on. It’s written by Chris Anderson and Chris Sells. Both are just brilliant guys from the product team and genuinely nice guys.

Pro WPF in C# 2008: Windows Presentation Foundation with .NET 3.5, Second Edition by Matthew MacDonald From Brad Cunningham, Senior Software Engineer at InterKnowlogy who is an absolute expert in WPF with tons of widely publicized work: “Pro WPF is like the holy bible of WPF reference books. Whereas Unleashed is a great getting started walk through, Pro WPF is a book that I always have within in arms reach to look up hard find WPF features. It also does a good job of explaining why certain features are the way they are in WPF. The edges are beat up and the cover is coming off on my copy of the book. It is a “must have” for all WPF developers”.

Windows Presentation Foundation A Scenario-Based Approach by Billy Hollis This is going to be a must read book for you. Unfortunately it is not out yet. It’s being written by my friend Billy Hollis. He’s taken a dependency on Visual Studio 2010 so this book won’t be available until February of 2010. It can be preordered on the large internet book retailer sites.

WPF Control Development Unleashed: Building Advanced User Experiences by Pavan Podila, Kevin Hoffman This book looks outstanding. Unfortunately it is not out yet and won’t be until September of 2009. It’s being published by the same publisher, SAMS, that does the code snippets in the colors they appear in Visual Studio, making the code really easy to read. I do not personally know these authors, but I love this publisher and this book really does look like a “must read”.

A “Reference Application” is an application with source code whose sole purpose is to help you learn a technology. They are supposed to be functional, but not too complex so that you get lost in the code. The source code is supposed to be heavily commented and include design documentation. They are, by design, supposed to be the best way to learn a programming technology.

The Vertigo Software Family.Show application

The one and only WPF reference application I am aware of that Microsoft officially sponsored (meaning paid for). This application is so good and so popular that has been significantly criticized from under and above the hood. When something is so good it is easy for the human to focus on the bad. I demo it in front of large audiences all the time. It is the basis for many of my developer productivity demos. It does a great job of getting developers excited about what WPF can do.

The InterKnowlogy Adventure Works WPF and Silverlight applications

Adam Calderon from InterKnowlogy created these reference applications because there just is not anything out there in guidance for a normal CRUD application for WPF and Silverlight. At InterKnowlogy we use these two applications as the basis for internal and custom trainings.  We also use them as the technology basis for developer sessions at conferences.  I personally use them in front of audiences when I’m doing Intro sessions in WPF, Silverlight or XAML. They are beautifully written and include all the latest and greatest on the Microsoft developer platform including not only WPF and Silverlight versions, but the latest technologies within the .NET stack.  They are not too abstract or riddled with design patterns which makes the code easy to learn.  Additionally, one of the best things about these applications is the ease of install. They both use the sample database, AdventureWorks2008 that can be downloaded from a number of Microsoft Web properties including CodePlex. These are the perfect applications to start staring at in Visual Studio and Blend when you are learning WPF and / or Silverlight. It is my intention to make these reference applications available for broad distribution to the developer community (Supported by Microsoft including living on the Codplex site).  But, there is a bit of work to do before i can do that.  Firstly, the applications need supporting documentation.  Secondly, we'd like to update them for the latest and greatest including Touch capability and .NET 4.  So keep checking into this living Windows Client Guidance page or with me directly or at my blog.

It’s important for me to swag my definition at the past and present before speculating on the future. With that said this section on the past is going to confuse you if you are 25 or younger. If you are 25-35 you will shake your head with amusement and in disbelief. If you are over 35 you are going to feel a sense of pride and validity and superiority when reading this part.

• Broad Reach - Deploying a green screen application across the world was expensive, if not impossible in all but very rare cases where the cost of the wire could be consumed by the cost of the application.
• Distributed Applications – We didn’t even consider distributing an application in those days. We were lucky if our integration architectures included electronic media. And many times we had to parse print streams in code. Integration mostly meant re-keying the data.
• User Interfaces - Certainly the UX has improved as time has passed. And frankly, until WFP, we had not had dramatic improvements in the UI of the Windows; and most certainly not on the Macintosh. But this simple fact remains that it was hard to write robust applications on green screens, in a client-Server environment and win32 programmers were very talented people which made them rare and special.
• Tools – TSO edit. Edlin : line editors to text editors…no one will argue that visual studio is truly revolutionary.
• Plumbing – even before .NET we took so much for granted. We used to have to write our own print drivers. In this era building the plumbing of an application was a huge part of the architecture. We actually wrote code to allocate system resources like memory – I used to be one hell of a jcl programmer.
• Computer Time – every cpu cycle cost money. You got one shot at a compile so you poured through the cobol on 11*17 green bared paper over and over until you were positive it was going to compile. And you breathed a sigh of relief when it did before you’d have to answer to your boss if it didn’t.

• Broad Reach – we got it. The explosion of Internet Infrastructure and the browser. Suddenly our applications were extended for us, all over the world, 24-7. And a new genre of security problems arose that we still suffer intensely from.
• Distributed – this was the big promise of this era – that XML would even the playing field and it wouldn’t matter what platform the application ran on. Well, this proved to be a lot more complex than envisioned. There’s an enormous amount of black boxes out there. Some of them are licensed not to talk to anything else by design. And we are still dependant on nicely packaged interfaces on the mainframe side – we can’t just plow our way through to db2 or CICS. Most certainly WCF has helped here, but we are still a long ways away from the nirvana of distributed computing.
• Tools – TSO edit. Edlin : line editors to text editors…no one will argue that visual studio is truly revolutionary.
• Plumbing - Now, with .NET we get so much plumbing for free – now we simply concentrate on the application and its architecture. Suddenly the VB / C# programmer has a good portion of the power of the win32 programmer at his/her fingertips. In general terms we rarely think about plumbing code anymore.

I’m a terrible prognosticator. I don’t seem to predict anything correctly deep into the future. I was the guy just a few short years ago predicting the internet’s collapse. To my defense, TCP/IP is an insufficient protocol compared to some of the beautiful binary protocols out there that have existed for 30+ years. The Fax is a better protocol than TCP/IP and that was invented in the 1950s. The internet would have collapsed if a little company called Cisco didn’t make a bad thing worse by creating that 2500 series router. Do you realize how efficient a telephone call is? If I call from Singapore to my home in San Diego, I go 3 maybe 4 switches. If I browse to InterKnowlogy.com from Singapore I’m making 40+ router hops – ridiculous. In any event, I do not have a good track record of predicting the future of technology so it is with trepidation that I write this section.

• Broad reach – In America broadband internet access is finally coming to reality, but the interesting thing is it is being accomplished wirelessly. Europe and certain countries in Asia have always lead the way in infrastructure.
• Distributed applications – certainly web services, WCF and standards getting approved quickly helps in the battle for truly distributed applications. And the big players in the industry driving this is great. I just wish it would happen faster. And no matter what happens, we are still dependant on nicely packaged interfaces.
• Tools – the tools are so good. It’s just not that hard to write good software anymore; at least not like it used to be. But, we are not close to being there. The learning curve is still high. Technology challenges should never compete with business problems. The next version of Visual Studio has some big shoes to fill on the enterprise lifecycle of application development. It also needs to incorporate infrastructure and seamlessly integrate through deployment.
• Plumbing - Now, with .NET we get so much plumbing for free – if we look into the future, one might speculate that the web and windows worlds collide with some form of secure way to trickle download the framework classes as needed. That is a world I want to live in. And since the CLR is truly portable, it sure would be easy to port this version of the .NET framework to other hardware platforms.

I would argue that every developer plays some form of Solution Architecture role in his/her job. Solution architecture is difficult. The platform that you manifest your application on can be a daunting decision for the application developer. Very rarely is the Solution Architecture decision a clear one. There are so many factors involved. That is why so many obvious mistakes are made. Clearly the Windows platform is not always going to be the best choice to manifest your application; but, neither is the browser. There are going to be times when the broad reach elements of a browser based application make a lot more sense for your solution. And there are going to be times where a Rich client solution on Windows makes a lot more sense. And there are times when you are going to be torn on the decision or have to do both.

If time to market is a factor in your decision, and let’s face it, it always is, then the Windows Client might be the right choice for your application. The following factors could also weigh in to your decision.

• Web applications are still more difficult to build than Windows Applications
  • Windows apps are typically less complex to build
  • State Management is the major handicap of web programming
  • The .NET Framework classes in ASP.NET are insignificant when compared to the abundance of .NET framework classes in WPF
     
• The Windows application environment is superior
  • No browser compatibility issues
  • Visually superior and 3D capable
  • Windows Controls are more abundant and superior
  • Windows Controls are more abundant and superior
     
• Historically, Windows apps have been difficult, if not impossible, to deploy which is a good part of the reason for its adoption problems.
  • Touch every desktop
  • The scars of the past, COM: Versioning an app - DLL hell
  • .NET’s “ClickOnce” deployment might just pave the way for windows app-dev dominance
    • Internet users browse to windows executables like web pages
    • Run within a security context – CAS
      • Restrict permissions as appropriate
      • Similar to the way java applets behave

So if you have the luxury to build your solution on the windows platform with a technology like WPF I encourage you to jump in. Use the guidance section above as a tool to help you overcome the learning curve.