IMO, in my recent experiences, a large number of people still think of a skinned app as something like Windows Media Player, WinAMP, PowerDVD, the OEM apps that come with digital cameras, Bryce or even PwopCatcher. Skinning CAN be like that, and no doubt MANY people will want that (and need it too). However, skinning can also (and in a more widely needed as well as realistic pov) mean enhancing the existing structures of your WPF application controls.
In certain situations "skinning around the control" rather than "skinning the control" also helps. And if you allow me a moment to be painstakingly irritating, with WPF's super flexible design model, skinning is too narrow a term to really describe what can be done. But back to skinning around the control, let me clarify what I mean by building upon an example I (will) present in The Human UX:
Say we have a button that triggers a purge of a nuclear reactor (if you don't know yet, this is a hypothetical situation). From a typical skinning point of view (STC - Skinnin the control) we might have an urge to paint the control red, put a biohazard or radioactive symbol on it, and add those yellow-black warning stripes around it. Now that's all nice and good, but just PAINTING the control is not really helpful aside from making an idiot go "ooooooh, what does THIS button do?".
Let's build a USABILITY ENHANCEMENT on top of this. For a seriously dangerous function trigger like this button, a good accident deterrent is needed. Let's use a reversed version of the "Your computer will restart in 15 seconds" dialog. We make the button nicely big (say 100px wide and 50px tall). When idle, it says "Purge Reactor" and has an exclamation on either side. When clicked, the text says "Confirm?" and the button starts to pulsate its color. A small 95px wide, center-aligned, progressbar appears ON the button, and instead of the exclamation icon, a countdown is shown - which is also reflected in the "emptying" progressbar. If the action is not confirmed within 15 seconds, then it is automaticaly cancelled. To be safe from accidental double-clicks, the countdown starts 3 seconds AFTER the first click.
On cancellation, the button fades back to the normal "idle" mode.
Now this is something I just dreamt up right now. With proper planning and some usability experts (<cough> Nukeation </cough>) these types of "little things" can seriously enhance the usability of any application.
What we just did here was NOT your typical skinning. We actually edited the base template of an existing button, added various timelines to respond to different events, and added sub-controls hosted on its surface. This kind of work was not possible (at least in terms of practicality and ease) unless you knew some heavy C++. We are messing with new "sub-controls" and timelines rather than just slapping on sweet graphics, so this isn't really skinning. While the official terms for this are (as far as I know) "Editing a control template". I call it Avalonizing or Avalonization, of WPFing (pronounced "wip'fing").
But enough of terminology. My main point here is that we now have an affordable, easy to implement, and flexible model for doing such things. And this power should not be wasted on just skinning an application, but rather to create superior usability enhancements to your apps.
Coming soon
Next Part: Using various contains like Grid, Canvas, and Flow to seamlessly present both controls and textual content in a single form.
Tutorial: Simple Template Editing for the Button and Progressbar.