XAML Standard — Blessing and Curse

Last week my name was invoked in the XAML Standard(s) GitHub Issue list. First glance I laughed and felt flattered by it and initially wrote it off as being a humorous moment at best.

I went to lunch and didn’t think much of it until the walk back when for some reason I focused on the one word — standard. Not specification, not the proposal but standard.

In a space such as XML when someone throws that word around it takes on an important meaning, because what you’re saying out loud is we need to all agree now on a final version of this thing we are working with.

I’m now suspicious of Microsoft’s intent on defining a standard on an XML vocabulary that has been mutated quite a lot over the years, in that are they actually wanting to bring all boats to the same tide mark? or is this just a dump and run strategy?

I probed, I began asking questions and making change requests to see what comes back and sure enough, some folks in the Microsoft team took that bait. They updated the repo with some more specifics around “who” and “what” but still haven’t really cemented “why” (it’s vague at the time of writing).

The key ingredient to the probe was the answer to who is accountable and has authority on what gets in or out for this new “standard”. Sure enough, it ended with what I suspected, UWP and XAML Forms team(s) have the final say.

Why is this bad?

Well, firstly why are they two separate teams to begin with?

Seems odd, I mean I get the acquisition of Xamarin occurred but where is that odd project name that explains the “merger” of the two forces? Seems as if the two are still in isolation and that’s not a good thing.

Secondly, why are these two teams having a say in an XML vocabulary they themselves have mutated beyond what it once was in WPF/Silverlight days. Where is the third voice, the friction that says “don’t forget what we had done in the past” and if there is a fork in the road on the difference(s) — why? that question still goes unanswered today.

What is the solution to the bad?

Outside counsel, the different set of players, folks who have a dog in the fight as well as those who don’t. As at the end of the day the important point of defining an XAML Standard is to place a point on a roadmap and say out loud “everyone please move your vessels in this direction so we all land here in the next XYZ months/years”.

Instead, Microsoft has stated they want the standard done by the end of the year and that these two teams are the ones who’ll act as the ones who “review” the changes. It’s kind of like saying Microsoft will act as the people who will review HTML6 because the Internet Explorer team have a browser already? — you’d not accept that right? …..right? ..please tell me you agree.

You didn’t answer the question, who?

In order to answer that question, we need to agree on “why” first.

Why create an XAML standard and what’s the end game look like here?
Is it to make lives easier for the UWP/Xamarin team? or is it to enable companies like Unity3D, Adobe, SketchApp etc to create Tooling to support XAML while Microsoft and others create frameworks to implement?

If its the later, then the who is simple — Invite others who want to bridge the gap between designer and developer into the mix so that multiple lenses can be applied to the “review” of changes.

Is XAML Microsofts though? why do others need to be involved?

Friction. You need to look at how the implementation of XAML is going to work not just from the “framework” of choice but also the tooling and platform that are supposed to support it.

XAML’s job is to describe the intention of the User Experience platform, its job is to not tell you which language (C#, Java, JavaScript etc) you do the implementation on. It simply defines an agreed contract between developers and designers on how a user interface composition is to both behave and visually look.

To keep it independent it needs to live beyond Microsoft or subject itself to the failure of the Expression Suite past. Make no mistake that entire strategy failed and it left a bitter taste in the companies appetite to try again.

Microsoft want to teach developers how to design, but they lack the understanding of what makes the design instinct work and furthermore, they lack the ability to translate a great user experience from a non-Microsoft team into their pipeline.

They can’t be apart of this designs discussion until they fix this wound between developer and designer workflows. Anything but this is just lip service and theorycrafting.

Next steps then?

Microsoft needs to take a step back and ask the question “why” are they doing this and “who” is it intended for. If the answers keep coming back to making UWP and Xamarin Forms converge into a unified story, then it’s not a standard it’s a specification play. Fine, be upfront about this but do not declare a standard in an open source community to only hijack it with your own agenda.

If it is a standard than you the developers of Microsoft community have a very rare opportunity to fix the last 5–6 years of strategy in one hit. This is your opportunity to establish a contract between the UX Platform(s) of tomorrow and your cross-device / cross-platform strategies.

XAML 1.0 standard will be significant for the future of Microsoft going forward and if done right will likely jump start the companies UX strategy. As to define an XAML standard means to define what must at a minimum be compliant in order to wear the “standard compliant” badge. To then come up short is a huge party foul on the companies part, and will be a massive weak point in any upcoming product release ergo creating more pressure to get it right.

The Microsoft developer and designer community need to now hold this one GitHub repo accountable more so than ever, as you falter here in the slightest, you seal your own fate and no amount of “transparency” and “open source” narrative will save you.