In response to my post yesterday, Ed fires back with some good points about user model, window management, and familiarity...

"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." [Ed Kaim]

OK, a progress report on the authoring...

First, I submitted my chapter by chapter schedule for the book. Ten chapters (I wanted 7, but the Overview, Interop, and Base Services pushed me over the limit).

• Chapter 1: Due 12/15 (yes, this is the last chapter i'll write)
• Chapter 2: 5/27
• Chapter 3: 6/13
• Chapter 4: 10/4
• Chapter 5: 10/13
• Chapter 6: 10/25
• Chapter 7: 11/1
• Chapter 8: 11/7
• Chapter 9: 11/17
• Chapter 10: 12/2

My target for the book is ~350 pages. I'm taking some advice to heart - make the book as short as possible, but no shorter (with appologies to Albert).

I have approximately 25 pages written to date. My goal is to try and do about 20 pages a week. I'll have ~6 weeks off for a long vacation this summer, and ~4 weeks off for the PDC. The goal is to sim-ship the book with the release of Avalon.

I've created a new category on the blog "Programming Avalon" for future posts about the book.

Alrighty, today I had a conference call meeting with my team at Addison Wesley that will be involved in the writing of my book. I'm still looking at getting together with Don, but for now I'm pushing forward until we work out the details.

By EOD Wednesday I need to have a chapter by chapter schedule for the book. Should be fun.

I'm planning on releasing excerpts from the book up here on my web site, publised in the new "Metro" document format that we announced at WinHEC. Should be a lot of fun.

Tonight I need to get going on the Preface, as that is my first deliverable to the publisher. Tomorrow night I'll work on my schedule for the rest of the chapters. Should be a fun summer.

As I learned from internal and external folks in comments about my previous post, Quartz is also the name for the DirectShow runtime in Windows. Avalon doesn't directly use DirectShow. When playing video, i've been told, the DirectShow runtime will be loaded by the media subsystem. However, for rendering of all other content (2D, 3D, animations, etc.) the dependency is only on Direct3D.

Always good to be reminded of how little you know :)

Videoguy asks in a comment: "Is there yet more specific information about MIL around? I mean it looks like Avalon uses MIL to interact with the media elements. Is MIL using Quartz (through DX?) on both XP and Longhorn or something else? Can you elaborate on why MIL lives apparently on a native DLL?

If there's some presentation coming or that already answers these questions I'll gladly take a pointer to such too."

Quartz is a Mac OS/X feature, so I think we can rule that out on Windows ;-)

As for the rest, there are two definitions of "MIL" for Avalon. MIL standads for the "Media Integration Layer", and typically refers to either the set of technology that our MIL team produces, or the set of technology that resides in MILCORE.DLL.

