mark feinholz

I sometimes forget that WPF is still not out of the oven.  I talk and talk about WPF smart clients, when and where and why they make sense, how the developer and designer will be enabled with a new tool set to build next generation user experiences... as if it's already released - my bad.  The summer has been wearing on, fall is around the corner, and so is the V1 release of WPF.

Here's a great post by Tim Sneath with an update on what the WPF team is up to as they head full steam towards Release Candidate 1.

Xbap's are .NET 3.0 WPF smart client applications that are hosted by the browser – IE 6 or IE 7 only at this point. It’s an ugly name XBAP… pronounced x-bap.

XBAP is actually the extension of the file that you navigate your browser to in order to launch the application.  XBAP stands for XAML Browser Application… but that opens up a can of worms… again, it’s an ugly name.

Here’s a quick summary of the worms: 

Even though XBAP stands for XAML Browser Application, It’s not really a "XAML application", it’s a WPF smart client application.  XAML is just the programming model.  IMHO, you can call a standards Web application an “HTML application”, but you can’t call a WPF application an “XAML application” - it just confuses people still trying to get a handle on what XAML is.    Here’s why:  You likely – but not necessarily – used XAML to define the user interface of the XBAP and then you built your application, which means the XAML was compiled and wrapped up into a .NET EXE – bye-bye XAML.  

Then  when you publish the application, a ClickOnce application manifest and a ClickOnce deployment manifest get generated for that EXE.   The ClickOnce deployment manifest is an XML file that describes the deployment and serves as the launching point for a ClickOnce application and guess what… with WPF, that deployment manifest is give the extension of .XBAP (this deployment manifest in a Windows Forms ClickOnce published application is given the extension of .Application – not to be confused with the  application manifest that is also generated by a ClickOnce publish and given the extension of .Manifest – that’s right, another can of worms, for another day)

… so we call these applications “XBAP’s” – and I need to just learn to deal with it :)

Above I said that XBAP’s are “hosted by the browser”, what the heck does that mean?  It means that when you navigate to a URL that points to an XBAP, or find yourself on a page that has an IFrame whose source property is set to that same URL – the WPF smart client application will be launched inside the browser’s frame, it will look like you navigated to just another web page, but instead you are running a WPF smart client application.  No install step, no shelling out to a separate top level window on the desktop, the browser is the top level window.    The first time you go to this “page”, you’ll see a quick progress bar that indicates the WPF app is being downloaded to the machine – but subsequent trips to the same page will pull the application from cache.   And of course when a new version is deployed up to the server, then you’ll get the download again - for the parts that changed.

It's easy to immediately see the security risk here, a full blown smart client app running on my machine at the click of a link?.  Don't worry, XBAP's run in the sandbox, they only have internet or intranet zone permissions to the local machine (depending on the URL they are launched from) and as such have a limited set of capabiities.  In trusted line of business application scenarios it is easy to elevate these permissions though.  The XBAP manifests have to be signed with a cert that is installed on the client machine as a trusted publisher, then the XBAP can get elevated permissions.  If the cert is not installed on the local machine as a trusted publisher though, you won't see a permission elevation dialog - the app will just not run.

In order for XBAP's to launch hosted by the browser, .NET 3.0 has to be installed on the machine.  If you’re using IE 7 and .NET 3.0 is not installed on the machine, it will prompt you and then download and install it… but make no mistake, this is not a light plug-in experience like having to install an ActiveX control to get a web page to work, this is a 40mb or so download that requires local admin rights to install.  So my point here is, don’t think about an XBAP as requiring a download to run, think about an XBAP as a smart client application that requires the .NET 3.0 platform on the local machine.

