ThunderClap, Vol. 11, No.3: A New Way to Learn Silverlight and WPF

Thunderclap, the Newsletter of Rolling Thunder Computing

Volume 11, Number 3, Spring of 2010

In this issue:

Blatant Self Promotion: David Platt's Upcoming Training Classes

Feature Article: A New Way To Learn WPF And Silverlight

It’s well know in the software industry that Microsoft takes three versions to get a product right, Windows itself being the classic example. Visual Studio 2010 and .NET 4 represent the third release of Windows Presentation Foundation (WPF) and its tools, and the third real release of Silverlight as well. Right on schedule, my clients are telling me, “Yeah, now they look about ready, help us learn them, then we’ll try a pilot project.”

The problem is that these new, powerful graphical environments are double-edged, so I had to invent a new way to teach them. It’s no longer sufficient to drill developers on the function calls and then turn them loose on the world. That might have been OK with Windows Forms and Web Forms, but it would constitute malpractice with WPF and Silverlight.

WPF is more powerful than Windows Forms, and Silverlight is more powerful than Web Forms, as a chain saw is more powerful than a hand saw. This increased power can help your user accomplish more useful work than before. However, it also increases the need for great care in employing the powerful tool. You can’t hurt yourself too badly with a hand saw compared to what you can do with a mishandled chain saw. (See, for example, http://www.youtube.com/watch?v=PMseEKzkQho. Warning: graphic.)

Newcomers to these graphical environments are often distracted by the glitz, the perceived glamour and coolness. Dazzled by the fades and animations and color gradients, they forget that the sole purpose of their applications is to make their users happier and more productive. Abetted by graphic designers, they cram as many useless but flashy gizmos as they can into their applications; titillating their own vanity while bending the poor long-suffering user who’s just trying to get his damn work done into a five-dimensional hyperpretzel.

I teach them the fundamental underlying architecture of their graphical environment, so they can quickly look up and implement any particular piece of behavior that they need in the future. It’s not enough to teach students how to do this or that, how to animate an illustration, say, or how to implement a color gradient. That’s necessary, but nowhere near sufficient. It is far more important to understand “what-and-where-and-when to” and “what-and-where-and-when not to,” and most importantly, “why” and “why not”. For example, color gradients are now trivial to program, but what does a color gradient say to a user? Under what circumstances does it make him happier and more productive, and therefore is good, and under what circumstances does it make him less happy and less productive, and therefore is bad? (I once wrote a whole white paper on how the exact same features of WPF can be used both for good and for evil in the same application. You can read it here.)

My class spends spend three days on the fundamentals of the environment itself – its architecture, the use of XAML, tools and resources, common controls, data-binding, and so on. The analogy here is teaching new chain saw owners how to fill the tank with gasoline, hold it properly, and start it without chopping off their fingers.

We then spend two days learning how to make users happy in the graphical environment. We discuss writing user stories so that they are correct and implementable, how to test an application on actual users, and how to instrument it so you know whether you’ve made them happy or not (or more properly, which parts of the UI you got right and which you did not). Continuing the chain saw analogy, we discuss figuring out what your customers really want – lumber, firewood, open space, perhaps the occasional rustic log sculpture – and the chain saw utilization skills needed to produce those results.

Is this approach successful? As Zhou Enlai famously observed about the French Revolution , “It’s too soon to tell.” Certainly the students that have gone through my classes are enthusiastic. They want to do a good job, they want to make their users happy, they don’t want to write software that sucks. They just never before been offered the skill set to do it in an organized way. And I’m a whole lot happier to teach them when motion is good and when it’s bad instead of just telling them how to do it and letting them figure out when to use it and when not to. The true metric will be how much rapidly and how much less expensively you produce software that your users actually like and are willing to buy and to use. I think we're moving in the right direction.

Some managers have told me that they consider it wasteful to have everyone on the project team learn about making users happy, as the UI design is mostly done by just a few team members. The rest are grunts, solely banging out implementation code, and are better off not knowing why or asking silly questions that just take time to answer. I disagree with that, completely and totally and vehemently. Anyone using WPF or Silverlight is by definition touching a human user, and therefore needs to know the fundamental principles of doing it correctly, as a doctor needs to know basic anatomy and physiology. It helps developers fill in the gaps in their assignments that aren’t specified completely, or at all, and it helps them notice and question when part of the design is wrong. Particularly in agile development situations, where user requirements are illustrated with stories (“Customers can pay via credit card”) rather than precise IEEE-830 gobbledygook (“The system shall provide functionality in accordance with the aforementioned inclusion of …”), the knowledge of why we’re doing what we’re doing and not something else, is the difference between success and failure. The WPF class description is at this link, and the Silverlight class is at this link.

And taking this idea one step further, during this class’s lab time, we work on implementing the customer’s actual projects. That’s the Norm Abram approach (“If you start square and level, the rest of the house goes together smoothly.”) that I wrote about in a previous issue of ThunderClap. That’s my response to the recession, and to take the teaching and learning of software to a higher level. Please let me know what you think about it. Together, we’ll make software not suck.

If you love my writing, or if you love to hate it (and if you're a subscriber to this newsletter, one of these is probably true), you would probably enjoy reading my new monthly column in MSDN Magazine. It's entitled "Don't Get Me Started", and it's the last page of the paper magazine (remember them?), just inside the back cover. Think of a cross between Andy Rooney, Dennis Miller, and George Will. Or perhaps its better if you don't.

The editor's note introducing it ("Not Your Father's MSDN") is at http://msdn.microsoft.com/en-us/magazine/ee336018.aspx , the debut issue (February)is at http://msdn.microsoft.com/en-us/magazine/ee309884.aspx , the current issue at http://msdn.microsoft.com/en-us/magazine/ee336120.aspx , and the archives are at http://msdn.microsoft.com/en-us/magazine/ee532402.aspx sdmr=dontgetmestarted&sdmi=columns . It's free, and I guarantee it's worth every penny. Please write to me and tell me what you think of it.

And now, the moment for which I know you've all been waiting -- the pictures of my two girls. Lucy turned 7 years old and in first grade. Annabelle is now 9 1/2 and in third grade. Here is a very rare picture of both girls with Daddy, in a talent show at the girls' school. We sang Joe Scrugg’s classic song “Bahamas Pajamas.” A professional version is at http://www.youtube.com/watch?v=MjMDxz5aAW4 . I assure you that we were far, FAR funnier.

Annabelle reads a book with her snow leopard. How long will she still love stuffed animals? Next year? Year after? Ah God bless them, yours too, all of them.

Thunderclap does not accept advertising; nor do we sell, rent, or give away our subscriber list. We will make every effort to keep the names of subscribers private; however, if served with a court order, we will sing like a whole flock of canaries. If this bothers you, don't subscribe.

Source code and binaries supplied via this newsletter are provided "as-is", with no warranty of functionality, reliability or suitability for any purpose.

This newsletter is Copyright © 2010 by Rolling Thunder Computing, Inc., Ipswich MA. It may be freely redistributed provided that it is redistributed in its entirety, and that absolutely no changes are made in any way, including the removal of these legal notices.

Thunderclap is a registered trademark ® of Rolling Thunder Computing, Inc., Ipswich MA. All other trademarks are owned by their respective companies.