Paul Stovell says…

Thought: Evolution of the WPF Designer

Posted on November 2nd, 2007 by Paul Stovell

Windows Presentation Foundation has copped a lot of criticism over designer support in the past year, and from my experiences with Visual Studio 2008 Beta 2, I don’t expect that will change. Even as it stabilizes, I don’t see the current incarnation of the designer actually making developers more productive.

I believe that WPF does not lend itself to the WYSIWYG drag-and-drop designer paradigm that we are all used to. And there’s a very good reason for that: WPF is a new UI paradigm. The concept of a drag-and-drop preview-centric UI building is an old paradigm, a throwback to our primordial roots in Visual Basic 1.0.

A WYSIWYG designer for WPF is the technology equivalent of the human tail. However, that’s not to say editing XAML by hand is the right way either. Why do I feel this way about the WPF designer, and how else can we increase our productivity?

Above: Our UI design tools have come a long way since 1991. Not!

Why are they building a designer?

I think the answer is simple: customers say they won’t use WPF until there is a designer.

Everyone I’ve spoken to that hasn’t actually tried WPF tells me they won’t move until there is good designer support. However, the ones who do take 5 minutes to install the VS extensions and play with XAML are horrified to learn that they can produce software by tapping a keyboard instead a mouse

We need to remind ourselves why we fell in love with designer tools in the first place: productivity. When we see XAML on screen, we should not ask “is there designer support?”, but instead we should ask ourselves “how productive is this?”

I think the answer is that hand-coding XAML is “okay” in a productivity sense - you can certainly get a lot done in a short amount of time once you learn the basics, but there is a lot of room for improvement. But is taking the design paradigms from the last decade really the best way to increase productivity with WPF?

Why is the Windows Forms designer the way it is?

The current designer toolset and approach evolved under Win32-based systems over decades. Of the many factors that influenced that evolution, there are four that bare a stark contrast to WPF:

Win32 UI’s are predominantly 2D and “flat”, in the sense that the level of nested controls is pretty low - in a typical Windows Forms window, I wouldn’t expect to see more than 10 levels of nesting in even the most complex window.
Controls in Win32 are normally positioned using absolute positioning - X-pixels from the left, Y-pixels from the top, and sometimes using anchoring or docking.
Hand-coding was practically not an option, even with Windows Forms, if you wanted to get home before 6PM.
The controls you dragged on at design time matched those that would be there at runtime - instantiating and injecting controls at runtime was common, but not as common as in WPF, and certainly not through data binding the way WPF does.

As Win32 designers evolved over time, the design experience became optimized to work within these constraints. For example:

When you dragged something from the toolbox to the middle of the design surface, the X and Y values would be set to place the control near your mouse, rather than the top-left corner.
The design surface is also very flat and 2D, optimized for the low use of nesting.
The design surface itself was an interactive, modified preview of your form, made easy because of the low level of nesting and minimal runtime injection of controls.

Much like animals evolve over time to suit their environment, the design paradigm we’re familiar with evolved for the environmental constraints imposed by Win32. But WPF is a new environment. Are our ideas around design tools compatible, or do they need to evolve?

The goal is increasing productivity, not creating a designer

Rather than focus on “designers” for a second, let’s again go back to why we liked designers in the first place: productivity. Our goal should be to design a tool, or set of tools, which makes us more productive.

Increasing productivity is simply a case of identifying things that consume our time, and then building something to reduce the time they take.

For Win32, let’s identify a few things that used to take a long time when we were coding by hand:

Adding controls
Positioning controls
Setting properties on controls

When you think about how much time was wasted aligning TextBoxes on a dialog by modifying code, testing, modifying, testing ad infinitum, you can begin to see why the Windows Forms designer is based around the concept of a preview of your dialog that is interactive. It’s simply a much faster way to bump things a few pixels to the left or right.

Let’s compare that list to WPF.

Over the last year all of my WPF UI’s have been hand-coded XAML. When I consider where my time is spent, there are a few things that stand out, in order:

Managing styles and resources
Setting up bindings
Testing that things look pretty, tweaking colors, etc.

It’s a very different list, isn’t it? Adding new controls to my dialog is no longer time consuming - it’s just an XML element, and Intellisense tells me how to spell it correctly so it’s usually only a few keystrokes. (In fact, from a standing start, I bet I could add a Button to a WPF window faster than you could to a Windows Form )

