TV version (Display Regular Site)

Skip to: Navigation | Content | Sidebar | Footer


Weblog Entry

Avalon/XAML First Look

April 14, 2005

Familar with Microsoft’s new XAML? I wasn’t, until recently.

During the first day of the recent FITC conference, Karsten Januszewski (a Microsoft tech evangelist) gave a talk on the forthcoming Avalon. The relevance to the audience was that advanced media and UI features made possible by Avalon will eventually require creators, many of whom Microsoft hoped to reach here. Developers, developers, developers…

My familiarity with the technology up to that point was limited; I had basically thought of it as Quartz (OS X’s advanced screen rendering system) for Windows. I’m still not convinced the technology itself is much more than that, actually. Avalon composites many different types of media — text, images, video, and vector shapes. 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.

Quartz vs. 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. Avalon goes hand-in-hand with XAML, Microsoft’s upcoming eXtensible Application Markup Language, which is XML in name if not in spirit. The upshot of which is that controlling the display is as simple as editing a human-readable text file. (Although the Microsoft rep was quick to point out that by no means will this be the only way to do it as current and upcoming design tools adapt to generate XAML automatically.)

That everything in Avalon runs on text files is actually pretty slick. I’ll give Microsoft substantial credit for that, it’s going to ensure a lot of adoption. Put anything in text and it’s pretty much an open format to some degree. But there are two things that detract from what otherwise might have been full points.

The Code

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:

   <?xml version="1.0"?>
   <Canvas 
       xmlns="http://schemas.microsoft.com/2003/xaml"
       xmlns:def="Definition"
       Width="500" Height="500" Background="White">
       <Canvas.Resources>
         <LinearGradientBrush def:Name="RedGrad" 
           StartPoint="0,0" EndPoint="1,1">
            <LinearGradientBrush.GradientStops>
               <GradientStopCollection>
                  <GradientStop Color="#FFFFFF" 
                   Offset="0" />
                  <GradientStop Color="#FF0000" 
                   Offset="0.5" />
                  <GradientStop Color="#000000" 
                   Offset="1" />
               </GradientStopCollection>
            </LinearGradientBrush.GradientStops>
         </LinearGradientBrush>
          </Canvas.Resources>
           <Rectangle
              RectangleLeft="0" RectangleTop="0"
              RectangleWidth="500" RectangleHeight="5000"
              Fill="{RedGrad}"
           />
          <SimpleText Margin="5" FontSize="14">
            An h3, this is not.
          </SimpleText>
   </Canvas>

It appears to me this is single-purpose code, rather than the layered approached of HTML/CSS/DOM. Can it degrade? How much thinking has Microsoft done about accessibility? What will this code do on a PocketPC or PalmOS cell phone?

Maybe this code makes sense from a desktop computer application development context, but it does not work in today’s web development context. The separation of structure and presentation is now a no-brainer, so I’m left wondering why it has been completely ignored here. It’s like the past few years of undoing the markup sins of the late 90’s haven’t happened. Or, they haven’t happened at Microsoft. (Other divisions [MSN] seem to get it, to be fair.)

XAML on the Web

Which brings us to the second problem — XAML on the web. Yes, XAML is designed to run inside a browser. It appears a special XAML plug-in or player or something equivalent is necessary, as it was demonstrated running inside of a stock version of IE6 under Windows XP. But Microsoft ‘loves the browser’ according to Januszewski, and wants it to be painless to select a link on a web page and open a XAML app as a result. Longhorn will presumably feature tight integration of the two.

The past couple of years of IE security problems have raised a lot of awareness about browser lock-in, and the problems that tying your application into a specific browser/operating system can later cause. Like ActiveX, in-browser XAML/Avalon appears to be a method of continuing that trend. Something tells me we won’t be seeing an Avalon player for Linux any time soon.

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.

If anyone who understands XAML better than I would like to come in and tell me how backwards I have it, I’d love to hear from you, comments are open. I’d rather my first look is all wrong and my worries unfounded (even though I’d like to think I understood the presentation properly).


Andreas says:
April 14, 01h

(Sorry about the long comment…)

I’m instantly reminded of Apple’s Dashboard, which also uses a (couple of) web-standard(s) and adding direct hooks to OS-specific API’s.

(Let me preface: the technical difference being that Dashboard API’s aren’t meant for actual applications, outside of widgets, whereas XAML is. And the fact that XAML doesn’t seem to be made with web browsers as a primary playground anyway. But bear with me.)

The philosophical difference between Apple and Microsoft in this case (as far as ‘web-like coding’ is concerned) seems to be that Apple is leveraging the know-how of web-developers by using techniques they already know, and applying them *outside* the browser. (Apple explicitly limits the use of system API-hooks in WebCore to Dashboard. Widgets will be viewable, but non-functional in Safari)

Microsoft seems to want to do something similar (“You guys (kinda) know XML/SVG/XUL! Use it to develop cool things on our platform!”) but aren’t really leaving the browser behind. Nor are they using standards in a way most developers are used to (compared to Apple’s Dashboard).

Although XAML certainly has legitimate uses outside the browser; I can’t help but think that OS-specific API-hooks *inside* the browser is a bad decision and the foreshadowing second coming of Active X. (Although with a different set of functions and intentions).

Dave S. says:
April 14, 01h

> Hmm, the takeaway I get here is that “the
> extended HTML model is the only model; the
> WWW document browser is the only
> network access.”

No, definitely not my intent. I’d assume the browser is only one of many network delivery methods, and probably the least appropriate. I’m mainly making the comparison because my frame of reference is the browser right now. For page/app layout languages, I’m most familiar with HTML/CSS, so it’s easiest for me to view it in those terms.

