January 20, 2008

Microsoft Expression, WPF and UI Designers

The latest project I worked on used Microsoft's Expression suite to deliver a working prototype of a Windows application in Windows Prenentation Foundation (WPF). Expression is actually four different programs: Design; Blend; Web and Media. Clearly aimed at taking some of Adobe's market share they enjoy with Flash, Dreamweaver, etc, Expression can deliver Web sites, applications, "Silverlight" (can be thought of as a Flash-like plugin that plays Silverlight files in a Web browser), rich apps and also Windows Presentation Foundation (WPF) apps (Lots of MS Vista was built using WPF I hear). XAML is the main code format that Expression produces. XAML is a language that describes the interface layer, and is similar to Scalable Vector Graphics (SVG) in its appeal (rendering of interface objects as vectors based on code rather than as pixels which don't scale well).

Expression facilitates workflow between disciplines in the development team as it separates the presentation layer from code quite well. Both can be generated simultaneously and there's no longer a need for a developer to translate a designer's vision with lines of code - invariably a vulnerable communication process. Well, that's the promise anyway... but yes, there's a big 'but' here.

Leaving aside the immaturity of the application suite, while relateively slick for a Microsoft product it has got some nasty usability issues. In terms of flow, it runs a distant second to Adobe's products, which have been refined over the last decade and a half or so. Indeed, getting around some basic functions like relabeling layer elements seems like a chore by comparison. Unfortunately, the fact that an interface has been designed over the top of an underlying interaction architecture defined by programmers is fairly typical of the way Microsoft builds software. Credit to the design team who did a reasonably good job at pushing boundaries where they could and put some very pretty lipstick on this little piggy. Not all the applications in the suite are difficult; the 'Design' tool isn't too bad. It's not as powerful as Adobe Illustrator, but pretty similar to it for the most part. But where Microsoft had to invent something that didn't have a good example to follow (e.g. the 'Blend' tool), the resulting software is cumbersome for we UI designers to use.

The 'Design' and 'Blend' tools share some of the same functions, but ask the user to learn slightly different interface paradigms to do them. This contributes to the feeling of "anti-flow" aka 'frustration' that washes over you when trying to do things that could be done simply with Adobe products.

'Blend' when working in WPF is trying to create a very different underlying structure to interface objects than designers are used to thinking about. Grids, Stack Panels, Frames and other 'Containers' are a foreign model when you are used to just placing bunch of elements onto a page so they look right. This takes some getting your head around to say the least. Supporting documentation on when to use what 'Container' and why some 'Containers' are better suited to certain applications is not comprehensive. Add this learning curve to usability issues and frustration turns to exasperation rather quickly. Some may retreat to the familiar, comparitively friendly environment of Adobe Illustrator, exporting XAML from it using a plugin (which doesn't do the cleanest translation job either) and giving that to the programmer to construct the 'Container model'. That kind of defeats the point of Microsoft Expression if we're trying to get designers to put their edits directly into code via 'Blend'.

Perhaps its unfair to compare a product that's just recently come to market with one that's been honed over time and does something fundametally different. But with that said, there are some things that seem patently broken about 'Blend' (known bugs aside).

In my experience, developers hate using WYSIWYG tools because they don't do a very good job at interpreting intentions and create overweight and messy code as a result. In essence, that's what 'Blend' is - a WYSIWYG code editor. Typically, your programmer won't want to use 'Blend' to create the complex, object-oriented control structure inherent with software of any magnitude. They'll most likely want to use Microsoft's Visual Studio instead because it's what they're used to and frankly is does a better job of helping them to code than 'Blend' does. In this case, you will run into terminal problems trying to use 'Blend' to edit design artifacts nested in controls (usually also fed content by a data source). This is of course, unless your developer is aware that you need to use 'Blend' to edit your design elements and structures their code accordingly. How you do that, I don't actually know. But I believe it can be done. If I find a link to something that outlines best practice for this, I'll post it to this blog.

In summary, I've used blend for about 4 months now. Not day-in, day-out, but for weeks at a stretch at least. I still dread opening it and battling through doing simple things. Toward the end of the project I've just finished, we were back to filing design bugs for developers to fix (or not) because we couldn't get at design elements because the project had not been architected 'just so'. So why did we use Expression? Is it just immature? Or is it destined to be difficult for designers to use? Only time will tell.

Posted by Ant at 04:10 AM | Comments (0)