Post a Comment On: the urban canuk, eh

One of the dazzling showcase items of this conference is the Windows Presentation Foundation (Formerly code named "Avalon") and the WinFx applications that are built upon it. Several sessions have been focused around it, especially around the kiosk application that was built for The North Face -- a feature rich application with dazzling graphics and hi-definition video sure to drop many jaws of developers and designers alike. The really great thing about The North Face, as a premier early adopter of WPF, is that it is so completely over the top that it is going to reset the bar, and next generation applications will leave the web as we know it today far, far behind. But before we get into all that exciting goodness, let's talk more about WPF. This new distributable that will be downloadable for Windows XP and shipped with Vista is a framework for building feature rich next generation windows applications. Already we're seeing it being heavily utilized by the next-generation version of Windows Media Center bundled into Vista. Unlike GDI+, WPF is more than a set of classes and code examples; it's primary delivery mechanism is through structured Xml documents which drive the presentation elements, known as "XAML" (which is being pronounced as "Zam-mel"). Aside: When I first saw this, I didn't know what to think. As I was mulling it over walking to the next session, a Microsoft employee asked me what I thought. I smiled and replied, "Kinda reminds me of Liquid Motion" which got a good chuckle from him. Hardly anyone remembers this, but ten years ago, Microsoft tried to compete against Flash by creating a tool that created ActiveX based animations with DHTML. It failed miserably, and rightfully so -- it was like building a website using the PaperClip. It takes a second or two to fully realize what exactly XAML is, and it requires you to take a leap of faith in the presenter, because initially it doesn't makes any sense. At its core XAML is a markup language that describes presentation layer elements: a page, a grid, some text, an image, a button. If that was it, we could all log off and call it Miller time. But instead, XAML goes further to describe vector graphics, animations, complex 3D modeling, lighting and transformations. To put it into context, imagine a custom shape with a drop-shadow sitting on a shiny reflective surface with an cool fog slowly undulating in the background, described purely as markup with absolutely no code. That alone is very cool. Now add data-binding from an external xml file and provide scripting support from a codebehind, and your head is spinning. I'll definitely want to download the community technology preview and play with this technology. As a complete aside, just to give an example as to how next-generation XAML is, all colour representations are now 4 bytes (8 hex characters #FF3C3C3c) where the first byte represents opacity. As XAML can get very confusing very fast, Microsoft is introducing a new tool called "Expression" which is graphical designer that ...well, looks like Flash MX. Tweening, objects, timelines, but with a Microsoft Visual Studio sort of IDE. After seeing how simple objects can be transformed into majestic elements simply by changing properties of objects through the IDE, the great light-bulb in your head goes off and we see that our designers and flash developers can enter the production cycle earlier, working on the same file format and at each step it becomes more specialized. This is all very exciting, so why am I being skeptical? Okay, skeptical is a poor word. How about apprehensive, worried, or uncertain? One of my uncertainties comes from the fact that this is the first convention I've attended where Microsoft is making a deliberate effort to involve graphic designers. Traditionally Microsoft uses personas to identify developers (like "Mort", the VB6 spaghetti-procedural-code developer turned VB.NET object oriented procedural programmer) but Microsoft has no established Persona for designers(, yet). Which begs a very good question -- how well has Microsoft identified with the designer community? and.. Will the designer community abandon their traditional Macintosh and Macromedia tools in favour of Microsoft technologies? Or are we going to get rid of them all and make our developers graphical designers? (god help us, no) In the end, if there is no adoption from the designer community then it's becomes all promise and no delivery. After all, if I was responsible for Flash development, it'd be stick figures and powerpoint style animated text with swooshing noises. Microsoft probably knows this, and that's why this conference is trying to tickle designers into gleeful hysteria. My second apprehension is surrounding the "demo-factor" of the The North Face example. The gotcha is that it is not a web application, but rather a full-blown executable that is going to be running on high-performant PCs inside the North Face stores. The North Face went with a kiosk application because of the sheer size of hi-def video files and needed hardware acceleration to pull off hi-def movies rendered into a 3D Modelled space. I can also assume that there's a lot of custom application logic and controls that had to be hand-coded, and probably a lot of hours in trial and error to make it the killer app that it appears to be. Fluid, the agency who did the implementation, referred to their whitepapers for explanations of key concepts, but how much code will represent howto's within WPF/XAML versus core application logic is yet to be seen. Taking WPF to the Web In addition, there's a lot of talk about Windows Presentation Foundation for Everywhere (WPF/E) that works like a flash substitute as a browser plugin. A lot of people are wondering just how much of TNF can be ported to the web experience, and what the implementation will look like. In fact, the session I attended for WPF/E was about 40 minutes demo / 40 minutes of endless questions. WPF/E is an interesting beast, with gotchas of its own. The first one being that WPF/E won't be available until after Vista launches. The others are hard to explain, so I'll start by explaining what I know (which is very little). At the same time, this technology is bleeding edge and is more than a year out from ship date, which translates into another 18 months before market penetration is significant enough to make this discussion relevant. Although this is not a definitive list, the targeted audience for WPF/E is IE 6 SP2, FireFox / Mozilla 1.x, Safari running on Windows XP or Mac OS X. There appears to be some discussion happening about Linux support as well, but like most things that are a year out from their release, everything is "under consideration". Most of the examples shown in the sessions used an object tag (embed tag for FireFox) with a CLSID and a script block that hosted the XAML as a data-island, though some examples did illustrate referencing the XAML as an external file. From a client-scripting standpoint, JavaScript is the language of choice to directly manipulate the XAML through its Document Object Model just like it was DHTML; changes to the XAML are immediately reflected in the browser. A second option for scripting exists which the presenter quickly glossed over, but the audience was so horrified by the implications that it inspired dozens of follow-up questions (people started lining up at the microphones seconds after he moved to the next slide). The second option sounded like we were witnessing the birth of the Anti-Christ in ActiveX version 2.0 format: You can write your script in C#, compile it into a wpse file and then download it to the client where the runtime will parse the IL and execute your code. Sounds like a recipe for disaster, and I can just picture the continual stream of security advisories related to it, but I don't think it's as bad as it sounds. Let's decipher Lucifer... Mentioning "IL" to a conference room of .net developers means "managed code", and it also implies that the end-user must have the .net framework installed. Not true: "IL" in this case refers to an IL interpreter as part of the WPF/E browser plug-in. The classes within the WPF/E can be compiled using the same compiler built into Visual Studio, but only the classes within the WPF/E will be accessible via client-code. As such, you won't be able to include .net core classes that require the .net framework as part of the wpse file. Automatically executing arbitrary code simply by visiting a page on a website is scary and implies massive security holes that will be continually patched up. Also not true, but I'm willing to place bets that exploits will eventually be made. The classes within the WPF/E namespace will be limited only to the rendering engine and manipulating the XAML DOM. Currently, the wiring of the codebehind to web-services for AJAX style XAML inside the wpse is "under development". As an aside, it was mentioned that cross-domain scripting for IL won't be supported for version 1.0, probably because they don't want to expose themselves to security exploits. The thinking here is they want to do it right the first time. Compilation of code implies that my codebehind is somehow available for download and bundled with my assembly, or, we're creating projects for each xaml file? Although I didn't understand the explanation that was given to me (it's something i need to see), they glossed over it by saying my MS Build script would compile my xaml codebehinds and bundle them up. Referring to my "MS Build Script" really means someone better get cracking on the wpse Nant contribution for CruiseControl integration, or I need to better understand what they mean by "bundled up". The other observation that I have is that most of the code samples provided were ports of the The North Face kiosk application, which may work fine to demonstrate the portability of XAML to the web, but the actual implementation of that code is unsuitable for Internet applications. To illustrate, one of the samples is this amazing product shot of a jacket which can be rotated in 3D. Under close inspection of the sample, the product shot is not a 3D rendered model represented in a SVG format, but rather a collection of transparent PNG images taken in 360 degree angles. Where the example breaks down, is the javascript that manipulates the XAML is simply changing the image path to represent the requested angle of the product shot: if these images aren't preloaded, the experience will be remarkably different online compared to when the images are being served locally. Issues like this are fundamental problems that start alarm bells ringing in my head. Flash developers have long since identified and addressed these issues ages ago, and we take them for granted -- yet these problems are essentially brand-new and waiting to be rediscovered by a new set of developers. While this can be seen as a cost impedement to adopting WPF/E versus Flash, this is clearly an opportunity for early adopters and advocates of this new technology to establish key best practices. Since XAML is a well structured document format, we're already better positioned to start building tools and third party libraries compared to the current state of cobbled together flash solutions. Kinda wants you to go out and buy a Wrox XAML book, doesn't it? All in all, it looks like it's an amazing technology that is going to radically change many aspects of web and desktop applications. But its the minor considerations that cast shadows of reasonable doubt that will keep the Jury closely watching its evolution before coming to a decision.