Also influencing my comparison – SVG and XUL strike me as perhaps more relevant comparisons, but neither of them strike me as particularly formidable competitors to something Microsoft’s weight is behind.

Dave S. says:
April 14, 01h

“XAML isn’t for the web. It’s for designing windows applications that run on the Avalon technology.”

Yet Microsoft is selling it as something that can run inside a browser. Of course, I realize there’s a difference between something that can be natively delivered in a browser and something that requires an interpreting plug-in, but if you dissect it to that level then Flash isn’t for the web either, right?

XAML appears to function primarily as an operating system language for the rendering subsystem, which just so happens to have hooks into a web browser, granted.

It also just so happens to enable a subtle shift in mindset, from “I’m developing this application for the browser” to “Sure, it could run in the browser, but why would you want it to?” to “Who uses browsers anymore?” Get people to adopt XAML in-browser, then get them to move it out of the browser, and you have effectively put the (cross-platform) browser to bed in favour of a proprietary new technology. Not that it will happen, not that it CAN happen, but it’s hard to ignore that something like this is at least made possible by this browser/OS synergy.

mattymcg says:
April 14, 01h

Hang on, it sounds to me like XAML is a badly implemented version of Mozilla’s XUL, which does in fact have good separation of structure, behaviour and presentation. And was used to develop Firefox.

Are they planning to use this to write the new IE 7 I wonder? :-)

CornedBee says:
April 14, 01h

I, too, mostly view XAML as a MS-proprietary, slightly extended and thoroughly messed up XUL. Basically, the strength of XUL lies, IMHO, in that its current primary platform, Gecko, also supports XHTML, MathML, XForms, SVG soon, and most importantly, CSS and XBL. The combination of CSS, XBL and SVG, specifically, allows astounding styling abilities while keeping the primary markup clean. Every XUL app that’s developed with a reasonable amount of care has skinning completely built-in.

Looking at the XAML code, I can’t see it having any of these advantages.

Alistair says:
April 14, 02h

The people who write the GNUe have a similar open method for handling their interfaces, quite awesome actually.

The idea is, you write a single file (theirs happens to be xml as well I believe) to describe your user interface. However, this is where their implementation gets funky. They have parsers for this file that will generate your interface in a window (through gtk from memory), in a web interface, through a shell interface and so forth; yet all controlled by a single plain text file.

The idea of multiple interfaces like that, to me, is dead sexy.

With that said, I can see how their XAML might be useful in other areas. Yes the markup looks dirty, however have you considered that it isn’t meant to be ‘rendered’ like HTML is in a browser?

Al.

April 14, 02h

>> XAML, Microsoft’s upcoming eXtensible Application Markup Language, which is XML in name if not in spirit.

XAML *is* an XML format. How is it not XML “in spirit”? It isn’t based on the religion of web standards, but that’s got nothing to do with the spirit of XML. XML = set of rules for data markup. XAML is following those rules.

* I don’t claim to like XAML, not that I’ve spent much time looking at it, but it irks me a little when the misunderstandings fly.

Oli Young says:
April 14, 03h

Yes, XAML is an application of XML, but I think the “in spirit” refers to the idea that content & style in XML should be seperate.

If the data content of XAML is the canvas and it’s resources, the look & style should be, in the “spirit” of XML, be kept seperately and independantly.

April 14, 10h

As far as I understand it, Avalon will use XAML to describe how it should look - if so, then there should be nothing wrong with having it presentational, especialy if it will only ever appear on *your* desktop.

However, having said that, how far is the latter point true? I don’t quite understand how this is meant to be synched with the web, given that it seems to be describing how the window looks. I suppose we’ll have to see.

10
Martin says:
April 14, 11h

Hello,

Recent mezzo reader, never replied before.

I noticed you did not mention XAML’s similarity to SVG. In many ways, its an inferior rip of SVG.

XAML is nothing more than what you stated about lock-in. Instead of following an open standard ( SVG ), Microsoft can’t give up its nasty old ways of going their own way and trying to use its ponderous inertia of users as a fulcrum against the rest of us.

Welcome to the new “browser wars” except the fate of the web itself is now at stake as it moves toward a truly dynamic medium.

It’s the same old sad, stupid story of greed and conquest.

April 14, 11h

The problem with XAML on the web is that its not really presentational semantic markup. Its just a serialization of an object graph. Basically, its the simplest, most quick and dirty way possible to take an interface and convert it to XML. No semantics were taken into account in any way, and you are right that its just like the “old days” of HTML.

I am not entirely sure that they want you to use XAML in a web browser anyway though. I think its really designed as just a “better” way of saving an interface to disk, since its human readable and easier to parse.

I find it really amusing when .NET people wax poetic about how great XAML is going to be. Its serialization folks, this is precisely how its been working forever, just with XML instead of a binary format. Really not all that exciting since the tools produce it for you anyway.

If you really want a revolution for designing desktop interfaces — think Mac OS X’s Interface Builder and NIB files. I am totally convinced that “freeze dried” objects are the way to go for interfaces instead of generating massive amounts of code and or markup.

Turnip says:
April 14, 11h

Linkiness relating to comment #2: http://inkscape.org/cgi-bin/wiki.pl?SVG_Competitors_Plan

April 14, 11h

I really do not like the direction XAML is going. On a deep level, I find XAML slightly insulting. No one will ever write such verbose markup, especially considering that it is the worst kind of tag soup. I escaped that nightmare in the 90s. Having Microsoft trying to cram it back on me is frightening. Just wait until automated form designers start pumping out truly tangled xaml. Then comes the optimizers, and the eventual promise of something better on the horizon. Soup begets soup.