You’ll also notice that layout-related issues are not at the top of my “time-wasted” list. That’s because WPF gives me a number of layout options:

DockPanel - docking elements top, left, right, bottom and fill
Grid - divide the layout into columns and rows
StackPanel - repeat items horizontally and vertically
Canvas - X/Y positioning, like Windows Forms

Of these, the Canvas is in fact the layout element I use least, because the majority of scenarios a line-of-business developer faces are easier solved with one of the other layout containers. And because I use these other layout containers, everything automatically aligns.

Identifying the things that slow me down gives me a good idea of the things a development environment should provide to increase my productivity. I think it’s pretty clear by now why I don’t think the approach to a design tool that has worked so well for Windows Forms will work well for WPF. Let’s see how the WPF Designer compares…

Does the WPF Designer measure up?

If you use the WPF designer in Visual Studio 2008 Beta 2 and take time to define your layout using a Grid, then drag, say, a Button onto the Grid, the designer inserts crazily stupid Margin settings to position the Button near where your mouse was at the time.

For the Windows Forms developer in their first 5 minutes using WPF, this seems natural - you dragged the button onto the Window, and it put it where your mouse was. Simple. If it worked any other way, they’d dismiss it as buggy.

But for the competent WPF developer, this is a frustrating hindrance. Here I am, using this whiz-bang framework with these amazing layout capabilities I’ve heard so much about. I’m trying to use a Grid so that my layout is clean, simple and scales well at different resolutions and window sizes. Why the hell are you giving me a margin of “237,114,0,0″?

When you then take into account the deep levels of nesting most WPF windows will contain (assuming you don’t put everything on a Canvas with absolute positions, the way the designer wants you to), the UI experience becomes very clunky as it can be difficult to insert or move elements into the correct layout container in the hierarchy.

Again, this comes back to the paradigm: the flat layout of the Win32 designer didn’t have to worry about deep levels of nesting.

Even when the bugs are ironed out (and to be fair, the beta 2 designer is a lot more stable than it has been previously), I can’t see the current designer approach increasing the productivity of even semi-competent WPF developers.

My Ideal “Designer”

Having identified my productivity hindrances and demonstrating that the WPF designer does nothing to reduce them, and in fact will only hinder me further, I’ll now attempt to describe what my ideal IDE would provide in order to make me super productive.