MILCORE.DLL is the unmanaged composition engine that Avalon uses for rendering. It is a layer above Direct3D, giving us basic 2D, 3D, Animation, and Composition services (probably a few others i'm forgetting to mention also). The composition engine is unmanaged primarily for interop/performance reasons. The composition engine spends most of it's time talking to Direct3D. In addition, there are multiple customers of the composition engine, including some that can't take a managed code dependency right now.

There is also another unmanaged DLL, WindowsCodecs.dll, which houses all the unmanaged implementation of our imaging codecs - BMP, JPG, etc.

The rest of the core that the MIL team produces lives in PresentationCore.DLL. This is the low level APIs of Avalon, dealing with the base Visual system (2D, 3D, etc.) that is a combination of wrappers ontop of MILCORE.DLL, and a set of value add features written in managed code. Also in the Core is the base implementation for UIElement and ContentElement - the roots our our display element and typographic hierarchies.

Dave saw a presentation on Avalon at Flash In The Can, and had some interesting take aways...

On 3D: "I’m somewhat unclear how detailed the native 3D rendering support is. There was a demo of multiple video sources being mapped to rotating spheres, so there’s at least a few basic shapes and textures. My confusion is partially the result of the ‘special guests’ pulled on stage — a software company that created a 3D -> Flash convertor, which it had adapted for Avalon. Given Flash’s lack of native 3D object support, hence the need for this tool, I’m left wondering what that means for Avalon’s 3D support."

The big difference here is that Zam3D for Avalon allows the full 3D model to be brought into Avalon. You can rotate at runtime, zoom around the model, change lighting, etc. Their Flash based product flatens the 3D to a fixed series of 2D vectors, which gives you a fixed movie, instead of an environment.

On XAML: "The code itself looks like (well-formed) tag soup from 1997. Whereas the web has seen a shift from presentational markup (in the form of tables, embedded attributes like bgcolor, and the dreaded font tag) to structural markup with a separated presentation layer (CSS), XAML is purely a presentational language. I couldn’t see evidence of attention toward semantics, and all the presentational attributes are embedded right in the markup. Januszewski referenced ‘a CSS-like syntax’, but there’s nothing CSS-like about it. It’s ugly presentational HTML all over again. A sample snippet:"

Ah, here is one thing that I think just didn't show through on the demo. Avalon uses a very powerful styling system to allow exactly the type of semantics that Dave talks about. You can have simple markup ("<Button />") and then elsewhere declare exactly what the button looks like (using "<Style.VisualTree>"). I think the biggest difference with Avalon's model is that it is extensible. CSS works great for the fixed set of ~200 attributes that they define, and for their fixed set of elements (I understand that CSS can be applied to arbitrary XML, however the output is limited to the browser HTML render).

This is a platform, so all of this works seamlessly with accessibility, globalization, etc.

On web integration: "I’d be a whole lot more comfortable with XAML if it were strictly meant as a Windows OS rendering language. Proprietary markup on a proprietary platform is nothing to get worked up over. But the obvious web cross-over leads me to hope we’re not going to see a whole new generation of browser/OS-specific web apps. I wonder if Microsoft might be hoping for something different."

Avalon is a Windows platform technology. XAML is a language for binding CLR objects into markup. Avalon elements in XAML is a Windows application markup. The ability to seamlessly deploy and integrate Avalon based applications into the browser is our attempt to bridge the worlds of the web and Windows. Today application authors are forced to choose between rich client applications and familiar browser activation, hosting, and ui models. With Avalon we are trying to make it so that people that want to build rich client applications can leverage the user's familiarity with the browser.

On devices: "What will this code do on a PocketPC or PalmOS cell phone?"

This is a fabulous question, and I can say right now, I don't know. There is some hope that we could build a PocketPC version of Avalon (much in the same way there is a PocketPC version of Win32/User32/GDI/WinForms/etc.). PalmOS is probably not doable, because it isn't based on Windows (Avalon is pretty closely tied to DirectX, which is available for PocketPC but not, to my knowledge, PalmOS - there are other OS dependencies there as well, this is just one example).

Building client software for Phones/PDAs/TVs/etc have very different input and usage patterns. This is an area that I'm really interested in - how much can you really reuse the UI? I'm all for saving the business objects, which I can do today using .NET Compact Framework, but when it comes to the UI, I'm not convinced that any level of styling will make my desktop application "just work" on my cell phone.

Dave isn't universally down on Avalon... there are some great quotes in there:

On Quartz and Avalon: "Without getting too carried away with the specifics though, what seems to be the main difference between Quartz and Avalon is the openness and flexibility."

Anyway, Dave, keep the feedback coming.

If anyone out there knows Dave, I'd love to chat with him via phone, email, or in person.

I've been meaning to blog about Zam 3D ever since I saw them at a recent customer event on campus... Michael Swanson reminded me that they released they CTP build... Super cool tool...

When people ask why Xaml was based on XML, this is a great response!

Nathan showed me the empty site for www.designerslove.net, but at the time he didn't have content... wahoo!, he is posting!

Uhm... except I can't his RSS feed (only atom), and I can't find the permalinks on his site... and there isn't any comments... ouch.

Either way, Nathan is the man behind all the cool visuals we use in Avalon demos. His 3D button is freakin' amazing!

Turns out that my March CTP machine had a slightly different build of the CTP than what we distributed (basically I had an RC on my machine). So, trying to "run" AvPad won't work for anyone. You can download the sources and recompile and it should work. I'm working on getting a copy of the official build we released, at which point I can safely repost the build.

As a side note, it seems pretty screwed up that our binding story to assemblies is so strong that a dot-release on an RC causes everything to fail. I hope I can track down someone on the loader team to explain to me why this should work this way.

I removed the dependency from AvPad to PresentationFramework.Luna... I used this reference when building the new style for all my controls, but it wasn't actually needed to run. According to the comments, it sounds like this was biting some people when running...

As a side note, I set the update frequency to be 3 days, so if you really want to pickup the new fix immediately, you will need to click the run link again.

Run, or download the source and binaries.

OK, with the new March CTP builds (get it today for MSDN, soon for everyone!), I did some major overhauls of "XP", my XamlPad clone. Now it's called AvPad... Some new features:

1. Ships with a complete custom style for all Avalon controls
2. New "radial" menus animate in from the corner (ok, this is kinda a hacked in feature <G>)
3. Better background parsing (waits to parse based upon the duration of time it takes to parse)
4. Child window manager implementation
5. Visual tree viewer

Note Because this requires the March CTP, this will not auto-install if you have the previous version of "xp" installed. You must choose "run" below to get the new ClickOnce subscription...

Run

Source and Binaries

Oh yes Sam, we released again! For right now it's only available to MSDN subscribers...

This new CTP marks the first combined Avalon and Indigo release since PDC 2003. It is awesome to be able to use recent bits from both stacks together.

CTPs are relatively tough things - we release effectively "daily" builds from the labs and publish them. Expect a non-trivial number of blocking bugs and good set of release notes. That disclaimer said, this is by far the best release of Avalon we have had.

Tomorrow morning I'll post the new version of AvPad (my renamed version of XamlPad), complete with a new style for all controls, custom layouts, custom controls, background parsing, all sorts of fun!

Late last year I was interviewed by the folks over at TheServerSide... it just went live... wahoo!

I've written a proposal to a major publishing house. I've talked with several people that have written books. I've considered co-authoring with people. At this point a lot is up in the air (I still haven't gotten an offer from the publishing house), but I think things are moving forward. I've started writing and I have about 12 pages of real material. I'm going to try to set some rules - at least 1 page a day, at least 25 pages a week. Both are aggressive goals, from what I hear.