I’ve been making applications for a long time on various Microsoft platforms (.NET, MFC, VB, etc) and as far as I know there is still no decent declarative semantic window layout engine/compiler. If you want a dialog, you design it by the pixel/point. Xaml addresses only the pixels problem (scalable), but it is still forcing a single presentation, etc.

What I was hoping XAML would turn out to be (before cold reality smacked me upside &c.) is a two-tier layout manager where I could specify what a window does (in terms of input/output), and then link this (*loosely*; with stylesheet-style including) to various presentations (PDA, 72dpi, 300dpi, stdout, etc).

The input/output definitions could be used to hook with code, and the designer would hook on the other side for presentation.

Xaml has almost none of this. Code is separate from design (just like resource files), but input/output contracts (the semantics of dialog design, if you will) are completely fuddled. If a designer mistypes an ID or something, no warnings occur until integration. With a contract, the designers work would be tool-validated out of the gate by default, and vice versa with the programmers work.

Such a contract would ideally hold/encode much of the knowledge which must be transfered between programmer and designer when building complex interfaces.

What does XAML give us? XML comments as far as i can tell, and that comes from the parser for free.

I’ve tried using XSLT to convert semantics to XAML, but XAML uses a lot of opaque strings, making the process somewhat harder than I was expecting. And the fit is poor.

I’ve been doing some Cocoa development recently. I like interface builder for smallish projects, but it suffers from a lot of the same problems as dialog resource files and xaml. You place things. Explicitly. There is only a strong linking of contract between code and window. So 90s.

Weak contracts like the CSS XHTML binding, web services, and Indigo are definately the future of development as projects get large.

Dave P says:
April 14, 11h

Bah, In the last couple of years I’ve really lost any faith whatsoever in Microsoft.

Reading the IEBlog, you’ll quickly see that they’ve pretty much discounted any standard that isn’t inline with their market dominance strategy.

Don’t get me wrong, I have no problem with MS moving to maximize its business opportunities, but it’s getting to the point where they’re developing their own closed, incompatible standards just for the sake of doing so.

What’s more, many times said standards or structures are actually holding any true internet revolution back.

It’ll be interesting to see if anyone even bothers to upgrade to Longhorn, considering a lot of folk are still refusing to move to XP.

15
Ryan Dawson says:
April 14, 11h

You have nailed all of the high-points. It’s perfectly understandable to look at a new technology with doubts, as you should.

The CSS point is well taken, and it has already been answered to a degree in an earlier comment with the fact that XAML is a plain and simple object graph. Essentially this enables someone to store all of their styling in a separate file (It might be the same extension, but that’s why it’s extensible).

So, in essense, you *should* store your styles in a separate file. I always start out with a file called styles.xaml, and that is where I add them.

Believe me, there are answers for these things, it’s just the fact that the word hasn’t got out, yet.

April 14, 12h

Hmm, the takeaway I get here is that “the extended HTML model is the only model; the WWW document browser is the only network access.”

From what I’ve seen, XAML promises to be a nice way to specify a network-aware interactive interface via XML. It’s more about applications than WWW document browsers.

Many of the materials on the Microsoft site are difficult for me to read (because they focus on implementation details without necessarily providing context of what the project is attempting to do or why), but some of these introductory articles are quite readable:
http://msdn.microsoft.com/Longhorn/understanding/pillars/avalon/default.aspx

For comparisons, I’d see it as closer to XUL than to HTML, although the size of the renderer is much, much larger. XAML does include ways to specify scalable vector graphics, but that doesn’t mean its scope is similar to SVG.

Regards,
John Dowdell
Macromedia Support

April 14, 12h

XAML isn’t for the web. It’s for designing windows applications that run on the Avalon technology. It is true that one can connect your application to the web using a technology such as Indigo but it is in no way a markup language for web browsers.

This is a common misconception.

Sriram says:
April 15, 02h

Comparing XUL and XAML really doesn’t make sense - they’re built for different reasons and have different capabilities (show me how to put a 3d object in XUL and overlay it with a 2d list box and animate both together).

Also, lots of Microsoft folks have made it clear that no one will have to type XAML code manually. You’ll have tool support - the beginning of which you’re already seeing from companies like Adobe and various ISVs. MS itself is working on something called Sparle.