An easy way of managing resources
1. Some kind of “Resource Explorer” to manage the resources I have, break them up into different XAML files (I DO care about which files resources are kept in).
2. Ability to drag and drop images and other files from the file system over a XAML file, and have the image added to the solution (in a folder somewhere) as well as a resource in the XAML which I can access via {StaticResource ...}
3. Ability to drag and drop images and other files from the file system over the “Resource Explorer”
4. Intellisense in the IDE so that when I type “{StaticResource “, it gives me a list of the resources in scope - maybe even filtering them by whether they are appropriate.
5. Drag and drop from the Solution Explorer into my XAML editor for resources, automatically adding any necessary ResourceDictionary entries.
Hot XAML editing features
1. Auto-closing XML tags (they took this out in Beta 2 (I think someone was stoned) but apparently they’re adding it back)
2. Support for custom namespaces and assemblies (they did a great job with this in Beta 2 - you even get Intellisense when you add an XML namespace for your CLR assembly.
3. Better support for custom attached dependency properties.
4. When expanding/collapsing the XML, the summary it gives for a node would be smarter - showing the x:Name of the node for example, or the Path of the first Binding it encounters.
Modest preview functionality
1. I don’t need an editable preview of the Window/XAML. I will only be using it occasionally, such as when stuffing around with colors or margins.
2. A 100px by 100px window with automatic zoom cursors would be perfect.
3. No more “Page intentionally left blank” crap. Funny the first time, painful the 200th time. You do realize I am using this tool every single day?
4. Loads in the background, is lightweight, and doesn’t interrupt me when I’m opening a XAML file to edit the contents.
A binding editor
1. A tool that helps understand what objects you have in scope and what bindings to write. More details below.
2. Intellisense for binding based on the above.
A layout outline

My IDE would then be organized into something like:

The Layout Outline is a 2.5D summary of the layout elements used in your window. It would be a small tool window that looks something like this:

It simply looks at the layout-related elements in the visual tree you have constructed, and highlights the one your cursor is closest to. It would have the following functionality:

Clicking an abstract element takes you to that element in the XAML
Changing the element you are on in XAML changes the selection in the layout outline
It would only show a limited number of items to avoid becoming cluttered (say, two levels of parent elements, and two levels of children). As your selection changes, the view changes, so you can effectively “zoom” through a abstract representation of the window to find the XAML you need.

The Binding Editor is a tab or perhaps tool window at the bottom of the screen. It provides an outline of your elements (like the Document Outline in VS2005 for Windows Forms) on the left, and an outline of your data contexts on the right, and allows drag and drop between them. For example:

The elements would expand/collapse like a TreeView, the DataContext can be set by typing in the window or dragging properties or other elements around, and validations, binding directions and converters could all be set in a simple editor.

My ideal designer recognizes that XAML is not something to be hidden away, but rather, that it is central to the editing experience and should be supported by various tools in the IDE to make editing it productive. A drag-and-drop designer inspired by Windows Forms does not fulfil that need.

This IDE would provide me with all the productivity boosts I would need to write build great WPF applications quickly. Things like animations, drag and drop and complex template editing can be left for Expression Blend. I feel this would be an evolved “designer” that targets the needs of line-of-business developers and anyone with enough patience to get over the “oh, the designer is different to Windows Forms” moment.

Will I ever get my designer?

Sadly, I don’t think so, not for the foreseeable future. And it isn’t Microsoft’s fault. It is our fault.

As I mentioned at the start, there are too many developers out there who are convinced that WPF needs a designer that looks and acts like the Windows Forms and VB6 designers. It’s a regular chicken and egg: if they tried WPF, they might also realize how impractical this is, but they’ll never try it until there is one.

For the foreseeable future, Cider will ship and I imagine future versions of the designer will improve slightly, but will still carry a lot of baggage from the VB 1.0 designer paradigm. People will continue to say “well in Windows Forms, you could do X…”, just as I have done in the past myself, and it will be a long time until our “design” experience begins to really improve our productivity.

As developers, it’s up to us to remember why we expect certain things to remain the same when new technologies arise, and to question those expectations before dismissing the technology. Maybe then I’ll get my designer

Technorati tags: wpf, cider, vs2008, designer, visual basic 1.0, xaml

Filed under: WPF

« Half-baked Ideas Presentation: 14/09/2007 - ADNUG - LINQ »

15 Responses to “Thought: Evolution of the WPF Designer”

Corrado Cavalli, on November 2nd, 2007 at 7:31 am Said:

Paul,
I’m with you when you states that the WPF designer should not be the WPF version of the WinForms designer, this just because WPF is NOT the new version of the windows forms technology. Unfortunately Cider, at current stage, is nothing more that a well integrated version of XAMLPad with a good intellises (excluding when, w/o any reason it breaks and no longer work)
We have indeed a good designer, and it’s Blend (the more i use it, the more i love it) even if, as all designer’s tools, no one is better than manual editing.
But do you really thing that WPF developers will be happy to spend their time among XAML typing {StaticResource …} or {Binding Source={RelativeSource …}} even if supported by a good intellisense? frankly I don’t think so, that’s why WPF success is tied to a good WPF designer (integrated or not) without one, WPF will remain a great technology but it won’t spread to the masses.
I personally edit a lot of XAML manually, but I’d love to spend my working time on more interesting stuff other than deciding if margin=”2,2,2,2″ is better that placing the control inside its own cell.
I agree with your designer view anyway…
Mabsterama, on November 2nd, 2007 at 8:50 am Said:

Paul Stovell on WPF Designers

Paul has just made an insightful post about the history and future of visual form designers with a Windows
Andrew Tobin, on November 2nd, 2007 at 9:29 am Said:

Actually I was speaking with Mabster at work the other day and I mentioned how the one thing I would like to see in XAML is an object explorer/easier way to bind.

It’s the one thing in WPF that I’m not wrapping my head around easily enough, and I’m basically just doing the same thing over and finding workarounds to do things the same way, rather than trying to figure out better ways to do it.

I’d love to be able to drag and drop an object into a ListView or something and get the right context created.

The only other thing that annoys me is while I get intellisense in the XAML designer, there’s no explaination of what each element does, like you get with C#, etc. If they told me the function of the elements then I’d have a much nicer time choosing between some of them.

And I know that, that is a crutch I need until I can get used to what is in there, and not really the sign of a good dev, but even us bad devs need a helping hand until we get there
Paul Stovell, on November 2nd, 2007 at 9:49 am Said:

Hi Corrado,

I think developers would be more productive editing XAML with good supporting tools than they would be using a “designer” — including Blend. They might not be happy per se, but with experience they will recognise that XAML gets the job done faster.

It is, unfortunately, a dilemma - to be productive in XAML takes experience with it, and that requires being open to the prospect in the first place. However I’ve seen a lot of developers pick it up with ease given the proper training.

Paul
Paul Stovell, on November 2nd, 2007 at 9:54 am Said:

Hi Andrew,

A binding designer is something I’ve been throwing around in my head for a while, and this post gave me a place to develop the idea more. I agree with your experience - it takes some time before you begin to recognize what binding you should be using when you go beyond {Binding Path=Blah}.

And yep, better intellisense would be nice. They could use pictures of the controls as icons for the elements, group the intellisense into logical ways, and show documentation and maybe even usage examples (in the status menu or something).

That will only come when we realize that XAML is a Good Thing, not something to be hidden away, and that the majority of WPF developers are comfortable with hand-coding XAML.

Paul
Jim Burger, on November 2nd, 2007 at 10:27 am Said:

It is unfortunate that people associate WSYWIG design with fast design. Personally, I have always disliked WSYWIG designers for markup languages; the markup they create is usually terrible.

We are software developers, we need to learn how to code before we learn to use tools to help us code.

For those of us who do know, some 3rd party productivity tools have arisen for ASP.NET and improve the hand coding experience in VS dramatically. I guess if MS doesn’t get enough productivity enhancements into the XAML editor, I expect it wont be long before these appear. This in turn would presumably encourage MS to include such functionality in a future release. *Hopefully* this occurs in a timely fashion.

Still, its a shame that the (seeming) majority of coders out there think they need a designer before they can learn a language.
Peter Drew, on November 2nd, 2007 at 1:57 pm Said:

Hey Paul, why wait for someone to build it for you? Think up a catchy name, get onto codeplex and start up an open source designer project.
Paul Stovell, on November 2nd, 2007 at 2:10 pm Said:

@Jim - I think you hit the nail on the head!

@Peter - I’ve got too many open source projects and ideas on at the moment but if anyone does want to build it, consider everything mentioned in that post as public domain.
Nigel Spencer, on November 2nd, 2007 at 9:04 pm Said:

Great post Paul - agree with all of this. I’ve never used the Visual Studio designer for serious business applications - not even for WinForms. In my experience its always been a little flaky - particularly when used in conjunction with my own set of flaky user controls :-).
I particularly think that there is a lot of merit in having a view that shows data/command binding separate from the UI hierarchy. I’m somewhat of the view that data binding that isn’t entirely UI specific (e.g. linking business object properties to controls) is best done separately from the WPF markup. Having a viewer/editor tool built over the XAML to show/edit the bindings would address this. Still stored inline with the XAML but able to be edited in bulk without trawling through reams of UI layout.
PaulStovell.NET Evolution of the WPF Designer « Noocyte’s Weblog, on November 3rd, 2007 at 2:48 am Said:

[…] Link to PaulStovell.NET Â» Evolution of the WPF Designer […]
Mike Brown, on November 9th, 2007 at 10:36 am Said:

Paul,
You already know my feelings on this. I’m performing a balancing act on the fence here. I haven’t used Cider much because I’ve been using Blend for my UI. I believe that for getting the *COARSE* layout of my UI done, it works great. I can get my UI done in a few minutes and move on to functionality.

Before I consider the UI finished however, I always come back to it and edit the XAML by hand. Like you said, the markup that gets spewed out at you is less than perfect.

I still believe that as WPF UIs are handed off to Designers (the people not the applications), they will need something that they can work with. That is where Blend comes in. I can do a quick and dirty layout using cider, xaml, or whatever and hand it off to my designer while I code the functionality. The designer can take that and make it not look like a developer threw it together very quickly to get to the functionality.

I truly believe that the entire dev-designer workflow is a great asset that WPF provides.

Once people realize that WPF UIs share more in common with the web than with Windows UI, they’ll get it.

BTW, a lot of the features you ask for in a designer are present in Blend, you can apply a template to an element and specify that the template is in an existing resource dictionary or even tell it to create a new RD for that template.

There is a treeview of your element tree that you can use to right click on an element and go right to the XAML, you can even drill-down to the template of an element and design against that.

Binding is dead simple too, you can bind against a datacontext or an existing element. If the element doesn’t have a name, it will automatically generate a name for the element for you. You can also bind against a CLR object and Blend will create a ObjectDataSource for you.

The designer of your dreams is here (minus the intellisense *DOH*) . And it is good.
David, on November 29th, 2007 at 6:13 am Said:

Paul,

I agree with your general point that the current WPF designer is trying too hard to be like the WinForms designer, and the reason is pressure from ignorant end users. However, there are other aspects of your post that are very hard to swallow.

“…the majority of scenarios a line-of-business developer faces are easier solved with one of the other layout containers [not the Canvas].”

You’re kidding right? Have you written a line-of-business application recently? Simple layouts just don’t cut it. Why do you think that the preferred method of laying out websites in the last several years has morphed from simple flow, to tables, to absolute positioning with CSS? WPF is trying to go backwards! Absolute positioning is not always necessary, and I wish WinForms had a better option for flow and table based layouts. But in the end absolute positioning is a necessity for a large majority of applications.

“Hand-coding was practically not an option, even with Windows Forms, if you wanted to get home before 6PM.”

That’s not true at all. Although I like the WinForms designer and use it for most GUI-related work, editing designer code is trivial if I ever feel the need. Why? Because the designer code is just regular code; its simple to look at it, understand what it is doing, and make modifications if necessary, even to the point of make wholesale changes. Contrast that to WPF, where coding in XAML not only requires a paradigm shift from WinForms to WPF object models, but also requires learning what is in effect an entirely new language.

“I think developers would be more productive editing XAML with good supporting tools than they would be using a â€œdesignerâ€ â€” including Blend. They might not be happy per se, but with experience they will recognise that XAML gets the job done faster.”

This is false almost by defintion. Editing GUI code, be it xaml or any other language, requires you to read the code, parse it, and transform it into a visible UI in your head, make the necessary changes in this conceptual model, and then translate those changes back into code, and make those code changes. Of couse, the more experience you have with a particular environment, the faster you will be able to accomplish this, until EVENTUALLY there might be almost no difference. But a good designer can dramatically reduce this threshold, allowing even mere mortals to accomplish tasks much more quickly than performing the same tasks by hand. Of course, any designer will almost certainly be an abstraction, so that hand editing will be necessary at times. But for the bulk of the work, a good designer could vastly improve the situation. Now, as you have pointed out, the current WPF designer, or any designer based on the old Win32 paradigm, won’t fit the bill; nor in my opinion does Blend, at least in its current incarnation. But that doesn’t mean that hand coding will always be the best option.

I like your ideal designer that you have outlined, but I still believe that a properly designed editable designer would be a great benefit to the vast majority of developers.

Mike,

I have wasted many hours trying to use Blend, and I can say with confidence that nothing about it is “dead simple.” But regardless, how am I supposed to justify to my manager that he needs to spend twice the money to outfit our developers with another IDE for developing .NET applications when he has already purchased Microsoft’s “premier” .NET IDE?
Paul Stovell, on December 3rd, 2007 at 10:59 am Said:

Hi David,

>> Simple layouts just donâ€™t cut it

Having built LOB applications in WPF I disagree. Going back to abolute positioning in Windows Forms proves to me just how much of a pain it was. And while most websites are using CSS, I wouldn’t agree that the best ones use absolute positioning

The HTML flow-based layout isn’t as powerful as WPF’s layout model.

>> editing designer code is trivial if I ever feel the need
>> Editing GUI code, be it xaml or any other language, requires you to read the code, parse it, and transform it into a visible UI in your head…But a good designer can dramatically reduce this threshold

Isn’t that contradictory?

In Windows Forms designer code you can’t look at the label with a Location set to 140,94 and know whether you need to move it three pixels down so the content aligns with the TextBox. With relative positioning, you can see that the Label goes next to the TextBox pretty easily.

Also, that’s why I suggested a read-only preview window, where the selected item is synchronized with the line of XAML you are on.

Paul
SK, on December 11th, 2007 at 11:12 am Said:

Good thing you don’t make IDE’s. We’d all still be using DOS to make apps, or at least hand-coding web pages using Notepad.

The very fact that VB & VS (not to mention Dreamweaver and a host of other web page editors & WYSIWYG IDEs) are sold in the millions of copies shows that your opinions on designers represent a minority of people. If it were not so, Notepad with Intellisense would dominate the industry.

WPF won’t take off until it has a designer that is better or at least as good as the ASP & WinForm equivalents.
Andrew, on March 11th, 2008 at 3:50 pm Said:

I’m a bit of a fence sitter on this one, I have built application completely by hand with WPF (in the Beta of Cider BTW which was hell) . And I agree there needs to be better designers for Resources, Binding etc. But having a visual preview that you can interact with is sometimes critical. Especially in complex UI’s it’s sometimes quicker to click a ListBox on the designer than it is to scroll through pages of Xml to find it. I think the best of both worlds could be achieved with context menus in the code editor, including Jump to Resource, Jump to Bound object etc. I’m dying for a Binding schematic diagram visualiser too which shows glyphs of objects (or a control preview via their data templates) with wiring between them.

Welcome

My name is Paul Stovell, and I am a software developer from Australia. I work for Readify, a .NET consulting company specialising in technical readiness. I am also a Microsoft MVP. In my spare time I work on Bindable LINQ, a set of open source extensions that enable data binding over LINQ queries.

November 2008
S	M	T	W	T	F	S
« Oct
	1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30

November 2008

« Oct

Corrado Cavalli, on November 2nd, 2007 at 7:31 am Said:

Paul,
I’m with you when you states that the WPF designer should not be the WPF version of the WinForms designer, this just because WPF is NOT the new version of the windows forms technology. Unfortunately Cider, at current stage, is nothing more that a well integrated version of XAMLPad with a good intellises (excluding when, w/o any reason it breaks and no longer work)
We have indeed a good designer, and it’s Blend (the more i use it, the more i love it) even if, as all designer’s tools, no one is better than manual editing.
But do you really thing that WPF developers will be happy to spend their time among XAML typing {StaticResource …} or {Binding Source={RelativeSource …}} even if supported by a good intellisense? frankly I don’t think so, that’s why WPF success is tied to a good WPF designer (integrated or not) without one, WPF will remain a great technology but it won’t spread to the masses.
I personally edit a lot of XAML manually, but I’d love to spend my working time on more interesting stuff other than deciding if margin=”2,2,2,2″ is better that placing the control inside its own cell.
I agree with your designer view anyway…

Mabsterama, on November 2nd, 2007 at 8:50 am Said:

Paul Stovell on WPF Designers

Paul has just made an insightful post about the history and future of visual form designers with a Windows

Andrew Tobin, on November 2nd, 2007 at 9:29 am Said:

Actually I was speaking with Mabster at work the other day and I mentioned how the one thing I would like to see in XAML is an object explorer/easier way to bind.

It’s the one thing in WPF that I’m not wrapping my head around easily enough, and I’m basically just doing the same thing over and finding workarounds to do things the same way, rather than trying to figure out better ways to do it.

I’d love to be able to drag and drop an object into a ListView or something and get the right context created.

The only other thing that annoys me is while I get intellisense in the XAML designer, there’s no explaination of what each element does, like you get with C#, etc. If they told me the function of the elements then I’d have a much nicer time choosing between some of them.

And I know that, that is a crutch I need until I can get used to what is in there, and not really the sign of a good dev, but even us bad devs need a helping hand until we get there

Paul Stovell, on November 2nd, 2007 at 9:49 am Said:

Hi Corrado,

I think developers would be more productive editing XAML with good supporting tools than they would be using a “designer” — including Blend. They might not be happy per se, but with experience they will recognise that XAML gets the job done faster.

It is, unfortunately, a dilemma - to be productive in XAML takes experience with it, and that requires being open to the prospect in the first place. However I’ve seen a lot of developers pick it up with ease given the proper training.

Paul

Paul Stovell, on November 2nd, 2007 at 9:54 am Said:

Hi Andrew,

A binding designer is something I’ve been throwing around in my head for a while, and this post gave me a place to develop the idea more. I agree with your experience - it takes some time before you begin to recognize what binding you should be using when you go beyond {Binding Path=Blah}.

And yep, better intellisense would be nice. They could use pictures of the controls as icons for the elements, group the intellisense into logical ways, and show documentation and maybe even usage examples (in the status menu or something).

That will only come when we realize that XAML is a Good Thing, not something to be hidden away, and that the majority of WPF developers are comfortable with hand-coding XAML.

Jim Burger, on November 2nd, 2007 at 10:27 am Said:

It is unfortunate that people associate WSYWIG design with fast design. Personally, I have always disliked WSYWIG designers for markup languages; the markup they create is usually terrible.

We are software developers, we need to learn how to code before we learn to use tools to help us code.

For those of us who do know, some 3rd party productivity tools have arisen for ASP.NET and improve the hand coding experience in VS dramatically. I guess if MS doesn’t get enough productivity enhancements into the XAML editor, I expect it wont be long before these appear. This in turn would presumably encourage MS to include such functionality in a future release. *Hopefully* this occurs in a timely fashion.

Still, its a shame that the (seeming) majority of coders out there think they need a designer before they can learn a language.

Peter Drew, on November 2nd, 2007 at 1:57 pm Said:

Hey Paul, why wait for someone to build it for you? Think up a catchy name, get onto codeplex and start up an open source designer project.

Paul Stovell, on November 2nd, 2007 at 2:10 pm Said:

@Jim - I think you hit the nail on the head!

@Peter - I’ve got too many open source projects and ideas on at the moment but if anyone does want to build it, consider everything mentioned in that post as public domain.

Nigel Spencer, on November 2nd, 2007 at 9:04 pm Said:

Great post Paul - agree with all of this. I’ve never used the Visual Studio designer for serious business applications - not even for WinForms. In my experience its always been a little flaky - particularly when used in conjunction with my own set of flaky user controls :-).
I particularly think that there is a lot of merit in having a view that shows data/command binding separate from the UI hierarchy. I’m somewhat of the view that data binding that isn’t entirely UI specific (e.g. linking business object properties to controls) is best done separately from the WPF markup. Having a viewer/editor tool built over the XAML to show/edit the bindings would address this. Still stored inline with the XAML but able to be edited in bulk without trawling through reams of UI layout.

