Admittedly, people that have experience or understanding with Glade or XUL or whatever typically get it (although with a response of “why reinvent that wheel?”) although I think Joe (in the video) does a decent job getting across the “this isn’t just for UI elements” point.
I had gone with a one-sentence answer in the past of “Some chunk of your code builds up a DOM of objects and then hooking up events and logic – XAML lets you do that work in a language better suited for such representation”. Of course, I then expect something to happen that hasn’t yet – I expect the conversation to turn to intentional programming(-ish) kinds of topics.
It’s somewhat funny, because VS2005 has taken things to the point where the 80% case is UI / data source / event / etc. hook-up is abstracted from the user anyway, so for most people XAML vs. “normal” is no work flow difference for them (in the “UI designer == implementation dev” case). After all, if I want to add logic to happen when an event fires, I choose the appropriate object in the properties window, look at his list of events, find the one I want to hook up to, and double-click in the empty area that would list the delegate to be hooked up to that event. I’m not writing the event hookup logic, so why would I care about xaml vs. C# code? Sure, if I want to edit manually down the road, the xaml is more expressive, compact, probably less fragile (valid C# code can fail in lots of ways that valid XAML can’t, the most obvious being various null ref kinds of cases)
At some point, people are going to write Monad commandlets in XAML. That’ll be interesting, I’d think.