Arguably the easiest approach, and certainly a good way to get started. You can use design tools like Visual Studio or Expression Blend and viewers like Kaxaml. The drawback is that since APL isn't fully integrated into "The Microsoft Way" we soon start inventing little idiosyncracies of our own (like putting placeholders in for folder names) and stop being able to use the standard design tools.
Still, a good way to make a start on the visuals of an application. Maybe I need to build myself a few utilities to mutate my personalised XAML files into a form that Visual Studio can render.
Since what happens inside our APL code is that we read XAML files into a vector and use the vector to feed into WPF's XAML-handling it's a logical step to build the XAML ourselves within APL. This is certainly a more-than-valid route to take if you want to build forms on the fly, gives you a lot of flexibility.
The downside is that there really is very limited scope to view what you create in an external tool, and WPF is very finicky about XAML contents (get it worong and you'll see nothing but Status Windows full of incomprehensability). Again, some as-yet-unwritten utilities could be helpful.
When XAML is being used we're dealing (in APL terms) with a character vector, one that's both verbose and with a lot of internal structure. Creating these character vectors can be tedious, and manipulating them (for example to flesh out place-holders) is also tedious. But, there's an alternativer - XAML is just a special case of XML, so we can read a XAML file into APL, use
And finally, of course, you don't have to use XAML at all. Deep (?) down, all that XAML is doing is setting up a series of calls to .NET functionality - and a bit (?) of time studying WPF documentation can get you to the same end-point.
But I'm not really recommending this at present - what's lost is the separation between code and UI definition, and this may be detrimental to long-term application maintainability.