PaulStovell.NET Evolution of the WPF Designer « Noocyte’s Weblog, on November 3rd, 2007 at 2:48 am Said:

[…] Link to PaulStovell.NET Â» Evolution of the WPF Designer […]

Mike Brown, on November 9th, 2007 at 10:36 am Said:

Paul,
You already know my feelings on this. I’m performing a balancing act on the fence here. I haven’t used Cider much because I’ve been using Blend for my UI. I believe that for getting the *COARSE* layout of my UI done, it works great. I can get my UI done in a few minutes and move on to functionality.

Before I consider the UI finished however, I always come back to it and edit the XAML by hand. Like you said, the markup that gets spewed out at you is less than perfect.

I still believe that as WPF UIs are handed off to Designers (the people not the applications), they will need something that they can work with. That is where Blend comes in. I can do a quick and dirty layout using cider, xaml, or whatever and hand it off to my designer while I code the functionality. The designer can take that and make it not look like a developer threw it together very quickly to get to the functionality.

I truly believe that the entire dev-designer workflow is a great asset that WPF provides.

Once people realize that WPF UIs share more in common with the web than with Windows UI, they’ll get it.

BTW, a lot of the features you ask for in a designer are present in Blend, you can apply a template to an element and specify that the template is in an existing resource dictionary or even tell it to create a new RD for that template.

