I like metadata, so it bothers me when I see articles that encourage abusing it.  In particular I am referencing an article recently posted on MSDN titled "Metadata-Driven User Interfaces". 

In my interpretation, this article does a good job describing what you would have to do to create your own extensible UI runtime.  The idea is to define an XML representation of a UI, store the XML, interpret the XML and display the UI at runtime.  On the surface, this sounds like a good idea.  In fact, it seems "avalon like" (or Windows Presentation Platform) behavior.  The promise of extensible and customizable UIs make marketing and sales folks do back-flips, and creating a custom runtime makes alpha-geeks salivate.  BEWARE!  LOTS of good companies and developers have tried to do this and have failed!  Implementing a UI engine is much harder than it sounds.  Just because you can do something doesn't mean you should.

Among other things, ASP.NET reads markup and renders HTML.  Essentially you create an abstracted data store (aspx file), persist the store (save the file), and ASP.NET finds your abstracted data store and renders HTML.  At a high level this ASP.NET behavior is very similar to the behavior described in the MSDN article.  If you sign on for a "Metadata-Driven User Interface" you might be signing up to finish a project akin to re-creating ASP.NET.  Geeks like that, but the people bankrolling the project might not.

Here's some of the things you will need to think about:

1) Create Designers (in VS.NET or standalone) - this is a big deal.  Essentially you will have to create tools that design time render controls in any arrangement and save error-free XML (Sounds like VS.NET -> Source Code to me ).

2) Set boundries for what your UI will do and what it won't do.  You have to create UI schemas and treat them as immutable.  More times than not, you will have to "Kentucky Windage" guess at a set of functionality.  Your UI requirements will be "x" when you start.  You'll be wrong, then you'll have to change the schema, update the designers, etc.

3) Test the runtime.  Do you know how the runtime will be used?  Chances are you don't.  In my book it is really hard to test when you don't know how it will be used.

4) Performance can become a big problem.  Reflecting over metadata can be expensive.  Do it when you need to and no more.  The UI runtimes I have seen outside of MSFT have been too liberal in their use of reflection and as a result performance suffers.

The task certainly isn't impossible, but you need to know what you are in for.  I have seen several of these projects go awry due to overpromising and underdelivering.  If you want my advice, don't drink the UI Runtime Koolaid.  Use the tools that Microsoft gave you and don't reinvent the wheel.