Also - you shouldn’t compare XAML to HTML - you should compare it more to CSS than HTML. XAML provides the presentation for the .NET (C#, VB.NET, J#, IronPython,whatever) code. And this is a model that works - just see the huge number of ASP.NET sites. XAML + .NET is very similar to the ASP.NET codebehind model of today.

As for the web integration, MS is pushing the ‘smart client’ idea a lot. The ability to run an application of the net just by pointing to a URL. This has already been done by Java (applets,etc,etc). Since they run inside the .NET sandbox, they’re a lot different from ActiveX.

And before anyone cracks a joke about how long it’ll be before people find security holes in .NET, take a look at Secunia or any other security site and look at .NET’s track record over the past 4-5 years.

April 15, 02h

“show me how to put a 3d object in XUL and overlay it with a 2d list box and animate both together”

The question that pops up in my mind is why would you want to do that in the first place? Your average user doesn’t fully understand what a listbox is anyway, why slap it on to something they have to chase round the screen to use? Talk about a usability nightmare!

What I like about XUL is that is can be used on any platform, and can be styled accordingley. If I create an application I probably won’t want to limit it to a single platform, especially with the increase of Linux and Mac users in the past few years. True, I might not be able to do all the uber-cool things that XAML can offer, but then again I don’t want 2D listboxes on 3D objects in my simple personal accounting package.

21
juan carlos says:
April 15, 05h

> Also influencing my comparison - SVG and XUL strike me as perhaps more relevant comparisons, but neither of them strike me as particularly formidable competitors to something Microsoft’s weight is behind.

Unless Google really does develop a Mozilla/Gecko-based browser….!

Ara says:
April 15, 05h

RE: XAML sparking another proprietary markup war in browserville…

What with the momentum of Firefox and the growing weariness toward IE in the browser market, I think MS will be hard pressed to regain market share by introducing proprietary code.

They stand a better chance of winning people back by properly supporting existing web standards.

A.

April 15, 07h

Alistair: Indeed, the GTK toolkit has had this for years. There’s an application called Glade which generates XML-based interface description files (think something similar to the NIB files produced for XCode in Mac OS X). These Glade files are then parsed by a library (libglade) and an application writer can either pull individual widgets and treat them just like code that had been hand-written or connect callbacks defined within Glade.

Glade itself is a bit clunky, but the files it produces and the model behind it is extremely useful and makes it very easy to do RAD with GTK and have an application work across platforms with no code changes. If that’s all XAML is, fine.

However, if someone tries to shoehorn XAML into making IE-only browser apps, it’s going to be just another way of Microsoft trying to shut out Firefox/Opera/Safari. My suspicion is that it will very likely be the latter.

Sriram says:
April 15, 07h

DysFunctional - See http://www.microsoft.com/winme/0504/24295/avalon_interview_and_demo_MBR.asx (around 35 mins in) for an example of how 3d and 2d working together improves usability a *lot*. Also, check out the Longhorn concept videos up on MSDN for how stuff like accounting packages can benefit from Avalon and XAML

April 15, 08h

Wow - reading a lot of the comments here makes me realize just how much of a better job MS needs to do to communicate the XAML/Avalon message, and how many people (wrongly) think that MS is just out to push some new proprietary standard. That’s not the mission of Avalon at all - MS is clearly positioning Avalon as the future of the Windows client presentation layer.

I would expect designers to be really excited about this - it means that you can essentially use all of your existing vector and animation skills to create not just Illustrator drawings and Flash titles, but entire front-ends for Windows apps. The market for your skills is about to become a lot larger and include places where designers have not traditionally had a lot of opportunities to make money.

But, for those who are not convinced:

1. XAML is not “just a XUL ripoff.” XUL is entirely about presentation structure. Yes, XAML contains presentation information, but it goes WAY beyond that and provides a way of specifying not just physical appearance but interactive behavior and abstract object instantiation. It goes a long way toward declarative programming, and provides some very nifty ways of making sure the two stay separate. In fact, I’ve built entire examples of XAML-only functionality that would require a lot of script programming in the past (you can see them on my site).

2. Microsoft is not “ignoring standards like CSS and SVG.” CSS was in fact deeply investigated, and doesn’t have the necessary power or extensibility to accomplish what you can do in XAML. Neither does SVG, which was built and pushed by its creators primarily to be an animation engine. That’s not XAML’s primary mission.

(By the way, I find it highly interesting that Macromedia’s Flash format is closed and propietary and yet nobody complains about that, yet MS went out of its way to make XAML easily extensible via third parties and gets no kudos for it. And please don’t tell me how Macromedia “opened” SWF - they just documented the bytecode. They still control the language and its implementation, and you can’t extend it like you can XAML).

3. XAML is not MS just making another IE-proprietary language to shut out other browsers. Many of you may find this hard to believe, but the ratio of intranet applications to internet apps is somewhere around 10 to 1. For scenarios where you can control the runtime environment, web delivery of Avalon apps makes a lot of sense.

Look at it this way: XAML/Avalon is another tool for your toolbox. There will be times when it is the right one to use, and we hope that you will choose to use it for those times.

26
Cory says:
April 15, 09h

You Linux and Mac faithful are funny.

How about this? Wait until it comes out to make your (pre-)judgements. Hmmm…wonder if they’ll change? :)

Joe Marini, you said it all, man. And I for one am excited to see what this will do with One Click deployment and the blurring of the lines between web-based and Windows apps.

Nay-sayers, it’s called innovation, and it shouldn’t just make you teary-eyed when Apple does it. Stop hating Microsoft because they’re Microsoft.

April 15, 11h

Allow me to highlight my XAML slide deck from my BC .NET User Group meeting talk titled “XAML: Turn .NET into a Browser” online @ http://xaml.sourceforge.net/talk/dotnet-dec-2004/slides.html

28
René Enguehard says:
April 16, 06h

Well, XMAL looks like something users shouldn’t really be hearing about. The fact that we are (my parents are still running Windows which means I still have to save their computer from near-death every two weaks…) hearing about it isn’t the best of things. It does generate pre-conceptions, like it or not, based on Microsoft’s past track-record which, I’m sorry to all you Microsoft folks, is less than admirable.

I’d like to cite my wonderful run-on sentence above as an example of what XAML looks like to me, something that simplifies by ugly-fying. Yes it makes things quicker and easier for the developper. No it doesn’t look nice, it isn’t easy to maintain since it’s hard to read and not intuitive. Half XML tag soup does not cut it, especially if the person coding actually knows proper XML.

Now, one last point: I haven’t told you what OS I’m running apart that it isn’t Windows. Does it make a difference to you what I run? Well, the fact is, I don’t care to tell anyone considering it’s just munitions to getting called some kind of zealot. So let it be known, I am not promoting any particular OS, I’m just saying that Microsoft has been a terrible failure in the past and this does not seem to be an exception.

April 18, 02h

The interesting thing that I can deduce from the comments above is that people seem to think that Avalon/XAML is misunderstood. Okay, so it’s not XUL, it’s far more than that. It attempts to integrate presentation and functionality all in one layer. But from all this I get the distinct impression that the architects of XAML have entirely missed the point behind separation of data, functionality and presentation that technologies like the modern DOM/CSS/Javascript or XUL/CSS/Javascript provide.