There is a treeview of your element tree that you can use to right click on an element and go right to the XAML, you can even drill-down to the template of an element and design against that.

Binding is dead simple too, you can bind against a datacontext or an existing element. If the element doesn’t have a name, it will automatically generate a name for the element for you. You can also bind against a CLR object and Blend will create a ObjectDataSource for you.

The designer of your dreams is here (minus the intellisense *DOH*) . And it is good.

David, on November 29th, 2007 at 6:13 am Said:

Paul,

I agree with your general point that the current WPF designer is trying too hard to be like the WinForms designer, and the reason is pressure from ignorant end users. However, there are other aspects of your post that are very hard to swallow.

“…the majority of scenarios a line-of-business developer faces are easier solved with one of the other layout containers [not the Canvas].”

You’re kidding right? Have you written a line-of-business application recently? Simple layouts just don’t cut it. Why do you think that the preferred method of laying out websites in the last several years has morphed from simple flow, to tables, to absolute positioning with CSS? WPF is trying to go backwards! Absolute positioning is not always necessary, and I wish WinForms had a better option for flow and table based layouts. But in the end absolute positioning is a necessity for a large majority of applications.

“Hand-coding was practically not an option, even with Windows Forms, if you wanted to get home before 6PM.”

That’s not true at all. Although I like the WinForms designer and use it for most GUI-related work, editing designer code is trivial if I ever feel the need. Why? Because the designer code is just regular code; its simple to look at it, understand what it is doing, and make modifications if necessary, even to the point of make wholesale changes. Contrast that to WPF, where coding in XAML not only requires a paradigm shift from WinForms to WPF object models, but also requires learning what is in effect an entirely new language.

