PETZOLD BOOK BLOG

Charles Petzold on writing books, reading books, and exercising the internal UTM


Recent Entries
< PreviousBrowse the ArchivesNext >
Subscribe to the RSS Feed

The Disasters of Visual Design Tools

July 16, 2010
Roscoe, N.Y.

Many years ago — about the time that visual design tools were being introduced into our programming environments — I promised that I would never believe myself to be teaching programming if I were writing sentences like "Now drag the Button from the toolbox to the window." I am proud to say I have kept to that promise.

Let me make this clear: As a programmer, I am not opposed to the use of visual design tools. But as a teacher of programming, I consider visual designers to be pedagogical catastrophes. Obviously they can't be used to teach good ways to construct code, and the reliance upon these tools by beginning progammers often leads to very sloppy and sometimes horrifying results.

An extreme example was provided by some recent email I received. A programmer writing a Windows Forms application needed to construct C# statements in strings during runtime and then execute these statements. I was curious why, because this is not a need that comes up very frequently in most programming jobs. Well, it seems he had a bunch of Label controls on his form, and they all had different names, and he couldn't find a way to access a particular one. But he was able to patch together strings such as "label800.Text = \"xyz\";" to do what he wanted, and that's why he needed a way to execute that statement at runtime.

It took me awhle to realize that the existence of controls with names such as label800 implied that he had laboriously constructed the visuals of his program by dragging over 800 Label controls from the Visual Studio toolbox to his form, and then arranging them into rows and columns.

