The team blog of the Expression Blend and Design products.
It’s been a while since we released an update for those of you working on Windows Phone 7 projects! Well, wait no more! Today we’ve released an updated version of Expression Blend that supports all of the latest changes made to the Windows Phone 7 runtime along with some cool new features.
First, download everything you need below:
As you can see, you no longer need to download and install Expression Blend separately. You can just run the single Windows Phone Developer Tools installer and get Windows Phone variants of Expression Blend, XNA Game Studio, and Visual Studio for free.
Note This version of Expression Blend installs and runs side-by-side with Expression Blend 4 and only supports working with Windows Phone projects.
New Features As mentioned earlier, beyond supporting the changes made to the runtime since the last release, we’ve added a lot of new functionality that makes designing Windows Phone 7 applications easier. Some of the more notable features are described below.
Improved Design Time Previewing Because your applications can be viewed in different orientations, themes, and accent colors, we’ve made it easier for you to visualize within Expression Blend what your application would look like.
All of this functionality is exposed via the improved Device panel:
The Device Panel now provides you with easy access to preview between Landscape and Portrait orientations, Light and Dark themes, and Accent color.
For example, here is a preview of what your application looks like in the default Dark theme:
Clicking the Light theme button in the Device panel swaps out all of the dark theme resources to display the light theme variants of them:
This allows you to design and make sure that your applications look the way you want regardless of which light/dark mode the user has their phone in.
Preview Text Styles Windows Phone 7 applications emphasize consistent use of text as a key design element. To make it easier for you to preview and apply existing text styles, we’ve added the ability to preview inline what a particular text style would look like:
Initial Application Bar Design Experience One of the unique and differentiating features found in Windows Phone 7 when compared to Silverlight and WPF is the Application Bar:
In this release, we have exposed a very early preview of our support for allowing you to design the Application Bar. You have the ability to create an Application Bar, add Application Bar Buttons, and add Application Bar Menu Items. Because Application Bar Buttons display a 48x48 PNG icon, you can specify your own icon or pick from a collection of icons we have provided for you:
A future blog post will go over in greater detail how to use what you have today to design a working Application Bar!
Easier Page Navigation Because Windows Phone applications are very page centric, we decided to make navigating between pages easy. To navigate from one page to another, we exposed a Navigate To context menu:
This menu can be accessed when you right click on any element that you wish to start the navigation when clicked.
Updated FluidMoveBehavior We have revised the FluidMoveBehavior to be on par with the improvements we made for Silverlight 4 and .NET 4. You can learn more about what this means by reading Kenny Young’s blog post on this topic.
Optimizing the On-screen Keyboard Unlike Silverlight and WPF where a full keyboard for input is almost always guaranteed, Windows Phone users may not have that luxury when working on their phones. While a on-screen keyboard is available, given the size of the screen, having the full keyboard with all of the keys appear on-screen may not be ideal for all situations either. It may be helpful to users if the keys displayed were optimized for the type of information they would be entering at that particular moment.
To address that need, we improved our support for the InputScope property on TextBox that allows you to specify what kind of data will be entered:
For example, if Number was selected for the InputScope on a TextBox, here is what the on-screen keyboard looks like when you focus on it on the emulator/device:
Notice that you are not seeing the traditional full keyboard. Instead, you are seeing a keyboard optimized only for numerical input.
As always, if you have any questions or feedback, please feel free to comment below or post on our forums.
Thanks, Expression Blend Team
A few weeks ago, a couple of Expression Blend team members presented at the TechEd conference held in New Orleans this year!
You can view those sessions given by Unni/Alan and Dave below:
You can browse through all of the sessions by clicking here.
Cheers, Kirupa =)
Creating great looking and functioning applications is tough. It requires having a good eye for design, but it also requires some technical knowledge about how to make the design functional.
As you can probably guess, it is our goal to help you use Expression Blend, Visual Studio, and our related tools to create those great applications. We spend a great deal of time adding new features and making existing features better to help you do just that. Making improvements to the applications is only one side of how we try to help you create great applications, however.
The other side involves helping you better understand how to actually create great applications, and we try our best to provide some valuable training resources. Some notable shoutouts include the .toolbox and the Expression Community sites. While looking at videos or reading tutorials is useful, we wanted to go further and also provide you with a library of xaml+code samples that showcase something small, something specific, something cool. We felt that, in many cases, simply being able to deconstruct how something was done can be equally (if not more useful) in learning how to do something.
This library of xaml+code snippets, known better by its friends and family as the Pattern Library, lives as an extension to the Expression Gallery:
You can learn more about the Pattern Library by reading Lars Power’s newsletter article introducing it.
Please feel free to download and play with the patterns. If there is something you feel is missing, please feel to let us know or just create it yourself and upload it.
Today at Internet Week in NYC, we announced the availability of Expression Studio 4. You can download the trial of Expression Studio 4 Ultimate that includes Expression Blend 4 and SketchFlow by clicking below:
Keep watching this blog for more news, updates, and in-depth looks at some of the new features that we’ve introduced. Until then, here are some related links:
Note that if you are currently doing Windows Phone development, please do not upgrade to the final version of Expression Blend 4 yet. We will release an updated version of all of our phone components in the future, so please continue using Expression Blend 4 RC.
Of course, no major release would be possible without the feedback all of you have provided, so thank you!
- Expression Blend Team
While the PathListBox control provides an easy way to lay out items along a path, creating a carousel control that appears 3 dimensional and has smooth scrolling requires additional functionality that we did not have time to do in Expression Blend 4. I’ve created the PathListBoxUtils sample available on CodePlex to provide the tools that make creating a carousel like the one shown below very easy:
Visit the Carousel tutorial to see how to create this example, and you can view all PathListBoxUtils-related tutorials here on .toolbox.
Happy scrolling!
Joanna
It’s been a while since the last article where I promised to write about all of the behaviors that ship with Expression Blend in greater detail. I’ll try to be more prompt in the future. Today, let’s look at the ControlStoryboardAction and the StoryboardCompletedTrigger.
Storyboards are one of the primary ways you create animations in Silverlight, WPF, and Windows Phone using Expression Blend. Creating a storyboard is fairly easy, but actually using a storyboard such as having it play is not. To help with this, you have the ControlStoryboardAction.
Simply put, the ControlStoryboardAction is an Action that allows you to select a storyboard and specify what you would like to do to it:
Let’s look at some of the properties it contains in greater detail.
When it comes to this behavior, there are only two properties that you need to concern yourself with. They are the ControlStoryboardOption and Storyboard properties.
The ControlStoryboardOption property lists the tasks you would like to perform:
From here you can choose whether you want to play a storyboard, stop it, toggle between play/pause, pause, resume, or jump to the end.
The only missing piece so far is knowing which storyboard to affect. Not to worry, because you specify the storyboard using the aptly named Storyboard property:
This property will list all of the Storyboards your behavior has access to. Once you have selected a Storyboard, you are done!
Another little behavior component we have is the StoryboardCompletedTrigger:
This trigger invokes an Action when a specified storyboard (set via the Storyboard property) has fully run to completion. Of course, because it is a trigger, you can use it with any Action.
In Expression Blend 4, one of the new samples we added is called MockupDemonstration. If you haven’t had a chance to use it yet, you can open MockupDemonstration from the Welcome screen, which is available when you first start Expression Blend or when you click Help and then click Welcome Screen. In the Welcome screen, click Samples, and then click MockupDemonstration:
As you can tell quickly from exploring this sample, this sample contains a handful of controls designed to help you create prototypes easily. The catch is that these controls only exist within the confines of this particular sample. Since some of you have requested that it would be useful to have these controls available outside of the sample, this blog post will explain how to make these mockup controls available in other projects.
To enable mockup controls for any SketchFlow project, copy the mockup controls run-time and design-time assemblies from the MockupDemonstration sample to the pre-configured Libraries folder by following the steps below:
1. Copy both Microsoft.Expression.Prototyping.MockupsSL.dll and Design folder from:
Documents > Expression > Blend 4 > Samples > MockupDemonstration > MockupDemonstration > Libraries > Silverlight > Debug (for WPF projects, follow this step but copy files from … > Libraries > .NETFramework > Debug)
2. Add copied files to the following destination:
Computer > OS (C:) > Program Files(x86) > Microsoft Expression > Blend 4 > Libraries > Silverlight > 4.0 > (for WPF paste the copied files from the NETFramework folder in the previous step to … > Libraries > .NETFramework > 4.0)
3. Restart Blend. You can now start using mockup controls by clicking the Mockups category in the Assets panel (the appropriate assembly reference is automatically added to your project).
If you have any questions or comments, please feel free to post below or on our forums.
Thanks,
Dante, Rick, Billy
At MIX, we released an early preview of our support for building applications for Windows Phone 7 that only ran on a pre-release version of the .NET Framework.
If you have been holding off on upgrading to the latest versions of Expression Blend, Visual Studio, or .NET 4, wait no more! Today, we (along with the Windows Phone team) are releasing an update to the components we released last month to work on the final version of .NET Framework 4.
Download everything you need below:
Windows Phone Development Besides the RC posted above, you will need the following components installed for developing Windows Phone apps:
Besides support for .NET 4, there have been some general improvements to the overall design experience, emulator updates, and breaking API changes. You can get a broader overview on the Windows Phone Developer blog.
As always, we love to hear from you. Please feel free to comment below or use our forums here.
- The Expression Blend Team
As most of you know, last week we released the release candidate version of Expression Blend 4. Shortly after many of you had a chance to play with it, some of you reported that Expression Blend crashes during launch.
If you are one of those people whose Expression Blend crashes after launch, please download this minor revision of the release candidate we released last week:
If you aren’t having any problems launching Blend, you do not have to upgrade. There are no new features or changes besides some changes to make sure Expression Blend runs properly on launch.
Submit Error Reports! We were able to detect this issue thanks largely through the error reports those of you with this crash submitted. We constantly go through all of the crash reports we receive, and we try to fix as many of them as possible.
While we hope you never have to experience crashes from running Expression Blend, if you do experience a crash, please do submit the error reports!
Recently, the final versions of both Silverlight 4 and .NET 4 have been released! To coincide with this, we are releasing a release candidate version of Expression Blend 4 that you can use to target them:
There are two things that you really need to know about this release.
First, if you are doing Windows Phone development, you should not use the Expression Blend 4 RC. We will have an update for you soon with updated components, but in the meantime, please use Expression Blend 4 Beta.
Second, this release of Expression Blend 4 targets the final versions of Silverlight 4 and .NET 4, you can share your creations with the rest of the world. You no longer are limited to only sharing your creations in source code form or for private testing.
If you haven’t had a chance to check out the sessions from MIX10 that showcased Expression Blend 4, the links below should help you out:
Authoring for Windows Phone, Silverlight 4 and WPF 4 with Expression Blend by Christian Schormann and Pete Blois
Dynamic Layout and Transitions for Microsoft Silverlight 4 with Microsoft Expression Blend by Kenny Young
Prototyping Rich Microsoft Silverlight Applications with Expression SketchFlow by Chris Bernard
This post only focuses on the sessions from MIX that are Expression Blend specific. By now, all of the sessions from MIX should be available online, so head over to the MIX Sessions page to view more: http://live.visitmix.com/Sessions
Click here to watch Kenny’s MIX 2010 session that covers a lot of the topics that you see in this post.
- Kirupa
In Expression Blend, we’ve been thinking for a loooong time about how to make it ever easier to create great animated visual effects quickly on top of the Silverlight and WPF runtimes. We’ve been looking at large-scale animation needs since Blend 2 SP1 and steadily building features to address those needs, and we think we’ve reached critical mass. With Blend 4, we have a compelling set of technologies that work very well together.
This blog post is a companion to the “Dynamic Layout and Transitions” demo app that we’ve placed in the Expression Gallery at http://gallery.expression.microsoft.com/en-us/DynamicLayoutTrans. That app shows off the features whose motivations are described here.
Since its inception, Blend has offered keyframed editing of Silverlight and WPF properties via Storyboards. While I won’t go into specific details on that here, it forms the basis for all the features described below. Some of these features work directly from Storyboards you create and others create Storyboards behind the scenes on your behalf – and sometimes both.
Let’s start by turning the clock back two years. In Expression Blend 2 SP1, we introduced the States Panel, which edits VisualStates and VisualStateGroups for Silverlight 2 (and WPF 3.5 with the WPF Toolkit). This introduced the notion of a “state” as a means of communication between visuals and code, and made it dramatically easier to describe a set of visual changes. Based on input, the control code could decide when to enter what state, and the visuals would decide what changes were present in that state plus how long it took to transition between any pair of states (e.g. you might want most state changes to take 0.25s, but want Pressed state changes to be instantaneous).
This proved to be a very effective tool, but it had limitations. The core VisualStateManager runtime (which we’ll call “VSM” from now on) could only do linear interpolations of the values being set. This works great for opacity and transform offsets, but doesn’t work well for discrete properties or data that isn’t known until runtime. Also, not all animation scenarios are driven by state changes. So we put our thinking caps on about how we could get more scenarios to work in a way that designers could rapidly tool the effects.
In V3, we added four primary enhancements in this area. The first was EasingFunctions, which are critical to making property animations have the right feel. We’ve got all the classics – quadratics, cubics, bounce, elastic, etc. Plus, you can write your own EasingFunction in C# or VB and apply it to any animation you wish. This is all supported in Silverlight 3 and WPF 4. EasingFunctions can be applied to an individual animation or keyframe, and you can apply a default EasingFunction to your entire state transition.
The second was a GoToStateBehavior on top of Blend’s Behaviors engine, which made it easy to program all your state change logic directly in the markup without code. Like all of Blend’s Behaviors, you can simply drag it from our Asset Panel onto any elements you choose.
Those two enhancements just made the existing scenarios run better. We also wanted to address new classes of scenario. The first one we tackled was the issue of elements moving in a StackPanel or WrapPanel. Traditionally, these elements have snapped into place as an application changes elements or changes size, and we wanted a smooth transition that users could control. So we introduced the FluidMoveBehavior to make it easy for an element to watch the layout manager for when it moved to a new spot, and smooth out its progress with an animation controlled by one of those EasingFunctions we described earlier. So now it’s easy to have your elements animate into place at a speed you choose!
Here’s a picture of the feature in action. There’s no more room on the first line for the purple rectangle, so it’s moving to the beginning of the second row and the other elements are moving to make space. Technically, from a layout perspective, the elements in motion are actually at their destinations already – but by adding the appropriate transforms on top, we make the change look smooth from the visual perspective that users care about.
The fourth enhancement we made was the most challenging for us. We noticed that many times, customers wanted different states in their control to have different layouts entirely, but still respond to active layout changes in the application. For example, one layout might have a set of task panes visible outside the working area, and another might have one or more of these panes hidden. Customers wanted to describe these different layouts with states to get a good separation between their visuals and their business logic, but the properties that needed to change between these states weren’t properties that could be smoothly interpolated. For example, how do you interpolate between Visibility.Visible and Visibility.Collapsed?
What we learned was that in cases like these, users weren’t satisfied with the direct property animations that our system provided – they just wanted it to “look right”, and making it “look right” required that we animate a morph of the change rather than the change itself. So we wrote an engine that would take a layout snapshot before the state change, take another layout snapshot after the state change, and create a smooth morph between the start and end positions, employing the duration and EasingFunction of the user’s choosing. We dubbed this “FluidLayout”, and you can turn it on here:
Just click that little button, and all your layout changes in that VisualStateGroup will be animated between states even when it seems impossible. We’ll even simulate a Visibility change by means of an opacity simulation. Note that you’ll have more success if you click this before you start making layout changes – otherwise, when you move an object, it’ll create translate/scale animations that don’t respect layout, because that’s the best that the standard VSM can do.
It’s hard to do justice to this feature in a picture, but here’s my best attempt. In this example, the Timeline Pane is in the process of shrinking to the leftmost column, which I configured by changing the Pane’s Grid.ColumnSpan property in a state. Similarly, I changed the RowSpan of the pink rectangle, and it is in the process of growing taller as a result.
In Blend 4, we’ve managed to take these themes even farther, and have three more toys for designers to play with. Let’s start with animating things in and out of lists. In V3, you could apply a FluidMoveBehavior to your ListBox, and the other items would dutifully make room for your new item or close up the space. But there wasn’t any easy way to effectively control the item that was itself being added or removed; if you were clever, you could rig up some events to make an element animate on entry, and you had to be really really clever (and pollute your data model in unfortunate ways) to make an element animate on exit. We worked closely with the Silverlight team to produce a solution here that you can tool effectively, and it’s called LayoutStates. To find them, first edit the ItemContainerStyle:
And then, note these three new VisualStates in the States Panel:
You can use these states to model what an element looks like just before it’s loaded, what it looks like after it’s been loaded, and what it looks like just before it’s unloaded. Silverlight will then animate the state changes for you at the appropriate times, as your items are added to or removed from the list. Remember to add a FluidMoveBehavior to the ItemsPanel template (note its presence in the Edit Additional Templates submenu, a couple of pictures above), and set AppliesTo = Children, to get the other elements to move out of the way. Note that if your ItemsPanel is a VirtualizingStackPanel, your ListBox should have VirtualizingStackPanel.VirtualizationMode set to Standard, or you should learn one of the other new tricks below.
Here’s an example of this in action – the middle item is just entering the list.
The next feature we added is another in the vein of simulation. In V3, we added FluidLayout to VSM in order to get a smooth and realistic morph between two states, but it got us to thinking about the other sorts of morphs we could perform. Enter TransitionEffects. Whereas transition effects in video editing provide a pixel-based transition from one video clip to another, Blend’s TransitionEffects provide a pixel-based transition from one state to another. In Blend, a TransitionEffect is a PixelShader that has an animatable Progress property. We are shipping several of these in our SDK, and if you know HLSL you can write your own. Here’s how you set one up:
As configured here, all state changes in the LayoutStates group will perform a “Smooth Swirl Grid” pixel-based TransitionEffect, taking one second and with a cubic ease. You can of course set a different transition for any individual state change if desired. Some of the TransitionEffects have properties to further customize them; for example, Smooth Swirl Grid lets you control the level of subdivision and the intensity of the twisting effect, but those properties are under the combo dropdown in the picture. Here’s a screenshot of that TransitionEffect in action:
The final feature we added is something that we’ve been trying to wrap our minds around for five years. We’ve noticed that in a lot of applications, visuals will move from one part of the application to another even though the visuals are often generated from data. In a true MVVM design where the data model should know nothing about the visuals, it’s extremely challenging to get these kinds of effects.
What we’ve done is train the visuals to learn more about the data model – specifically, to train FluidMoveBehavior to associate positions with data instead of with visuals. This needs a little bit of explanation, but is remarkably easy to use – you can create an animated list-detail example from scratch in about two minutes.
Here’s a picture of such an app:
What we want is for the large chair in the details view to appear to grow out of the small chair in the master list. All we have to do is locate the Image element in the ItemTemplate for the ListBox, and give it a FluidMoveTagSetBehavior that will register it with the FluidMove system. That looks like this:
Note that the Tag property indicates that element will be tagged according to its DataContext, which is the model item behind the visuals. Next, there’s a FluidMoveBehavior on the detail Image, which looks like this:
The other half of the connection is made with the InitialTag field that is set to DataContext. This means that when the detail element appears, it will consider the registered position of its DataContext to be the place it will appear to come from. And that’s the whole thing! Here’s a screenshot of that app in action; note that in this case I set the FluidMoveBehavior on the entire Grid, so that the details would animate along with the image.
There’s an awful lot happening behind the scenes, but we’ve managed to boil this complex scenario to these two simple properties. This system can even be used to animate objects from one list to another list.
If I had included all of our future investigations in this area, this blog post would be twice as long as it is already. We’re working hard to address more and more scenarios in the simplest ways possible. Rest assured that you’ll be hearing about even more improvements someday in the not too distant future!
If you have any opinions or feedback, please feel free to comment below.
Kenny Young Architect, Expression Blend
As many of you know, today was the first day of MIX - Microsoft’s annual conference for designers and developers. Just like previous years, there has been a lot of great news coming out of the conference.
The two big things we announced are Expression Blend 4 Beta and an add-in to Expression Blend that gives you the ability to build applications for the Windows Phone.
Download everything you need below (*updated for RTM):
Windows Phone Development You will need the following components installed for developing Windows Phone apps:
Christian Schormann has a nice overview of Expression Blend 4 and the new features in it, so if you want to learn more, go read his blog post.
Of course, there will be plenty of posts in the upcoming days and weeks that dive into detail on what we’ve released and announced today, so stay tuned.
Over the next couple of weeks, it seems like a good idea to go over some of the behaviors we shipped as a part of Expression Blend 3. Many of you have mentioned that you would like to learn more about the stock behaviors we ship and how they are used, so this blog will be a good interim solution for that until we properly incorporate your feedback into our future product documentation.
First up on our list is one of my favorite behaviors that we shipped, the GoToStateAction!
What is it? As you know, you have the ability to define and modify your own visual states in your applications:
Having a visual state is only one part of what needs to be done. The other part is actually being able to switch to the visual state at the appropriate time. For predefined visual states that you find in your controls, the mechanism for switching states is built in. For visual states that you create on your own, you will have to provide the logic for switching the visual states yourself.
That is where this behavior comes in. The GoToStateAction allows you to easily switch visual states given an appropriate event using just your Properties Inspector. The following screenshot shows you the standard behaviors UI customized with the properties exposed by GoToStateAction:
Let’s look at some of these properties in greater detail.
Using It Like I mentioned earlier, this behavior primary functionality lies in allowing you to change the visual state. How it does might require some further inspection, so let’s look at the various properties in more detail.
Picking the Visual State The visual state is set via the StateName property. By default, you will see all the states defined in your root scope (ie: UserControl or Window) regardless of where you drag/drop this behavior onto. You can change this by targeting this behavior at another element.
For example, the default target is my UserControl where I have two states defined:
If I were to target another element, such as a Button that contains its own states, the StateName list is populated with those states instead:
I spoke a lot about changing the target that your states come from, so let’s look at the TargetName property where the element you wish to target is actually specified.
Changing the Target If you want to target states that live somewhere else such as another Control or UserControl, you can use the TargetName property to change the element you want to point to. As mentioned earlier, the default value for TargetName is the root scope such as your UserControl or Window.
You can change the default by clicking on the little circular icon in the value editor to visually pick another element from your Artboard or Objects and Timeline panel:
If you are trying to pick something that isn’t easily selectable visually, you can hit the little … button to see a flat listing of all of your elements. That is similar to what you see in the Objects and Timeline panel.
Playing Transitions You can either switch states suddenly, or you can smoothly transition into states. The UseTransitions property is what controls what your behavior will do. By default, the UseTransitions property is checked, but you can uncheck it if you want a sudden switchover to your new state.
Conclusion Hopefully this helped provide you with a summary of the GoToStateAction and how it can be used. If you have any questions, please feel free to comment below.
Cheers! Kirupa :-)
Hi everyone, For a limited time, there is a 30% discount on all Microsoft Expression 3 products (Microsoft Expression Studio + Expression Web, both full and upgrade versions) through the Microsoft Online Store for US-based customers:
No promo code required at all – just go to the store and add to the shopping cart!
Cheers, Kirupa
Ok, pop-quiz time. Below, you will find two screenshots I took from two different applications:
[ Screenshot 1 ]
[ Screenshot 2 ]
Can you tell what is different between those two images? If you said that the button in the second image seems a few pixels off from the image on the top (or something similar), you are wrong. The UI depicted in both of the screenshots is exactly the same. Yes, it was a trick question.
While both applications look almost the same when run, let’s look at both of these applications when opened in Blend. Here is what the application depicted in Screenshot 1 looks like:
The application depicted in Screenshot 2 looks as follows:
As you can tell, there is a major discrepancy between the first and second screenshot when viewed in Blend. More specifically, the second version of the application seems to be missing some UI and the button is not styled at all.
What Happened? The source of the discrepancies have to do with what Blend actually shows on the design surface. By and large, Blend is a XAML editor. Anything defined in XAML, we will do our best to display it on our design surface. For visuals defined in your code-behind files, you may not always be able to see them in Blend.
This is where the differences between the two apps stems from. In the first app, everything was defined in XAML. In the second app, some of the visuals were defined in XAML, but a many of the visuals were not. That is why Blend is only showing an incomplete subset of what your application actually looks like when you view it on the design surface. This is a problem.
Why is this a problem? The word “problem” may be a harsh word for this, but the outcome is less than ideal if your application is a collaborative effort between someone technical and someone less technical. If you are a developer, being able to visualize code and make changes may be straightforward. If you are more design oriented, looking at code to define the look and feel of an application is not natural. You would prefer something that looks like the application depicted in Screenshot 1 where everything is exposed in Blend’s design surface and you can make changes visually without writing code.
Some Solutions The first and obvious answer that I have is to have you resist the temptation to add controls, define layout, or perform other visual tasks using code. The reason is that, as you saw in the screenshot of the second application, Blend’s design surface won’t be able to help you out.
Of course, there are many cases where such an extreme solution will not work. It is common for many applications to fall into a gray area where visuals are partly defined in XAML and partly defined in code. Fortunately, there are some simple steps you can take to make designers more productive while still giving developers the flexibility to develop the application.
Use UserControls If you have visual content that needs to be added programmatically, make sure that content is defined as UserControls. The reason is that you can define the UserControl and make changes entirely within Blend. Programmatically, you can add this UserControl – which may have been edited inside Blend – to your application without sacrificing the designability of the UserControl itself.
Create Styles in XAML, Apply them Programmatically Sometimes, UserControls may be a bit excessive. For example, in the second screenshot, I have a button that is unstyled:
Instead of having a dedicated UserControl to wrap your styled button, you could just define the style in Blend and programmatically apply the style. Let’s say you have a style called GreenButtonStyle defined in your Resources panel:
To apply this style to your button, use the following code:
This allows you to still define the look and feel of your Button using Blend, but its application is handled entirely via code.
Conclusion Hopefully this post helped give you some ideas on how to ensure the visuals of your application have the ability to be modified by Blend. I didn’t enumerate all of the various cases, but if there is something clever that you do to enable developers and designers to work together, please comment below.
Today at PDC, we made a few announcements that would be of interest to you! First, Scott Guthrie announced the availability of the Silverlight 4 Beta. This version of Silverlight contains some cool new features that many of you have asked for, so read the What’s New document to get an overview of some of the new features.
To coincide with the release of Silverlight 4 Beta today and the release of Visual Studio 2010 Beta 2 a short while ago, we are making a version of Expression Blend available that allows you to work with .NET 4 and Silverlight 4 based projects.
Download it from the following location now:
This release of Expression Blend works well alongside Expression Blend 3, so you can continue to work on your WPF 3.5 and Silverlight 3 based projects at the same time.
Hi everyone, When using Expression Blend, a common task you probably engage in is working with layout. Tasks I commonly associate with “working with layout” involve moving things around, rearranging the order of elements, ensuring everything flows when resized, changing your layout container, etc. For the most part, the changes you make to the layout of your application are pretty harmless…except when it involves DataContexts.
In a nutshell, data contexts allow you to specify the data that elements can inherit and work with. Seems pretty harmless so far. Data contexts can be set on pretty much anything, but because the data is inherited, data contexts are often placed on parent elements (such as a layout container) whose children will inherit the data:
What seemed harmless earlier now has the potential to cause trouble. Because data contexts are often placed on a layout container, and because data contexts primarily benefit any children listening in, you need to ensure that any layout changes you make do not cause your data context to break. The common ways your data context can break are:
Today, Blend does not let you know when you perform a layout operation that breaks data context. It is up to you to be vigilant, and you can see which element has a data context set on it by looking at its DataContext property:
If this property isn’t empty, it means that a data context has been set on it. While having a data context set should not imply that data is actually being used, it is a good gauge on whether a layout operation you perform will have any negative side effects on the children involved.
Cheers! Kirupa =)
One of the goals of Silverlight’s Visual State Manager technology is to let you do quite a bit of control customization without needing to use Blend’s Timeline, nor even having to know what a Storyboard is! Feel free to test-drive the Silverlight Button below, and then read on for a run-down of how easily it can be built.
I started out with some vectors (Paths) depicting the face in its normal resting state. Then I used the Tools > Make Into Control command to make the artwork into a template applied to an actual Button. After deleting the ContentPresenter from the template, I selected the MouseOver state in the States pane, so that the changes I was about to make to the existing elements (to produce a face that looks alert and ready) would be recorded only in the MouseOver state. I moved the head and the features upward a little, and the rest of the changes involved using the Direct Selection tool to move Path points around.
Because I wanted the Pressed state to be a variation on the MouseOver state, I used the Tools > Copy State To command to duplicate all my changes into the Pressed State. Then, with the Pressed state selected, I adjusted one eye and the mouth to make the wink.
For the Disabled state I decided I needed new graphics instead of adjusting properties of the existing graphics. So I created a simplified grayscale version of the face and made that version opaque only in the Disabled state.
For transition timing, I created a number of transitions to and from various states and set their durations to taste.
Finally, so that each Button instance can customize some aspect of the template, I used template bindings so that Brush colors used in the template to draw various pieces of the face are bound to properties of the Button instance. So for example I selected shoulders, then selected Fill in the property inspector, and then clicked Advanced property options > Template Binding > Background. So now, by setting a value for Background, Foreground, BorderBrush and OpacityMask, a Button instance with this style set on it can determine the colors of the shoulders, face, hair, eyes and nose.
You can download the sample project files here.
Steve
What are these things – are they different ways of doing the same task? When would I use one in preference to another? Do they all work in all project types?
This post will try to answer those questions by describing the animation and control customization tools that are available to you in Expression Blend 3 + SketchFlow, and discussing what jobs each tool is meant to do. I’ll be classifying project types along two independent axes: WPF or Silverlight, and Blend or SketchFlow.
In the first release of Blend, if you wanted to change the value of a property over time, then the Storyboard was your one option. Using a Storyboard is also known as ‘keyframing’. You create a new Storyboard (or create a BeginStoryboardAction and let that workflow create a Storyboard for you), move the playhead to various times and then use the artboard or the property inspector to change values. Each time you change a value, a keyframe is added to Blend’s Timeline meaning that, at that time, the property has that value. During the interval between keyframes, the property value smoothly takes on intermediate values in a process known as interpolation. By default, the interpolation between two values is linear, meaning the value changes steadily as time passes to form a straight gradient on a graph. And you can control interpolation between keyframes by describing an easing curve. Whether you were changing the Y coordinate of a bouncing ball, or changing the color of a rectangle in a Button template in response to a mouse click, in the first release of Blend you would have used a Storyboard to do it. Something you would have known about, too, is a handoff animation. This is an animation that has no keyframe at time 0 so that, when the Storyboard begins, property values are snapshotted and gradually changed to the value of the earliest keyframe. Handoff animations are important when defining the transition into a control state because you need the animation to be continuous even when it is interrupting an already in-flight transition (say you move the mouse over and then away from a control before the transition into the mouseover state completes).
Storyboards are available in all project types. They’re just as useful today as ever, and they are worth learning how to use, because at some point you’ll probably need to use them. They give you the most control over animation, but control can come at the cost of some effort.
For the task of customizing the look and transitions of a control’s visual states, there’s an alternative and arguably simpler mental model than using a Storyboard to define the transition into a state. The simpler mental model is that you draw the control in each of its states then, if it’s important to you, specify how long any of the transitions take. I say ‘draw’ because that’s morally what you’re doing; strictly speaking you select a state in Blend’s States panel, set properties, select another state, and so on, but you’re drafting a static image of how the control looks in each state. You needn’t be concerned with animation, although it’s interesting to note that the runtime that supports this mental model (that runtime is known as the Visual State Manager, or VSM for short) does generate a handoff animation for each state transition. For practical purposes, drawing states and setting transition durations like this gets the job done much of the time without needing to see Blend’s Timeline at all. But, if you need a steady state animation (say you want the blue focus rectangle to pulse all the time a control is focused), then yes you’ll need to open the Timeline and drop a couple of keyframes and set the animation to repeat indefinitely. Or if you want a shiny reflection to flash across a glass button during the transition from Normal to MouseOver, then again you’ll need to know what a Storyboard is.
Of course you can leverage the Visual State Manager in your own UserControls too. This is because states can apply at the level of the individual control (e.g. in the MouseOver state a Brush is a different color) as well as at the level of a page or scene (e.g. in the ShoppingCartOpen state an otherwise hidden panel is visible). So, you can add states to one of your UserControls that represents a page or scene, set different properties in different states, then use GoToStateActions to drive state changes in response to events.
The Visual State Manager is fully integrated into Blend Silverlight projects and SketchFlow Silverlight projects. You can also use VSM in WPF projects although, while the UserControl experience is the same as for Siverlight, not all WPF custom controls support VSM. I’ve written previously about the States panel and WPF controls.
The last tool I’ll mention is the SketchFlow Animation, and this tool is available in SketchFlow projects only, both WPF and Silverlight. A SketchFlow Animation is logically a ‘storyboard’ in the true sense of the word: a sequence of frames that tells a story. When you’re building a prototype, you don’t want to implement a feature fully in order to demonstrate it. Playing back a scripted example of the interaction you have in mind gets the job done at the prototyping stage. So if you want to show off how you imagine your application will reorganize and animate in response to the user dragging a product into the shopping cart, you could create a new SketchFlow animation and then draw a few frames showing how the product gets dragged between containers and how the layout of those containers responds, and even specify the easing between frames.
For those who like to know how things work under the hood, a SketchFlow Animation is represented internally as a VSM state group. But you don’t need to be familiar with VSM to use a SketchFlow Animation. Nor do you need to be aware of what a Storyboard is, nor be able to use Blend’s Timeline. In a sense, each frame (or state) in a SketchFlow Animation is a keyframe, but at a macro level so that each keyframe defines the entire scene at a point in time rather than the micro keyframes in a Storyboard that define a single property’s value at a point in time.
Now that you have an idea of what these different pieces do, and when they’re available, you’ll be able to pick the most efficient tool for each animation job you want to do.
As you probably know, Silverlight and WPF have a runtime piece called the Visual State Manager (or VSM for short). As I’ll describe in this post, VSM and the Expression Blend tooling support for VSM lend a nice clean mental model to the business of visual states and visual state changes for both custom controls and UserControls.
Although chronologically the story begins with the control author, I’ll talk about that aspect later in this post simply because there are more people in the world concerned with the visual stuff than with the logical stuff. The visual aspect begins in Blend, with a set of already-defined visual states organized into groups in the States panel.
You can identify three stages in the design of visual states and transitions. First, the static stage. Here you make each visual state look the way you want it to, and you do so ideally without any thought of transitions. You select a state in the States panel and you change object properties. And speaking of the States panel, this is probably a good time to introduce the idea of state groups.
Visual states are grouped in such a way that a) the states within a state group are mutually exclusive of one another and b) the states contained in any group are independent of the states contained in any other group. This means that one, and any one, state from every group can be applied at the same time without conflict. An example is a check box where the checked states are independent of, and orthogonal to, the mouse states. Changing an object’s property in more than one state within the same group is common practice. For example, you might change a Rectangle’s Fill to different colors in MouseOver, Pressed and Disabled. This works because only one state from the CommonStates state group is ever applied at a time. But changing an object’s property in more than one state group breaks the independent nature of the state groups and leads to conflicts where more than one state is trying to set the same object’s property at the same time. Blend will display a warning icon (with a tooltip containing details) next to any affected state group whenever this conflict situation is detected.
Each state group should contain a state that represents the default state for that group. CommonStates has ‘Normal’, CheckedStates has ‘Unchecked’, and so on. It is a good (and efficient) practice to set objects’ properties in Base such that no changes have to be made in any ‘default’ state. So, for example, you would hide a check box’s check glyph and focus rectangle in Base and then show them in Checked and Focused respectively.
So now you can click through the states to confirm that each looks correct. You can build and run, and test your states, and you might even stop at this stage if you’re happy that the control switches instantly from one state to another. But if instant state switches are not what you want then you can breathe life into your transitions in stage two, the transitions stage. First, add any transitions you want to see, then set transition durations and easing on them, still in the States panel. And again, in very many cases this will be enough for your scenario. What’s interesting for those designers who can stop at this point is that there was no need to open the Timeline and no need to be bothered with the attendant concepts of what a Storyboard is, etc. To keep unnecessary concepts and UI out of your face, by default Blend keeps the Timeline closed when you select a visual state or edit a transition duration. You can of course open it at any time with the Show Timeline button.
Still in the transitions stage, there may be times when you need a property’s value to change during the transition from StateA to StateB but, because of the way StateA and StateB are defined, the property either doesn’t change or doesn’t pass through the desired value. In this case you need to customize that transition. Select the transition and then use the Timeline as normal to define the animations that should take place during the transition.
The last stage is dynamic states. If, for example, you want a blue rectangle to subtly pulse while a control has focus then you need a steady-state animation. I also call them ‘in-state animations’ because the animation happens while you’re ‘in a state’. To do this, just select the state, open the Timeline, and go ahead and keyframe as usual, possibly also selecting the Storyboard and setting repeat behavior and auto reverse.
Now let’s move onto the topic of how states relate to control authoring. Before a designer can begin deciding what states and transitions look like, the control author must decide what states exist. As a control author, your job is not to think about visual states, but logical states. Forget what it looks like; what does it mean? You need to consider all the ways the end user (and possibly other factors such as invalid data) can interact with the control, and from that thinking build out a set of candidate states; and the states are logical at this point because they have no ‘look’. Now’s the time to think about whether your candidate states need factoring. Look for islands of states: closed graphs that don’t link to other states. There are two kinds: orthogonal and nested. Orthogonal islands should be put in their own state group. An example is that of CheckedStates and FocusedStates. There are no transitions between a CheckedStates state and a FocusedStates state, and a control is either checked or not, and focused or not, and there is no dependency between those two aspects. Islands that should be nested have the characteristics that there are no transitions between a StateGroupA state and a StateGroupB state, and the states in StateGroupB are only effective for one state in StateGroupA. For example if StateGroupA contains LoginPageHidden and LoginPageShown, and StateGroupB contains LoginNormal and LoginError, then it’s clear that StateGroupB is only effective during StateGroupA.LoginPageShown. In this case the two state groups are not orthogonal so you may choose not to use state groups. An alternative, and arguably cleaner, design would be to put StateGroupA at one level of hierarchy with StateGroupB defined on a nested control. Another point to bear in mind, related to naming states, is that each state name must be unique for a control type, even across state groups.
When a control initializes, it first has to get itself onto the state graph. This is important. If a control doesn’t do this then it is still in Base after initialization. Base is not a state; it merely represents the control with its local (or ‘base’) property values set, with no states applied. When the mouse pointer first moves over this control it will go to MouseOver but it will go there from Base, so the Normal -> MouseOver transition will not run the first time. This is a subtle bug that the consumer of your control cannot fix by defining Base -> MouseOver, because Base is not a state. So when you author your own templated control or UserControl, you should define a ‘default’ state in each state group. Have the control go to those ‘default’ states when it initializes, and do so with transitions suppressed so that it happens without delay. Once it’s on the state graph, the control is ready for state transitions to occur so now you can implement the event-handlers that trigger the transitions within the state graph.
I hope this post has been useful and has helped clarify some of the less obvious aspects of designing and authoring controls to work well with the Visual State Manager. If you want to see a walkthrough of some of the ideas presented here, you could try my Button styling video.
Hello!
The Expression Blend team is currently planning features for future versions of Expression Blend. We encourage everyone to take our Blend 3 Survey and send us your feedback. All eligible participants will be able to enter a drawing to win a FREE Zune HD!
As the winner you will be able to customize your own 32GB Zune HD (color and pattern).
The deadline for submitting a survey response is October 5th, 2009 @ 11:59pm. The winner will be announced on October 9th, 2009.
The survey contains various areas, feel free to respond to the areas you feel most relevant to your experience with Blend. We look forward to receiving your feedback and suggestions.
Cheers! Expression Blend Team
We’ve published eleven new articles on the blog and they all contain information and tips that you’ll find useful when styling common Silverlight 3 controls. First there’s an article with some general tips: it discusses template binding, different ways of binding Content in your template, some of the smarts in the Make Into Control command, and some tips on visual states. Then there are ten articles focusing on specific commonly-used controls. For each of these specific articles the article format includes a list of the control’s visual states and parts, an explanation of the function and importance of each part, a graphical comp of a control and its states, a XAML representation of the control in artwork form, and then in-depth steps for turning that artwork into a template for the control. Here are links to the articles. Enjoy!
- Steve
With Blend 3 it’s now possible to draw a marquee (or lasso) around keyframes to select all the keyframes that fall within it. Hold down the CTRL key then drag out a marquee with the mouse pointer as shown below. You can even begin your drag operation when the mouse pointer is over a keyframe or an animation bar; so long as CTRL is pressed, this will not result in selecting and/or moving any keyframe or animation.
If you ever used the time ruler area above the Timeline to move the yellow playhead (current time marker) you’ll be pleased to know that you can now click, or click-and-scrub, in any empty area of the Timeline to set the current time. And if the mouse pointer is over a keyframe or an animation bar then hold down the ALT key and click, or click-and-scrub, and you’ll be able to move the current time without either selecting or moving any keyframe or animation.
You’ll also notice the new blue drag-handles on the animation bars in the illustration above. You can use these to move the start and end times of the animation, and the times of the keyframes within it will be scaled up or down accordingly. This makes it very easy to change the time taken by an entire keyframe animation without having to move all the keyframes around. You can also click and drag on the gray background of the animation bar to shift the whole animation in time.
-Steve
Ok, Jeff Kelly is back with Part IV of his coverage on behaviors-related topics. This one talks about some of the built-in value editors we provide to make it easier for your users to use behaviors that you create - Kirupa
In Expression Blend 3, we’ve provided a number of custom ValueEditors in the property inspector to enhance the usability of our standard Behavior set. As an added bonus, we’ve introduced some limited extensibility to allow third-party controls and behaviors to reuse a few of these.
Specifically, the ElementPicker, the StateNamePicker and the StoryboardPicker can all be reused by placing the CustomPropertyValueEditorAttribute on the property you wish to use the editor. The CustomPropertyValueEditor enum provides the available options:
Note that both the ElementPicker and StateName picker expect to be used on properties of type String, whereas the StoryboardPicker expects to be used on a property of type Storyboard. It’s up to your control or behavior to figure out what to do with the value you get back.
A Note on Design-Time Metadata I’ve covered a number of attributes that are meant to help improve the tooling of your behaviors and controls in Blend 3. It is perfectly valid to place these attributes directly on your class and property definitions; they will work fine. However, doing this raises a general architectural concern: design-time metadata should not be encoded in a run-time DLL. This is a valid concern both from a simple conceptual standpoint, as well as a more practical standpoint, as each attribute adds some overhead in terms of size to your run-time assembly.
While an in-depth discussion is outside the scope of this post, there is a way to segregate your design-time metadata from your run-time classes in the form of a .Design DLL. You can find some introductory information about creating and using design assemblies in Blend 3 on UnniR’s blog here and here.
Conclusion I hope that this blog series has provided a solid overview of the API and mechanics behind the new Behaviors feature in Blend 3. While you hopefully have a good understanding of the fundamentals now, we’ve barely scratched the surface of what can be done with this exciting pattern. I encourage you to check out the Expression Gallery to see what amazing things our community can come up with using Behaviors, as well as to watch this blog and others for more tips and tricks in the weeks and months to come!
Jeff