Partager via

Windows Forms and Avalon

  • Article

A lot of people have written on Windows Forms and Avalon, from Michael Harsh  and Joe Stegman on the Windows Forms team to the PDC docs, to Ian Griffiths. Based on all this, I realized that it's clear that, even though we at Microsoft think we're clear about when to use each, we haven't made it clear to customers. So I took the opportunity to write something up and have it reviewed by the Avalon and Windows Forms teams. What I found most interesting about this process was how hard it was to get to a simple, memorable set of guidelines (see the bulleted list below). The interactions of the software and requirements of each development project mean that there are choices to make. In any event, I'd love feedback if you have any.

At PDC2003, Microsoft introduced a new Windows presentation technology, code-named “Avalon.” Though Avalon v1.0 is not slated to be available to customers until 2006, we want to provide guidance on the relationship of Avalon to Windows Forms to ensure that customer investments in user interface are protected.

Windows Forms has substantial customer adoption today. It delivers a powerful rapid application development experience with full integration with Visual Studio, which lowers cost of development and time to market of smart client applications. Windows Forms v2.0 will release with Visual Studio 2005 (prior to Avalon v1.0) and is the best way today to create client applications using the .NET Framework. Going forward, Windows Forms will continue to be part of the .NET Framework and supported as such and is the main way to write managed code today to prepare for Avalon.

Avalon is Microsoft’s future presentation platform, designed for creating visually stunning, differentiated user experiences. Avalon builds on top of DirectX and introduces a unified engine for creating forms-based applications, graphics, video, and documents. Avalon’s engine fully exploits the richness of today’s hardware. When delivered, Avalon will become Microsoft’s strategic UI platform.

Microsoft is committed to providing guidance, tools, and technologies that will enable customers to leverage their skills and, where appropriate, source code to extend applications with the latest technologies. One of the key areas Microsoft has invested in is interoperability between Avalon and Windows Forms, enabling Windows Forms controls to be used in Avalon applications and Avalon controls to be used in Windows Forms applications. This interoperability technology will help customers smoothly transition to Avalon.

Microsoft’s roadmap for client UI development has three main phases:

  1. Today, use Windows Forms v1.1 and observe the Microsoft Patterns and Practices guidance for maintaining clean separation between UI and other application logic.
  2. When Avalon v1.0 releases (scheduled for mid-2006), we recommend that applications looking to differentiate their user interface such as Web sites and graphically intensive applications such as complex data visualization look closely at Avalon. Other applications should continue using Windows Forms.
  3. Following the release of Avalon 1.0, the next version of Visual Studio following Visual Studio 2005 will contain tools and designers to support Avalon. At this point, customers should start to move their new development efforts to Avalon and use the Windows Forms/Avalon interoperability features.

