It's been a very interesting couple of weeks...
I attended the local .Net User's Group "Education Day" event covering the Model-View-ViewModel architecture pattern, presented by Microsoft's WPF Program Manager, Karl Shifflet, and Jamie Rodriguez . Karl missed our breakfast meeting, but we arranged to talk on the phone, and he apparently thought enough of my e-mail summarizing some of the issues to forward it to HIS boss. Microsoft dev. evangelist Bruno Terkaly has also forwarded some of my feedback on various topics, and we joked that I'd end up on some kind of internal list of "trouble makers" at Microsoft (I listen for the black helicoptors at night...).
My e-mail included the following: "Looking at forums and sites like StackOverflow.com and listening to questions at the end of presentations, you'll keep hearing confused developers asking "Do I need to learn Blend?" "For data access, are we supposed to use ADO.Net, or DAAB, or Linq to SQL (and is that now deprecated), or Entity Framework (and what about the posted 'vote of no-confidence')...?" "Are we supposed to REJECT the WPF architecture encouraged by VStudio in order to insert some MVPoo mini-framework?" "Should we use MVPoo version A, B, C, or go with Prism?" etc. etc. etc. Microsoft reps seem to treat these as trivial concerns because they are each focused on their own specific area of technology, not considering that a dev. team on an actual project is in the position of having to essentially investigate ALL the available options in order to pick the best approach for EACH area of technology (because their project involves data access, AND remote comms, AND a UI...), and they have to do this in the limited time available before a project is under active development, and they have to train all the members of the dev. team (who are generally NOT MVP caliber developers)."
The gist of our conversation was that Microsoft is aware of many of these issues, and has been discussing them internally. Karl was also surprised to hear that Blend is NOT included in the professional-level MSDN subscription, and said he'd recommend changing that, which would be great.
I attended the first meeting of a local SilverLight User's group, hosted in Microsoft's San Francisco offices. This was the first event I've ever been to, where the number of designers and design-related discussion had any kind of parity with development concerns. Presenters included Scott Stanfield and other representatives from Vertigo, as well as design/devs from the San Franciso offices of the advertising firm, McCann Worldgroup.
I also attended the day-long MSDN Developer's Conference, billed as a "mini-PDC", covering updates to topics and technologies presented last September, and was honored/priviledged to be invited to attend not one, but two social gatherings, where I got to hobnob with Microsoft and local dev. community leaders, bending their ears on dev.-related issues -- especially after the first couple of free pints... I reluctantly passed up a free pass to MIX, since I just can't justify the hotel and other costs at this time (and videos for the sessions will be available online anyway).
For the second time in as many months, I've gotten e-mail from someone who noticed my CodeProject posts, asking if I'd be interested in doing some WPF consulting. This time the request came directly from the CEO of an east coast medical equipment manufacturer, and I've forwarded some WPF resource links that should help their devs get up to speed, and offered to put together a simple demo to illustrate some architecture and design options just for fun -- since many of the requirements don't seem all that different from another CodeProject demo I've been working on anyway.
My social calendar hasn't been this busy since college! Even the ILLUSION of being included in serious dev. discussions has me hooked, as I discovered from monitoring, the "WPF Disciples" discussion thread. You have to filter out alot of empty "banter", but I swear I learn something completely unexpected from that site at least once a week (variations on approaches to M-V-VM, markup extensions as a localization technique etc.), and it really makes you feel like you're sitting directly together with the people who will have the most influence in guiding the direction of the WPF platform.
I've posted several demo projects to dev. community sites, and I'll continue to update this page as more are completed.
"So, each player gets six cards, except for the dealer, uh, the player on the dealer's right, who, uh, gets seven."
"On the right?"
"Yes. The second card is turned up, except on Tuesdays"
"On Tuesday..."
"Mm-hmm. Oh, look what you got - two jacks! You got a half FizzBin already."
"Heh-heh... I need another jack!"
"No, no, if you got another jack, why you'd have, uh, a shralk."
"A shralk?"
"Yes, you'd be disqualified."
"Oh"
"No, what you need now is either a king and a deuce - except at night, of course, when you'd need a queen and a four"
- Star Trek episode #46, where Kirk and Spock explain WPF
I've spent much of the past year working pretty intensively with WPF (and other technologies), working through all the major published references, posting demos to community sites, and occassionally presenting at meetings of the local .Net User's Group. WPF enables you to do some amazing things, and I LOVE it... but I always feel obligated to qualify my recommendations, whenever developers ask me whether I think they should be moving to the new technology.
- Are your developers willing (preferrably, EAGER) to spend the time it takes to learn to use WPF effectively? I never would have thought to say this about MFC, or Windows Forms, or even unmanaged DirectX, but you probably do NOT want a team trying to "pick up" WPF over the course of a normal dev. cycle for a shipping product!
- Do at least one or two of your developers have some design sensibilities, and do individuals with final design authority have a decent understanding of development issues, so you can leverage WPF capabilities to create something which is actually BETTER, instead of just more "colorful", featuring gratuitous animation?
- Does some percentage of your target customer base run on integrated graphics chip sets that might not support the features you were planning -- or are they still running Windows 2000, which would eliminate them as customers altogether? Some people would also ask whether your customers actually CARE about enhanced visuals but, having lived through internal company "Our business customers don't care about colors and pictures" debates in the early '90s, I know that well-designed solutions from your competitors will MAKE them care, and the real question is whether the conditions are right, to enable you to offer something that will make them care NOW.
- Does the project involve grounds-up development, at least for the presentation layer, to avoid the additional complexity of trying to hook into incompatible legacy scaffolding (Interop with Win Forms is NOT seamless)?
- Can your manager accept (or be distracted from noticing) a significant DROP in developer productivity for four to six months?
This last issue is due to what I like to think of as the "FizzBin" nature of WPF, with ten different ways to implement any task, and no apparent reason to prefer one approach to another, and little guidance available to help you make a choice. Not only will the shortcomings of whatever choice you make become clear only much later in the project, but you are virtually guaranteed to have every developer on your project adopting a different approach, resulting in a major maintenance headache. Most frustrating of all are the inconsistencies that constantly trip you up, as you try to learn the framework.
Here are some considerations I'd suggest are important, to avoid making a big mess with WPF...
- Embrace Xaml If you're writing code-behind to define more than the tiniest fraction of your layout, to quote Mae West, "you're not doin' it cor-rectly!" Xaml was invented for a reason. It makes it easy to switch styles, support designer tooling, and often simplifies the implementation to an almost unimaginable degree, but I constantly see developers writing large volumes of code when they should be writing a tiny amount of markup. Here, for example, is something that amazes alot of people; a fully-functional WatermarkTextbox implemented using just 3 lines of Xaml, leveraging the BooleanToVisibilityConverter provided by WPF.
<Grid Background="{StaticResource brushWatermarkBackground}" >
<TextBlock Margin="5,2" Text="Type something..." Foreground="{StaticResource brushForeground}"
Visibility="{Binding ElementName=txtUserEntry, Path=Text.IsEmpty,
Converter={StaticResource BooleanToVisibilityConverter}}" />
<TextBox Name="txtUserEntry" Background="Transparent" BorderBrush="{StaticResource brushBorder}" />
</Grid>
There are some exceptions, especially when it comes to animation and setting DataContext but, in general, layout = markup, and you usually should not need to resort to code-behind just to set control properties.
- REALLY Embrace Xaml! If you're excited that VStudio sp#1 now features an "event" button, and you're waiting for point-and-click support to cover all the essential WPF features you will use regularly on actual projects (DataTemples, for example)... good luck! It only takes a few weeks to become completely comfortable with direct manipulation of Xaml, and this is infinitely faster than searching through property lists, and results in much more succinct, maintainable mark up.
- Rely on DataTemplates This is another area where even some very experienced developers seem to completely miss the point. Just the other day, I watched a presenter's WPF demo include newing of ListItems in code-behind, with object references attached through the "Tag" field. As many WPF authors have emphasized, WPF supports a true "data centric" implementation model, enabling you to do things like simply bind a high-level container directly to a collection of objects, defining a DataTemplate to specify the visual representation an object of that type should take when it appears in the list. Otherwise, you end up using WPF to write Windows Forms code.
- Go Easy With Custom Control Templates Many published WPF resources and online tutorials focus heavily on the ability to replace the appearance of any control, simply by defining an alternative ControlTemplate. Unfortunately, this can lead developers to whip up new templates for things as simple as a request for a ListBox with rounded corners, when they could simply center a ListBox with a Transparent background over a rounded Rectangle. The volume and complexity of markup in many of the standard control templates (along with accompanying color and component definitions), is non-trivial, and trying to maintain edited local copies of more than a few could grow to become a problem.
- Learn Blend - but REFACTOR ITS OUTPUT! Animation and other visual effects can often really only effectively be designed using a tool like Expression Blend. Unfortunately, Blend's simple point-and-click interface encourages generation of massive amounts of convoluted Xaml, which must be refactored early and often if you expect to have any hope of maintaining the source. Members of the developer community, including some inside Microsoft, have discovered benefits in keeping Blend and Visual Studio project activity separate -- even to the point of manually cutting and pasting carefully-refactored versions of Blend-generated Xaml into the "official" project source, rather than allowing designers and developers operate directly on a single shared code base.
MS User Experience Team UK - Lessons learned in teaming devs and designers on actual WPF projects
Billy Hollis demos a very nice UI, discussing design/dev. lessons learned on an actual WPF project
- It Really is REQUIRED Reading I believe that someone else in the developer community has already stated that WPF makes it much easier to generate a more hopeless mess far faster than was ever possible using any previous Windows development technology. In order to make any sense of the pros and cons associated with the array of implementation choices, I recommend that you start by reading Nathan cover-to-cover (things seem to start making sense around the third reading), work your way through Sells, MacDonald, and Anderson, and keep a copy of Petzold on hand as a reference of last resort. As always, even the most definitive resource was out of date on the day it was published, and you must monitor online feeds for the latest information on feature changes, best practice recommendations, and working implementations you can simply borrow.
Update (9/22/08): I laughed out loud when I first came accross the title "Teach Yourself WPF in 24 Hours" in a bookstore recently, but I found this to be an AMAZINGLY good book! It covers all the major areas of WPF succinctly and clearly, using non-trivial examples that are applicable to real-world projects, and even manages to sqeeze in mention of architecture and process issues that are usually ignored. I had some minor quibbles with some of the material, including the decision to use the MVP (Model-View-Presenter) pattern in all of the examples, but its still an excellent book. Don't get me wrong. You absolutely can NOT learn WPF in 24 hours, but you CAN get an excellent introduction to WPF concepts and techniques in the three to four days it will take you to get through this material, and I highly recommend that you start here, even if you've already had some exposure to the framework.
The fact that the Blend tool was used to design the non-trivial UI of Blend itself, is pretty convincing evidence that the first release version is probably already suitable for use on many real-world projects, but there are a few practical concerns that always seem to be glossed over in Blend-related discussions.
How exactly is this new designer-developer coordination supposed to work? An interesting Channel9 interview with members of Microsoft's User Experience Team in the UK details some valuable lessons learned through trying to apply this developer-designer collaboration on actual projects (jump to minute 16:00 to skip intro material). The team discovered that designers needed some level of understanding of Windows development and WPF, in order to avoid problems such as designers creating image elements where they should have restyled control templates, or designers breaking links to underlying business logic by "replacing" controls with restyled versions. The developers also found the auto-generated Xaml provided by the designers to be difficult to read and edit in those inevitable situations where it became necessary or beneficial to do so. The UK team finally settled on the very interesting approach of having the designers generate a "wire frame" DRAWING of the overall UI, which the developers use as a guide in beginning the actual project, while the designers go on to create separate resource library projects, featuring the production quality UI elements that the developers plug into their own carefully-crafted production code. Other development teams have reported success using a single set of shared project files, but its helpful to be aware of a full range of real-world proven alternatives before rushing to apply Blend on your company's next mission critical project.
Realistically, what are the chances that your company will hire professional desigers, or approve funds to hire one of the few consulting firms with experience in this area, like Vertigo? I recently worked at a chemical equipment manufacturer, which contracted with a professional industrial design firm for their complete line of hardware enclosures, while relying on the artistic talents of internal developers using MS Paint for their accompanying software, and a marketing manager at a different company once asked why I couldn't just use clip art throughout the UI for the "commercial quality" digital video capture and editing application they'd hired me to write (using DirectShow, to accompany one of the first generation 1394 Host Bus Adapters). For many organizations, this attitude is likely to continue -- at least until that first trade show where a competitor demonstrates a professionally-designed product that takes full advantage of new WPF graphics capabilities. Even if a company is willing to allocate the funds, there is still the issue of trying to FIND designers who have the combination of skills described in the UK group video. This is not a situation where you can simply retask your company's web developer or marcom person, which still leaves it up to the DEVELOPERS to acquire expertise with Blend, at least in the near term.
On the architecture front, Blend promises to enable designers to "reskin" an application at will, but this separation of UI from business logic occurs at a much higher level than what is currently supported through code-level frameworks such as CAB and SCSF. Whereas these code-level frameworks often attempt to create extra abstraction layers (presenters, controllers, etc.) to decouple UI "views" from the underlying business logic, they still assume that developers will be required to "code" the UI. Microsoft has already announced that CAB/SCSF will be replaced by Acropolis, which will offer some degree of support for Blend (currently, limited to the ability to open "PartViews"), but is not expected to ship "for quite some time".
Finally, Blend is specific to building WPF applications, and WPF is a brand new technology, with a steep learning curve, which will not even enjoy a significant degree of Visual Studio designer support until the release of Visual Studio 2008 at the end of this year. Some corporate managers may feel it is safer to hold off on any commitment to Blend, or designers, or possibly even WPF, until things sort themselves out. I disagree, in cases where a change in technology clearly represents a major advance that will need to be adopted eventually anyway, and I'll have more about THAT attitude in a future post. A beta of Blend 2.0 is already available and, as the tool continues to mature, and the practical issues I've mentioned are resolved, we can expect Blend-based development to become the standard for a significant percentage of Windows dev. projects in the not-too-distant future. I recently decided to check out an online course in Blend at the local junior college, and the text we are using, "Microsoft Expression Blend Bible", seems to be a pretty good introduction to its features
A few hours of playing around with one of the earliest CTP builds of "Sparkle" (now, "Blend") got me very excited at its potential to address some familiar UI design PROCESS issues...
1) Our client's team of marketing product managers had flown in from corporate headquarters for the annual project kickoff meeting. After reminding us that we had to deliver in ten months in order to meet Christmas store deadlines, they proudly announced that it had been decided that EVERYTHING in this year's version of the product would be designed around the concept of a "concierge". If the user wanted some information, they would consult the "concierge". We said, "Fine," would this take the form of some kind of animated assistant, or were they envisioning a special screen that the user would navigate to in the application? Would the feature involve recorded or synthesized speech? Would it have an online component?" We were told that focus groups were already hard at work, considering such questions as "If you were to invite the concierge to dinner, what would he look like?". Four months later, a group of us flew East to participate in formal usability lab studies on the product shell, and I took aside one of the PMs, to try to pin down this still-undefined concept of "concierge". He told me the design consultants were still busy, finalizing the product color scheme, and he was shocked when I told him they could safely delay a decision on the final RGB color values almost to the end of the project (this was MFC, so I simply #defined place-holder color codes in a header file), whereas implementing the "concierge" might require significant effort. Six months later, we shipped a product (to good reviews) whose only reference to "Concierge" consisted of a single modal dialog.
2) In preparation for a major revamp of the company's flagship product UI, myself and several other developers in US and German engineering departments spent several months separately implementing a number of interactive mockups using Windows Forms, while I used PhotoShop to generate over 200 additional static "screen shots" of UI alternatives that would have been too time consuming to code...
3) I've almost always had a major role in defining the UI of the products I've worked on, writing many custom UI elements (in Windows Forms and, previously, with MFC), and working with end users or user proxies (ie: Marketing) to design the overall UI experience. This is one of my favorite parts of the development process, and I've read most of the popular design references (Cooper, Krug, Nielsen, Spolsky, Tufte...), so I've always been surprised at the number of developers with good technical skills who seem to have no affinity for, or interest in, user interface design. In some cases, the developers simply seem unable to envision how complex and unintuitive their proposed application workflow will appear to the target (non-technical) end user. In other cases, it's pretty clear that they consider any amount of attention to aesthetics or design to be completely irrelevant to the task of engineering an application, even to the extent of failing to size and line up controls properly, or to follow basic Windows UI design guidelines.
For those who have been busy with existing projects, and may still be unaware, Microsoft's Expression Blend is a UI layout tool (and much more) for WPF applications, that enables designers to generate the actual production UI for an application themselves, rather than having to settle for the developers' distortion of some carefully-rendered initial design. Because they share the same project file format, developers can load a Blend project in Visual Studio to add business logic to the designer's work, and designers can load a Visual Studio project in Blend to professionally "style" basic control layouts stubbed out by the developers. Blend's capabilities extend far beyond mere layout however. Without leaving the design environment, designers can bind controls to XML data, or to class instances defined in code-behind files, or bind property values between controls. Designers can hook up events, create and trigger animations (defined in WPF as any change in the UI over time, including the appearance and location of controls -- as opposed to the more traditional definition, which was specific to image animation), completely restyle the appearance of system controls, or implement entirely new controls.
Sound a little too good to be true? A little skeptical that your same company management which ships products featuring artwork created by developers using MS Paint will suddenly approve funds to hire "interaction design professionals" -- and just where do you find these strange, half-programmer, half-artist, creatures anyway? More about all that in my next post.
|