Not really, Blend's original purpose was to be the middle-ground tool, to take the WinForms "design your screens" and really just isolate that workflow into its own area. The grand vision was that a designer / developer mutated zombie (devigner?) was to sit in a cubicle and interact with both parties to produce a XAML based solution for all to worship, high five and adore.
It wasn't until we spent around $500k in research that we soon figured out that the Devign Zombie doesn't exist, in that they are very rare (I'm an actual Devign Zombie, so ....i'm rare! lol) and in reality the overall story between the XAML/C# pipeline started to grow further and further apart. It's why you see the Cider Teams version of the designer surface didn't really matchup all that well in VS2008 to say Blend. In VS2010 the teams put together a better design surface, but the result is what I'd call "going to the prom with your cousin" (its better than nothing, but you're going to feel really wrong afterwards). Blend for me is the actual productive way of developing UI, I still every now and then revert into XAML mode mainly to fix bugs that I find in Blend - as its a piece of buggy crap. The gains you get over editing XAML imho is way better and i've never really understood why on earth developers spent so much time making sure the XAML is tabbed correctly and readable given it as a "language" was never ever ever ever meant to be touched by human hands other than to tweak attributes here and there. That being said, its clear Blend never got traction with developers as it was considered to foreign and the same goes for designers. It's why its actual download rates aren't that high and the actual purchases of Blend were embarrassing low. It's definitely in dire need of a UX personality to come through and simplify the entire existance of this into user friendly tooling but in reality that has been pitched and shot down many times internally. Given Blend is now a HTML5 focused tool going forward, who knows how that will pan out. All that said, WPF / SIlverlight has no short cuts to "getting started", its simply a solution that requires a pound of flesh up front. You're going to find days when you get excited about the possibilities but then there are also days when you figure out soon enough that the overall solution(s) have their way of kicking your butt. Many a time i've watched devs spend days on a bug, despite time boxing rules. Reality is, Silverlight/WPF aren't that well thought out and you simply have to pick fights with the two each day to master it. It at times feels like you have to plant the forest, harvest the wood, carve the tools and then you can start to build your dreams (kind of like Minecraft really, you start naked in the forest and 90hrs later, you have a wooden house that you can hide in from creepers (Blend/VS tooling). --- Regards, Scott Barnes http://www.riagenic.com On Thu, Nov 24, 2011 at 10:28 AM, Grant Molloy <[email protected]> wrote: > I think in the beginning Blend was thought to be the "designers" tool, and > vs to be the Devs tool. Many devs think of themselves as designers too > (devsigners) or their company doesn't have a designer, so they delved into > blend themselves. Then cae the blog entries, which I think led devs to > believe they need Blend. > > I haven't been in xaml for a few months now, but I think you need to > remember how mature winforms is versus xaml. MS missed the mark by a fair > way with xaml by not matching the completeness of winforms. I haven't > played with VS2011 and don't know if MS have improved this. > > Having said that, xaml is powerful and it's the fine control in these > times that makes it so powerful. I remember an app which needed a zoom > feature on an image, so I styled a check box control into a zoomable image, > using xaml (layout, style, and behaviors). > > My question about your interfaces would be why are they so complex? > Do they need to be? > Should you simplify / refactor them? > Are you using a 3rd party control suite or just VS controls? > Are you cutting your own themes or using 3rd party ones? > Are your themes in separate resource files? > > Am I wrong in saying that you can drag and drop a toolbox control into the > text editor view? > > In the end, if it's not economical for you, don't use it. > On 24/11/2011 9:12 AM, "Greg Keogh" <[email protected]> wrote: > >> Hi Folks, I’ve been working with Kirsten on her new WPF app, and I’m the >> source of her concern about WPF productivity, after she watched me >> composing moderately complex screens by editing the XAML in VS2010. I >> posted about this last year, but only received replies about “persist and >> you’ll get there and like it” types of responses.**** >> >> ** ** >> >> I’ve now been writing Silverlight and WPF intermittently for a few years >> now and I have never found a more productive way of creating reasonably >> complex screens other than by manually editing the XAML, and if it weren’t >> for the intellisense I would probably never have started.**** >> >> ** ** >> >> I hope you’ll agree that the VS2010 design surface is utterly useless for >> composing XAML using the toolbox, if anyone disagrees, let me know. Any >> attempts to drop tools onto the designer produce bizarre unexpected >> results, and you’ll be lucky if they even drop where you expect. For that >> reason I became quite proficient in editing XAML directly.**** >> >> ** ** >> >> Then Blend 2, 3 and 4 came out. I didn’t actually legally own Blend until >> I recently paid $3750 for a two year premium MSDN subscription which >> include Office and Blend suites. I have never like Blend. It has a totally >> different “feel” with new shortcuts, docking behaviour, colours and UI >> hints, it’s also “cluttered”, confusing, non-intuitive and worst of all I >> would have it open on one screen and VS2010 on the other, getting dizzy >> looking back and forth. Blend gives me the stinkin’ sh*ts.**** >> >> ** ** >> >> As a result of all this, I claim it can take me from 5 to 20 times longer >> to write a WPF app UI compared to a WinForms UI. That results in a lot of >> time, money and frustration wasted. I know that WinForms and WPF have >> totally different underlying encoding schemes, so it’s simply the design >> experience that leaves me bewildered and leads me to ask this:**** >> >> ** ** >> >> Do others out there have day-to-day techniques for efficiently composing >> complex WPF UIs? How are you doing it? Is there a friendly toolbox-drop and >> design technique that Kirsten (and me) are used to?**** >> >> ** ** >> >> Any specific advice would be most welcome. I feel I must be missing out >> on some productivity “trick”. Perhaps it’s because I hate Blend that I’m in >> this rut.**** >> >> ** ** >> >> Greg**** >> >> ** ** >> >> Ps. I have skipped mentioning other irritations like styling (which >> requires someone with special skills and Blend) or adding animations and >> triggers which bloat the XAML to huge sizes making them nearly impossible >> to edit by hand. I also ignored the sheer complexity of the XAML and how >> hard it is to remember something like the syntax and nest of tags required >> to make a ListBox item template (for example). I find I’m continuously >> looking up XAML samples on the web and pasting them in. I also find I’m >> writing converters all the time to get stuff appearing as I need.**** >> >> _______________________________________________ >> ozwpf mailing list >> [email protected] >> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >> >> > _______________________________________________ > ozwpf mailing list > [email protected] > http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf > >
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
