sticky
ANN: The New Iteration: How XAML Transforms the Collaboration Between Designers and Developers in WPF RRS feed

  • Общие обсуждения

  •  

    I'm excited to announce the availability of a white paper that's been long in the making: The New Iteration: How XAML Transforms the Collaboration Between Designers and Developers in WPF.  This is a 28 page white paper written by Jaime Rodriguez and I that digs into issues and solutions when working on a WPF project with both designers and developers.  A result of extensive interviews with developers and designers with real world WPF experience, Jaime and I tried to get some canonical information out there for people trying to live the XAML dream and realize the benefits of the new workflows engendered by XAML.  We talked to both internal Microsoft folks as well as many external companies to coalesce the best practices that are being established in this domain.

     

    Would love to hear people's feedback and thoughts on the paper...

    7 декабря 2007 г. 21:55

Все ответы

  •  

    Great article on a very important topic, thank you for posting it.

     

    Cheers,

     

    Karl

    7 декабря 2007 г. 22:21
  • Excellent read, that was a great article. Nice to get a better idea of where I stand in the workflow Smile.

    14 декабря 2007 г. 18:36
  • Cheers Karsten - I was delighted to get a physical copy of this in my Mix pack.  The best thing we got in our swag this year at Mix!
    20 марта 2008 г. 4:01
  • Thanks, Rob!

     

    24 марта 2008 г. 23:44
  • The white paper does a good job of summarizing the collaborative model anticipated by Microsoft. But I think there is a fundamental problem with Microsoft's vision, and even a careful reading of the white paper has not affected my opinion.

    As a developer, my experience of WPF is that it basically liberates me from the need to hire or deal with a designer, and this is exactly the opposite of what Microsoft is advocating.

    In ASP.NET, if I wanted a form to have a gradient background, the easiest way to accomplish this was to get someone with a copy of PhotoShop to make a static graphic for my use. There were probably programmatic ways to do gradients (and other slick graphical effects), but it was far easier to just rely on the design / "skinning" process to provide this kind of effect. By and large, decent-looking applications had the people and processes in place to do this kind of static skinning, and there was a ready-made job market for designers working on ASP.NET and WinForms apps that would otherwise be "battleship gray." Times were good... everyone was thinking with portals, and hilarity ensued.

    In WPF, on the other hand, even a novice can create a gradient background with minimal training. The same is true of drop-shadows and transparency. Three of the most common graphical design chores have turned into easy C# calls or XAML tags. So why on earth would I bother hiring someone (or buying more software) to help me with this? And now that the gradients, drop-shadows, etc. originate from C# or XAML, how would designers (trained in PhotoShop or AutoCAD) even participate in the project?

    I understand the "party line" answer to these questions (they'll use Expression Blend to add a sense of artistry to the app) but I'm not convinced. There is no more compelling reason to buy Blend than there is to hire a designer... in both cases, the money spent doesn't add anything obvious to the project (unlike adding, say, a designer with Photoshop to an ASP.NET project, which can change the app's look-and-feel dramatically in ways that were previously impossible.) And I'm not sure that ITT Tech, the local junior college, etc. are going to rush out and buy copies of Blend for training. They will continue teaching in PhotoShop, AutoCAD, etc. and most Blend sales will go to people who are basically programmers, and most WPF projects will continue to not even open in Blend.

    Now I realize that there is an obvious counterargument: that graphic designers are not just PhotoShop jockeys, but instead they add an artistic vision to the project which has value regardless of the tools involved. I can admit that, but I think people are underestimating the creative abilities posessed by programmers. Not all programmers are creative, but programming is a very creative activity and I would submit that programmers as a whole are just as creative as graphic designers. A programmer in posession of WPF and a few design basics (use a consistent proportional font, choose a few hue / saturation combinations that look good together and apply them consistently, etc.) should be able to make an attractive GUI if he's so inclined. I have seen it happen, and I'm not referring just to my own work but to that of some of my colleagues, none of whom is otherwise much of an artist. Basically, when we roll out a new WPF app, it is received with giddy enthusiasm and praised as the best-looking thing ever. It's not because we used designers (we didn't), it's because of the technology we (programmers) had available.

    Are programmers as artistic as designers? That's impossible to quantify, but I think that the stereotype of programmers as a bunch of knuckle-draggers who would give us all battleship gray GUIs at best and the "$" prompt at worst is dead wrong. If I've ever failed to create a "compelling" or "stunning" user experience, it's not because I lacked the creativity, it's because I was using REXX or Gupta SqlWindows or some other tool that discouraged any UI paradigm other than battleship gray. I can't speak for everyone, but graphics were always a big part of what excited me about computers. I don't think I am that different from a graphic designer, I just had the extra money or patience or ability to get a CS degree instead of an AA in design.

    In fact, I'm not sure graphic design is a very good backround for designing a WPF app. Graphic designers tend to think in table-based-layout terms, which was fine for ASP.NET. Most of my WPF apps have a fluid layout based on floating, transparent container controls. Much of their visual appeal comes from dynamicity: motion, speed, and interaction with other graphical objects. Designers used to working in a static, 2D box a la ASP.NET or PhotoShop aren't really thinking in these terms. They used things like color, gradient, and shadow to create attractive ASP.NET GUIs because that's what they had at their disposal. The stereotypical ASP.NET app had beautiful buttons that didn't depress when clicked (rather, they were suddenly and incongruously surrounded by a stippled rectangle.) WPF, to me, seems to have an entirely new set of capabilities (e.g. raw speed) that will be more exciting for (and accessible to) programmers than designers.

    I don't claim that my opinion is a fundamental truth of the universe, but I think it's a counterpoint to the "party line" which deserves consideration. I have often said that Microsoft provides some great tools, but doesn't have a clue how they ought to be used. But that's the whole point of software.


    Beau W.
    10 июня 2009 г. 22:10
  • The white paper does a good job of summarizing the collaborative model anticipated by Microsoft. But I think there is a fundamental problem with Microsoft's vision, and even a careful reading of the white paper has not affected my opinion.

    As a developer, my experience of WPF is that it basically liberates me from the need to hire or deal with a designer, and this is exactly the opposite of what Microsoft is advocating.

    In ASP.NET, if I wanted a form to have a gradient background, the easiest way to accomplish this was to get someone with a copy of PhotoShop to make a static graphic for my use. There were probably programmatic ways to do gradients (and other slick graphical effects), but it was far easier to just rely on the design / "skinning" process to provide this kind of effect. By and large, decent-looking applications had the people and processes in place to do this kind of static skinning, and there was a ready-made job market for designers working on ASP.NET and WinForms apps that would otherwise be "battleship gray." Times were good... everyone was thinking with portals, and hilarity ensued.

    In WPF, on the other hand, even a novice can create a gradient background with minimal training. The same is true of drop-shadows and transparency. Three of the most common graphical design chores have turned into easy C# calls or XAML tags. So why on earth would I bother hiring someone (or buying more software) to help me with this? And now that the gradients, drop-shadows, etc. originate from C# or XAML, how would designers (trained in PhotoShop or AutoCAD) even participate in the project?

    I understand the "party line" answer to these questions (they'll use Expression Blend to add a sense of artistry to the app) but I'm not convinced. There is no more compelling reason to buy Blend than there is to hire a designer... in both cases, the money spent doesn't add anything obvious to the project (unlike adding, say, a designer with Photoshop to an ASP.NET project, which can change the app's look-and-feel dramatically in ways that were previously impossible.) And I'm not sure that ITT Tech, the local junior college, etc. are going to rush out and buy copies of Blend for training. They will continue teaching in PhotoShop, AutoCAD, etc. and most Blend sales will go to people who are basically programmers, and most WPF projects will continue to not even open in Blend.

    Now I realize that there is an obvious counterargument: that graphic designers are not just PhotoShop jockeys, but instead they add an artistic vision to the project which has value regardless of the tools involved. I can admit that, but I think people are underestimating the creative abilities posessed by programmers. Not all programmers are creative, but programming is a very creative activity and I would submit that programmers as a whole are just as creative as graphic designers. A programmer in posession of WPF and a few design basics (use a consistent proportional font, choose a few hue / saturation combinations that look good together and apply them consistently, etc.) should be able to make an attractive GUI if he's so inclined. I have seen it happen, and I'm not referring just to my own work but to that of some of my colleagues, none of whom is otherwise much of an artist. Basically, when we roll out a new WPF app, it is received with giddy enthusiasm and praised as the best-looking thing ever. It's not because we used designers (we didn't), it's because of the technology we (programmers) had available.

    Are programmers as artistic as designers? That's impossible to quantify, but I think that the stereotype of programmers as a bunch of knuckle-draggers who would give us all battleship gray GUIs at best and the "$" prompt at worst is dead wrong. If I've ever failed to create a "compelling" or "stunning" user experience, it's not because I lacked the creativity, it's because I was using REXX or Gupta SqlWindows or some other tool that discouraged any UI paradigm other than battleship gray. I can't speak for everyone, but graphics were always a big part of what excited me about computers. I don't think I am that different from a graphic designer, I just had the extra money or patience or ability to get a CS degree instead of an AA in design.

    In fact, I'm not sure graphic design is a very good backround for designing a WPF app. Graphic designers tend to think in table-based-layout terms, which was fine for ASP.NET. Most of my WPF apps have a fluid layout based on floating, transparent container controls. Much of their visual appeal comes from dynamicity: motion, speed, and interaction with other graphical objects. Designers used to working in a static, 2D box a la ASP.NET or PhotoShop aren't really thinking in these terms. They used things like color, gradient, and shadow to create attractive ASP.NET GUIs because that's what they had at their disposal. The stereotypical ASP.NET app had beautiful buttons that didn't depress when clicked (rather, they were suddenly and incongruously surrounded by a stippled rectangle.) WPF, to me, seems to have an entirely new set of capabilities (e.g. raw speed) that will be more exciting for (and accessible to) programmers than designers.

    I don't claim that my opinion is a fundamental truth of the universe, but I think it's a counterpoint to the "party line" which deserves consideration. I have often said that Microsoft provides some great tools, but doesn't have a clue how they ought to be used. But that's the whole point of software.


    Beau W.

    Finally - someone else gets it...

    I knew down deep in my programmer heart of hearts that I wasn't the only one looking at Blend and Microsoft's overall "vision", and standing mouth-agape, screaming "WTF?!"

    Can I reprint this on another web site?



    11 июня 2009 г. 9:40
  • Guys,

    I might suggest something different here.

    The designers we have working with us now are actually from a video/flash background, not from a PhotoShop background (though they have proficiencies there, too).  Specifically, they were involved in kiosk projects with user input and video/flash transitions.

    They know all about timelines, can write a little script here and there but aren't programmers.  But, they've been in the field long enough to understand and appreciate user interface, interactivity, keyframes and limitations of the platform, once you step out.

    On the flip side of that, there are rediculously insane programmers that I have worked with that could code themselves out of an Apollo 13 situation with only a stick of gum and three paper clips (maybe even two).  But they haven't a lick of design ability.  Their moms even threw out all the crafts they made for them for Mother's day as children.  Pretty harsh stuff.

    I wouldn't say your vision is the vision of everyone else, nor would I say that Microsoft has it nailed in all regards, but I think taking anyone's definiation of a term like 'design' and limiting it to what you've been exposed to in your career isn't quite fair, either.

    I'm about halfway through the paper as I write this and I think it's a good read.  The role of the integrator speaks directly to your concerns, and likely steps on your toes a little bit.  If you work in a smaller shop, you just have to be prepared to share the hat in the middle.

    The other option is just to split your own time between development and design, or hire out the design pieces to a competant third party.  I wouldn't farm this work out to any-old-PhotoShop-shop, and I'd assume that anyone working in the WPF space would qualify their vendors, as well.

    Cheers,
    -jc

    Edit: one more thing to consider, if you're using design patterns and specifically MVVM you don't really require any UI layout from your programmers.  There are framework, model, data access and business rules that can all be bound to by *gasp* a designer.  


    Me, coding and stuff: Mr. James
    • Изменено JamesChambers 19 июня 2009 г. 15:43 added comment on MVVM
    19 июня 2009 г. 15:38

  • Finally - someone else gets it...

    I knew down deep in my programmer heart of hearts that I wasn't the only one looking at Blend and Microsoft's overall "vision", and standing mouth-agape, screaming "WTF?!"

    Can I reprint this on another web site?




    Yes, of course you can. And I hate to sound like Richard Nixon, but I believe in that the "silent majority" of working developers views this kind of hype with skepticism. Not that long ago, Microsoft was foisting "N-Tier" on us, which was a nasty little pre-.NET combination of DCOM and Model-View-Presenter. This got replaced by .NET Remoting (ugh), and now presumably has been replaced by WCF. In the database and UI fields, there have been similar parades of one technology after another. The mind boggles at the collective complexity of these technologies, and also at the complexity that has come to characterize the technology selection process.

    None of this is meant to detract from the fact that Microsoft was making some really good compilers and debuggers throughout this period. But throughout that time I've also found it necessary to mostly disregard Microsoft's advice on how to use these tools (and convince my colleagues to do so as well, often unsuccessfully.) In the context of this thread, I would mention that I do think WPF is a great technology for GUIs, but that there a number of areas where I diverge significantly from Microsoft's recommended practices in the way I use WPF. Not using Blend is just one example. Beyond that, the entire philosophy of my designs is simply unanticipated by Microsoft's technical docs... I hinted at this in my last post.

    Microsoft would very much like to revolutionize the productivity and predictability of the software development process, and that's fine. But at the same time, I think they are underestimating the potential for more incremental improvements. For example, my hope for Linq was basically that Microsoft would enable us to use a subset of C# exactly how T-Sql was used previously. But that's not at all what Linq ended up being. Another example: Visual Studio has a bug in which cancelling a build renders "Find in Files" unusable until a magic keystroke is entered. This problem has been around for something like 10 years now.

    Of course engineers find it more enjoyable to "revolutionize" things, but it's the job of management (and the market - which seems to have lost its collective nerve in this regard) to keep these same engineers honest.  
    Beau W.
    26 июня 2009 г. 21:35
  • Guys,

    I might suggest something different here.

    The designers we have working with us now are actually from a video/flash background, not from a PhotoShop background (though they have proficiencies there, too).  Specifically, they were involved in kiosk projects with user input and video/flash transitions.

    They know all about timelines, can write a little script here and there but aren't programmers.  But, they've been in the field long enough to understand and appreciate user interface, interactivity, keyframes and limitations of the platform, once you step out.

    On the flip side of that, there are rediculously insane programmers that I have worked with that could code themselves out of an Apollo 13 situation with only a stick of gum and three paper clips (maybe even two).  But they haven't a lick of design ability.  Their moms even threw out all the crafts they made for them for Mother's day as children.  Pretty harsh stuff.

    I wouldn't say your vision is the vision of everyone else, nor would I say that Microsoft has it nailed in all regards, but I think taking anyone's definiation of a term like 'design' and limiting it to what you've been exposed to in your career isn't quite fair, either.

    I'm about halfway through the paper as I write this and I think it's a good read.  The role of the integrator speaks directly to your concerns, and likely steps on your toes a little bit.  If you work in a smaller shop, you just have to be prepared to share the hat in the middle.

    The other option is just to split your own time between development and design, or hire out the design pieces to a competant third party.  I wouldn't farm this work out to any-old-PhotoShop-shop, and I'd assume that anyone working in the WPF space would qualify their vendors, as well.

    Cheers,
    -jc

    Edit: one more thing to consider, if you're using design patterns and specifically MVVM you don't really require any UI layout from your programmers.  There are framework, model, data access and business rules that can all be bound to by *gasp* a designer.  


    Me, coding and stuff: Mr. James

    I think you make a good point, and probably the best possible counter-argument to my post. I did set up a metaphorical "straw man" designer which I then knocked down on the way to my conclusion. But I think you must acknowledge that this "straw man" designer (with his or her table-based designs and static gradients) exists. I think the associated skills became quite prevalent in the last 10 years or so, and they will need to be un-learned.

    As far as MVVM goes, I am amazed by its sudden popularity. To me, it looks like yet another variation on Model-View-Presenter with an even more confusing name (I would rather the tiers have arbitrary names like Magic, Larry, and Mike than to have quasi-meaningful names that all sound the same.)  I think all of these three-tier derivatives have a way of exciting architect-types at conferences but I have never seen the supposed benefits play out in the real world. In particular, the layer-swapping anticipated by MVP, MVC, etc. never seems to happen in the real world.
    Beau W.
    26 июня 2009 г. 21:48
  • I haven't read the white paper yet, but my impresson of XAML is that it's very complicated.  I mean what's easier than dropping a control on a windows form?  It stays where you place it, it enlarges as you want, it changes backcolors as needed and can display graphic background.  XAML to me is a pseudo marriage between HTML, XML and Windows Forms, it's confusing to me. 

    At first, I figured as a greenhorn, it was me and my learning curve was going to take a while, but the more I got into it, the more it reminded me of ASP.NET programming.  Shoot there's not even a control.refresh() option built in.  It acts like it's a web page all the time and that a round trip is required for everything.  Then I thought well, it liberates me from GRAY FORMs, so I tried to do the pretty stuff and found I have to have a degree in ART to get all these XML parms for gradients and the like, sure it's easy once you get it, but there's no simple IDE like C# express out there to do it.  It's all manual and burdensome work.  I personally don't like XAML and will stay away from it as long as Windows forms are around.  I don't do much ASP.NET stuff but still even ASP.NET is simple to use because it's just fancy HTML with a tag language of asp controls.  XAML on the other hand is a whole new thing.
    2 июля 2009 г. 5:11
  • I haven't read the white paper yet, but my impresson of XAML is that it's very complicated.  I mean what's easier than dropping a control on a windows form?  It stays where you place it, it enlarges as you want, it changes backcolors as needed and can display graphic background.  XAML to me is a pseudo marriage between HTML, XML and Windows Forms, it's confusing to me. 

    At first, I figured as a greenhorn, it was me and my learning curve was going to take a while, but the more I got into it, the more it reminded me of ASP.NET programming.  Shoot there's not even a control.refresh() option built in.  It acts like it's a web page all the time and that a round trip is required for everything.  Then I thought well, it liberates me from GRAY FORMs, so I tried to do the pretty stuff and found I have to have a degree in ART to get all these XML parms for gradients and the like, sure it's easy once you get it, but there's no simple IDE like C# express out there to do it.  It's all manual and burdensome work.  I personally don't like XAML and will stay away from it as long as Windows forms are around.  I don't do much ASP.NET stuff but still even ASP.NET is simple to use because it's just fancy HTML with a tag language of asp controls.  XAML on the other hand is a whole new thing.

    Everything can be done in C#. That fact doesn't excuse any particular aspect of XAML, but it might make your life easier. Charles Petzold's WPF book (Applications = Code + Markup) does a good job of showing how to code WPF in C#. The first half of the book is a complete exploration of WPF using only C#. He starts with gradients, and I had no difficulty parsing his instructions. Normally I recommend "WPF Unleashed" as the best WPF text, but if you want to see C#, Petzold's book might be better.

    More generally, I share your misgivings about XAML. My initial reaction to the idea of XAML (back in early 2005) was something like "so they're making Windows programming more like ASP.NET programming? Isn't that backwards?" Since then, I have heard all the arguments about how declarative programming is better than procedural, and the arguments about design encompassed in the white paper, but my opinion has not really changed. If anything, I am even more skeptical about XAML now that I have seen its constructs related to data binding and styling.

    I think the problems with XAML fall into two categories, each of which rests on a fundamental misconception:

    1) The confusion of simple "layout" with "GUI development."  For me, the term "layout" has a very static connotation: such-and-such goes here, such-and-such goes there, and the proportions and colors are pleasing and rational. "GUI development" is broader, and more dynamic: this control expands depending on context, that control can be resized, or becomes gray under certain scenarios, and so on. "Layout" can be done very effectively without using procedural code. "GUI development" cannot, and when one attempts to write a declarative GUI program, all sorts of awkward constructs (like XAML's data binding language, or WPF "triggers") become necessary. 

    I also think that the WPF GUIs that result from an overgrown "layout" process are sub-par. The real power of WPF comes out in performance: things can move quickly, things can be transparent, etc. Programmers live to exploit such a power tool. Designers, on the other hand, don't really know or care how many megaflops the vector engine can do (or whatever...) and are actually less likely or able to exploit WPF in new-looking ways. Ultimately, I think the vision in the white paper would result in designers bringing the appearance of ASP.NET applications to WPF apps. They will give us pretty-looking blobs, a la Media Player, which don't so much convey the power of WPF as they do the power of PhotoShop (or, more technically, Blend). 

    2) The mistaken belief that abstraction is an absolute good. I prefer to work at the highest level of abstraction at which I still feel like I understand what's happening. That guideline sounds obvious but I think the design of WPF overlooks it. A proponent of WPF once told me that he "prefers to work at the highest level of abstraction possible"... that's an absurd thing to say, but sadly typical of WPF I think. WPF is full of features that allow wide-ranging effects from minimal syntax (triggers, dependency properties, routed events, etc).

    These abstractions reduce the need to type, and in theory open up the process to designers. But in practice they come at a cost, in legibility. Consider what routed events and dependency properties do to the colocality of the code: they destroy it. Ask questions like "where did this value come from?" or "what code does this call actually run?" and you will all too often find that the answers have been abstracted away into some inaccessible file. Then you must resort to reading English-language descriptions of the operation of a black box, or to looking around in .NET Reflector.

    And I don't think real designers will ever embrace the more complex aspects of XAML... at best they will suffer them without much comprehension, as we've seen with CSS, and that's not a model I care to embrace.

    Beau W.
    7 июля 2009 г. 15:51
  • 2) The mistaken belief that abstraction is an absolute good. I prefer to work at the highest level of abstraction at which I still feel like I understand what's happening. That guideline sounds obvious but I think the design of WPF overlooks it. A proponent of WPF once told me that he "prefers to work at the highest level of abstraction possible"... that's an absurd thing to say, but sadly typical of WPF I think. WPF is full of features that allow wide-ranging effects from minimal syntax (triggers, dependency properties, routed events, etc).

    I agree that working at highest level of abstraction is the best way to go, all OOP and OOD designs lead us there.  I too, like you, like working there, but it took a number of years for me to think that way.  The problem with the C# and VB.NET versions of visual studio is that it is centered (or rather was centered) on GUI based development using the very powerful "Observer Pattern" of click events.  This very powerful design pattern actually hindered many programmers from adopting abstraction of classes.  Why? Because it allowed us to think in terms of "top-down" programming techinques that went like this "If the user clicks this button then we need to do this".  The marriage of GUI and underlying Business logic not only became one, the click event pattern flamed the fire of the marriage.  It takes a disciplined programmer to separate the two in the Windows Form based programming model.

    To me what whould make XAML more palatable would be a user control based model similar to what we see in WinForm development.  I should be able to drag any control and under the properties page access ALL properties via GETTER and SETTER methods which would show up in the properties page.  In addition I should have simple functionality in the code behind like CONTROL.REFRESH() which is not there now.  The XAML world is too disconnected from the code behind in my mind, and requires a Master's degree in understanding the zillions of things you can do with it.  How many years would it take to be truly a Subject Matter Expert in XAML?  (Shoot after 20 years of Java and Windows Forms, I still am learning GUI stuff, not to mention Design Patterns for code behind. 

    What Microsoft has done with XAML, similiar in scope to WCF is to create a whole new layer of very complex and steep learning curves for the novice to those areas.  Those of us with years of experince with C# and VB.NET have a good fundamental starting point, but I get discouraged when I can do good things with Winforms, and can't with XAML.  It doesn't make sense and reminds me of what IBM has done with their folks.  IBM regularly throws away technologies like OS/2 and even the AS/400 not to mention Token-Ring, PL/MI, 5250, 3270 all in favor of UNIX which was not even their own baby.   The moral of the story is be careful what technology you hop on because tomorrow it could die.  Running to keep up in the world of IT is a constant, but how long can we run?

    I still don't like XAML but maybe that will change one day when I can take a year off of work to really learn it.
    7 июля 2009 г. 17:42
  • IBM regularly throws away technologies like OS/2 and even the AS/400 not to mention Token-Ring, PL/MI, 5250, 3270 all in favor of UNIX which was not even their own baby. 

    I would add the MicroChannel bus to your list; 20 years later, MicroChannel (MCA) still remains the one "plug-and-play" technology that actually worked. The clone-maker's "plug-and-play" system was and is a joke. Eventually, widespread use of USB covered up the ugliness of "ISA," but there were some pretty lean years in the mean time. Sadly, the vast majority of PC users struggling with ISA had no idea that there was anything better available.

    Another example: the PowerPC chip. Intel's design philosophy for the x86 seems to be "maximize the marketable." You want RISC? Inflated clock speeds? SSE? 64 bit? CISC? Realistic clock speeds? Multi-core? It doesn't matter... eventually it will be grafted onto the monstrosity that is x86. PowerPC gave us a few years of hope for the future, then it was abandoned, in pursuit of some tiny performance advantage that we've probably squandered away 1,000 times since then. Sometimes I feel bad that IBM didn't select the 68000 for the PC, but then I remember that there was an equally large outcry for them to use the (8-bit, Intel-based) Z80, and they probably viewed the 8088 as a compromise.

    The lesson, I think, is that technological progress is not as inevitable as people believe. It's incorrect to say things like, "oh, the market voted on that one so I guess your wrong about AS/400s" or "WPF is the hot new technology so it must be better than WinForms." History doesn't bear out such assertions.

    If one must draw a solid line separating success from failure, I sadly must put WPF on the bad side. To be fair, it comes close to greatness, and Microsoft probably could have achieved greatness had they simply made WPF smaller. But too much of the ASP.NET engine remains, too much is abstracted out-of-sight.

    In particular, I think it is really brazen of Microsoft to tout the ability of WPF to offload operations to the GPU compared to WinForms. For one thing, WinForms already was hardware accelerated (remember "Windows accelerator" cards, the S911, etc.... they didn't disappear, they just became ubiquitous). Also, whatever does get offloaded to the GPU in WPF has been supplanted by all the scaffolding necessary for Dependency Properties, Dispatchers, Routed Events, etc. WPF crashes have some of the deepest stack traces I've ever seen. That translates to clock cycles on the CPU, and it's just disingenuous to say that using WPF somehow frees up the CPU.
    Beau W.
    7 июля 2009 г. 21:41
  • I worked with XAML when .Net 3.0 was introduced. The following was the major issue that I ran into:

    1. It was slower than anything else I had come accross in 20 years of programming.
    2. It is still slow.
    3. It is programming wrapped in XML.
    4. Please stop saying that XAML is designer friendly or that it is not programming.

    The option that I selected was to stop using WPF or anything that used XAML.

    I would not be concerned but now XAML has found its way into .Net 4.0 WF also. Just start an instance of WF in .Net 4.0 and you can see the same delay.

    It seems that XAML has design flaws like Bubble sort.

    Please tell me I am wrong and why ?

    Thanks



    hoon
    14 декабря 2009 г. 21:21
  • Forester September 2009 - WPF industry penetration is 10%. Surprise?!
    4 января 2010 г. 3:49
  • There seems to be a fair about of negativity about WPF and Blend in this thread.  I have a handful of personal success stories, most of which are on projects that are MVVM with every piece of UI done in Blend.  I do not have to believe, I have seen my results and are more than happy with them.

    Does MVVM with Blend work?
    I have successfully built applications (internal I'm afraid) that follow MVVM, where (close to) the entire interface was done in Blend.  When I say "close to", I talk about capabilities such as list filtering which I build into the viewmodel.  There is also the occasional control that has to be built.. but those are much more rare when you start building a good library of simple controls, valueconverters and Behaviors that are designer friendly.

    WPF is too slow.
    I understand there are speed issues.  I find that for many applications the speed is just fine.  I built one proof of concept application that had video and application sharing where I was updating 6 video feeds and their individual shares from others in a conference.  I could display live thumbnails of all of these in a sliding "drawer" window while there were other animations such as buttons that animated to show your camera was on.  There were other things going on in this window, such as a participant list.  All worked fine.  No complaints about speed.  This project was MVVM with all UI done in Blend.

    Now that we have Blend, we don't need designers!
    That might be true for a small set of engineers, but for the most part, I believe projects suffer if you try to give too much to a single person.  I'm an "OK" artist.  I can look at a candy button and build something close, but it will take me longer than a professional, and even when it takes them less time theirs are almost always better than anything I could do.  Not to mention the time I could have been coding, researching, refactoring, documenting, testing... all the things that I can make the most significant impact on for the team.  I could go on about how the art looks so much better when professionally placed and tweeked in Blend, but this reply is too long already.

    Ok, but designers are going to break my code base!  I'm not letting them within two time zones of my source control.
    In the game industry (which I'm not in now, but was for quite a while), I have worked with many artists ("designers" in the corporate world) that used 3D tools like MAYA and 3DSMAX, where me or someone else would write exporters to work with our game engines.  The designers would export their work directly into the project, where it became source for the build.  This work would include textures, animations, models, game AI scripts, and sound.  Did they break the build?  Of course they did... just as anybody new to version control will do.  But like all of us before them, they will learn quickly.  I've worked with more artists than I can count now, and believe me, if they can figure out some of these art tools, they can figure out simple version control (and any related tools and procedures in your checkin process.)

    MVVM??? Why do we need another goofy pattern?
    In 2 words, "it works".  I've been writting software since 1972 (really).  I've seem my share of snake oil.  The high promises of CASE (Computer Aided Software Engineering), how AI is going to make everything better, voice recognition.  Sometimes the  benefits are alluring, but we always find it's "not really there yet." (Although voice is getting real close finally.)   MVVM is here... now... it works.

    This WPF stuff has got problems.
    Yep.  Most of which I can get around right now... just part of the deeper part of learning anything new and worthwhile.  I find that each version of WPF (and .NET in general) gets better each time.. I mean a lot better.  Think back on just about anything in Microsoft history... Version 1 =  big problems, huge criticism, wails of impending doom.  Version 2 = some things fixed, too little too late, new features they should have put in the first time.  The next versions:  Some do go the way of the dodo I must admit, but I do not believe WPF to be in that group with all the consistent progress.  The things that do survive typically end up getting far better.  I believe that since .NET 3.5 that WPF is very viable, and I predict the WPF application sighting in the wild will start to outrank bigfoot sightings very soon.

    Lastly, I don't care what your doing your UI in now, but whatever it is, it's got problems too!  You've just learned to accept what cannot be done and work around it, and to focus on what can.  I believe as you learn WPF you'll find that your UI list of "can't be done" is far smaller than it's ever been.

    One engineer's views based on personal experience and peer review,
    Jim Tomasko

    23 января 2010 г. 12:53
  • My First impression of WPF was not good.  I didn't like it, felt it was too wordy, and it required too much internals knowledge to really make it sing.  Then I kept working at it and saw the abilites which far surpassed Winforms capabilities.  Then there was this neat little thing "Silverlight" which is a subset of XAML in WPF so now you could develop one and the same application for both desktop and internet.  Then there was Blend, which is just getting better and better.  And finally with .NET 4.0 even the free Visual Studio Designers have added a lot more function for things like gradients etc. 

    I didn't realize how much I had become fond of WPF until I was forced to go back to Winforms on a recent project.  I kept thinking, man, If this was only in WPF, I could do this and that.  Then I realized that even after 6 years of working on Winforms platforms I am still learning things I never knew in the past.  So, for me, I was slowly but surely converted to WPF and am now a big fan.  I can understand why there are the absolutely dedicated fans of WPF out there of which I am now a novice of that club.

    There really is no substitute for WPF and one could be kidding themselves if they believe that the presentation of our applications is not as important as the function...  I mean just look at what Apple has done to the cell phone market....

     


    Javaman
    7 мая 2010 г. 13:23
  • Thats really awsome :) please give more articles like this.

    Thanks,

    Thani


    Hei
    24 мая 2010 г. 13:16