Decoupling the User Interface from the underlying code has been one of the holy grails of application development.
Layers of indirection and new patterns have been invented over time to try to separate what the user does from the back-end data. It’s been a long and difficult journey but WPF is the last attempt at completely separating the user interface from the gut of an application, leaving graphic designer do what they do best and programmers do what they do best.
I think this disconnect has actually hindered the adoption of WPF to a great extent.
I also believe that Silverlight, while showing great promises, is going to take a long time to get off the ground.
Good graphic designers who work on User Interfaces are too few and far between, and large organisations will take time to get staff with a sufficient level of expertise to be useful in developing meaningful WPF/Silverlight applications.
Until now, the bulk of the development effort was done by developers. Most ISV only have developers onboard.
As far as I can tell, it seems that main reason behind this slow adoption is that WPF/Silverlight has only been noticed by developers and they don’t know what to make with it.
WPF/Silverlight are not really developer-friendly: the development infrastructure is there but we’re left with a blank canvas and nothing to drag and drop onto it.
There will be a great gap, probably lasting a few years, before there are enough experiments in these new user interfaces that some useful lowest common denominator can be exploited by non-designers.
We’ll have to wait for tool vendors to provide the bulk of user interface blocks and for a few new patterns to appear before all the designer-challenged developers like me can make decent interfaces without requiring a professional graphic designer in their midst.
In the mean time, we’ll probably have useless, but pretty, applications, some useful, but ugly ones and a lot of people scratching their head trying to couple the designers and the developers in a working relationship.