Not only are these three tangibly separate concepts, but if Microsoft is serious about the technology being the basis for future application development, then it follows that different team members would be involved in the three different elements. Having all three in the same place means that developers need to at least understand all three parts in order to work with XAML. Comparing this to the XUL model, an individual interface developer can create the structure of the application by creating a raw XUL document, a designer can create a stylesheet which gives the interface whatever non-native aesthetic is necessary, and another developer can create application behaviour through javascript. There’s even the other layer of XPCOM being called by the JS.

Now some of the comments above talk about how we wouldn’t need to create XAML manually, since it could be automatically generated by code or developer tools. This strikes me as undercutting the entire point behind using an XML-based interface language in the first place. If the language is so unwieldy as to necessitate such tools, then what does it say about the language? I’m inclined to believe that using XML is merely paying lip service to openness and interoperability (as Bill Gates himself recently did); Microsoft still want people to buy their next iteration of Visual Studio, and you can guarantee that the “tag soup” of XAML will be far easier to edit and create using the in-house IDE.

The biggest thing that concerns me with XAML is the one that several people (Microsoft groupies or employees, I wonder?) seem to be denying; that it will form a new web-based technology. Of this I have no doubt. If any MS executive saw a XUL application being loaded in-browser (i.e. you type a URL in Firefox and it loads a fully native UI application with all the richness of interface of a native application), you can guarantee they’d see the value in such a technology. The potential for shopping sites, customer service or database management applications which can be accessed via any browser without the need for a client install is a dead cert killer app. To deny that this is one of Avalon/XAML’s purposes is at best ignorant, at worst disingenuous in the extreme.

Mstyle says:
April 18, 05h

>> “show me how to put a 3d object in XUL
>> and overlay it with a 2d list box and
>> animate both together”

>> The question that pops up in my mind is
>> why would you want to do that in the
>> first place? Your average user doesn’t
>> fully understand what a listbox is
>> anyway, why slap it on to something they
>> have to chase round the screen to use?
>> Talk about a usability nightmare!

Even worse in this scenario. Although the ‘average computer user’ might not understand the terms, as this technique comes availble to them to play with they might not even care. As a reference: ever worked with some noob friend, or a client that made like say a design that was just no good, but loved it because ‘they’ created it?
This might be exactly what microsoft hopes for to katalyse XAML.

Scary indeed!

On the other hand i do remember something like activeX. And although it is still a bother every now and then, what real good did it do for the redmond boys?

The number of quality developpers has grown largely. So there will be a lot of watchfull eyes outthere, as proven on the comments here. If this turns out to be a new model to grow dominance without adding real value i am sure it just won’t work.

If i had to put a compliment of some sort to the guys in Redmond, it would be the dare of being all stubborn and ignorant again, as they do best. *sigh*

Kevin says:
April 18, 07h

Chris Anderson, an Architect on Avalon, has replied: http://simplegeek.com/

April 18, 07h

“3. XAML is not MS just making another IE-proprietary language to shut out other browsers. Many of you may find this hard to believe, but the ratio of intranet applications to internet apps is somewhere around 10 to 1. For scenarios where you can control the runtime environment, web delivery of Avalon apps makes a lot of sense.”

Yes, and that’s exactly why XAML is all about lock-in. All those wonderful intranet applications built with XAML/Avalon will require you to run IE on Windows. And since you’re locked into running IE/Win to use your intranet applications, you’re not going to switch to another platform for external browsing.

If all XAML will be a presentation layer for Windows desktop applications - something like Windows.Forms in .NET, that’s one thing. But another technology that locks users into one browser and one platform isn’t going to get many fans in the design community, most of whom have to suffer through the fact that their platform of choice is systematically locked out.

April 18, 10h

Ben,

XAML provides for very clear and distinct separation of data, functionality, and presentation via explicit parts of the language.

And nobody is “denying” that XAML/Avalon will be deilverable via the web - having something work both via client and web delivery has its advantages.

Like I said before - Avalon is a tool for your toolbox. There will be times when it is appropriate to use, and initially that’s going to be for rich client-side application development.

April 19, 01h

Joe;

“XAML provides for very clear and distinct separation of data, functionality, and presentation via explicit parts of the language.”

Explicit parts of the *same* language. Distinctly separate concepts being presented and specified via the same mechanism. XML is, naturally, very flexible. But this flexibility is the same thing that people moan about Perl or Regular Expressions or Sendmail or mod_rewrite; give people too much flexibility and you run the risk that people will use a tool inappropriately. I can’t think for the life of me why combining all these heterogenous concepts into a single language was preferable to separation of data/presentation/behaviour as per XUL/CSS/JS.

Perhaps I was picking up the wrong end of the stick in implying people were denying that this technology would have a web-based side, too, but it’s certainly true that many individuals are denying that it’ll lead to browser lock-in; that is the biggie, for me. I may use Longhorn on the desktop in the future, but I’m far less inclined to use IE7 - I’m quite happy with Firefox thank you. Where will that leave me (and the millions of others who’ve downloaded Firefox since November last year) when the likes of Amazon start making XAML-based versions of their store (or perhaps even Microsoft will themselves, if the tech demo shown in the movie interview linked above is to be believed)?

April 19, 02h

Ben,

>I can’t think for the life of me why combining all these
>heterogenous concepts into a single language was
>preferable to separation of data/presentation/behaviour
>as per XUL/CSS/JS.

Well, let’s start with the fact that they’re all different syntaxes with very little commonality between them. I mean, don’t you find it irksome that CSS syntax looks NOTHING like tags, even though you’re using it to style a tag-like language?

