The team blog of the Expression Blend and Design
We released important news today about the Expression family of products. Please visit the Expression Community site for details.
Hi everyone, If you have watched the BUILD keynotes and sessions, you may have seen some exciting things about Expression Blend’s support for Metro-style applications.
For all future news and updates concerning Expression Blend, please visit our new team blog called BlendInsider. The BlendInsider blog will provide you with the types of content you found here…and hopefully much more!
This blog will be kept around for archival purposes, but no new content will be added.
See you all “on the Inside!”
As you can imagine, shortly after a major release like we had, most of us shift our focus slightly towards talking about and sharing how to use some of the cool new features we released. In this first of a two-part series, I hope to make up for the long period of inactivity on this blog by sharing two Windows Phone focused videos that Unni, Billy, and I recorded for Channel 9.
Overview of Expression Blend for Windows Phone 7 The first video on this list is one that walks you through, at a breakneck speed, most of the new features we added to Expression Blend to help make building Windows Phone 7 apps easier:
Through the guise of building a Bing Search application, I cover features ranging from our Device Panel to Application Bar support to creating Sample Data from a Class file. You can learn more about these features by looking at some of my more in-depth Windows Phone 7-focused articles.
Windows Phone Design Templates Billy and Unni are up next to showcase some of the templates they created to make creating common Windows Phone 7 UI layouts really easy:
The templates they created cover a wide range of common UIs that you will see, so feel free to use these directly in your own projects or simply as a source of inspiration. Before you can do any of that, of course, download the templates from codeplex first.
As always, if you have any questions, feel free to comment below. If you recorded some interesting videos, post them in the comments as well.
Cheers, Kirupa =)
Today, we have released the final version of the Windows Phone Developer Tools. You can download it below:First, download everything you need below:
This installer will automatically install free, phone-flavored versions of Expression Blend, Visual Studio 2010, and XNA Game Studio.
If you already have Expression Blend 4 installed, unlike earlier releases, running this installer will update your existing version of Expression Blend 4 and give you the ability to create Silverlight, WPF, and Windows Phone applications:
Thanks to everyone who has provided feedback over the past number of releases to help us get to this stage. As always, if you have any additional feedback, feel free to post them on the Windows Phone Developer Forums.
- The Expression Blend Team
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.
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.
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.
Cheers, Kirupa =)
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.
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.
Cheers, Kirupa =)
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.
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.
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.
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!
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.
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.