Probably the most terrifying thing - breaking changes. I know how many changes we are making right now, and the idea of processing breaking changes through a 500+ page book scares the begeezus out of me...

I got a question in the comments of my latest MSDN TV show appearance with a response email address... I figure I'll post a blog response and email the person...

Q: "No definition of what Avalon is: A layout designer? A windowing system to replace Windows API? Absence of contrast to existing methodology that shows benefit. Contrast to Qt."

A: We have talked about Avalon in other forums, so in that particular TV episode we didn't cover the basics. Avalon is a new presentation layer for Windows. It isn't neccessarily a replacement for the Windows API, but more an eventual replacement for specific technologies (User32, GDI, etc.). The roadmap of technologies WinForms, User32 transitioning to Avalon is best answered over on John Montogomery's blog.

Avalon is a rich, integrated, productive UI platform. If we compare/contrast that to other platforms, we see a lot of rich-but-not-integrated libraries (HTML, Flash, etc.). These libraries do a couple things great (text, animation, etc.) but don't really offer a comprehensive integrated platform. We have some productive libraries (VB6, etc.) that offer great developer productivity features, but don't go far enough in richness. The design goal of Avalon was to try to achieve all three:

• Rich: High quality text and graphics with built in animation.
• Integrated: Best of Win32, best of the Web, integrating UI, Documents, and Media
• Productivity: Built from the ground up for developers and designers

