But generally you only need to write new controls when you are composing other controls. Otherwise you can change a control's UI easily through its template, and you can change its behaviour by attaching behaviours, rather than rolling your own.
Its these kinds of quick wins defined above that make WPF dev so much faster than win forms. Perhaps the problem here is trying to write a win forms app in WPF is harder than writing a win forms app in win forms, as opposed to writing a WPF app in WPF? (did that make sense at all?) Steven Nagy Readify | Senior Consultant M: +61 404 044 513 | E: [email protected]<sip:[email protected]> | B: azure.snagy.name<http://azure.snagy.name/> From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, 18 October 2010 11:37 AM To: [email protected] Subject: RE: Should I give up? Bloody oath. WPF Nirvana rocks. It's probably important to mention that even though one of the advantages to using WPF is that you can distinguish application from your opposition (via near-infinite flexibility in what you can do with the UI), a good UX will still ensure the user needs little to know training to use your app. If it's too hard to figure out, they won't use it (unless they're forced to of course!). If you're writing a regular business-type app in WPF, make sure you lock down the controls (and extended controls) you use to provide a consistent feel across your app. Resist the urge to spend weeks developing some new control to do everything. Little tweaks (like adding icons to combo boxes) go a long way to enhancing the experience without too much effort. But the point is don't go nuts extending the basic controls and you should be fine. That said, make your own controls where necessary. Well written WPF controls are pretty easy to do when you know how and can give huge value. Carl. From: [email protected] [mailto:[email protected]] On Behalf Of nos <[email protected]> Sent: Saturday, 16 October 2010 10:07 AM To: "'ozWPF'" <[email protected]> Subject: RE: Should I give up? I spent many years working in the WinForms world but a few years ago I transitioned to WPF. In the last three years I've never considered writing a WinForms application if WPF is an option. I find WPF to be far more productive for any of the application I write - that ranges from mickey-mouse home projects, simple CRUD apps and full blown multi-tier enterprise apps. In my opinion WPF is the clear winner over WinForms in every one of these cases - both in terms of productivity and potential capabilities. In terms of whether it's difficult to learn? There certainly is a change of mindset that I personally found frustrating until I was forced into the deep end writing a commercial app full time. Then there is the normal initial "where is the xyz property", or "damn I could do this so easy in WinForms" - but that's just part of picking up on any new technology that overlaps a previous one. Is it as hard as learning Win32 programming with MFC - hell no! Is it as difficult as wrapping your head around objective-C and Cocoa on the Mac - no way! Sure it easy to create a differentiating UX in WPF than it was in WinForms (writing customized highly performant controls in WinForms was really hard work). Its true also that having a great UX makes an app so much more marketable. However, even an internal battleship gray CRUD app is easier to write in WPF than WinForms (in main due to the vastly improved data-binding and the oh-so-wonderous DataTemplates). The only area that WPF really loses out on is the third party control eco-system - but give them time (does anyone remember how terrible the earily WinForms third party controls were?). I was kinda surprised by this thread that so many people seemed to think WPF was too hard or unproductive. Then again perhaps I shouldn't have been. After all look how long it's taken people to move away from VB6 (to .NET or other). Most of the stragglers used exactly those same arguments comparing VB6 to .NET. I'm lucky enough to be working for a company that only considers WPF and Silverlight for Windows desktop applications. Our clients expect us to be using those technologies - and yes on some apps we get to work with dedicated UX designers to produce some very pretty - but even more importantly - highly usable apps. I certainly hope that those on this list with lingering doubts about WPF keep striving to get over that initial learning curve. Should you give up? No way - don't be weak - there are rewards waiting for you on the other side. Stick with it and join us in the land of WPF nirvana. :-p Nigel Spencer http://blog.spencen.com From: [email protected] [mailto:[email protected]] On Behalf Of Winston Pang Sent: Friday, October 15, 2010 9:06 PM To: ozWPF Subject: Re: Should I give up? It's such a mix debate around who wants a WPF app over a WinForms app. Certainly at times I love going back to WinForms to make my test harness, and going back to the days where I draw my controls out through code, sure was fun back then, but now, damn, it feels great to not have to sit down and do some maths on measuring my dimensions and placement for custom controls. With WPF it's really easy to make rich custom controls, but it also comes with a price, the visual tree sure becomes fat, but so damn easy. At my current work place, maybe all our clients are very superficial or we tend to push it out a lot, but there's one WPF application we rolled out, it sure was a little bitch to get done, but one of our very first kicks into the WPF world as far as large applications are concerned, and it was pretty much similar to an AutoCAD system, you might think, holy crap AutoCAD systems, even the plans have a million lines and shapes whatever it might be, it's a kill to use WPF, should use WinForms and focus on perf. Well that client in particular was very into visuals and animations and really wanted the application to shine. I wouldn't know how you'd have that happen with WinForms, but it will be a bitch to do, to make it so rich. Another project we're currently working on is with a large waste disposal company, and the IT manager is also interested in focus on UI and visuals, at first I thought it might be an over kill, but like many has mentioned humans like looks, and especially with some companies having systems that all users use for 8+hours a day, you'd at least want them to smile when a screen looks nice or things transition so nicely. Think about iPhones, when you take the UI off it, it's actually nothing out of the ordinary, but because the visuals are so nice, transitions are so consistent, it becomes so pleasant just flicking between screens. Furthermore, I think a rich visual experience does help with people who aren't as literate, like they say a picture is worth a thousand words, I think the combinations of layout and visuals can also communicate the use of a system without many words on a screen. I think this thread discussion isn't ever going to end, because there are opinions on both ends, and to date it really is a combination of factors: a) does the developer think it's worth it to use WPF to make pretty UIs, thus resulting a push to recommend to their clients b) when should it really be used, does an app with two screens constitute to using it? On Sat, Oct 16, 2010 at 11:52 AM, Stephen Price <[email protected]<mailto:[email protected]>> wrote: People have come to expect a richer experience. I'm sure if you could install windows 3.1 onto todays hardware you'd be so impressed with the speed things run... but would you do it? I think of all the times I've installed some tool or app and noticed an outdated UI and decided that I don't really need it, and uninstalled. It's standard UI knowledge that the acceptance of an application (especially in corporate environment) can make or break it's actual usage. If people don't like it they will do everything in their power to not use it. The user's perception of an app has little to do with if it actually does the job or not. (sure it's a component) Looking and feeling good is a driving force of human nature. It's not survival of the fittest, its survival of the prettiest!! WPF can deliver that desired look. People want round corners and gradients, and gratuitous animations. People want modern looking homes. If you go out and find an old house made of brown brick with floral curtains and carpet and retro decor... well, it may sell but not for as much. Good looking UI/UX gets an emotional reaction from people, which is a very powerful driving force. Actually bad UI does too but not the desired emotions. I guess users are shallow, it's all about the looks. No one wants a Fat app! :) On Sat, Oct 16, 2010 at 6:34 AM, Greg Keogh <[email protected]<mailto:[email protected]>> wrote: > Why should anyone write an app in WPF? > > > > Serious question. If you have to create an app that looks beautiful with > gradients, shadows, smooth moving parts, menus containing videos, grids with > complex template cells ... then WPF is the only choice. Is there any other > compelling reason to use WPF to write a desktop app that doesn't need such > beauty? > > > > Since Framework 3.0 was released I've had a single job offer to write a UI > that had to be "beautiful". We did a demo, then the project was canned and > they finished up doing it in a browser with Google Web Toolkit (and it looks > impressive, in the Google Mail page style, but fancier). Every other desktop > app I've had to write needed absolutely nothing that WPF provides and it > would have wasted time and money to use anything other than WinForms. > > > > WinForms apps might arguably be a bit "dull", but more importantly, they > have a standard appearance. I strive to use standard menus, toolbar, status > bar, icons, shortcuts, etc, and WinForms encourages me to do the right > thing. WPF tempts you to write something strange and non-standard, which is > fine if that's what you want, but if not? > > > > So even though I'm greatly impressed by what you can do with WPF, it takes > much longer to write anything with it, and most business apps requested of > me don't gain anything. So why should anyone write an app in WPF if they > don't have to? > > > > Greg > > > > P.S. Maybe in some future thread I can explain the reasons why I am so > unproductive in WPF, XAML, type converters and infrastructure. Perhaps > people will be able to point out ways of overcoming my speed bumps. I'm not > unfamiliar with WPF, I'm just slower with it. > > > > P.S. A few weeks ago I did actually start writing a significant app in WPF, > by deliberate choice, even though the app doesn't technically need any WPF > features. We're converting a VB6 app to .NET in stages. Progress is slower > than it would be in WinForms of course, but it will be interesting to see > what benefits result. There is a risk that we will use fancy visual effects > just because we can, and I wonder if other people fall for that trap. > > _______________________________________________ > ozwpf mailing list > [email protected]<mailto:[email protected]> > http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf > > _______________________________________________ ozwpf mailing list [email protected]<mailto:[email protected]> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ ozwpf mailing list [email protected]<mailto:[email protected]> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf _______________________________________________________________________________ This email has been scanned by the Bankwest Email Security System. _______________________________________________________________________________ _______________________________________________________________________________ Unencrypted electronic mail is not secure and may not be authentic. If you have any doubts as to the contents please telephone to confirm. This electronic transmission including any attachments is intended only for those to whom it is addressed. It may contain copyright material or information that is confidential, privileged or exempt from disclosure by law. Any claim to privilege is not waived or lost by reason of mistaken transmission of this information. If you are not the intended recipient you must not distribute or copy this transmission and should please notify the sender. Your costs for doing this will be reimbursed by the sender. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. ___________________________________ ____________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
