Add some notes on differences with WPF and TODOs

Author: michael-hawker

components/Adorners/samples/Adorners.md

@@ -18,9 +18,7 @@ Adorners allow a developer to overlay any content on top of another UI element i
 
 ## Background
 
-Adorners originally existed in WPF as a main integration part as part of the framework. [You can read more about how they worked in WPF here.](https://learn.microsoft.com/dotnet/desktop/wpf/controls/adorners-overview)
-
-UWP/WinUI unfortunately never ported this integration point into the new framework, this experiment hopes to fill that gap with a similar and modernized version of the API surface.
+Adorners originally existed in WPF as a main integration part as part of the framework. [You can read more about how they worked in WPF here.](https://learn.microsoft.com/dotnet/desktop/wpf/controls/adorners-overview) See more about the commonalities and differences to WinUI adorners in the migration section below.
 
 ### Without Adorners
 
@@ -30,7 +28,7 @@ You could try and incorporate a [`InfoBadge`](https://learn.microsoft.com/window
 
 > [!SAMPLE InfoBadgeWithoutAdorner]
 
-It also by default gets confined to the perimeter of the button and clipped, as seen above.
+It also, by default, gets confined to the perimeter of the button and clipped, as seen above.
 
 ### With Adorners
 
@@ -40,6 +38,24 @@ However, with an Adorner instead, you can abstract this behavior from the conten
 
 ## Highlight Example
 
-Adorners can be used in a variety of scenarios. For instance, if you wanted to highlight an element and show it's alignment to other elements in a creativity app.
+Adorners can be used in a variety of scenarios. For instance, if you wanted to highlight an element and show it's alignment to other elements in a creativity app:
 
 > [!SAMPLE ElementHighlightAdornerSample]
+
+## TODO: Resize Example
+
+Another common use case for adorners is to allow a user to resize a visual element.
+
+// TODO: Make a simple example here for this soon...
+
+## Migrating from WPF
+
+The WinUI Adorner API surface adapts many similar names and concepts as WPF Adorners; however, WinUI Adorners are XAML based and make use of the attached properties to make using Adorners much simpler, like Behaviors. Where as defining Adorners in WPF required custom drawing routines. It's possible to replicate many similar scenarios with this new API surface and make better use of XAML features like data binding; however, it will mean rewriting any existing WPF code.
+
+### Concepts
+
+The `AdornerLayer` is still an element of the visual tree which resides atop other content within your app and is the parent of all adorners. In WPF, this is usually already automatically a component of your app or `ScrollViewer`. Like WPF, adorners parent's in the visual tree will be the `AdornerLayer` and not the adorned element.
+
+The `AdornerDecorator` provides a similar purpose to that of its WPF counterpart, it will host an `AdornerLayer`. The main difference with the WinUI API is that the `AdornerDecorator` will wrap your contained content vs. in WPF it sat as a sibling to your content. We feel this makes it easier to use and ensure your adorned elements reside atop your adorned content, it also makes it easier to find within the Visual Tree for performance reasons.
+
+TODO: Adorner class info...