We could drill into each topic for quite a while, but for starters lets talk about one of the points - Integrated.

Avalon strives to integrate Windows and Web concepts. We have native support for navigation, custom controls, dialogs, typography, dynamic layout, localization, shell integration, and the preverbial "more". Traditionally developers had to choose between a great client application or something that supported navigation. When you chose navigation you were also forced to implement using JScript/HTML/server programming and running in the browser. In Avalon you can build a navigation application and then decide if you want it to run inside of the browser or externally. Browser hosting is just a bit in the project file. It is simple concepts like this - separating the navigation decision from the rest, that allows this rich integration of windows and web concepts.

I haven't used QT, so I can't really compare. sorry.

Thanks for the question!

Kam VedBrat is blogging... Kam is a new (but not to Microsoft) member on the Avalon team , he specializes in user experience (design, etc) and is working on all sorts of cool stuff.

Very cool solitaire program that Sells wrote... The perf is pretty bad, clicking a card has a delay, etc... we should get this app into our perf lab and figure out what the issues are (besides just the loading of the resources 52 times)... I love the graphic - the hand drawn card faces look AWESOME!

Couple "bugs":

1. Card stack "auto shows" when you pull from it (for example, you take an initial ace from the lower section)... this could be called a feature, but because the "real" sol.exe makes you click, I kept accidentally doing this. Compatibility is a feature :)
2. Cards have a wierd green "box" around them. We are fully composited, it should be transparent around the corners.

And a feature request - change the opacity while dragging to make the cards semi-transparent... that would be cool. Oh, and make every game winnable. Oh, and add cool 3D spinning stuff... and... uhm, I'll go back to work now :(

I'm going to a customer visit next week, and the material is the begining of what I hope to be some of the central story that we are going to be telling at the PDC. I'm really pushing hard for focus on content and the story, and not on power point presentations. Of course there are some good uses of powerpoint, but far too often people get wrapped up in the slides...

I don't have my notes in front of me, but I believe for a 4 hour presentation, this is the outline:

1. Vision
2. Overview & Lap around Avalon
3. Application Model
   1. Navigation
   2. Application Styles
   3. Deployment
4. Building UI
   1. Layout
   2. Controls
   3. Vector Graphics
   4. Resources & Styling
   5. Data Binding

Almost all coding, with myself and Rob... should be a lot of fun!

The latest in the "Inside Avalon" series just got published on MSDN... this time I cover Properties, Commands, and Events... oh my!

[fixed link]

I have to respectfully disagree with Marc Clifton's article on Code Project. There is one definition of what "XAML" is - it is a set of technology that Microsoft is producing. Whether or not we license it to other vendors, people attempt to clone it, or what, there is still only one thing that is XAML. I feel somewhat passionately as I, and other people I work with, invented the thing and are still working on the final definition of it.

If you want to claim that Xamlon, MyXaml, and other attempts at XAML clones are in fact XAML, that is incorrect. They are attempts to clone XAML.

If you article was entitled "what are options in declarative UI definition" and you listed "XAML and Avalon", "Xamlon and Windows Forms/VG", "Lazlo", etc., I would have no complaint. MyXAML is not XAML, Marc even says this himself. Lazlo is clearly not XAML. I don't have anything specifically against MyXAML, Xamlon, Lazlo, Flex, XUL, or any other declarative UI programming models - but I would no sooner claim that XAML was Flex as I would expect Macromedia to claim that Flex was XAML.

I love it when folks in the community do a better job than us! <G>

Gaston Milano wrote his own XAML viewer that is integrated into Visual Studio. [Link From RRelyea]

Rock On!!

After integrating Daniel's 3D demo, I realized what I really wanted was on out of band way of post "demos" into XamlPad... so, XamlPad is now a connected client... There is a "Demos" menu that is populated from a web service and downloads the demo you chooses on demand. Of course, the next release (or soon there after) will cache the demos locally, but for now I can start publishing demos out of band...

