Is Expression Blend required when you have VS2010? - wpf

There have been posts on this site in the past that say that programming in WPF is difficult without Expression Blend?
Is this still the case with VS2010, or does this new IDE have features that make WPF a lot easier?

I am a developer, but there is no way I would develop XAML applications of any kind without Expression Blend. The value is far too great and not limited to just pretty graphics. Templates, data binding, resource management, layout, rapid design, visualization, etc. are all vastly superior experiences in Blend.
I really struggle with developer rejection of Blend. Aside from the fact that it isn't free or included with Visual Studio there are no compelling reasons to ignore such a powerful tool. Yes, it is different than Visual Studio, and yes, there is a learning curve, but once you know how to use it Blend is unquestionably the right choice.
I understand developers need help through that learning curve. I also understand that Blend is unlike other tools we have used in the past: believe me, I've been there! That's why I wrote the book "Expression Blend in Action: a developer's guide", to help developers over this hurdle. This isn't meant to be an advertisement so I'm not providing the link, but if you're interested you can find it at Manning.com.

I am not sure why people are comparing the development of WPF apps on Visual Studio and Expression. The Simple answer to this question is when you need to do vector designing for your application, Expression Blend is the resource for it. You can't design a control in WPF as per your requirement. Expression Blend supports the WPF text engine with advanced OpenType typography and ClearType, vector-based 2D widgets, and 3D widgets with hardware acceleration via DirectX.
In essence, it is a user interface design tool developed and sold by Microsoft for creating graphical interfaces for web and desktop applications that blend the features of these two types of applications. It is an interactive, WYSIWYG front-end for designing XAML-based interfaces for Windows Presentation Foundation and Silverlight applications.
Expression Blend supports developing Microsoft Silverlight browser-based Rich Internet Applications providing animation, vector graphics, interactivity and video playback capabilities

It depends what you are using WPF for.
If you are writing a line-of-business CRUD application, then there is no need for expression blend at all.
I've been programming in WPF for years, and was only introduced to Expression blend a month ago.
It definitely makes some things easier, in particular animations or vector graphics.
But, if you've become comfortable typing directly into the XAML editor (as most developers are), then it really isn't necessary to do your job.

The short answer is no, it's not required. But Expression Blend is a great UI design tool that can simplify your UI development. It's a tool, like any other, optimized for doing certain tasks. Developers pick tools based on what they do for us. Think about unit tests. Using a Unit Testing framework saves us a lot of time and effort, as the framework people have optimized their tool for the task.
For me, Blend is my goto tool for these features.
Animations and Timelines
Gradient Editing
Control Templates
Template PARTS
Visual State Manager
Resources and Resource Dictionaries
Styles
Sample Data, with DataBinding
Shape Combining
Paths, Layout Paths
Here is just one example. Setting up an multipart animation in Blend might be a two minute job. Writing the same Animation logic in Visual Studio XAML editor may take 5-10x longer. Plus Blend has an animation preview. In VS I have to compile and run my app to see if the animation works as intended. On big projects that build time eats into my productivity.

It is a bit yes and no, you can do Xaml development without Blend but for somethings Blend is a better solution. Personally I stick with VS2010 unless I know that I'm gonna be doing some custom styling or custom UI in general.

You mentioned programming in WPF so take it that you are not a UI designer. Go with Visual Studio, theres's nothing you cant to in Visual studio that you can do with Expression Blend.

Blend is not required for WPF or Silverlight. However, it makes some things a heck of a lot easier. Specifically:
Animations
Extracting control templates
Styling controls without having to build and run everything
You can do all of these things without Blend, but it's not as easy. For example, you can write a WPF program that extracts the default template for a control and then displays it as text. Or if you use Blend, you can click a button. I find that without Blend, I have to constantly do edit/build/run cycles and that takes time. ("Nope, that color isn't right. What if I just tweak it this way a little bit..." and then I'm off to get a cup of coffee as the whole thing builds and runs just so I can check a color.)
Blend saves me time and makes my life easier -- that's why I use it or any other tool.

Related

Expression Blend for VS2012

