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.