Also, I fixed some parsing issues (parse in idle instead of key press), and some other minor fixes.

Again, once you install from the ClickOnce file, you don't need to force the upgrade, it will trickle down somewhere in a day or so... (or, for those of you more impatient, just run the link again <G>)

Daniel Lehenbauer ported his Amiga inspired demo to the new CTP build... not to be outdone, I shaved off enough of the demo so I can run it straight in XamlPad... XamlPad is now much heavier (up to ~200Kb), but there is a snippet that is Daniel's bouncing ball (lights and reflection removed to make it not require any code)...

I added a new menu to the XP menu - "Reset Snippets", which will let you get access to the new snippet.

Note For some reason, if the text area has focus the animation is really choppy of the ball. The work around (super hacky!) is to click the splitter bar (giving it focus), then the animation seems much better. Hopefully someone at work tomorrow can investigate...

Just to make sure everyone understands the last post I did, I thought I'd simplify a bit and explain what everything is... First, a warning: when working on this post I ran into a lot of cases where XamlPad would hang or crash. Not sure the cause, I'll work on debugging this tomorrow. For now, I would suggest editing in notepad and pasting into XamlPad. My guess is that there is something about tearing down and recreating the Windows Forms controls that is causing a hang...

<?Mapping
  XmlNamespace="windowsforms"
  ClrNamespace="System.Windows.Forms"
  Assembly="System.Windows.Forms" ?>
<?Mapping
  XmlNamespace="windowsformsintegration"
  ClrNamespace="System.Windows.Forms.Integration"
  Assembly="WindowsFormsIntegration" ?>

<Grid
xmlns="http://schemas.microsoft.com/2003/xaml"
xmlns:x="Definition" xmlns:wf="windowsforms"
xmlns:wfi="windowsformsintegration">

<wfi:WindowsFormsHost>
   <wf:Button Text="Hello From Windows Forms" />
</wfi:WindowsFormsHost>

</Grid>

Anyway, the first two tags are "mapping PIs". These will be going away in a future rev of the XAML spec, but for now they are the way to import a namespace/assembly into an XML namespace. We need to import System.Windows.Forms and (because XamlPad is written in Avalon) the System.Windows.Forms.Integration namespace. SWF.Integration is there when you need to host Avalon in Windows Forms or vice versa.

The root tag is a Grid, really it could be about any Avalon element. Then we have the WindowsFormsHost, which is an Avalon element that knows how to host a Windows Forms control. Finally we have the Windows Forms Button tag, with it's text set. Really the only whacky part is the mapping PIs.

Oh yes, it works!

Avalon, XAML, and Windows Forms

Using any rev of XamlPad, you can paste the following XAML into the window and see Avalon and Windows Forms components interoperability. Wahoo! I added a new snippet to XamlPad rev 8 that is this sample. If you have a current version of XamlPad, just delete the snippets.xml file from your My Documents\XamlPad directory and XamlPad will automatically recreate the file. I should probably add a feature to recreate this file. Check this out:

<?Mapping XmlNamespace="windowsforms" ClrNamespace="System.Windows.Forms" Assembly="System.Windows.Forms" ?>
<?Mapping XmlNamespace="windowsformsintegration" ClrNamespace="System.Windows.Forms.Integration" Assembly="WindowsFormsIntegration" ?>
<Grid xmlns="http://schemas.microsoft.com/2003/xaml" xmlns:x="Definition"
  xmlns:wf="windowsforms"
  xmlns:wfi="windowsformsintegration">

