Is the Rich .Net Client ready yet?

May 15, 2004 @ 11:30 am

On my trip to Amsterdam to the SDGN Conference I had a chance to talk a bit with Chris Anderson from Microsoft. Chris is heavily involved in the Longhorn team and especially with Avalon which is the codename for the Longhorn desktop/graphics engine. As might be expected Chris is a strong proponent of Client Side development and he jokes frequently about wanting to kill off the ASP. Net team and converting long time server buffs into client side developers.

I have long been a proponent for getting away from HTML based interfaces and moving to a more distributed architecture that relies on rich client apps with a Web backend via Web Services or other XML based mechanism that pulls the remote data as needed. In fact, in 2000 just before the release of .Net I wrote an article about the Diminishing Importance of HTML regarding this topic. I think the content of this article still applies today, but to the detriment of the point in this article, the trend away from HTML has not materialized as strongly as I would have thought.

This may have many reasons of course. For Microsoft developers especially I think that the focus of Web development has just drastically overshadowed client side development in the last few years because Microsoft has pushed server development very heavily. .Net 1.x certainly has had mostly a server push with ASP. Net and the WinForms end of it feeling more like a last minute addition that wasn’t quite ready for the release. It works but there are many small problems with controls and implementations that either seem incomplete or not quite thought through all the way.

The end result is that today most new applications are giving first shrift to HTML based Web applications, simply because it seems the most common and in some ways the easiest route to getting content out to users. For some scenerarios this is definitely true today, but for many others the choice to go to a mixed rich client and server implementation is a choice that’s often plainly overlooked or simply ruled out.

In fact, I got caught in this when talking to Chris who challenged with a simple question: “What do you do with digital images?” to which my proud answer was that I publish them to a custom application on my Web site. I upload the pictures to my site either via FTP or via the included Web interface that sends the images up to the server – another click allows creation of thumbnails and an admin page allows re-ordering, resizing and a few other options to lay out the album. That’s fine and well for somebody like me but I hardly qualify as Johnny Average Computer User who would likely have a few problems with this arcane interface to send up the images. Chris countered with the point that a decent client application could do a much better job of allowing selection of the images from the media card or directly from the camera, previewing and manipulating the images (cropping, basic image adjustments etc.) and uploading of the images to the Web Site.

Aside from the fact that this is an overly simplistic scenario, I do agree strongly on this point for the best user experience this makes perfect sense. But even for my own photo album application that I use very frequently I have yet to build this rich client front end. Building the Web Front end for this app was pretty easy (a few late nights), but building a Rich Client front end for this app by the same token would take a lot more doing and essentially require the creation of a separate application and development cycle. It would take a lot to make this process more compelling and well, I don’t feel nearly as motivated to do it as I did for building the Web photoalbum in the first place. It also requires that the Web backend is in place and well thought out (and in fact would require some changes to work with a client front end). In other words, a lot more knowledge is required to build this sort of an application compared to either a Web or Fat Client application.