As for the JS part, you can code your application logic in C# or VB as much as you want. However, it makes much more sense to use declarative syntax to say “this element fades out when the mouse moves out of it and fades up when the mouse moves over it” than to do the same thing in back-end script logic. For one, the WHOLE STYLE is now a unit, appearance and interactive behavior and all, that can be applied to anything else that you want to fade up or down when the mouse moves in or out of it. That is a pure extension of the CSS metaphor of creating styles to encapsulate presentation - we’re just expanding what “presentation” is. Now, what *happens* when you click on the button is NOT part of the style - that’s back-end logic, and you use a programming language for that.

What exactly are you saying is the *advantage* of using different language syntaxes to achieve this? I think one syntax makes it easier to learn (and extend - CSS can’t be extended to achieve effects that the browser doesn’t already understand. XAML doesn’t have that problem, because YOU compose the style out of base primitives).

I can understand your comments about browser lock-in, and other people’s comments about Microsoft’s past track record and how they feel about us (as evidenced by Mstyle’s post about us being “stubborn” and “ignorant”).

Let me state this as clearly as I can for everyone here reading these comments:

I am relatively new here to MS (less than 2 years). Beforehand, I worked at Quark (but not customer service!), mFactory (on mTropolis), my own design software company, and then Macromedia (where I was one of the original Dreamweaver engineers). I’ve spent my whole career in the designer software space, and learning what designers need and how to give it to them.

Many of the people that I work with here at MS are also from the same space, and are most are also newer to Microsoft.

I can ABSOLUTELY ASSURE all of you that I would not be here if I didn’t think we were trying to build the best possible software for designers. The people I work with and I all care very deeply about “doing the right thing”, and this is leading to conversations that many of you would probably be shocked to hear if you could listen in on them. We all routinely talk about supporting standards (for all the crap that MS gets for standards, the fact is that an MS representative has sat or currently sits on almost every W3C committee of substance), understanding the Designer customer, and making sure that we don’t stray from the accepted industry best practices unless it’s because we have a chance to really innovate and make things better (which is why we didn’t go with CSS or SVG for our XAML styling mechanism - we have what we think is a much better way).

All you designers out there have a choice to make, and we realize that. I’m asking you to help us make our software better. I can’t do anything about what your past experience with MS might have been. But I and my colleagues are working to make sure you have as wonderful an experience as possible in the future.

By the way, I don’t expect *any* of you to just take my word for any of this. All of us here understand that we’re going to have to prove ourselves to you. That’s exactly what we plan to do. All I’m asking from all of you is to just give us a fair chance.

36
kevin says:
April 20, 01h

http://www.designerslove.net/

37
morph says:
April 21, 04h

Joe,

The depth of frustration towards MS implementations, and our collective commitment to cross-browser, multi-vendor, publicly accessible systems has inspired MS to create a new commercial, proprietary paradigm?

That’s just sick.

W3C standards, if they are wrong or incomplete, will become right, given our support and time.

Intolerably multiplying (polluting) our workspace with proprietary technologies, vendor lock-in and other questionable strategies can only be bad for designer/developers in the long term. Period.

You see, wool don’t blind many of us any more.

I choose W3C, Mozilla XUL, CSS, JS, XML; it is these, and the act of volition of holding to them that makes my working life hopeful and tolerable. MS offers me the opposite.

Sorry. I’m sure it’s pretty, but if it’s not got W3C support and branding you can shove it, you could have used the time more wisely.

Developers ownership, their future, and the publics heritage, should not be supplanted by vendor-specific tech, however good you ‘think’ it is: it’s not.

MS owes an act of self-mortification to the community, a sign of devotion to developers interests at the W3C. We demand it. But yet again MS draws outside the bounds.

Don’t want MS stuff any more, it’s morally barren.

April 22, 03h

Hi Morph,

>… has inspired MS to create a new commercial,
>proprietary paradigm?
>
>That’s just sick.

How is it any more “sick” than Flash, which is closed and proprietary and controlled by one company? How about PDF, which is also closed and proprietary and controlled by one company? It always puzzles me how much slack people are willing to cut for companies like Macromedia and Adobe despite their efforts to create as much lock-in for their platforms as anyone ever has.

XAML is an OPEN LANGUAGE. It is XML COMPLIANT. How many times do I have to say it?

>I choose W3C, Mozilla XUL, CSS, JS, XML

Morph, I’ve been in this business for FIFTEEN years. Let me tell you a secret: most of your “open standards” today started out as somebody’s attempt to create a proprietary technology that failed.

Mozilla XUL started out as Netscape XUL, which was a PROPRIETARY invention intended originally only to run inside the Netscape browser and thus create Navigator lock-in. I know this because, see, I actually TALKED with Netscape AT LENGTH about this way back when I was on Dreamweaver and they wanted us to provide support for it.

JavaScript ALSO started out as a PROPRIETARY Netscape invention, and was in fact called LiveScript originally until they decided to try and piggy-back off of Java’s momentum and renamed it JavaScript.

Both of these technologies only became “open” when the business cases for keeping them closed collapsed, not because of any altruism on the part of the developers.

CSS is nice for web pages, but the fact is that from an architectural viewpoint, it has so many structural problems that need addressing. You can’t extend it. It’s not compositional. I could go on and on.

XAML is XML. PERIOD. We could have used a format that wasn’t an open W3C spec-compliant one, but we didn’t. It was important to us that we base it on an open W3C standard.

>You see, wool don’t blind many of us any more.

Oh, I think you’ve been blinded just fine there, morph.