<Grid>
 <Grid.ColumnDefinitions>
  <ColumnDefinition Width="*" />
  <ColumnDefinition Width="*" />
 </Grid.ColumnDefinitions>
 <Grid.RowDefinitions>
  <RowDefinition Height="*" />
  <RowDefinition Height="*" />
 </Grid.RowDefinitions>
  <Button Grid.Row="1">Hello From Avalon</Button>
  <Canvas Grid.Column="1" >
  <Ellipse Width="50" Height="50">
   <Canvas.Top><LengthAnimation From="0" To="100" Duration="8" AutoReverse="True" RepeatDuration="Indefinite" /></Canvas.Top>
   <Canvas.Left><LengthAnimation From="0" To="200" Duration="2" AutoReverse="True" RepeatDuration="Indefinite" /></Canvas.Left>
   <Ellipse.Fill>
<LinearGradientBrush><LinearGradientBrush.GradientStops><GradientStop Offset="0" Color="#FFFFFFFF" /><GradientStop Offset=".33" Color="#FFFF0000" /><GradientStop Offset=".66" Color="#FF00FF00" /><GradientStop Offset="1" Color="#FF0000FF" /></LinearGradientBrush.GradientStops></LinearGradientBrush>
   </Ellipse.Fill>
  </Ellipse>
 </Canvas>
  <wfi:WindowsFormsHost Grid.Row="1" Grid.Column="1">
   <wf:Button Text="Hello From Windows Forms" />
  </wfi:WindowsFormsHost>
  <wfi:WindowsFormsHost>
   <wf:TreeView>
    <wf:TreeView.Nodes>
      <wf:TreeNode Text="Hello">
        <wf:TreeNode.Nodes>
          <wf:TreeNode Text="Hello" />
          <wf:TreeNode Text="Hello" />
          <wf:TreeNode Text="Hello" />
          <wf:TreeNode Text="Hello" />
        </wf:TreeNode.Nodes>
      </wf:TreeNode>
      <wf:TreeNode Text="Hello" />
      <wf:TreeNode Text="Hello" />
      <wf:TreeNode Text="Hello" />
      <wf:TreeNode Text="Hello" />
    </wf:TreeView.Nodes>
    
   </wf:TreeView>
  </wfi:WindowsFormsHost>
</Grid>

</Grid>

Rob posted the steps for fixing up the WinFX SDK to work with C# Express... THANKS!!! I think there is a slight typo... on my machine the double-double quoting of the directories got my command window angry... here is what I did:

set MyVisualStudioLocation="%programfiles%\Microsoft Visual Studio 8"
copy "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\ProjectTemplates\CSharp\Avalon\1033\*.zip" %MyVisualStudioLocation%\Common7\IDE\VCSExpress\ProjectTemplates\1033
copy "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\ItemTemplates\CSharp\1033\*.zip %MyVisualStudioLocation%\Common7\IDE\VCSExpress\ItemTemplates\1033
copy "%programfiles%\microsoft visual studio 8\xml\schemas\avalonFall2004CTP.xsd" %MyVisualStudioLocation%\xml\schemas\
copy "%programfiles%\microsoft visual studio 8\xml\schemas\xamlFall2004CTP.xsd" %MyVisualStudioLocation%\xml\schemas\
%MyVisualStudioLocation%\Common7\IDE\VCSExpress.exe /setup

Basically, I had to remove the quotes from around the target of the copy commands.

I've released about 7 builds totaly of my XamlPad Clone now (just pushed one up)... In the latest release (v1.0.0.7) I moved the location where files went by default (to My Documents\XamlPad) to allow you to run as admin, and to find the files since ClickOnce puts the application in a random directory. The Snippets file is there also, so you can add new snippets - you'll have to restart the app once you update the snippets XML.

Some discoveries:

• Our default manifest generator kinda sucks - I have to hand edit it each time to update the company and application name.
  
• Internally we had several problems with left over crud from random installed builds breaking deployment... hopefully that shouldn't be a problem for many of you folks out there.
  
• I have no idea how many people are installing or using this thing. I think I'm going to add an OPTIONAL ability to notify me when you install it. We'd like to track (at least internally) how many people fine the application useful. I'll probably also put in a little feedback form so people can complain about problems and suggest features since I don't have comments on my blog.

