I’m looking forward to being part of an interesting conference, and hopefully helping to lift the profile of EVM in New Zealand.

Link to presentation abstract

( The abstract’s reference to “Number 8 wire” may be unclear to overseas readers :-)  The phrase simply means “New Zealand ingenuity”, in this part of the world.)

By the way, this means commenting finally works properly again.

My full presentation is here, although sometime I hope to isolate the middle section (on workplace interpersonal skill) so it can be viewed as a stand-alone 15-min presentation. [Done] As it stands, the presentation is 30 minutes on these topics, with 5 mins of questions at the end.

Virtually all the presentations are up now. If you’re wondering where to start, I can recommend Kay Johansen’s excellent session on Agile Testing, which I learnt a lot from; and Jeff Patton’s two-part workshop on story mapping, because story mapping is such an important idea. (And Jeff made it so interesting, it didn’t seem like it was 3 hours long.) I thoroughly enjoyed the whole conference, and can recommend every session that I attended. Now that the videos are up, I’m looking forward to seeing the ones that I missed.

If you like this blog (and presumably you do, since you’re reading it ;-)  I think you’ll love the conference.  It’s a new and different kind of agile conference, focussing back on the core principles of the agile movement.  In one respect, it’s like a giant retrospective for the agile movement as a whole — but it’s also much more than that.  For details, see this page on the conference blog.  I strongly encourage you to attend if you possibly can.

By the way, I’m presenting a session with the deliberately strange title of “Better Agile Through Stealing”.  (Thanks to Bevan Arps for the idea for the title.)  The talk is consistent with the material on this site, but most of it is brand new material which I haven’t blogged about yet.

Hopefully, I’ll see you there!

Why does everyone want web applications?  What happened to old fashioned applications, so-called “rich clients”?  (Applications that is. Rich customers are still very popular, when you can find them :-)

I use the term rich client to refer to applications where an exe file runs on the user’s machine.  Other terms such as “smart client” mean (more-or-less) the same thing.  Rich clients are seldom stand-alone.  They usually connect to a middle tier using Web Services, .NET Remoting, or a similar technology.

Right now, web clients are the most popular option.  This article explains why rich clients ought to make a comeback.  The article covers three things: why rich clients have fallen out of favour, how .NET addresses those underlying problems, and some rules of thumb for which type of client to use.

Why Rich Clients Became Unfashionable

Deployment is the big problem with rich clients.  The exe file must reside on the user’s machine.  It is expensive and time-consuming to install software on a large number of machines, and to make sure it stays up to date.  This is even more difficult with applications that rely on DLLs and COM objects (as most rich clients did before .NET).

As an industry, we have chosen to solve the deployment problem by not deploying software.  Instead, we write web applications with HTML user interfaces.

Of course the dot-com boom helped to boost the popularity of this approach.  The boom has gone, but the industry’s mindshare has stayed with web interfaces.

.NET and Deployment

With the .NET framework, many of the old deployment problems are gone.  The only downside is  the intial installation of the .NET framework on each user’s machine.  This is not without its problems, but since they have been discussed extensively elsewhere, let’s move on and look at the deployment of rich clients under .NET.

