[IxDA Discuss] Expression Blend a "review"

Wed Apr 11 17:33:48 PDT 2007

Some clarifications and answers on some great questions Dave posited in his last post.  (This will be long and transparent so if you're not interested in Blend I'd move on to the next subject. I've edited but not altered comments for clarity.) I suspect some of this may be too arcane for this list and if so Dave and I will go back to the blogs on this stuff).

If you're in a hurry here's the quick summary.

-Blend and Expression Tools are a supplement to tools you already use, not a replacement.

-Blend, Expression and other MS gooblygook are simply mechanisms to execute good designs, they won't solve a lot of the challenges we have as IxD folks or experience designers (but they will give us a new set of options and capabilities to ponder and we move from conceptualization into design).

-They are 1.0 tools that support new technology platforms. We certainly have some areas that need improvement. If you use or dabble with these tools and have things to say we're listening and want to know what you think.

Here's more...

So Dave starts with..."I've been reading your stuff with interest about why Blend is not what I think it is supposed to be and I realized reading your last message where I get stuck. It is this concept:  '...interaction design production tool for an API ...'. Huh?"  Why in the world would there be a difference between an interaction design production tool and an interaction design tool regardless of whether it is open like Dreamweaver (HTML being the open technology) or closed like Flash?"

Dave is asking a few questions here based on two different statements that I made on my blog. (www.designthinkingdigest.com<http://www.designthinkingdigest.com> and his blog at http://synapticburn.com)

Question One
I stated that Blend is a production tool that is designed for creating user interfaces or is...'an interaction design production tool for an API...' In the wonderful of Windows application development this is accomplished by the interaction of a number of components that are predicated on a separation of application logic from presentation.

Application logic is typically created using a tool called Visual Studio with a variety of gooblygook I won't detail here. In fact, Blend uses this very same project system (So projects in Blend look more like what you'd see if you were using something like After Effects or looking at a Web Site in Dreamweaver. What's different about this than using a tool like Photoshop or Illustrator is that the work you do in Blend is not saved in a binary file format. Rather, it's saved it something called a XAML file. XAML stands for eXtensible Application Markup Language and it's basically like an XML file. This file actually describes your interface (but not the application logic).

There are some amazing benefits to this. One benefit is that there is no translation that needs to occur between a design in Photoshop or Illustrator that might need to be 'cut' or optimized. The second benefit is that if you've built a proof of concept using something like Azure or iRise or Flash that you don't need to recreate the look and feel and interactivity (or perhaps discover in production that your target platform doesn't support it). Finally, it allows you to rapidly and iteratively work on the design and application logic in parallel without having to worry about a designer stepping on the code or a developer making a mockery of the design.

But there are also some challenges that you're taking on with this approach too and they require a learning curve to overcome right now that may be uncomfortable for some designers. Because Blend is designed to be a tool for production it's looking for real code to drive that application logic that may make a button do something interested, like populate a data field in another region of an application. In our model you'd create this code using Visual Studio. A more succinct way to put it is that your 'code view' in Blend is Visual Studio. Blend creates a part of the application you're creating (The UI and interactions and controls that can be supported by it's numerous component libraries or via databinding). But it doesn't create the entire application.

Question Two
Dave asks "Why in the world would there be a difference between an interaction design production tool and an interaction design tool regardless of whether it is open like Dreamweaver (HTML being the open technology) or closed like Flash?"

I perhaps should have chosen my words more carefully here and perhaps Dreamweaver is a better analogy than Flash but I think the difference I was trying to illustrate is this. There's a difference between a tool like Dreamweaver versus Blend because of the nature of what they are trying to accomplish. In Dreamweaver you may be able to declaratively create a Web site but eventually you're going to need or want to go into code view to tweak things or perhaps using a dynamic scripting language like JavaScript to add application logic.

Blend's ambition was to be a tool that would let you declaratively create an interface that can be rendered in XAML and plug into application logic controlled by (gooblygook coming) MS technology called .NET 3.0. NET 3.0 is similar to Java in which a virtual machine called a common language runtime (CLR) will execute application logic for the UI engine this is called Windows Presentation Foundation or WPF and other CLR languages like C3, J# and VB.NET.
We've succeeded in creating a tool that lets you declaratively design interfaces and accomplish A LOT without ever having to go to code. But there are some things that we can't do without code and that jump to Visual Studio is required. We still need to expose a user to code in Visual Studio and have users manipulate WPF or C# to do some of the things they might want to accomplish.

In this way I think Blend is more like Dreamweaver or even Flash (if you're using ActionScript). I don't think that down and dirty interaction with WPF will every completely go away. Just like folks that can write HTML and CSS by hand can be very effective in Dreamweaver, perhaps more effective than they can with handcoding I think you'll find the same with Blend. Knowing WPF and XAML even though you'll very rarely touch it is useful and will help you be more productive with Blend, but just like with HTML and CSS there are going to be some designers that aren't going to pick that up. For folks like that Blend, in its current state, will be tough and I think this precludes it from being considered a true prototyping tool by many. To say you can't prototype in Blend is probably not true, to say you can't prototype without touching code or having application logic assets or proxies for them (like XML files to support or simulate a data pull) is true.
A more real way to think about this is like this. I may draw a shape in Illustrator or Photoshop or create an animation in After Effects and I really don't care how it's done. However in Flash or perhaps in a 3D modeling program knowing the technology that is driving what happens in the application is really important. A giant gradient in Flash or in WPF may have performance issues if I don't understand the rendering pipeline for example. A large 3D model with multiple polygons may make a render barf if I overload a scene.  Some technology can shield me from everything. Some technology doesn't even try. We're trying to hit the middle ground here and we've largely (but not totally succeeded for the 1.0 product).

Moving On
Regarding Visio and how we use it (or dislike it). As nice as it would be I don't think Blend solves any of the issues that Dave illustrates in his post. But I don't think we said it would either. That being said I'd love to hear from folks how it could be useful for them if it had certain features. A few that come to my mind are the ability to have some type of application component or page structure (ala InDesign perhaps) and an annotation layer that could live and breathe and follow a project and be turned off and on or have no impact on runtime applications. Could something like this finally give us living and breathing artifacts that actually lived with the application?

Production tools versus design tools
Dave says "But I digress ... my real point here is that good design tool is one that is both in production and out of production. It is a tool that the designer can use to complete a picture and use that tool to create a vision. If it is a "production tool" as you suggest, then it is not a design tool, b/c it seems that the main person who should be using it is a coder, and not the designer."

So I guess my question is this? Is Adobe Photoshop a design tool? I can conceptually figure out a lot with that tool if I'm creating a web site or hashing out how an application can layout. I can do the same with Illustrator. Even with Omingraffle or Visio. I can even chunk up and optimize all my elements in those programs, but I can't really complete the picture can I? Blend is a great tool for being conceptual and getting your design or interface in a format that is REAL and can be rendered as is by an application. You can do all this without ever having to look at code, optimize something or cut it up. Is it REALLY not a design tool to you? I think that's an overly broad statement. I suspect developers will use Blend but I know any designer that is determined to work on a Windows based project would benefit tremendously from using Blend. For our target scenario of building Windows applications a designer will simply be better served by using Blend  that other existing design tools if they want to ensure that their vision is represented in software in the most cost effective, quality focused and efficient way possible.
Dave continues with, "Either, I have to be the UI coder, or I have to hire someone to take on that role. This happens in (D)HTML/AJAX/JSP/ASP, Flash/Director, C++, .NET1.0, etc. Wherever I've worked there has always been this intermediary between myself and the "back end" coding team. What I thought I was hearing from MS was that through XAML (created by Blend) we were finally going to have the ability to remove that go-between. But what I think I'm hearing is that the go-between is not only there, but intentionally? This is where I get stuck on where I'm hearing you are saying where Blend is headed or was intended."
Here is where I agree with Dave. Our goal was to allow designers and developers to work directly with each other.  XAML is supposed to remove that go between and it does, but in a rather specific scenario (in the design and interactivity) right now and we've got room to improve here (in providing more application logic that lets people prototype more robust scenarios). Specifically from a prototyping perspective for those folks that really aren't too keen on bumping around in Visual Studio. Dave's made some very good suggestions to me privately and publically for how we could improve this and if others on this list have insights I'd love to hear them.

I'd like to reiterate folks that are on this list that part of the reason I'm here is to take your thoughts and feedback back to the product teams for these products. Many folks on this list have reached out to me and I'm interested in helping folks be successful with these tools if you choose to use them.

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of David Malouf
Sent: Sunday, April 08, 2007 10:35 PM
To: IxDA Discuss
Subject: Re: [IxDA Discuss] Expression Blend a "review"

Hi Chris,

I've been reading your stuff with interest about why Blend is not what
I think it is supposed to be and I realized reading your last message
where I get stuck. It is this concept: "interaction design production
tool for an API ...".

Huh?

Why in the world would there be a difference between an interaction
design production tool and an interaction design tool regardless of
whether it is open like Dreamweaver (HTML being the open technology)
or closed like Flash?

I also think you are misinterpreting something here or maybe taking
the Visio > Blend beef a bit too far. Personally, if I never opened up
Visio again, it would be too soon. Its not that I hate it as a tool, I
just think it is the wrong tool for my job. It is a drawing tool and
to design interactions you need to be able to design with "time" as a
primary manipulated component of your sketches. Yes, I can can do
click through in Visio, but itis clunky.

But I digress ... my real point here is that good design tool is one
that is both in production and out of production. It is a tool that
the designer can use to complete a picture and use that tool to create
a vision. If it is a "production tool" as you suggest, then it is not
a design tool, b/c it seems that the main person who should be using
it is a coder, and not the designer.

I think in one of your articles or someone else's I read they spoke
about the triad of designer, ui coder, developer as the bridge where
the designer works with the UI coder to create something that is
handed off to the developer. But to me that is where I've been for the
last 10 years. Either, I have to be the UI coder, or I have to hire
someone to take on that role. This happens in (D)HTML/AJAX/JSP/ASP,
Flash/Director, C++, .NET1.0, etc. Wherever I've worked there has
always been this intemediary between myself and the "back end" coding
team. What I thought I was hearing from MS was that through XAML
(created by Blend) we were finally going to have the ability to remove
that go-between. But what I think I'm hearing is that the go-between
is not only there, but an intentionality? This is where I get stuck on
where I'm hearing you are saying where Blend is headed or was
intended.

I don't think there is anything inherent in WPF or WPF/E that should
make Blend any more complex than any other markup + scripting tool. It
has some great features, and an amazing component library and
language, but it is as similar to other methods of development as
Windows is to Mac is to Star. Separate style, structure, and user
interaction from logic. Makes sense to me.

Now, if Blend is not "ready" yet to fulfill the promise, that is cool,
but that doesn't mean that it isn't falling short or the mark in a
market filled with tools that achieve similar comparable goals for the
80% that would be using it.

Now there are things in WPF as a desktop application designer, I think
are totally worth keeping to the old model of design & pray (with a
little more stability so you need a bit less prayer), especailly in
the many types of grid components. 8-)

But I could just draw things in designer and hand them off, or draw
things in Blend. But what I draw in either system is going to have to
be reworked just like the HTML work I've been doing for a decade, once
it gets passed through the 2 levels of interpretation necessary to
make the application stable, scalable, and a good performer.

-- dave

-- dave
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

Chris Bernard
Microsoft
User Experience Evangelist
chris.bernard at microsoft.com<mailto:chris.bernard at microsoft.com>
312.925.4095

Blog: www.designthinkingdigest.com<http://www.designthinkingdigest.com/>
Design: www.microsoft.com/design<http://www.microsoft.com/design>
Tools: www.microsoft.com/expression<http://www.microsoft.com/expression>