I'm releasing drops frequently for my XamlPad clone, and will continue to do so... ClickOnce deployment makes this pretty simple. New features I added:

• Simple refactoring - specifcally "surround with" for a couple tags
• Snippet support - added a couple common XAML fragments
• Formatting - run the XAML through XmlTextWriter's formatting engine
• Editting arbitrary files - pass a xaml file in on the command line and it will edit that file instead of the default file

I won't be releasing source for a bit, I'm going to play around with binary deployment for a while. A lot of these features are super hacky right now, and I'd like to move to a more data driven model before I release the source (also it's a bit of a hassle to package up the source and everything else... anyone know of a MSBuild extension for including the source in a package?).

Anyway, if you install via the .deploy that I've linked to, these updates will appear automatically sometime between 1 hour and 1 day after I release the build. You can manually force a refresh by clicking on the link again.

I really want to publish this application as a auto-deployed application using ClickOnce technology, however I need to get my friendly site administrator to make a few tweaks to the IIS config... anyway, for the time being you can download the ZIP file (including source) for a little test application for Avalon.

The application is simple, you type XAML in the bottom pane and it gets parsed and rendered in the top. If you type code in error, the error is displayed at the very bottom. This is a clone of an internal application "XamlPad" that some folks wrote... I happened to be without the app on a flight to WinDev last month, so I wrote this clone... Have fun!

XP binaries and source.

[Added Link]

Today we released a new build of Avalon to the world (well, anyone subscribing to MSDN)... This build of Avalon runs on Windows XP (and Windows Server 2K3, but not the PDC or WinHEC Longhorn builds)... which is pretty cool. Last night I tried to get C# Express and everything installed so I'd have a cool application available today, but it looks like that didn't happen.

I'll be blogging and writing code on this build for the next couple months (I'm taking most of December off from work, and like the geek I am I intend to write some code!)...

A couple points:

1. This is a "Technology Preview"... translation - rough bits. While I'm willing to install this on my home machine, I don't recommend you put this on your primary development machine. It requires installing a beta build of .NET, etc.
2. You also need a pretty beefy machine to run the bits.
3. This build will run on Windows XP
4. This build will not run on PDC or WinHEC Longhorn builds
5. This is not the final API set, XAML spec, or anything else - this is a "Technology Preview"

I'm super excited by this. Nothing gets me more jazzed than getting bits into customer's hands. Download the build, install it, and give us feedback. You can send feedback through official channels (forums, newsgroups, even your own personal blog!), or you can always just send me mail at: ChrisAn (at) Microsoft (dot) com.

Aaron gave me a great compliment on his wrapup of Win-Dev... "whose keynote I thoroughly enjoyed - it was the best motivation for rich client applications that I've heard to date"...

Thanks, and congrats on sponsoring a great conference!

Thanks for the response Miguel... I'm still trying to digest the Slashdot thread also (I'll respond on Slashdot for that thread... )...

Before I start, I'm not taking any of this personally - I really enjoy debate, regardless of the opinions. As far as I'm concerned, bring it on! More Feedback == Better.

Security

The low-tech (aka phishing, aka con artist) attacks are being worked on. The social engineering and human behavior/interaction research is happening, it's just not on my team.

As for the "weakest link" characterization of ClickOnce, I think you are confusing some things.

ClickOnce is a deployment technology that improves upon the base technology introduced in .NET 1.0 for downloading and loading code. ClickOnce supports a subscription and application manifest. A principle advantage to the approach is that a customer can establish a subscription to an application and get automatic updates. In addition, the application manifest creates a complete descriptions of the parts of the application - enabling both validation and download/install/uninstall to be implemented by the system.

Next in the stack is CAS - Code Access Security. This is the security system built into the CLR. This technology has been in place since .NET 1.0, and we are continuing to iterate on it. In addition in Whidbey (the version of the CLR that we are talking about here) has a new level of application level security that can "lock back" the permissions of the loaded assemblies to that of the application, further limiting attack vectors.