[Update 15 Dec 06: Microsoft Vista includes the .NET framework, so as Vista gradually takes over most of the world's desktops ;-) the framework deployment problem will diminish further.]

After the framework is installed, there is a subtle change in the behaviour of Internet Explorer.  If you  click on a link to a .NET executable, Internet Explorer will just download it and run it.  No questions asked, no dialog boxes, “no nothing”.  It just runs.

If you’re using Internet Explorer, and if the .NET runtime (version 1.1) is installed on your PC, you can try it right now.

There are two special things happening here, two things that are different from clicking on a hyperlink to an “old fashioned” exe file:

• There is no dialog asking if you want to download and run the program.  This is OK because of the strict security checks enforced by .NET.  [See note at bottom of page if you did get unwanted prompts.]
• The application is cached in a special place for downloaded .NET applications.  Next time you click the link, Internet Explorer checks the web server to see if the cached version is still up to date.  If it is, the cached version is used directly.

Note: This style of deployment is technically known as an “HREF EXE”.

Security

Applications downloaded like this are subject to very strict security restrictions.  So strict, that they cannot actually do very much!  For instance, they can read files from your machine, but only when those files are chosen by you in the File Open dialog box.  The .NET framework ensures that they cannot open any other files “behind your back”.  They cannot write files to your machine at all.

Security measures like these make downloaded .NET applications very safe, but also very limited.  If you want to deploy a more powerful application in this way, you need the user to perform a one-off manual “setup” step.  This simple manual operation tells the computer to increase its level of trust for your application.  Basically, it’s a way for the user to say, “See this application here, grant it these extra permissions”.

I won’t cover the details here.  Instead I’ll refer you to an article on Microsoft’s site, written by Chris Sells.  By following the approach advocated in that article, it is possible to deploy powerful rich clients securely and easily.

When To Use Rich Clients

Rich clients have several advantages over web clients.  Rich clients:

• Can support more features
• Provide a more responsive “user experience”
• Tend to be faster and easier to develop

It is worth noting that rich clients are not in any way a “worse” architecture than web clients.  It is still possible (and advisable!) to separate the GUI, business logic and data access.  Typically the rich client will handle the user interface and will communicate with a middle tier using Web Services or .NET Remoting.

Articles on Microsoft’s web site describe the advantages well:

“[Web] user interfaces are, by nature, primitive to use and difficult to implement and maintain. … You would have thought that long ago people would have given up building HTML applications, at least for situations like the corporate intranet where the client environment is tightly controlled, but so far, HTML still has the mindshare.”  – from an article on .NET Zero Deployment

“Everyone seems to be fixated on Web applications. Web applications are a great way to get the largest reach, but for more than occasional use
, Web applications are a poor imitation of what’s available in a richer client that Windows Forms enables.

…

Windows Forms [i.e. rich] applications tend to be much easier to develop.”
- from an article on using rich clients for easier state management

In summary, good reasons for choosing a web client include:

• You need the application to run all virtually all client platforms (e.g. it is available to the public over the internet.)
• Users will use the application infrequently (and therefore don’t expect to download anything)
• The user interface is simple
• Users do not have the .NET runtime (e.g. dial-up modem users in particular, since even if you provided an installer for the .NET runtime, it would still be a 22 MB download.)

A rich client may be the better option if:

• You must minimise the time and cost of development
• Users use the application frequently (and therefore will appreciate the snappier performance and greater features of a rich client)
• The user interface includes features that are difficult to create in HTML
• Users have, or can easily get, the .NET runtime.  E.g. they are on a corporate intranet where the runtime can be “pushed” onto each workstation, or simply installed from a network drive.

Update, 27 March 2004:  There’s a new article on this subject on MSDN.  It includes comprehensive discussion of the business case for rich clients (with a little Microsoft marketing mixed in :-)  It doesn’t really cover details of web deployment under .NET 1.x, although it does mention “ClickOnce”.  When MS release the ClickOnce technology, in the 2005 “Whidbey” release of Visual Studio .NET, deploying rich clients will become even easier.

Update, 2 April 2005: Two more useful links from Microsoft, which offer alternative ways to grant extra permissions to your application.  This one uses the caspol command line tool; while this one packages security information in MSI files.

Update, 11 Mar 06: For some reason (presumably some “Microsoft Security Updates” which I’ve applied) I now get some prompts when opening the sample program (above) on my home PC. I don’t know why. I’m sure ClickOnce avoids them – although it does have a different dialog box of its own.

Update, 21 Feb 07: Here’s the answer.  Web deployment of .NET 1.1 apps is broken by installing .NET 2.0 on the client machine.  If you have .NET 2.0 on your machine then you always get a prompt, about opening it, rather than the seamless opening without prompts which I describe above.  Note that this affects internet apps, such as the sample on this page, but does not affect intranet (internal, coroporate) apps -  which is where I expect this technology is generally used.  Note that this only affects the old style of .NET 1.1 web-deployed applications.  Naturally the new .NET 2.0 style, ClickOnce, works fine under 2.0!