“I think developers would be more productive editing XAML with good supporting tools than they would be using a â€œdesignerâ€ â€” including Blend. They might not be happy per se, but with experience they will recognise that XAML gets the job done faster.”

This is false almost by defintion. Editing GUI code, be it xaml or any other language, requires you to read the code, parse it, and transform it into a visible UI in your head, make the necessary changes in this conceptual model, and then translate those changes back into code, and make those code changes. Of couse, the more experience you have with a particular environment, the faster you will be able to accomplish this, until EVENTUALLY there might be almost no difference. But a good designer can dramatically reduce this threshold, allowing even mere mortals to accomplish tasks much more quickly than performing the same tasks by hand. Of course, any designer will almost certainly be an abstraction, so that hand editing will be necessary at times. But for the bulk of the work, a good designer could vastly improve the situation. Now, as you have pointed out, the current WPF designer, or any designer based on the old Win32 paradigm, won’t fit the bill; nor in my opinion does Blend, at least in its current incarnation. But that doesn’t mean that hand coding will always be the best option.

I like your ideal designer that you have outlined, but I still believe that a properly designed editable designer would be a great benefit to the vast majority of developers.

Mike,

I have wasted many hours trying to use Blend, and I can say with confidence that nothing about it is “dead simple.” But regardless, how am I supposed to justify to my manager that he needs to spend twice the money to outfit our developers with another IDE for developing .NET applications when he has already purchased Microsoft’s “premier” .NET IDE?

