I have been during the last months becoming increasingly warm to the idea of branching the UIP block into two branches: windows and web.

Here's the reasons why we did it unified in the first place, and my opinion on why the assumptions aren't holding that well:

• Assumption: The conceptual model for flow of windows and web is er.. fundametally similar. Really.
  Yeah. Like flow between web pages is the same as a single window hosting multiple controls in a layout...not 
  I (re)learnt that what is conceptually similar deep down inside isn't necessarily obvious, or helps communication. People get the similarity after some minutes of harassing them on the whiteboard, but we shouldnt inflict that experience to everybody. And if it takes that much explaining theres probably something eeky with the idea anyways. 
• Assumption: people can just move their navGraphs from windows to web or viceversa and reimplement views and taDAAA you have a new win/web ui
  er...sure...who want the views organization, contents & look & feel to be the same for windows & web?
  Reality is, we haven't seen folks do this at all, despite early beta feedback. Folks tgell us unifying the dev model from an MVC perspective is more useful, and that the actual protability of written navgraphs is secondary. So, having a common state and controller architecture seems to be 'enough'.
• Assumption: if you want a new UI activation style (wqizards, winforms w layout, asp.net controls, etc) you just build a ViewManager plugin
  oh yeah. Redirecting to nother aspx is the same as transferring and the same as showing a new control in a winforms layout?
  OK - the IViewManager idea technically worked but it was hard to see how Activate(a View) would, by itself, be an intuitive way of adding views into a collaboration for a use case. One of the things that irked me is that the view manager, inwinforms, has to keep references to views. The role of these components started going beyond activating views.

Of course there are other learnings but these are some of the important ones

We'll be floating the idea of separating them in the GotDotNet site for UIP, once we have a more solid proposal.

Regardless of separating windows from web, we want to make sure some issues are adressed nevertheless:

1. Moving to Whidbey (ASP.NET 2.0, Winforms etc.) - lay out the migration / interop nits & tricks. Foremost in my mind is making sure you can adopt the next platform rev naturally, quickly & without pain.
2. Reduce config needed! Some relationships we might as well move into code or attributes or designer properties
3. Help with more tooling. not necessarily ' flow designer' but to help people do databinding of state (model) to views, add..new view wizards and so on
4. Keep the controller -state relationship the same

If we decide to spearate windows from web, We'll try to follow our soon-to-be-posted smart client community process for the , but in the meantime, let us know what youd like in the workspace. If we do split it, the web verision will probably ship with entlib and the windows version will ship on a different timeframe (but probably close to each other)