See, the problem with people like you is that you’re so busy fighting your little war that you’ve lost your objectivity. I suspect that there’s probably nothing we could do to win you over, because all you know is hate. Go back and read over your post - it’s filled not with reason and logic, but with venom and vitriol based on personal opinion. I fully realize that it’s all hip and fashionable to jump on the MS Bashing Bandwagon these days, but I’m just thankful that there are more open-minded designers out there who base their opinions on merits and not on the fact that their favorite horse didn’t win the race and got put to pasture.

Technologies aren’t “morally barren,” morph. They’re just tools. You can choose to use them or to not use them. But believing that companies that make platforms, whether it’s us, or Adobe or Macromedia, or Nokia or Sony or Nintendo, that they aren’t trying to find ways to keep developers inside their fold is just plain naive.

If you’d rather not take your skillset and go address the huge new market that’s about to be opened up for designers, then that’s up to you. But it’s ultimately self-defeating.

See, I used to be just like you. A LONG time ago I was a huge Amiga bigot (yeah, remember them?). Everything else was crap, I used to say. Amiga was king and if you didn’t develop for Amiga then you were just an imbecile, I used to say. Then one day I had to scramble to update my skills because it turned out that Commodore’s horse lost the race, and I realized that attaching so much emotion to such trivial things made little business sense.

I really do hope that you’ll give us a chance. I want very much to make designers’ lives better. Go ahead and be skeptical. I know it will take time to change minds. I also know that some minds will never change, and I can’t do anything about that.

What I can do is try to make the best design tools out there. Anyone who wants to come along for the ride is free to contact me.

39
morph says:
April 23, 01h

I don’t think you’ll find so many around here cutting companies like Macromedia and Adobe slack.

XAML is to be served by modern MS systems and in the future it will be competing for attention with the inevitable and far more fundamentally open alternative.

There is no question then which is the best tool for a developer. Choose MS XAML brand now unmeshed with the public standard later; or full attention to the current standards now and the inevitable son of svg standard later.

Can MS guarantee overnight consolidation with the standard when it comes? I doubt it.

XAML complicates developers lives, and for you to consider it ‘just a great tool’ is wishful thinking.

Because in fact, no matter “how good a tool” you believe it to be (it’s probably really sexy wool), it can only become a tool that developers will regret ever existed.

The issue of morality, comes from the fact that the MS entity, rather than really listening to its customers, is more than willing to force pain upon us.

40
Aankhen says:
April 23, 09h

“See, the problem with people like you is that you’re so busy fighting your little war that you’ve lost your objectivity. […]”

And you think you’re being objective?

April 25, 01h

Allow me to chime in on something Joe said:

“XAML provides for very clear and distinct separation of data, functionality, and presentation via explicit parts of the language” and
that XAML “…goes a long way toward declarative programming, and provides some very nifty ways of making sure the two stay separate”, I find this a bit difficult to swallow.

I personally find quite the opposite to be true. A XAML-only application is an entangled mess of UI state management via property triggers, data binding, and UI definition via xml element/attributes to object graph class/property mapping. Look at a typical example and you’ll see the entanglement of binding (data), property triggers (functionality), and presentation (object graph). I don’t think this helps the concept of declarative programming.

I think there’s a lot of great things that can be done with xml and object graph mapping, but to entangle property triggers and data binding along with the object graph representation is not good architecture. And frankly, as I gain experience with MyXaml applications, I’m also concerned with DIRECT xml element/attribute to class/property mapping. The resulting xml is too dependent on the underlying class/property definition. While you can do cool things with it (and it is a tool, after all), there’s a lot to be said for defining a schema that is INDEPENDENT from the underlying class definition. I’d love to see what happens to XAML applications build with Avalon 1.0 running under Avalon 2.0. If there are changes to class names, properties, or even their functionality, XAML code will break just like imperative code. However, if Microsoft had chosen to abstract XAML and actually create a schema that can be nailed down, then there would be good decoupling.

But then you’d have SVG. :)

Marc

April 25, 01h

Filip and Marc,

XAML does in fact achieve this kind of separation, but just like in HTML, *you* have to do it. Like HTML, there’s no automatic way to have it done for you (without using a tool, I mean), and bad coders will always be able to create bad code. I can tell you horror stories about people who *thought* they knew what they were doing with HTML/CSS/JS, and the kinds of nightmares of code they produced. That’s not the fault of the architecture - that’s a coder who doesn’t know what he’s doing.

This is a very important distinction you have to make, and not everyone “gets it” right away: you have to distinguish between the concepts of “Documents” and “Applications”.

HTML is for Documents.
XAML is for Documents, AND Applications.

HTML is not XAML (and please don’t anybody write me saying what great HTML apps you make using DHTML - HTML IS A DOCUMENT FORMAT).

Right now, you guys are comparing Apples to Oranges.

The concept of separating CSS styles from HTML tags is an approach that makes sense for documents because you want to be able to extract the information from the document in a way that does not include the presentation.


Although XAML certainly allows for this in the case of documents using a well-defined structure for pages and styles (none of which you’ve seen so far), in Applications this requirement changes dramatically.

You want to be able to design controls that are functional units unto themselves and then re-use them across projects or even different windows in the same application. In this scenario, things like interactivity (how a button behaves when the mouse moves over it, for example, but not the logic that happens when it is clicked) become just another style selector.

So, claiming that Property Triggers inside Styles somehow “breaks” the separation model just completely misses the point. You have to remember what it is that you’re separating. In this case the model of what a Style is has simply been expanded to include not just physical appearance but behavior, and in fact this is how modern component systems work.

Instead of looking at individual trees in the woods and claiming that the ecosystem is screwed, you need to take a higher-level view of the whole forest.

April 25, 01h

Marc, your comment
“I’d love to see what happens to XAML applications build with Avalon 1.0 running under Avalon 2.0”