Certainly Microsoft could make my life easier for this sort of thing on the client side. For example, here a Common Dialog for image manipulation would come in handy. A GetPicture() type dialog that allows previewing images from lists (in a thumbnail format), the ability to rotate images, crop, adjust brightness and contrast, color balance etc. and then save and select the image. Sure there are opportunities to make things easier and if Microsoft is serious about working more effectively with common media types (of which images and audio are probably the #1 consumer feature) they could provide features along these lines out of the box for a common user experience.

To build these kinds of distributed applications requires significant additional resources – resources that enhance usability, but otherwise don’t necessarily enhance the functionality. The point is it’s gotta really pay to build the rich client front end ontop of the Web functionality to make it worthwhile. I suspect the same is true on a larger scale for a more significant development effort. I certainly have been on a few projects where I’ve pushed for a rich client front end and it was almost always overruled for a plain HTML based Web implementation. There’s a stigma to overcome…

I’ve built these kind of two way interfaces for a long time – I started doing this way back in ’95 with some of my Fox Web apps. For example, my Message Board includes an offline reader that provides a ton of functionality that is not part of my Web based Message Board running on the Web site. I built the rich front end because I replied at some point to over 75 messages a day and it was much easier and convenient to use the markup tools and other aids in the rich client application to create my messages.

The reader was free available to all, yet very few people used it. Even today when it installs as part of a couple of my products, it's still lightly used even though now it's already installed anyway! It’s definitely useful and provided in this case significant feature enhancements. Why? Two issues I think: Installation and the feeling that it’s easier to run something in the browser. There’s a distinct stigma associated with installing applications these days and this is something that Microsoft has to work hard to overcome if rich client is going to come back in force.

Now Microsoft has given us opportunities to make this sort of thing more transparent in .Net with the ability to run .Net applications off a URL. Unfortunately in Version 1.x this model is severely limited due to the security configuration that makes it next to impossible to run a useful application off the Web without having to modify the machine security policy (and a whole lot of fun that is!). Essentially to run any semi-sophisticated app on the client downloaded from the Web you have to give full rights to it using CASPOL or the .Net Administration tool. For commercial, broad reach applications this is not an option. It might work for internal corporate apps, but for consumer applications the .Net security model is way to complex to throw at consumers of an application.

ClickOnce in Whidbey promises to address this issue by better control on figuring out what rights are required and providing a customized security policy for this. All of this can be packaged up into a sort of light-weight install package that can install from a URL and can provide the same easy versioning that you get with a pure Web backend by automatically checking and installing updates.

While this is a big step in the right direction, I’m not sure that this helps perceptions. Clickonce still feels like an install and the security policy needs to be installed and accepted has potential for the sloppy ignorance we were used to back when ActiveX controls and Java applets were commonly floating around in Web pages. If we get enough of these dialogs that ask us to install a custom security policy to run this or that app, we’re back to accepting all the security dialogs and just allowing installation of anything which puts us right back at an insecure environment. It’s a sticky issue.

So what’s the answer here? A change in perception. Lightweight installations are key and it seems that ClickOnce may address this well. Security is a tricky subject always. If it’s secure it will give people confidence to install, but if it’s too secure we won’t be able to run the damn code. What to do, what to do?

There are no easy answers, but it’s an interesting topic that has many conflicting facets to think about. I’ll have more on this topic in a few days as there are more reasons I think that thin client or even Fat Client apps with distributed backends will still be a while off…

Feedback for this Weblog Entry

re: Is the Rich .Net Client ready yet?
by Steven Black May 15, 2004 @ 6:32 pm

This is a superb article, Rick.

So in short, it's really a people problem. If so, then the solution is probably way outside the realm of VS.Next.

The fragmented client-side world consists entirely of installations of "Windows.Prior" and "Browser.Prior", and hopefully "Runtime Version X". Therefore richer client-side "Solutions.Future" fundamentally can't scale, and VS.Next can't really change that.

With current infrastructure, protocols, and methods, creating rich channels with trust at the channel endpoints is ridiculously difficult. So we must live with the current security constraints. Again, VS.Next can't change that either.

Another bummer is, from a business perspective, continuously replacing boxes and/or upgrading OSes to "Windows.Future" is economically expensive, very frustrating, and at current levels of windows maturity and saturation, it's frankly unrealistic to expect businesses in the developed world to move quickly anytime soon. So in a sense, like it or not, we are stuck with our Minitel here.

All this means that the real breakthroughs will need to be server-side. The world needs a standard client-side executant compatible with "Windows.Ancient" that runs lightweight "Terminal Server.Next" forms. In other words, we'd write fat-client apps, to be thinly and transparently servable anywhere.

**--** Steve

re: Is the Rich .Net Client ready yet?
by Rick Strahl May 16, 2004 @ 11:39 am

Steve, I think Microsoft is well aware of the difficulties especially with security and this is in large part what Indigo is driving at. Indigo is supposed to consolidate a lot of the protocol stack and provide the infrastructure to provide built in security at the protocol level so it's transparent to the application. Whether this can be accomplished and be kept simple/transparent is another story, but this is at least part of what you hear coming from Microsoft.

It's an interesting thought to think of Terminal Services as a possible future avenue to host rich client apps. Given that bandwidth is likely to continue to go up and power of boxes as well, this might be an opportunity to greatly simplify the development of complex client/server apps and still get hte distributed aspect of apps. We're not there yet though - neither bandwidth nor hardware makes this possible today for anything but small scenarios. There's also the issue of what do you do in a disconnected scenario... there's no offline capability in a TS environment.

As far as hardware goes I think for the most part we're ready for what's available. Although there are slow points, these are more a nuisance than an insurmountable problem. With distributed applications the bottleneck is likely to be the connection for a long while to come.

The legacy issue is something that will only be overcome if there's a compelling reason to switch. I don't see this now, but slowly but surely this move will happen, surely on the Windows platform.

+++ Rick ---

re: Is the Rich .Net Client ready yet?
by Gabe Hudson May 17, 2004 @ 1:19 pm

Not sure if you've heard about this or not, but the future of Windows programming (forms) is based on a new XML format called XAML...
http://longhorn.msdn.microsoft.com/lhsdk/core/overviews/about%20xaml.aspx

This will make programming windows forms applications very similar to programming ASP.NET apps. As a matter of fact, I'm sure you'll be able to easily deploy XAML applications via the web. Long story short, they have made forms based off of a markup language. Pretty cool.

re: Is the Rich .Net Client ready yet?
by Rick Strahl May 17, 2004 @ 9:25 pm

Yeah of course I've heeard of XAML, but I don't think this changes anything in regards to how client apps are build. XAML is just a front end for the Windowing engine - IOW, you can still use plain code to gen your UI.

I'm not sure if this is an improvement or not. The reason this is cool for ASP.Net is because prior we didn't have an object model to address. But WinForms always had this model, so there's not the huge AHA experience. I think the only thing that gets easier with XAML is for the vendor to build the definitions via markup rather than generating the code directly.

The key feature of Avalon IMHO is the ability to layout text in different ways and hte ability to mix grid and flow laylout. This will make it easier to design attractive interfaces and hopefully get out of the 'boxed UI' mode that we've always worked with in GUI apps. Of course it'll have the side effect that you will get ever more truly hideous applications for those that abuse the visual effects to create interfaces that might give you nightmares at night :-}...