I have been developing in WPF using VS2010 for a few months now and have just upgraded to VS2012 Professional and noticed it comes with Blend for VS.
Is this expected to replace GUI design in VS or is it for doing "extra" bits that cant be done in VS?
I want to know if I need to spend time learning this new tool?
Blend is primarily used to make designing your app easier. It can be used to replaced the Visual Studio designer but it's better to use VS to create the backend code. Assuming you have the same project opened in VS and Blend, when you make changes in one, the other will ask to reload these new changes.
Blend makes it a lot easier to write your XAML (since it's a WYSIWYG editor) but also provides easy access to some of the more complicated aspects such as data binding. You could do all this in VS, and by hand, but Blend just makes it more efficient. It also has nicer workflow features from a designer perspective such as having the ability to zoom in and out.
You don't have to learn to use it, but I prefer using Blend for the GUI design and VS for the code-behind.

First dabble in WPF using VS2010 and Expression

I am looking at using WPF for the GUI side of an upcoming project.
I know I have a huge decision to make on WPF vs. Win forms, but before I can make that decision I want to have a play around with a few simple WPF programs.
I have read a few posts online that say Visual Studio (2008 at the time of the post) lacked somewhat in editing the XAML and they recommended using MS Expression?
Questions are:-
I have VS2010, Has this fixed the lacklustre XAML editing present in VS2008?
Which product in Expression studio is used instead to edit the XAML?
Is the idea that you build the code side of the WPF in VS and Build up the XAML in Expression the copy the generated XAML into VS?
Any suggestions/tips on combining Expression and VS2010 would be appreciated.
Kind Regards
Ash
VS2010 has a much better enviroment for supporting XAML compared to VS2008 (in VS2008 it really was not the greatest experience) - so it would be possible to play around with some basic projects straight in VS2010...
Expression Blend really shows it power when you get into animations and transitions etc (Expression Blend to me would be the starting space in the Expression suite once you had covered the basics in VS2010).
The approach I would take is to get basic exposure in a tool/ide you are used to like VS2010, and then go through some of the Blend examples/tutorials that are available off the Expression Website to then take it to the next level.
The things that got me sold on WPF/Silverlight were databinding, separation of concerns using the MVVM pattern and commanding... it just seemed easier than what I was achieving in the winforms arena and cleaner... but it took a while before I was sold on it just because I was used to the winforms way of things and was trying to do WPF but with a Winforms approach.
For basic projects you could build the code and XAML all directly in VS2010. In fact for someone learning XAML for the first time who comes from a code centric perspective, coding XAML directly in VS2010 might be beneficial so that you get used to the basic syntax before you work in a tool like Expression Blend where that can be hidden from the developer.
use VS2010, it has much better intellisense support for XAML (and better support for large solutions >50 projects).
also you dont copy over files between Expression blend and VS2010, both open the same solution work on the same solution (Blend now has support for source contorl as well), you can flip to show the C# in Blend and vice versa in VS2010

XAML editing options

I use Visual Studio 2010 for WPF development of desktop apps. I edit my XAML with the visual editor, often tweaking it manually. My code-behind is C#. I haven't had any particular problems with this arrangement.
What are the advantages of Expression Blend over Visual Studio for editing XAML? Why is Expression Blend so expensive (it's more expensive than I paid for Visual Studio!!) Are there other full-featured XAML editors which are cheaper? (I'm not talking about free ones like kaxaml - those are too limited)
Thanks in advance.
Expression Blend does not come stand alone any longer; it is part of Expression Studio which also provides SketchFlow, Design, and a couple of other tools.
Visual Studio is geared towards the development aspect while Expression Blend is geared towards the design aspect. Building animations and performing binding all within the UI of Expression Blend is possible; not forcing you to modify the XAML by hand. You can however modify the XAML directly within Blend as you can the C# code behind as well.
I typically use Blend to lay out the UI and then make use of Visual Studio for the code behind and tweaking of the XAML. Blend is definitely a nice tool to have within your tool belt and I would recommend you download the trial to get a better understanding on the offering.
I find that the main advantage of Blend is that the UI makes it very, very easy to create complex animations and transitions - really gorgeous user experience things - but you need to spend some time 'learning' Blend to do it. To write the XAML in Visual Studio to create the same effects would be much more difficult - Blend does it much quicker, and you can preview the results instantly. It's not easy (if it's even possible - I've honestly not tried the more demanding stuff) with Visual Studio.

Are WPF more 'flashy-like' than winforms?

I just installed visio, and the installer almost seemed like it was built in flash.
The buttons kinda glowed when I hovered over them, and when I clicked on 'continue' the form phased out in a cool way.
I'm assuming it was built in WPF.
Anyhow, so are WPF more flash-like (visually speaking).
Do they have new properties where you can make forms phase out nicely/smoothly compared to winforms?
Disclaimer: I work for Microsoft. However, I don't work on Visio, WPF, CLR or Silverlight team. So, the following is my personal take on these technologies. If you want to quote me, don't do it implying it's the official Microsoft position. :-))
Update: Anything I say below about Flash/Flex/AIR might be wrong, as I have not worked with these technologies and what I know about them is based on what I read on the intertubes. :-) If you notice anything wrong, just shout in the comment and I'll correct it.
To the best of my knowledge, the Visio installer is not built with WPF. It's all unmanaged code; it's just people took a lot of care to make it really polished.
WPF is the new UI platform for building standalone applications for the Windows OS. It supports a declarative UI language - XAML, and related CLR types to program against. WPF is a different platform than WinForms, although it is possible to build applications that mix UI built with both. WPF supports a lot of things that WinForms does not, like bitmap effects, animations, control styling and so on and exposes them both in XAML or through code. Also, WPF relies heavily on vector graphics, as opposed to the pixel graphics in WinForms. In short, WPF is quite powerfull and allows building very snazzy UI. (Don't take my word for it, though, as I am biased; go check around for what people are saying about it or buiding with it. :-))
WPF and WinForms do not compete with Flash/Flex. WPF and WinForms are both UI frameworks for building standalone client applications. As far as I know, Flash/Flex are frameworks for building rich internet applications - RIA (though lately people started interpreting this abbreviation as rich interactive applications).
Adobe did come up with AIR about half a year (or maybe a year) ago, which allows building standalone client applications, so you could say that Adobe is trying to position Flash/Flex/AIR to compete with WPF. Of course, that's my take on it and I doubt Adobe's official positiong is anything like that.
If you want to compare particular MS technnologies with Flash/Flex, take a look at Silverlight - it's the MS RIA platform.
Silverlight is related to WPF in the sense that they share XAML and the corresponding CLR types. Silverlight supports only a subset of what WPF offers, though, as it is not targeting Windows OS only and thus is limited by the fact that it has to be portable.
Quick update to reflect the changes in the year since I've written the answer :-)
With Silverlight 3 shipped, SL and WPF are getting even closer and sharing bigger set of supported features. In addition, most of the new XAML controls are built for platform at the same time. Thus, SL/WPF are getting to a point of singularity...
Also, SL 3 supports out-of-browser applications. In that sense, SL is not only starting to compete with Flash/Flex, but it is also encroaching on AIR's turf.
And no, I still don't work on the WPF or Silverlight team. :-)
WPF is being used as a replacement for WinForms, and as a competitor to Flash in the form of Silverlight. WPF consists of an entirely new object model that sits on top of DirectX (at least the desktop version). You can create WPF windows, controls, etc, entirely using C# or another .Net language just like you can render WinForms. However, Microsoft has also created a markup language called XAML (eXensible Application Markup Language). Nodes in an XAML document (XML) map to objects in a similar fashion to the way ASP.Net maps to web controls. XAML typically exists in a .Net project alongside a code-behind style C# file (or VB.Net or whatever). The C# file interacts with the objects generated by the XAML. This is fairly consistent with the "graphics via markup, logic via code" model that Microsoft and others are pushing.
One of the overlooked features when discussing WPF is the completely awesome data-binding that Microsoft wrote for WPF. The new data binding framework is a quantum leap beyond Windows Forms 2.0 data-binding. Microsoft added a couple of new interfaces that make it much easier to make an object or collection emit data-biding events properly. They also provided a very rich set of data-binding classes. You can bind anything to just about anything else. You can bind one-way data to control, control to data, two-way control to data and back, control to control, etc.
Back on the graphics side of the house, WPF makes it fairly easy to make an existing control look like anything. WP lets you compose your own template for what a class of buttons should look like, or one button, or all buttons. Or radio buttons. Or labels. You get my drift. Imagine if CSS included the ability to define what an input button would look like using other HTML controls.
They also provide a number of layout controls. You can continue to use exact positioning like in WinForms, or you can leverage of variety of techniques to make your window act more like a web page that grows and shrinks with resizing, etc.
The downsides: It is too easy to create spectacular effects that crawl on slower machines. Some of the graphics do not take advantage of hardware of graphics cards, though Microsoft has incrementally improved support for this. I believe when 3.0 first came out drop shadows were rendered purely using software. I think 3.5 or 3.5 SP1 changed it so that WPF would utilize graphics hardware for the task. Microsoft has said they will continue to enhance WPF in this fashion.
WPF is .Net 3.0 and above, which runs on XP SP2, Vista, and Servers 03 & 08. So don't plan on deploying WPF to a customer with Win2k desktops.
Summary: If you are doing desktop programming in .Net, you should be doing it in WPF unless you are targeting Win2k. You can avoid the downsides of WPF, and there are many upsides. Microsoft will probably throw away WinForms in some future release, or at very least you will stop seeing new features, etc.
As far as Silverlight goes, the betas for SL 2.0 look good. I think that Silverlight will require some wide-spread adoption. Microsoft has already tried to get this going. The NBC Olypmics site used Silverlight, and Major League Baseball uses it for its MLB.tv product. As soon as Silverlight gets a good install base I think you will see the Microsoft side of the development world starting swinging away from Flash and to Silverlight.
Edit after using Silverlight 3 and MVVM:
I have moved away from WPF and am doing a lot of Silverlight 3 development. But I think my comments here will still apply to the WPF developer.
I have been using the MVVM pattern in my app (think MVC with a twist). The Microsoft Patterns and Practices team has released a set of libraries known as Prism that supports various aspects of MVVM. There are WPF and Silverlight versions. Take a look at MVVM and Prism if you are going to be doing WPF or Silverlight development.
You can do a lot of flash w/ Winforms, or with custom components. But if you want out-of-the-box bang-whizz availability, WPF is the way to go.
Yeah, I think the intention is to be flash-like, it seems to me that MS has set its sights on taking down Adobe.
The way I see it: WPF is to Flash as WinForms is to Flex. WPF has more emphasis on vectors and states than on programming.

Is knowing blend required?

Do you expect your WPF developers to know expression blend?
Any good resources for learning more about Blend?
[UPDATE] Does knowing blend make you more productive?
I found Blend a great way to ease into XAML. Many of the common things you want to do are easy in Blend, especially databinding. Databinding has no intellisense and I found doing things in Blend a great way of discovering how do write the databinding syntax.
I now find myself mostly editing raw XAML buy hand.
The areas where blend is really handy:
Customizing templates.
Animation
Breaking the UI down into user controls
As a WPF developer I surely see the benifit of knowing Expression Blend for many of my previous projects. This help me to jump start on creating Usercontrols and Custom controls very effectively. And if we do in the conventional way of writing XAML from the scratch, it is gonna take a very long time of your development.
And also for creating DataTemplate,ControlTemplate,Styles and ItemsPanelTemplate - it is just a click away in Expression blend.
So I highly recommend Expression blend for a WPF programmer
I typically work in both blend and Visual Studio (2005) side by side when doing WPF development. (Although, granted, I typically do both design and c# coding).
The benefits of using Blend is that certain tasks are extremely fast there - things like picking colors/brushes, creating animations and layout fixes such as tweaking margins/paddings.
Another usage is to instantly see how your hand written XAML will look like without actually starting the app.
Blend has a bad habit of producing some weird XAML so I always have to clean it up in the VS text editor afterwards. I still find it to be a net win to use blend though.
So, to answer your question: Is Blend required? no, not really. But it will make your life easier for certain tasks and thus make you more productive.
Things like animation and gradient color definitions can really only be done effectively in Blend. Blend is also often extremely useful for generating some non-trivial custom visual elements, just so that you can view the generated Xaml and import a CLEANER version into your production code. Unfortunately, the point-and-click nature of Blend disguises the fact that huge volumes of very messy Xaml is being generated under the hood, and you'll want to REFACTOR that Xaml before using it in your production source. Fortunately, learning Blend is not that hard. The best tutorial I ever found was called the "Fabrikam" tutorial. There may be updated versions available, but one version of that tutorial is still available at the link below.
http://blogs.msdn.com/expression/articles/516589.aspx
Realistically, very few dev. shops have access to qualified "interactive designers" (its not somethiing a company can just re-task one of its junior Mar-Com people to perform), which means, at most places, developers will need to learn some amount of Blend if marketing wants to add the kind of fancy visuals that provide alot of the justification for using WPF in the first place.
As a developer, after working intensively with WPF for several months, you will find yourself becoming totally comfortable editing Xaml directly and, unlike with Windows Forms, you'll rarely rely on features in the VStudio designer. Not only is direct editing MUCH faster than scrolling through property lists, but VStudio does not have point-and-click support for many of the features you will use in production WPF applications (they just got around to adding an "event" tab in SP#1). Blend has more support for many of these items (it can generate a DataTemplate, for instance), but I usually only jump into Blend to create a quick animation or other visual effect, cut and paste a carefully-refactored version of the markup into my "official" VStudio project source, and move on.
I think at least the designers should start using the Expression Suite.
The developers should be somewhat familiar with the tools but just enough to enable them to communicate better with the designers.
Since there are not so many good WPF tools, knowing Blend is a pretty useful skill. However I wouldn't consider it as requirement. The whole idea of WPF is to distribute work between coders and designers. IMO developer is not required to know Blend throughout, but basic skills are required to understand designer's needs.
Video training for expression blend:
Total Training Expression Blend
http://expression.microsoft.com/en-us/cc136536.aspx
http://windowsclient.net/learn/videos_wpf.aspx
I (as a developer, not designer, soo not designer) tried to start learning WPF through Blend. While I could get stuff working, looking back at what I produced makes me shiver.
Now that I know my way around WPF pretty good, I still use Blend and Design every now and then, but my work is based in XAML (not designer view in VS, mind you, but XAML). In other words,
I know how to clean it up now.
I'm still wondering how I can get my Adobe-Flash, -Photoshop, -Illustrator design guru to work with me in WPF.
It fully depends on what you want to do. To answer your second question, would you really want to try editing an animation storyboard outside of Blend? If you're working with the actual Visuals of the application, Blend is best suited for this. If you want to hack around with databinding, validation and other things where you must swap back and forth with code. Obviously its more sense to work on the XAML in Visual Studio.
Lynda.com has some cool expression blend training available online...
Getting Started with Expression Blend by Lee Brimelow
Developers don't need to know Expression at all.
What you do need to know is XAML and not hide behind some tool, which would be the worst thing you could do as a WPF developer. Your tool of choice is yours to decide on. I used to use the XML editor in Visual Studio.
The only persons who need to know Blend are the ones in charge of the visual aspect of your WPF application. They have to be able to understand how to skin your application with templates, but other than that, they can keep to Blend exclusively.
In general, I think it's more important to for developers to understand XAML, as Blend is just a view on top of it. XAMLPad may be more useful for learning XAML in the first instance.
More specifically to this question though, I think if developers are working alongside designers using Blend, it could be very useful to know at least the basics. As well as allowing better communication (as mentioned by #kokos), it will let the developer perform minor edits (such as alignment etc.) in the same environment, and also understand the limitations and boundaries of the tool with respect to the code generation.
Historically, designer tools have had a few quirks that developers have had to work around, such as re-coding HTML in FrontPage, or generating font tags instead of using styles or classes. I'm sure Blend wouldn't do such things, but it might generate XAML that the developer would prefer to restructure or slim down, so knowing which features generate which styles of code could be very hand for the developer.
Would you require your HTML developers to use DreamWeaver?
All good WPF coders should know XAML by hand and only use tools like Blend for quick mockups, for doing animations or tweening, or for doing complicated gradients, etc.
Coding XAML by hand is a requirement for good WPF developers - Blend is a tool, not a substitute for knowing XAML.
Brennon Williams new book should also be good!!!
(source: pearsoned-ema.com)

Resources