Comments

  • Anonymous
    November 27, 2004
    Hi John,

    your advice seems good and valid ,however, I think the problem is that the MS developer tools do not lead you in the direction of separating presentation from application code. A while ago I wrote a blog entry on this very subject
    -
    http://weblogs.asp.net/mspedding/archive/2004/04/13/112070.aspx

    Sadly the good developers will separate their code and then a lot of people will not and make a later move to Avalon problematic. I think the tools need to provide more guidance as a lot of people probably don't even know the patterns site exists.

    Martin Spedding
  • Anonymous
    November 27, 2004
    We're working on making the tools better at providing inline guidance about this -- VS 2005 in particular.
  • Anonymous
    November 27, 2004
    The former(?) MFC team should keep an eye on the separation auf UI and application code. I think their ideas were rather good, only the C++ language itself was not that suitable for it...
  • Anonymous
    November 28, 2004
    You're recommending we use Avalon on web-sites and complex data-visualisations? Seen as using it on web-sites is obviously out (there will be too many legacy users to even consider the technology, even if you're willing to say IE only) So it's only worthwhile considering for complex-data-visualisation, I don't do any of that, so presumably Avalon is completely irrelevant to me and I should put no effort into learning it?

  • Anonymous
    November 28, 2004
    I love being baited! :-)

    There are several scenarios on which you could use Avalon on a Web site. Already today there are full Windows applications that let sellers on eBay sell their equipment -- customers gladly download an application to help with this. If you built a better application that used Avalon and was transparently downloaded from the eBay site (or one of the sites that has made a business out of enhancing eBay), you could have an easy-to-update application that looks great. Or if you're a content provider like MSNBC you've already pushed the limits on what DHTML can do for your information, so you may want to build an application that lets you display it in a differentiated way.

    Yes, we'll have to overcome the fact that Avalon will run on XP and Windows Server 2003 and Longhorn and that we'll have to get it distributed. But that's a simple matter -- we've done over 100M desktops with the .NET Framework and can easily do that with Avalon.

    So yes, you should put effort into learning it. But if you're only building simple forms-based intranet applications today, you may want to wait until Avalon is what everyone is using.
  • Anonymous
    November 28, 2004
    That looks like great advice for Avalon, but what about Indigo? Should I still be using .NET remoting for my connected applications, or should I start looking into Indigo? I'm thinking here of internal Intranet-style apps where it's no big deal to require Windows XP and a WinFX download or whatever...
  • Anonymous
    November 28, 2004
    The comment has been removed
  • Anonymous
    November 28, 2004
    The comment has been removed
  • Anonymous
    November 29, 2004
    Fair enough points. From my perspective, one of the things that Avalon will do very well (along the lines of "differentiation") is to help meld the Web and Windows experiences the way Microsoft Money does today so users have an experience of your "Web site" that is local and customized to how you work. Is this a developer problem? Not really. But most of the companies I talk to from a business perspective are fighting for share of mind and share of clicks, and establishing a persistent desktop presence is part of that. Avalon makes that presence simpler.
  • Anonymous
    November 29, 2004
    The comment has been removed
  • Anonymous
    November 29, 2004
    John -

    the problem for many developers is that they really use quite a variety of different forms while developing in Windows tools:
    WebForms => ??
    InfoPathForms => ??
    VBAForms => ??
    classic HTML Forms => ??
    WinForms => all except complex visual forms and WebForms ???

    If you tell us the mappings I will post them on my site.

    Jacques Surveyer
  • Anonymous
    November 29, 2004
    I think MS Money is an excellent example for reference. I'm still impressed by how well it combines the best of both worlds.
  • Anonymous
    November 29, 2004
    If you want something easy to deploy, use VG.net, as it has only a small dll to be copied to the client (no installation) and runs in restricted security contexts:
    http://www.vgdotnet.com

    The run-time is free, you don't have to wait 2 years for a released version, and the vector graphics designer is integrated in Visual Studio .net.
  • Anonymous
    November 29, 2004
    You might want to contact me directly through Mardi Brekke. But the question you're asking is orthogonal to the point that this doc makes.
  • Anonymous
    November 29, 2004
    Then keep using ASP.NET!! :-)
  • Anonymous
    November 29, 2004
    This is still one of the best examples of an online/offline application that I've ever seen. The Money guys really get it. I haven't used the latest version of Quicken, but would be interested in how that's using online/offline experiences as well.
  • Anonymous
    November 29, 2004
    Sorry, it's Chinese only, at this time, but this web is a good example of presentation, code, and data separation. All work is done after the initial load via XmlHttp and .Net web services. http://www.twsm.com.tw/atNet Email: BDA_2003@hotmail.com
  • Anonymous
    November 29, 2004
    Sorry, I forgot to mention that you can enter with the "guest" account and password "guest". It's limited, but you can still get the feel of the UI.
  • Anonymous
    November 30, 2004
    John -

    Orthogonal ?? I think not - it is elementary developmental.

    Microsoft shop is currently using VBA with Word, Access, Excel and ASP for numerous desktop and Intranet apps - hence the need for VBAForms, HTML forms, and WebForms. Their managers say it is a brutal change management exercise. So a consultant was hired to fix it up. She recommands consolidating around InfoPath, hence the new but not compatible InfoPathForms. The company is ready to bite when all the discussion on Longhorn breaks out and new Avalon forms - now the company is back to square one.

    Jacques Surveyer
    =============================================
    PS: Who and where is Mardi Brekke? I am at jbsurv@theopensourcery.com

  • Anonymous
    November 30, 2004
    I'll have Mardi ping you.

    But it's different. When to choose Windows Forms vs. Avalon is one question to do with a particular (similar) type of application -- once you've decided on a "smart client." InfoPath is for a different challenges -- it's more the logical successor to Access. And Web Forms is a different solution to a different problem. But they're all for slightly different problems
  • Anonymous
    December 01, 2004
    John -

    Now I am totally mesmerized. The decision flowchart seems to be:
    switch (wheretogo){
    case "today":
    call Winforms(1.1);
    break;
    case "mid 2006":
    if(ComplexGUI || WebApp) {
    call Avalon("looksee");
    } else call Winforms(1.1);
    break;
    case "when VisualStudio Avalon appears":
    if(adventurous ? wetbehindEars : savvy) {
    call Avalon("use");
    } else
    call Winforms("WinformsAvalon Bbridge");
    break;
    case "VBAForms":
    call HailMary("move upto VSA???");
    break;
    case "HTML Forms":
    call HailMary("shame on you!");
    break;
    case "WebForms":
    call Orthodontist("He will know what..");
    break;
    case "Infopath Forms":
    call Orthodontist("It is going to cost");
    break;
    default:
    call Winforms(1.1);
    }

    This should parse in J++ but I am not sure all the routines are available.

    Jack
  • Anonymous
    December 01, 2004
    OK, this is hysterical.
  • Anonymous
    December 14, 2004
    No, this is realistic I'am afraid.
    As much as I like the idea of reusing windows forms for websites and making websites more interactive
  • Anonymous
    December 15, 2004
    That wasn't quite the point I was trying to convey. Can you elaborate?