re: XAML
by Gabe Hudson May 18, 2004 @ 1:47 am

I think the two real benefits of XAML are...
1.) Unification of the rich client and poor client programming models.
2.) The ability to (easily) distibute fat client applications over the internet. If the interface simply consists of XAML files and the application logic (or most of it) resides on the server, it should be fairly fast. As long as the client has the ability to render XAML, the user will have a rich GUI.

Of course, other technologies and models already exisit to do just this (even the current .NET implementation). However, I think when XAML is one of those evolutionary steps that finally brings everything together and allows this kind of technology to take off. Only time will tell. (It wouldn't hurt if they made it cross platform).

re: Is the Rich .Net Client ready yet?
by Rick Strahl May 18, 2004 @ 5:54 am

I think you're reading too much into XAML. XAML is just the page description and XAML won't be used both for WinForms and .Net. The format and feature set is way too different.

You will already be able to run apps off the Web (well, you can do it now except for the shitty security issues) using ClickOnce. XAML isn't going to change this model.

re: Is the Rich .Net Client ready yet?
by Steven Black May 26, 2004 @ 9:44 am

What I was referring to with the TS comment is imagine, for a moment, if you could run a *really* lightweight version of TS that is not exposing the desktop, or anything related to the desktop, but just the area of a window (form) that normally runs on the desktop but, for the purposes of this session, just exposes and runs the form area.

Lightweight enough that a reasonably modest server could run hundreds or perhaps thousands of these concurrent mini TS sessions.

This, of course, would change everything, and would seriously redefine computing as we know it.

It also would be a switch, a massive de-bloating of the kernal for one thing...

re: Is the Rich .Net Client ready yet?
by Rick Strahl May 28, 2004 @ 10:04 am

Steve, that's an interesting proposition, but i think that this still will not be a scalable solution in the near future (until computing resources get another order of magnitude greater). The problem is that TS or a TS light approach still requires dedicated connections to the server in order to work. As long as you have the connections on the machine there are going to be scalability issues because TS is inherently a two way mechanism. You're trading connectivity requirements for bandwidth requirements in this scenario.

I don't see how this could be changed either since the whole concept of TS is that you have a full interactive UI that needs to be two-way responsive at all time.