WPF Design Surface Improvements in Visual Studio 2010

I have to ask. I keep seeing these demos about WPF in Visual Studio and everytime, they claim 'things are easier'... and perhaps compared to earlier versions of WPF/XAML editors, they are - but so far, every example I've seen is an order of magnitude of complexity over Windows Forms - while rarely adding much value.

In this video, there are several beautiful examples of this.

When he adds a menu, it doesn't go where you'd expect. Then for some reason, he *manually* deletes the default settings - which is equivalent to opening the designer.cs file and editing the generated code, then fiddles with it to the point where it vanishes entirely. Then he has to find a way to actually select it (since it's zero height) and then he ends up in an entirely detached menu editor.

In WinForms, you just... drag the menu to the window. You edit the text IN the window. You edit the parameters - which are explicitly shown in the parameter panel - which brings me to the search feature shown.. it assumes you know the parameters before finding them. That seems harder, not easier.

The design of WPF really feels like someone's trying to develop a UI design language that looks like HTML - but HTML is one of the worst UI design languages out there. A lot of the 'new features' do not seem to actually make things easier - or when they do, it's fixing something that was made unnecessarily complicated by the design of WPF - and isn't that complicated in WinForms.

Watching this video leaves me with one thought: I could so most of this in 1/10th the time in WinForms. I'm still entirely unconvinced that WPF is better - except for things that ONLY exist in WPF that the architects of this refused to back engineer into WinForms.

Sorry if I sound negative, but I feel the .Net team is, once again, ignoring desktop application developers - or worse, trying to make us into web designers at gun point, which is amazingly frustrating. The feature that most appeals to me about .Net and WinForms is that I *don't* need to know the underlying UI code (even if it's now XAML rather than C#) and could focus on the business logic under it. It seems that this is going away.

I agree with you, but as a WPF developer I never use the designer in Visual Studio...we use Expression Blend. I think the experience in that designer is much better than the one in Visual Studio.

WPF looked extremely complicated and overkill for UI design when I first saw it, but after developing a small application using it, going back to WinForms is painful. The binding features alone saved me at least 40-50 hours. I did all of the work in VS2008 SP1, and only used the designer as a kind of live preview of the XAML changes I had made. It's hard for me to imagine using a drag-and-drop style editor to create XAML-based UIs. I'm very anxious to try out VS2010 (hopefull a beta soon?) so I can see the advantages over straight XAML entry.

I have to agree with you entirely [Werewolf], I was thinking exactly the same thing. One other thing is that somehow the styling is oddly abstract and doesn't feel as Window-ish as when you do a Windows Forms application. In the video, the XAML editor is always present and to me, if you want to demonstrate the power of the visual editor, you need to hide that text editor away. If it has to constantly assist you, the visual editor is lacking. Nothing wrong with the XAML editor of course (although with M, one may hope to see an even friendlier syntax in the future.)

<Button>
    <ProgressBar />
</Button>

Now go do that real quick in winforms....

The change from Windows Forms to WPF is huge, I agree.

You can do so much more in terms of User Experience in WPF. And in my opinion the UI is the final frontier. In WPF you can provide your user with more information. And I am not talking about textual information, but visual information.

For instance; if you click on an object you can create an animation to zoom in an then break down the object into individual components, to see how the object is composed. That's relatively easy in WPF compared to Windows Forms. It just wasnt possible.

There is a video up on this site that displays virus reseachers linking documents to the actual components of the virus. Before they needed endless pages just describing what elements of the virus they research before they could present their results!

That's the power of WPF!

Hi, at http://www.xamltemplates.net/ you can find styles for all the WPF controls it will be nice if Visual Studio 2010 will support also this styles.

I am so with you. The designer is not at all where it should be. 

Agree, this is terrible.

This is good news. Most of the features are interesting. One thing I want to ask is why the WPF designer is supposed to have the same feel as the WinForms designer when it's time to drag and drop a control? This is so annoying when you want an autosizable control.

sigh

I think you guys just find it hard to learn a new technology.

And you say that HTML sucks? The internet is full of it! Designers and developers working together. And here is a platform that looks like HTML, so the curve to learn is not that big and you blatantly say it sucks? Just because you can't attach a menu like you did in Windows Forms?

That's nonsense.

I agree with most of what you just said (other than the nonesense about the learning curve for XAML when you know HTML... uhmm, riiiiight). The majority of the complaints here are way off.  In many ways, Cider is shaping up to be a better designer than the WinForms designer, and Blend blows both of them out of the water. More importantly, the WPF architecture so vastly improves the LOB development workflow that even if you had to work directly with the XAML all the time you'd still find a productivity improvement.

However, despite making a mountain out of a molehill, they do have a few legitimate criticisms.  It's more than a little strange that the default behavior is to add properties that aren't likely to be what you want (especially giving the control a name, IMHO).  I understand it would be worse to drop the control in with no width/height, making it "invisible" and confusing many people, but it certainly seems like there could be some more intelligence built in.  Dropping a Menu into a DockPanel?  OK, I'll set a standard Height and set the Dock to the top.  Dropping the same control into a StackPanel?  OK, I'll set only the dimension required by the Orientation of the panel.  Dropping it in a Grid?  OK, we'll try and make a guess as to put into the "next" cell and not set any dimensions. And so forth.  Also, the habit of removing all of those generated properties screams for automation.  Put a big ol' button in the properties panel that will reset all of the properties in one go.

The values come from dragging the item onto a certain position, so they are not defaults.

And come to think of it, I find XAML easy-er to write then HTML and CSS.

It's okay to be a fanboy, but please, these are valid arguments. This is not comparing HTML with WPF, this is comparing the Windows Forms designer with the WPF designer. It is also not comparing the feature sets, only the editing experience and ease of use. XAML is quite simple, no doubt, but the demo is about the designer. That is the whole point.

The WPF data model is very wholistically thought out and clean. Compared to HTML/CSS/DOM et al, there is no competition, but this is not the comparison.

Watched the video. Intellisense inside of {} is fantastic! The databinding wizard is a nice feature as well.

Is there a date for the VS2010 beta yet?

Is there any chance of adding some tool options so that you can disable the automatic addition of height and width properties, and to disable addition of child grid elements?

Thanks - the default values and extra layout controls are just plain annoying. All through the demo he's just deleting the default values. Why put them in at all? Or better yet, why not make them smarter? It shouldn't be too hard to infer the developers intended layout based on the type of control he is dropping in to a certain type of layout container.

I'm really excited about 2010 - the markup extension and binding intellisense will be a huge help!

And to the WPF nay sayers commenting on here - for simply laying out controls on a basic LOB form, WinForms is easier, but I would argue that writing an entire, working, LOB application is easier in WPF thanks to data binding. Plus, when it comes time do to something a little more visual, templating a control in WPF is 1000x easier than writing a custom control in WinForms!

I have been using various Microsoft technologies for client application development for many years. Sorry about the length of this post in advance.

The #1 problem Microsoft has when it comes to Windows right now is a total lack of clarity and direction when it comes to UX, and adding new languages and UI frameworks into the mix is only going to make the problem worse. No two application teams (nor the language teams, natch) have common UX guidelines- at least, not that is discernible from the outside. Windows Live apps use completely different controls and UX methodologies than Visual Studio, or Office, or first party accessories like Paint. There are almost no common controls, and those that are used in common are often not implemented the same way. See: toolbars vs. Ribbon; the search control in Explorer vs. IE; the Hardware and Sound control panel vs. Devices and Printers control panel; MFC legacy apps vs. WinForms apps vs. WPF apps vs. one-offs like Media Center; the tab control in IE vs. Excel worksheets; the tree view control in Explorer vs. the Favorites tree control in IE.... the list goes on and on.

Do you know what the best looking app on my installation of Windows 7 is? blu, the twitter client from thirteen23.com. Beatiful WPF application with slick opening and closing animations, a neat scrolling behavior, and 100% custom UI. Right on, WPF team, you made a framework that smart guys like those at thirteen23.com can create awesome experiences. But wait- no other app on Windows 7 looks or works like this one. NONE. There is not a single native WPF-app on the default installation of Win7, in fact. No other app on Windows uses blu's impressive window flip to access a properties and settings area.

So now the WPF team has been slaving away, seemingly oblivious to the impact that WPF is going to have on the overall UX of Windows as a platform. The Office team is undoubtedly completely unconcerned with whatever the Visual Studio team is doing with the WPF designer, because the Office team always does its own thing and writes its own controls, and once WPF is mature (maybe in time for Office 2013?) they will start to think about using it. The Shell team is also totally unconcerned with WPF, or indeed .NET altogether, since they write their stuff in C++ and, again, create their own custom controls. Windows Live Messenger does a bang-up job of breaking Windows 7's new taskbar metaphor by putting a "running app" icon in the taskbar for a windowless application- clicking this taskbar button opens another window! Way to lead by example.

This haggling over the default settings of WPF controls in Visual Studio is missing the big picture entirely: Microsoft should have worked out the "Microsoft Way" for these controls to work ahead of time, and the WPF team's job should be to make the defaults adhere to those guidelines. Visual Studio should guide third party app developers towards creating experiences that look and work like the rest of Windows. Sure, the UI framework should allow custom controls and original ideas for UX, but these should be exceptions rather than the rule.

UX needs to take precendence over UI development at Microsoft. There needs to be some sort of "UX Czar" that creates a set of guidelines that other teams at Microsoft are forced to follow. Development of new UI frameworks MUST be subordinate to Microsoft's overall UX strategy, and release dates for new versions of Visual Studio and other tools must fall in sync with major client releases. If WPF is the way of the future, then Microsoft should dogfood its own tech and write Windows apps in it, and they shouldn't start releasing toolsets for it until they have worked out the "Microsoft Way" for WPF apps on Windows. Former walled gardens like Office are going to have to get into conformity with the rest of Windows, too.

Visual Studio 2010 is going to come out AFTER Windows 7 RTMs? Will it include the common controls that Microsoft uses to build Explorer, like the search control, the treeview, the weird new datagrid thingy that is used to display files and folders? How about the forward/backward control that is implemented differently in both Explorer and IE? What is the "Microsoft Way" for creating compelling UI that fits into the overall UX of Windows as a platform?

 

Welcome to 2003!!!

 

 

Please folks for god-sake , can u get some good camera & make the VIDEO look little professional

I could barely ready any of your code....

Agree. Doing QA and Build Management, things are even worse. It takes much more time to assure quality in WPF/SL than in Forms. Runtime is much more complicated. Compiler aid to find bugs is very bad. Seems that MS is doing a Top-Down approach here and ignoring the many side effects and additional work that comes with WPF/SL.

For example, XAML is created to help Web Designers, so they can use their skills. But the XML Editor in Blend 3 is not good. The core technology is working fine. But the tools and the ecosystem waste a lot of time.

If Microsoft was selling cars, they would insist that you know how to rebuild your transmission but NEVER tell you how to shift to drive the car. If that is not bad enough, they have to show how many different ways you can rebuild that transmission. Another words, totally confuse the user.

There must be one good way of doing things and Microsoft should be able to explain how to use the tools. If I need to know how the tool works, in order to use it, then I might as well build my own.

80% of all my work is now WPF/C# and I never use the toolbox, drag & drop or the properties window. It's so much faster to just start typing the XAML and let the IDE finish.  I would go nuts trying to build a large project using the methods shown.

 

To me the only thing the toolbox would be good for is if you could right click and select "Copy Template" to get the XAML of the control. Unfortunately you need Blend to do that and it's not compatible with VS 2010 projects.

I use MVVM pattern when developing WPF now. The feature of setting datacontext in XAML so that Intellisense is provided was an unknown functionality for me. This makes it easier to set up bindings to the view model in the binding expressions of the XAML.

Nice shirts by the way, but where is the drinks with the umbrellas ?

Annoying as this video is, it's made even worse because some of the content that is referenced by the tutoral is off screen, and can't be seen... how bad is that!!!  There is a also a comment above about the low quality resolution.   There is supposed to be a higher def version available top right of the screen listed as "High Quality WVM" but it's still low resolution, which makes it very difficult to read the text on the screen.
Some useful tips on how to best use the design surface - which I wish they had spent much more time on.