"Rich Everywhere" is a phrase I like to use to talk about Avalon. We want to enable every control to support any rich content, interaction, and presentation. Part of being rich is actually having a system that people can understand, tool, and build these great experiences on the platform.

In DOTNET the number of customization points brought about a big problem. You could customize the look of an element up to a certain point, but then you would have to completely change your programming model to use the presenter. Presenters couldn't be authored in XAML, and you weren't able to create elements dynamically inside of the presenter, so you ended up being limited to using low level drawing calls.

ECM

We had to solve the notion of "rich content". There is this tension between flexibility and programmability. For the VB developer, we want to enable something as simple as:

Dim b As New Button()
b.Text = "Hello World"

For a web developer we want to enable something as rich as:

<Button>
    <GridPanel><Video ... /><Text>Hello <Bold>World!</Bold></GridPanel>
</Button>

The problem was to do both with a single object model. We talked about having two buttons - a "simple" and a "rich" button. No. We talked about having multiple properties - "Text" and "Elements". No.

Then the idea came - borrow some pages from WinForms and ASP.NET, mix in some new twists, and viola!

ECM (I forget what the abreviation stood for originally...) was the idea to have a mechanism to take arbitrary CLR objects and convert them to UIElements. If the CLR object happened to be a UIElement, we were done. If it wasn't, then we could create a visualization for that data item using TypeConverters, ToString, or a data style. Basically that means that button now has a "Content" property, that is of type "System.Object". If you pass a string in, we stuff that string into a text element, and if you pass a GridPanel in, then we just display it.

Controls have 3 flavors - No content (Border, etc.), Singular Content (Button, etc.), Multiple Content (ListBox, etc.).

You can mix and match; a Menu has a header (Singular Content) and a list of menu items (Multiple Content) - so we have something called a "HeaderedItemsControl"...

Only use elements

When I talked about simplicity, I mentioned that we doubled down on element composition. Another side effect of this was to unify the programming model for all customization. You could now completely change the look of an element all declaratively in XAML.

Once we have this model, we now have a tenet that all controls must not have inherit knowledge of their visuals. This allows developers to completely change the look of any built in control without having to change the behavior at all.