In the middle of this is the TrustManager. This is a piece of code that provides a user with a single consistent prompt to determine what they want an application to be allowed to do. For example the application might request higher permissions or local installation. The goal here is to remove the half dozen security dialogs that users get prompted with today, and messy installation wizards, with a consistent user experience, giving them complete information.

All of this technology together, gives us the user experience that is (as you put it) one of the fundamental reasons for Avalon to exist. A perfect (or much more secure) computer would be one that you never plug into any network and have no software installed. You wristwatch is pretty secure is my guess.

We are doing usability studies on all of this, to validate that this is going to improve the situation... I'll keep you posted.

Complexity

I've used a handfull of GUI libraries; VB6, IE, WFC, AWT, Swing (limited exposure), KDE/QT (very limited exposure), and Cocco (limited exposure). Cocco was amazingly complex in my usage, the library felt like MVC on steroids with a pretty cool UI designer. KDE/QT felt a lot like WFC in C++, fairly straight forward. Swing, was, well, swing. MVC everywhere, powerfull, but very complex. I found that at JavaOne most of the Swing sessions started with a 15 minute talk on how you really can make Swing fast if you just understand MVC more. I think that the recent versions of Swing are much improved on this, my data is a little dated here. AWT was simple, but I felt that the event adapter model and peer model didn't lend itself to good usability, toolability, or performance. Anyway, I could go on... I'll try to take a look at Tk and XView, if they offer better simplicity, it would be great to learn from them.

The point about abstracting implementation from API is very interesting. The COM model has a very clear abstract, but removes the ability to deal with implementation inheritance. The AWT model of peers supported inheritance, but the real meat of what you wanted to deal with was locked away in the peer. We really wanted to embrace the "component framework" model that is present in ASP.NET and Windows Forms (yes, I know they have a peer model because of the HWND, but the WndProc is directly accessible, etc.)... the idea was to provide component developers full access to the implementation and not special case any Microsoft code as much as possible. The idea being, anyone should be able to implement "Button" and do all the same features we did, with no penalties.

This does come at the cost of more public exposure, but we hoped it would be worth it.

I know that Button is too trivial of an example to really talk about, so lets talk about lists, or more specifically ListBox. In most programming models that I've used the ListBox has a data model of providing strings - this is the Win32/AWT way (I think Cocco also?). Windows Forms added support for "object", but basically you had to .ToString() the thing to get it to display... unless you implement your own custom rendering. In all the systems I've seen the custom rendering is implemented in a completely different programming model - paint code in most systems.

Avalon has a simple "scalable" model. When I say scalable I mean to imply that the API starts simple but can scale up to support complex scenarios without requiring a massive leap in understanding - pay for play in complexity.

<ListBox>
    <string>Hello</string>
    <Image Source="http://..." />
    <Button>Hello</Button>
</ListBox>

You then can get into styles to manipulate all of this:

<Style>
    <ListItem />
    <Style.VisualTree>
        ....
        <Rectangle RadiusX="5" RadiusY="5" />
        ...
    </Style.VisualTree>
</Style>

The key thing is that I never had to switch programming models. Yes, if you try to digest everything at once (styling, binding, commanding, visual trees, etc.) then the system is complex - but the goal was scalability - Make simple things simple, and hard things possible.

Standards

First, an old post from Joe Beda about SVG and XAML.

Second, dismissing the CSS debate isn't really fair. A critical part of our design is unification. We didn't want one markup model for vector graphics, one for styling, one for 3D, one for data, etc. Another part of the unification was "Markup == OM", that is, we didn't want a separate markup programming model from code. HTML is this way, the markup and the code have a loose relationship. If we ignore the unification debate, I can understand how it seems simple to say "you should have used SVG".

Avalon is a developer platform. We want to enable an entirely new breed of applications that span UI, graphics, and media. Integration of typography with imaging with video with controls with styling is a core part of our value proposition. We aren't trying to create a new 3D system or animation system, we are creating a new developer platform.