is a complete red herring statement. EVERY component system, HTML included, would suffer the same consequences if you were to change the underlying runtime without providing backward compatibility. But given that even the original VisiCalc DOS application circa 1979 still runs on WindowsXP (go to Dan Bricklin’s site and try it!), I’m not too worried.

Look, I understand everyone’s attempts here on this list to want to take something they know well (HTML) and compare it to something new (XAML) to see how it works, but there are some important conceptual jumps you need to make, and this difference between Documents and Apps is a big one. You really need to expand your thinking on what constitutes a “Style” (and in fact, we prefer to use the term “Template”, since it is much more accurate).

Let me just say one more thing on this: YOU ARE ALL LOOKING AT PRE-ALPHA SOFTWARE. Things are going to change dramatically between now and shipping. If you want to have input into this process, you are welcome to! All of your feedback is truly appreciated!

April 25, 02h

Marc, your comment
“I’d love to see what happens to XAML applications build with Avalon 1.0 running under Avalon 2.0”

is a complete red herring statement. EVERY component system, HTML included, would suffer the same consequences if you were to change the underlying runtime without providing backward compatibility. But given that even the original VisiCalc DOS application circa 1979 still runs on WindowsXP (go to Dan Bricklin’s site and try it!), I’m not too worried.

Look, I understand everyone’s attempts here on this list to want to take something they know well (HTML) and compare it to something new (XAML) to see how it works, but there are some important conceptual jumps you need to make, and this difference between Documents and Apps is a big one. You really need to expand your thinking on what constitutes a “Style” (and in fact, we prefer to use the term “Template”, since it is much more accurate).

Let me just say one more thing on this: YOU ARE ALL LOOKING AT PRE-ALPHA SOFTWARE. Things are going to change dramatically between now and shipping. If you want to have input into this process, you are welcome to! All of your feedback is truly appreciated!

April 25, 03h

To continue the discussion about all things XAML before this comment page gets out of hand I invite you to join the XAML Developers Group @ http://groups.yahoo.com/group/xaml-talk

To Joe Marini: If you are interested in continuing the discussion about XAML offline I invite you to present at an upcoming VanX (Vancouver XML Developer Association) meeting. See http://vanx.org for details. We will, of course also invite Dave Shea.

April 25, 08h

(* sigh *) I really don’t understand why people think that open standards somehow AUTOMATICALLY result in better technologies.

In fact, history teaches us just the *opposite*. Great technology does not typically come out of standards committees. Neither Flash nor PDF are open, yet both are ubiquitous and are very good solutions for their intended purposes. PalmOS almost single-handedly broke open the handheld computing market. Is it open? No. Was the MacOS, which launched the GUI revolution in 1984, open? No (and it STILL ISN’T today - being “based” on BSD doesn’t make you “open”). Even venerable JavaScript wasn’t originally open.

But please, go right ahead and fight your little jihad, morph. Go ahead and refuse to learn from history.

I do have to say I respect the strength of your convictions; it’s always somewhat inspiring to see someone so idealistic. I just wish it were based more on pragmatism and open mindedness than on hate.

April 25, 08h

As a matter of fact, Aankhen, I’m probably one of the most objective people you’ll ever meet.

Having been one of the first people on the planet to make a web page, having sat on the W3C, having worked on Design software since before college, having used almost every programming and markup language of substance at one time or another, having created software for no fewer than 10 OS platforms, yes, I can say that I’m being objective when I say that Avalon is a technology that deserves serious consideration and enables some very rich design possibilities.

48
Filip Milivojevic says:
April 25, 11h

I’m sure that XAML was designed to help developers design their user interface, but I do think that design is designer’s job.

That’s why application logic/input-output/presentation/behaviour layer separation is invented in first place.

If MS follow this simple method, they will be on the right road, even if they use their own standards, and XAML does look as web in 90’s.

April 28, 03h

Hi Joe,

Well, it sounds like you’re frustrated, and I do understand your frustration. XAML is a cool technology, there’s been a lot of work and investment (personal, not just money) that’s gone into it and people are undoubtedly proud of what they’re working on.

I would like to say though, that from my perspective, I find XAML frustrating. It has odd syntactical elements, I disagree with many of the choices made with regards to functional vs. readable, I think it’s a bad thing that styles entangle physical appearance with behavior, I think the binding syntax is terrible, and I don’t think XAML is a good example of declarative programming.

I’ve written a lot about declarative programming with examples on containers, state and event handling, etc. That to me is part of declarative programming, because I’m discussing architecture and practices and how the underlying imperative code has to be written, not just the xml syntax.

I’m frustrated because Microsoft could really do some great things in promoting the benefits of declarative programming, not just XAML. It has the resources to create not just the underlying technology like Avalon and the XAML parsers, but the tools, designers, etc., to make declarative programming usable. I don’t see this happening. Maybe it is, and you guys are just keeping a lid on it, but I really doubt it.

Also, I don’t see that there is a dialog (not just feedback, but real dialog) between Microsoft and the people doing work in the things that XAML touches—declarative programming, vector graphics, thin rich clients, browser-client unification, etc.

Marc

50
Anonymous Coward says:
April 28, 08h

Like Joe said, bigotry and emotional attachement to a software platform is a complete waste of time. In fact, it’s plain silly.

I would LOVE to the faces of the thousands of Macromedia fanboys who spent the past 4 years spamming usenet with ‘Adobe is crap’ comments. Now they will probably convinced themselves the merger was in the best interest of their favorite product, then become Adobe-fanboy… ad nauseum.

Dave S. says:
April 29, 06h

Okay, too many trolls showing up now, so I’m shutting this thread down. If anyone reasonable wishes to continue it elsewhere, email me a URL and I’ll append it to this comment.