Although there are many correct ways to solve any particular programming problem, there are also many totally wrong ways, and using a visual designer to create more than (say) half a dozen of the same type of control arranged in some kind of visual pattern of rows and columns is wrong, wrong, wrong, wrong, wrong. This is a job for code. The controls should be created in a for loop that algorithmically calculates their locations (if necessary), and then stores them in arrays for easy access. (The question whether over 800 Label statements is too many for one window is an issue I won't address at the moment.)

But why would anyone think these controls should be created through the visual designer? Well, bring up Visual Studio and create a new Windows Forms project. The screen that comes up is a design view, immediately encouraging you to drag and drop controls on the window's surface. Visual Studio is telling us that this is the proper way to design our program's visuals.

Not only Visual Studio, but many books and presentations encourage the use of visual design tools as well. I suppose the intent is to show how "easy" it is to build a new program. But that's clearly dishonest, and downright lazy on the teacher's part. Much more useful and valuable would be different varieties of code-based solutions. But when was the last time you saw a presentation where the instructor showed how to create controls in a for loop and store them in an array?

Of course, the problem has become worse with WPF and Silverlight. My original fear — that many programmers wouldn't learn how to do something in code that could be done in markup — has certainly become true, but now many programmers don't even write their own markup! Expression Blend has convinced many programmers that they don't need to learn how to write gradient brushes, or animations, or templates, or become familiar with the Visual State Manager because Expression Blend handles all that.

It sure does, and I'm probably not the only consultant who has seen horrifying pages of XAML animations generated by Expression Blend when a simple code-based solution (such as a custom panel) would work much better, and be easier to understand and maintain.

Obviously our programming tools partially determine the quality of the programs we write. This is why the GOTO was considered harmful and why it's been largely banished from modern programming languages. Innocent in itself, the GOTO nevertheless encouraged programmers to create big ugly mounds of steaming spaghetti code that no human could possibly navigate or interpret.

Now we get mounds of ugly markup that's not even formatted in a way to make it easy to read. We're not supposed to read it. We're supposed to trust Expression Blend. But Expression Blend won't tell us if there's a better way to do the job.

I don't know what the solution is. Certainly our programming environments should encourage us to actually write code or markup rather than to drag and drop controls. Visual design tools should be considered "advanced" techniques that programmers are qualified to use only when they can accurately predict what code or markup the visual designer is generating.

And certainly authors and presenters shouldn't pepper their introductions to WPF or Silverlight programming topics with sessions in Expression Blend. That's just plain irresponsible.


Comments:

While I agree with you on most of your points, and I love the way you approached the matter in Applications=Code+Markup. It bothered me a bit that there wasn't a single screen shot. But as I read through the book, I realized the brilliance of your method and I still highly recommend the book to anyone who truly wants to learn WPF the right way.

But the truth is that the majority of applications built today are still simple forms over data. As an example, I am now totally converted to WPF and I really can't stand the designer in Visual Studio so I always use the XAML editor. But just the other day I had to write some bullshit forms over data application and I decided to use Windows Forms, a DevExpress Grid, and some BindingSources. I wound up with a ton of labels, text boxes, etc that were mostly auto-created by the designer but who cares? It's going to be used a few times and thrown away.

Now as for Blend, don't even go there. :) It's a totally different use case and it's very appropriate for Blend to focus on visual design tools.

Josh Einstein, Fri, 16 Jul 2010 10:54:53 -0400

It is probably a exemplar case of leaking abstraction...

It would be great (or not?) if we never have to mess with XAML code (either good or bad, no difference), just use Blend (or VS XAML visual designer), create UI with it, and then "simply add needed code to it".

But world is not that simple... or maybe we are not there yet...

Slavo, Fri, 16 Jul 2010 11:03:43 -0400

I certainly agree with the motive of your post. When I ran database administration teams, I wouldn't allow my DBAs to have graphical administration or development tools until they showed a level of competency for the dynamics of what went on underneath the facade of the graphical environments - and developed an ability to know when the code generated by the graphical tools was good & efficient, and how to use that product to tweak their way to efficiency.

I fear that our reliance upon code generation, the abstraction away from understanding what is going on behind the curtain and the general apathy towards educating our developers about organization, optimization and good design by not "forcing" them to relive the "good old days" is really creating a blind spot for us technologically. That is why I have developers killing 32-core database servers with some really, uh, "unique" code.

— 0dj0bz, Fri, 16 Jul 2010 13:15:29 -0400

I agree wholeheartedly. I post on a VB .NET forum that tends to have a lot of beginners, and the situation you described at the beginning comes up roughly once per week. Another common pitfall: if you've only ever used the designer, there's no intuitive way to find the AddHandler statement so you have no idea how to add event handlers to runtime-created controls. The list goes on and on...

While I would have loved to get some Blend experience out of your books, I have always valued your "code-first" approach to .NET. I read your Windows Forms book long agon, and when I learned the designer wasn't magic and was just spitting out code I could write myself it changed everything and made a lot of problems I was having easier to solve. I would even cheat sometimes and learn new concepts by doing something in the designer, then studying the generated code.

Owen Pellegrin, Fri, 16 Jul 2010 13:43:52 -0400

label800.Text guy is definitely a beginner or a hobbyist, but anyway, I see most successful applications (specially web applications and websites today) are made in a (very) "quick and dirty" way which leads to big mess in code and database.

I have been developing applications for many years and integrating them with many systems (big reputable systems) but I NEVER found a normalized database inside or a good implementation of reusability.

Sometimes I feel I am the only developer in the world today who creates normalized database and hand-coding about 90% of markup in apps.

Moutaz Shams, Fri, 16 Jul 2010 13:56:40 -0400

100 Percent agree!

RAD-Tools should be used only by Professionals, NOT by Beginners

Werner Mairl, Sat, 17 Jul 2010 01:30:15 -0400

— Jeff Prosise, Sat, 17 Jul 2010 08:59:03 -0400

One person still needs to know what is going on. Will that person please turn out the lights when we are done.

Dean Kaplan, Sat, 17 Jul 2010 17:48:49 -0400

The visual designer tools makes creating a GUI application much easier and faster. But the programmers should know what the code is generating behind, otherwise the applications will going to be hard to maintain.

Yin Peng, Sun, 18 Jul 2010 05:52:38 -0400

I have been also developing applications for many years and integrating them with many systems but I NEVER found a normalized database inside or a good implementation of reusability.

sandeep, Mon, 19 Jul 2010 03:21:26 -0400

You mean you don't get stuff like that every day? Really?

Don't follow the link then. You'll cry.

And don't say I didn't warn you., Mon, 19 Jul 2010 20:51:28 -0400

I think the idea behind Expression Blend is to allow non-programmers to create UI's and let programmers stick to the code behind it. Patterns like MVVM really help for this.

However, unless you're working at Microsoft or some other big software shop, I bet that scenario is very rare. I tried the VS2010 designer and Expression Blend for WPF applications for awhile and eventually reverted to 100% hand-coded markup. It's actually faster (I don't have to spend time cleaning up the generated XAML), cleaner, and more maintainable.

Blend is nice for doing little graphical embellishments and animations but most of the time that just leads you down a path toward bad usability anyway.

— Ben, Tue, 20 Jul 2010 10:01:27 -0400

I do agree with your point for the most part. But, I have to say that development has changed. It is no longer 1's and 0's. WPF allows windows applications to be built in a more interesting way as opposed to traditional boxes and lines. With that, it tries to separate the work between a developer and a designer (and interaction designer). You're talented in both ways so it may be easier for you to work on everything in code, even animations as you said. However, Blend does provide a much better option for visual representations of objects. It is true, that eventually it may have to be converted to code to allow for dynamic interactions, but I've seen the opposite too where someone tried to do everything in code, which is certainly not the recommended direction WPF is taking.

Jason, Tue, 20 Jul 2010 17:28:20 -0400

As a professional developer the word "appropriate" is very important. Therefore choose the right tools/techniques for a certain problem.

If the wrong tool is taken sometimes the solution does not work well. Sometimes it is just a waste of development time (bad productivity). Sometimes maintaining is a problem which often leads into quality, stability and productivity problems.

All of these do also apply for Code-Behind / Xaml / Blend.

If people just want to do all in Xaml or all in Code-Behind - both is naive (and for me not professional).

They key is the knowledge about possible tools and there pros and cons - then to find a balance between them.

Knowledge is (as often) the key. Know a lot of tools, techniques, strategies, ideas...

— Stefan, Fri, 23 Jul 2010 15:56:48 -0400

And contrast the premise that "form designers are a professional tool" with programming language design, where meta-programming is considered essential for sophistication, while Sketch-style blocks are considered unworthy of professional attention.

Larry OBrien, Fri, 30 Jul 2010 11:18:59 -0400

To be quite honest, the user interface shouldn't be left to the programmers anyway. Let the UI designers take care of that, and that's why I like Blend so much. We don't want the inmates running the asylum now do we? :)

— dan, Mon, 2 Aug 2010 09:55:02 -0400

It would help if we could eliminate VB, Java, etc. too :)

I learned to program in the early 80's on the x86 architecture, and I loved that machine.

About 6 years ago I was working for a company in Utah, debugging a particularly nasty bug, and I noticed that a key portion of a data structure was being over-written. I discussed the issue with one of the "lead" programmers, showing him a memory window at runtime where the data items were being corrupted. At the same time I had a window open showing the source code data structure. As I was walking him through the corruption, one for one on each data item, the lead programmer asked me how I made that assumption -- the assumption of how data was laid out in memory.

After I explained to him what a compiler or assembler might do with memory management and layout, etc. The lead programmer finally said to me, "I never looked at it like that". To which I replied, "Well, how did you look at it?"

And his response, "I never thought about it."

Jerry Richards, Thu, 12 Aug 2010 18:39:01 -0400

It's long been my opinion that a good background in assembly language would help every programmer. — Charles

The controls on forms issue kind of reminds me of my VB6 corporate programming days in the 90s. The problem with VB at that time was that it was almost impossible to programmatically add a new control to a form, not without there being one of the same type there already, manually added by the visual form designer. Where it was appropriate, we got around it at that time with control arrays, just adding one base control of each type of control we needed, then creating the rest programmatically at runtime, rather than doing it all by hand in the visual form designer. (Then along came corporate intranet developments, where the VB frontend was replaced by browsers and HTML interface code programmatically generated by the web server, possibly using ASP or VB again).

After my corporate days, I then ventured into Direct3D game programming with wait for it VB6 again, and creating visual objects in this way was done programmatically only, there was no visual design tool, which was good.

Fast forward to today, and it looks like most development environments support the idea of creating visual controls programmatically, what with .net, Javascript DOM, etc and this is a good thing.

But the visual design tools are still there. Yes they can encourage bad coding. But if implemented correctly, they could also act as good practice teaching aids if the code they produce and expose is the code you would have written if doing it programmatically.

There is also the issue of visual design tools for visuals which change over time, animations, timelines etc (e.g. Flash designer), which can make the visual design paradigm a more compelling one over doing things programmatically, and can make both approaches very different, sometimes seeming almost worlds apart.

Add to this the issues of team development, workflow, separating presentation from code, allowing designers and programmers to work together, allowing designers to change the visuals after the application is developed, and the issues do get a lot more cloudy and complex!

Abstract Worlds, Wed, 13 Apr 2011 07:27:24 -0400


Recent Entries
< PreviousBrowse the ArchivesNext >
Subscribe to the RSS Feed

(c) Copyright Charles Petzold
www.charlespetzold.com