Ed Kaim - Why Navigation Is *HUGE* In Avalon

February 2010

Sun

Mon

Tue

Wed

Thu

Fri

Sat

Navigation

Developer Marketing

Home

SharpLogic Software

Blogroll

Sunday, May 08, 2005

Why Navigation Is *HUGE* In Avalon

I came across Chris Anderson's blog and he raised the question of "why did web navigation really add value?" This question really echoes the question that comes up from lots of briefings I've given on Avalon: "Why is navigation important in Avalon?"

One of the messages Microsoft has driven regarding smart clients and Avalon is that they combine the "best of Windows, best of the Web". Although I've never been a huge fan of that specific way of describing the benefits, it's definitely the most concise way of describing the goals: take Windows client programming (the *best* client offering in the industry) and integrate features of the browser-based programming model (often incorrectly referred to as "Web" programming) to provide something better than either independently. By the way, when I say "browser-based" consider a blanket include for HTTP and HTML.

While there are tons of sexy features coming in Avalon, my money is on navigation as the single most important feature. Sure, the MIL, simple 3D, styling, declarative design, great tools, interop, etc, are all cool, but navigation is what Windows client programming is most sorely missing today and will benefit most from in Avalon.

The benefits delivered by navigation support in the browser were really a happy accident. If you look at how the Web works, it's a "Web" because of the way you can hop from one site to another and criss-cross your way from anywhere to anywhere else. The integration isn't complex--it's basically HREFs, POSTs, and GETs. What these enable, however, is a way to write large systems to address business needs in such a way that they are really a set of smaller building block applications that can be glued together (often dynamically). The typical login functionality of any given site can be treated as a distinct application that has a set of preconditions and postconditions. Although you would be able to use it standalone, it would deliver little value on its own. However, you can still see some sites, such as Microsoft's Passport, that are able to offer authentication as a standalone service because the navigation support in the browser makes it that easy. The net result of all of this is that an end user can easily do whatever they need to, regardless of the underlying technology.

In contrast, Windows client programming today (Win32, .NET, J2SE, whatever) has a programming model that is much less conducive to integration.

First of all, browsers are great because they provide an easy way for you to build an app that never requires the user to leave the window. For client apps, there is no comparable support. The most obvious workaround is to recreate the current window to look like a different part of an app every time the user would "navigate" to use different functionality, which is something nobody wants to do. As a result, you'll find that almost every single app will require a new window in order to accept login credentials for an end user. Why is this? Partly because nobody wants to write and test the code that hides all the existing controls and replaces them with new controls just so the user doesn't have to deal with a new window. Windows also doesn't provide a way to replace the existing window's contents with a new set of contents without doing the work by hand. The closest thing is to use a wizard, but wizard support didn't make it into the .NET Framework. Even with wizards, they're not great for branching as much as a set of unique pages and a navigation infrastructure would be. Avalon will address this by providing a way to develop standalone pages within an app that you can navigate to and from.

Second, today's Windows applications are heavily "stack-based", meaning that there's no such thing as fire & forget with UI. Every event handler is like a clingy ex-girlfriend--they will need closure before you can get on with the rest of your execution. The transfer of control from one part of the application to another is tightly coupled to the internal implementation and the idea of having one app transfer data and control to another is all but impossible (the command line is the only thing that pops into mind). As a result, application UI components can be partitioned into windows/forms, but they're still not standalone components and are at the mercy of their caller. While browser apps are made up of individual pages that are pretty much service-oriented with the way they have very defined boundaries in their interaction with the end user, client windows in the same app are very tightly coupled and inaccessible to other applications. Navigation in Avalon addresses this by providing a clean break between different parts of an application. You can take a page and treat it as a standalone application (in many respects) and develop for it in the same way you would a Web page today. Unfortunately, I don't believe there will be support for integrating across applications in the same way, although I will admit that it's been months since I've spent serious time with bits and am very open to happy surprises.

Lately, I've spent a lot of time using Microsoft Money 2005. If you build smart client apps today, it is well worth your time to get a copy and play around with it. Although it obviously wasn't built using Avalon, I think it best represents the benefits early Avalon apps will deliver. The best part of the app--and perhaps the best indication of a smart client--is that you can use it whenever you want to and will always get the best experience available. If you're offline you can work off a local store. If you've got Excel installed, you can export to it. If you want to integrate data from online bank or credit card account applications, you can do it without having to leave the shell. Its homegrown navigation support is not used as extensively as I'd like, but it's very well done.

5/8/2005 4:56:19 PM (Pacific Standard Time, UTC-08:00)