So, once you’ve gotten over the hurdle of being limited to the Windows .NET 3.0 platform (even though you're hosted by the browser) – I think you’ll find that XBAP’s are very cool.  They are a fundamental piece of the WPF vision: it’s deployment story.

Accruent, an ISV in the retail and enterprise real estate business, has built a WPF smart client that is tightly integrated into their web portal solution and it is deployed as an XBAP.  They have created an application experience that combines the best of the capabilities of a web app with the best of the capabilities of a smart client and the typical workflows of a Microsoft Office user.  Check out this Channel 9 video to see Accruent's app and get a really good idea for how XBAP’s can work in LOB App scenarios.  It’s kind of a long video, but it’s worth it – it is a very powerful demonstration of the possibilities of combining Office, portal and WPF smart client solutions into a cohesive whole that enables the work force.

This note from Tim Sneath contains a good summary of a few other resources for getting your head around XBAP's, including a few cool sample apps and the blogs of 2 PM's on the WPF product team at Microsoft responsible for XBAP related features.

IE 7 is coming and it will be delivered as a required update by Windows Update.

This is another data point when considering whether or not to build LOB apps that are only wired to work properly in a specific browser.  The day will come - it may take 5 years but it will come - when the browser you certified your business app to run in will be upgraded to a new version - and it won't be on your schedule, it will be on the browser publisher's schedule. 

Going forward the IE team is promising to release new versions at a much quicker pace - which makes this issue a more real concern than it has been for the past 5 years.

So don't do that... if it needs to run in the browser, then make it a standards based app that is coded and tested to run in all the modern browsers and this won't be as critical an issue.  Your app won't stop working until you get out a version that works in the new version. 

If it only runs in IE 6 - then make it a smart client instead.  You won't have to manage your release schedule around that of the browser publisher.

It's not an either-or world.  Back in 1999, "bricks and mortar businesses" were going the way of the schooner, the steam powered "pure play Dot Com" businesses were going to motor right by all of the floundering store fronts as they sat waiting for a favorable breeze.  Yea, right.    

I just read a Wall Street Journal article titled "Is It Time to Dump Your Desktop: Web-based software claims to do everything".  Have we not learned anything in the ensuing years.  Granted, the article itself is much more rational than the headline, but I find myself wandering into conversations all the time where one person in the conversation is arguing that "every" app of the future will be browser based.  

Outlook and Outlook Web Access (OWA) get along very nicely together.  Outlook power users would be lost without the full blown version of Outlook on their laptop, and they would be equally lost without the ability to quickly check their mail from some other machine using OWA.  I currently use beta versions of Outlook 2007 and OWA 2007, the user experience of each are both huge steps forward and they continue to complement each other.

I know nothing about the future plans of Office Live, but I can easily guess at a picture of the future that includes a Word Web Access and an Excel Web Access, and that doesn't mean the desktop is dead.  It means just the opposite: the desktop will be connected and "live".  If anything, it was dead before - when desktop apps were not connected, collaborative experiences.

WPF is breathing new life into the user experience capable of being provided by Windows smart client applications and at the same time AJAX developers are reaching new levels of cool with what they are doing in browser apps - both are taking huge steps forward, both will continue to complement each other.

Microsoft has it's line of Office client applications that need to continue to evolve into a more powerful line of live clients that combine the best of the desktop with the best of the web - but, um, I think you're nuts if you count out Microsoft's ability to make this happen.  The desktop is not dead just because Google is working on a browser based spreadsheet product.

It's not either-or.  Bricks get along very nicely with Clicks - or is it the mortar that gets along with the clicks? hmm...

quick update:   Funny thing happened as I was walking out to my car here at Microsoft's Mountain View campus after posting this entry - a Google employee stopped me in the parking lot and asked where he could find the HR office because he was interested in "transferring" from Google to Microsoft.  Nice guy, kind of stumbled on the word he was looking for, I don't think he really meant "transfer" - but kind of goes to the point of this post - maybe Microsoft and Google are the "bricks and clicks" and are getting along even better than I thought.

Continuing on for a moment with our discussion of "reach clients":

An application that can run on any client regardless of hardware or operating system, that will never run into any download and installation problems, and that leaves no footprint on the local machine is definitely an attractive proposition.  Reach clients are the right choice for many applications, especially those that cannot take a dependency on a specific client platform.

But the reach client in the browser does provide a restricted application environment, so there is a cost – decreased user experience.  Depending on the application, this tradeoff may be well worth it, often times however, the productivity and business opportunity cost associated with a drop in user experience will far outweigh any deployment advantage gained by a browser based reach client.  We'll talk more in a future post about what "user experience" is, the role/importance of user experience, etc.

Not All Browser Based Apps are Reach Clients

All reach clients run in the browser, but not all browser based applications are reach clients.  As we talked about in a previous post, many line of business client applications were built to run in the browser for reasons other than reach.  They often are engineered to the features of a specific browser – typically Internet Explorer, and rely on hosted ActiveX objects.  Reach is therefore specifically not supported or required.  But the browser was never designed to support the needs of sophisticated operations oriented transaction processing applications.  As a result, developers have struggled for years to come up with tricks to work around these limitations.  Examples include techniques to prevent transactions from double posting as a result of user actions that cause the browser to re-issue an HTTP Post request, and approaches to formatting reports, receipts and letters for print.  The browser was invented for… well, browsing.  Smart clients are the answer to these more sophisticated application needs.

The issue then becomes, what platform do you build a smart client on.  The answer depends on your environment and customer base.  In this blog we're going to spend our time discussing .NET 3.0 smart clients which run on the WPF platform - and require Windows XP, Windows Server 2003 or Windows Vista.  And we'll touch on .NET 2.0 smart clients - which use the Windows Forms platform which runs on Windows 98 and above with current service packs.

Yesterday I spoke with a dev at a startup here in the Valley who was telling me tales of his struggles in trying to build an advanced LOB application using AJAX techniques in the browser.  When I asked why the browser, he said because their target customer base use both Macs and PC's.  Simply put, for V1 of their app, they need reach.  So I do get it - the entire world does not run XP.  But for those that do, wait till you see some of the client applications that they'll be getting, we'll be seeing in the coming years a new standard for user experience!  Would a superior UX trump a need to run the software on a Mac - we won't know in the near future in this specific case, but keep your eyes out for companies that choose UX over reach... or better yet, in addition to reach.  It is all about providing options that the competition doesn't.  Many will pay extra to drive a Mercedes.

I like to classify client applications into one of 4 buckets:

1. Desktop.
2. Smart Client
3. Standards Reach
4. Rich Reach

Desktop and Smart Client apps I talked about in my previous post.  So that leaves us these 2 “reach” categories. 

What do I mean by reach?

Here’s the Readers Digest version: Reach apps run in the browser and are designed to work in all major modern browsers running on all modern client operating systems.  Standards reach refers to Ajax/HTML applications.  Rich reach refers to applications that require ubiquitous proprietary browser plug-ins to work.   Flash is an example of a rich reach platform.

Here’s the long version (again, the focus here is on LOB applications, but this discussion does apply to consumer scenarios as well):

Reach – 2 Perspectives

Like “rich”, the word “reach” means different things to different audiences.  One way to look at reach is from the perspective of a software consumer.  From this angle,  a LOB application can be considered to have a good reach user experience if the user can access the application in the most productive and efficient way possible from whichever device they happen to be using at the time.    There are 2 key components to a good reach user experience.  First, the application can be accessed from a variety of devices in a variety of scenarios, and second, the experience is optimized for the device, so that the user experience is as productive and powerful as the platform and scenario allows. 

A good reach user experience means the status of a critical customer order can be pushed to a cell phone while on the golf course, it can be polled from a public Sun workstation at a Java conference, and it can be reviewed and used to generate opportunity proposals from a corporate laptop running Windows - while traveling home on the train without network connectivity.  From this perspective, that of the user, reach does not mean one client interface that  that can be accessed anywhere, it means being able to optimally perform a business function using the most appropriate device from where ever the user happens to be.

Another perspective to take when talking about the term reach is that of the software publisher.  In order to obtain the reach user experience described above, multiple clients will be required. A client for a handheld device that can operate in a semi-connected state, a client for a corporate managed PC that can expect to leverage a variety of local resources, and a client that can run on just about any computer that has a standards based web browser.  To a software publisher, this last ubiquitous browser based client is known as the “reach” client.  It is important to keep in mind that the reach client is only one piece of an application strategy that results in the reach user experience as described above. 

Reach clients run in the browser and can be broken into two categories: standards based reach and ubiquitous rich, or rich reach. Standards based reach clients are truly zero-footprint based clients that utilize HTML, JavaScript, CSS, DHTML and other technologies that all modern standards based browsers recognize.  Nothing other than the browser has to be installed on the machine for this client to run.  Microsoft’s standards reach technology is ASP.NET and the new Ajax platform – Atlas.

Rich reach clients are applications that rely on ubiquitous proprietary technologies to achieve an enhanced user experience in the browser – and won’t function without the necessary plug-ins installed and enabled on the client machine.  Flash is an example of a ubiquitous proprietary technology.  It is a browser plug-in that runs in all modern browsers and on all common operating systems.  It has achieved ubiquity - Flash V7 is already installed on around 95% of the computers on the internet.  Usage of Flash can be categorized in 2 ways, as a technology to add rich “islands” in an HTML application and as a complete replacement for the HTML interface.  Applications built with this second approach are ubiquitous rich clients… they won’t function without Flash.  Microsoft's goal is to expand the WPF/XAML platform out to this rich reach category with WPF/E.

Shades of Gray

These four categories are easy to describe, but there are of course many applications that don’t fall crisply into one or the other.   For example, many browser based LOB applications were developed to run in IE only, they often require ActiveX components and only work in a specific version of IE.    These “IE applications” were likely built as browser applications to achieve ease of deployment and/or access beyond the firewall, not to achieve ubiquitous reach.  IE applications do not fall into the categories of desktop, smart client, standards reach or rich reach as I’ve described them, and I’m OK with that, because I don’t recommend building them for many reasons that we won’t get into now.

Another example of an application that does not fit neatly into only one of these categories is an HTML application that uses Flash “islands”.   In my experience, these applications can usually be categorized as either primarily HTML or primarily Flash and therefore we can “force” them into either the standards reach or the rich reach classification.

What’s Next?

We have much more to discuss.  In this post and the last I've introduced smart client and defined my 4 categories for describing client applications.  I personally am a fan of a premium user experience - the best the hardware in front of me can offer, so I have a bias towards smart clients.  But all four application categories I've described have their place, I am in no way advocating the demise of desktop and reach applications. 

What LOB scenarios require reach?  Why is the browser still interesting, even if reach isn’t a requirement?  Where does Ajax fit in?  Where does a WPF application hosted by the browser (xbap) fit in?  What is this WPF/E stuff all about? Why exactly does WPF re-invent this entire discussion? Stay tuned, and keep that mail coming.

I’m going to try and describe what a smart client means to me, please let me know what you think. 

The focus of this conversation is on LOB apps, but the discussion applies to other scenarios.

Without spending too much time on the obvious, I think a quick step back in time will help set the table for a definition of what a smart client is.

A PC on Every Desktop:

Before the advent of the browser, we were in client-server mode.  Microsoft’s vision of a PC on every desktop had pretty much materialized – and that revolutionized the workplace.  LOB apps were being cranked out quickly using a variety of RAD tools such as Visual Basic and PowerBuilder and a host of others.  But IT soon found they had thousands of PC’s running tens of thousands of line-of-business applications and of course DLL-hell was in full swing.  Installing one app often resulted in others breaking.  Business logic often ended up mixed in with the client presentation code (remoting business logic to a server based process wasn’t an easy task – unless you put it in the database.) So changing a business rule meant updating thousands of client installations – and that usually wasn’t easy. Admin rights were often required and of course DLL-hell ensured other apps on the machine would break.  All of these apps were stuck on the LAN, inside the firewall – they talked to databases on corporate servers using proprietary protocols.

I’m obviously generalizing a bit, but yikes, things were a mess.  That’s what we went running from,  those nasty thick client, desktop LOB applications when Netscape gave us the browser.

Browser based apps solved all of these problems.  They provided clear separation of presentation logic from business logic, were hosted on the server, were easy to install and manage, and accessible outside the firewall.

By the late 90’s, all new LOB applications it seemed were being built to run in the browser, and all ISV’s were scrambling to re-engineer their ‘legacy’ desktop applications to run in the browser.

But wait, they called it a ‘browser’ for a reason.  When I’m wandering through Best Buy, looking at 50” flat screen TVs, I always get a clerk asking if they can help, and I say: “No thanks, I’m just browsing”.  I’m not interested in transacting business with you, I’m just browsing.

HTML allowed great new presentation capabilities as compared to Win32, but I don’t think anyone would argue that HTML over HTTP was designed to support the rich interactivity needs of transaction processing oriented LOB client applications.

The benefits were too great though: TCO, reach beyond the LAN, 3-tier application architecture… and if that wasn’t enough there was that Dot Com fever – money was only being spent on browser based apps.  Users would just have to get used to clicking an “edit” button on a row of data in a grid to tell the server to redisplay the entire page with the requested row in “edit” mode - and then clicking again to save the change to the database, causing another complete page refresh.

Fast Forward to Today

First we saw the power of a PC on every desktop then we saw the power of the internet, now it is time to combine the 2 and deliver the next generation of user experiences.  Three technologies have emerged that have completely changed the desktop vs. web equation: web services, server based client deployment frameworks and the new Windows graphics and presentation subsystem – Windows Presentation Foundation (WPF).

With web services a desktop installed rich client application can easily centralize business logic on the server where it can be re-used by all – and with careful use of security protocols that desktop app is no longer confined to the corporate LAN because web services of course run over HTTP on port 80.

Client deployment frameworks such as Microsoft’s .NET 2.0 ClickOnce  platform combined with .NET’s side-by-side XCOPY deployed assemblies provide a server based deployment and update model with no more DLL-hell.  There are still thousands of installed clients, but they all know to update themselves when a new version is posted to the server – and there’s no chance that an update will break other apps on the machine.

And then there’s WPF.  The best of Html and Win32 and a whole bunch more, all rolled up into a new markup syntax and single .NET API for delivering UI, documents and media.

So let all of those negative connotations of installed, thick-client, desktop applications go. 

In its purest sense, a smart client:

1. Leverages local resources to provide the best user experience possible for a given client platform.
2. Communicates with distributed components via web services. 
3. Downloads and runs from a centralized location, potentially installing to the local machine, without requiring administrator privileges and seamlessly updates itself when a new version becomes available.

There are a thousand shades of gray when it comes to identifying an application as a smart client or not.  We still have very powerful desktop applications such as Adobe Photoshop and Microsoft Excel.  These applications typically require an admin to install, they update the registry, they work with local data, they require a new license and a high-impact install to upgrade to a new version, etc.  Smart clients are a new class of application that sit between desktop applications and browser based web applications. 

I’m certainly not here to campaign for the replacement of all applications with smart clients.  Desktop applications and browser based web applications definitely have their place, we’ll talk more about that in future posts.

Another dimension to the discussion is the client platform.  Smart clients take advantage of the local client platform; they don’t sacrifice functionality by providing a lowest common denominator application that can run on multiple platforms.  Smart clients can be built for hand held devices such as those powered by Windows Mobile 5, for Windows PC’s, for Linux PC’s, for Macs, etc.  In this blog – in the coming weeks, I’m going to focus on Windows smart clients written to run on Windows XP or above, specifically the .NET WinFX platform.

So before we go on and talk more about why it makes sense to consider Windows smart clients.  Take a second to ask yourself why your LOB application is in the browser.  There are plenty of good reasons – again, I’m not suggesting all LOB apps should have smart client interfaces.  But think about your scenario, why are you in the browser?

Send me some mail, let me know.

In my next post I want to talk about 'reach' and round out my categorization of client applications into 4 buckets: desktop, smart client, standards reach, and rich reach.

Welcome to my new blog, I intend to wax on about all things client and user experience related -  with a heavy bend towards the Microsoft smart client stack in LOB application scenarios. 

About me: Mark Feinholz.  I work in the Developer & Platform Evangelism group at Microsoft – and spend my time with large ISV’s engaged in early adoption projects.  I spent 2+ years working with early adopter customers on Windows Forms 2.0, now I focus all of my time on Windows Presentation Foundation (WPF).  I’ve been developing software in one form or another for 20 years this summer (wow, that just hit me).

Now that Ajax platforms are showing up that are enabling an entirely new generation of HTML-based user experiences (without having to have a PhD in Java Script and DHTML) – I’m constantly hearing the question:  “So if I can now get a rich, interactive experience with Ajax, why exactly do we need smart clients again?”

I’m going to spend some time in the coming weeks talking about why smart client, and why the browser, what does it mean to be a ‘web application’, what does ‘reach’ mean (to the software publisher as well as to the user), what does ‘rich’ mean, what is so frickin cool about WPF and why it changes everything... and more stuff like that.

I’m going to try and keep the posts on a higher level discussion of different client technologies and where they all fit in – at least for now.  It could be I’ll jump into talking about how to twiddle the WPF bits every now and then, but not at first.  

Of course, the standard disclaimer, this is me talking, not Microsoft.  I am interested in your feedback; I want to get more in touch with the communities opinions on these sometimes very religious topics.

If you’re reading and you care, send me an email (markfe@microsoft.com) or post a comment and let me know what you think.

We'll start with the next post and take a shot at explaining what a smart client is.