Paul Stovell, on December 3rd, 2007 at 10:59 am Said:

Hi David,

>> Simple layouts just donâ€™t cut it

Having built LOB applications in WPF I disagree. Going back to abolute positioning in Windows Forms proves to me just how much of a pain it was. And while most websites are using CSS, I wouldn’t agree that the best ones use absolute positioning

The HTML flow-based layout isn’t as powerful as WPF’s layout model.

>> editing designer code is trivial if I ever feel the need
>> Editing GUI code, be it xaml or any other language, requires you to read the code, parse it, and transform it into a visible UI in your head…But a good designer can dramatically reduce this threshold

Isn’t that contradictory?

In Windows Forms designer code you can’t look at the label with a Location set to 140,94 and know whether you need to move it three pixels down so the content aligns with the TextBox. With relative positioning, you can see that the Label goes next to the TextBox pretty easily.

Also, that’s why I suggested a read-only preview window, where the selected item is synchronized with the line of XAML you are on.

SK, on December 11th, 2007 at 11:12 am Said:

Good thing you don’t make IDE’s. We’d all still be using DOS to make apps, or at least hand-coding web pages using Notepad.

The very fact that VB & VS (not to mention Dreamweaver and a host of other web page editors & WYSIWYG IDEs) are sold in the millions of copies shows that your opinions on designers represent a minority of people. If it were not so, Notepad with Intellisense would dominate the industry.

WPF won’t take off until it has a designer that is better or at least as good as the ASP & WinForm equivalents.

Andrew, on March 11th, 2008 at 3:50 pm Said:

I’m a bit of a fence sitter on this one, I have built application completely by hand with WPF (in the Beta of Cider BTW which was hell) . And I agree there needs to be better designers for Resources, Binding etc. But having a visual preview that you can interact with is sometimes critical. Especially in complex UI’s it’s sometimes quicker to click a ListBox on the designer than it is to scroll through pages of Xml to find it. I think the best of both worlds could be achieved with context menus in the code editor, including Jump to Resource, Jump to Bound object etc. I’m dying for a Binding schematic diagram visualiser too which shows glyphs of objects (or a control preview via their data templates) with wiring between them.