Expression Blend

Silverlight 2 beta 2 is live!

Laurent Bugnion — Sat, 07 Jun 2008 06:23:40 GMT

Here we go, Silverlight 2 beta 2 can be downloaded and installed! I had the chance to take part to an "insiders" program at Microsoft, and to play with SL2 b2 for a couple of weeks, and it's a good one. You should switch to b2 as soon as you can!

There are obviously incompatibilities between b1 and b2, but much, much less than between the alpha version and b1. We're getting there!!

Silverlight 2 beta 2 will be used to build applications related to the Beijing olympics, so it's going to be a real nature test for that version. As for the final release.... it's still very much hush hush, so let's leave it for now :)

The best place to start is ScottGu's blog. As usual, Scott describes the new features at length, and has links to all the places where you can download the good stuff.

Note that there is also a new version of Blend 2.5 which can be installed next to a "normal" Expression Blend V2. There is supposed to be a new version of Deep Zoom Composer too, but the download seems to be down currently.

Enjoy!!

Microsoft, you're kidding me, right??

Laurent Bugnion — Thu, 05 Jun 2008 17:48:48 GMT

You got to be kidding me. What if I want Expression in the US locale, I can't buy it just because my IP is not in the US? Honestly? You are *that* stupid?

My talk at the "Internet Briefing RIA conference" in Zurich

Laurent Bugnion — Thu, 29 May 2008 21:11:28 GMT

I just posted today's talk at the RIA conference in the World Trade Center, Zurich. Unfortunately it was not recorded, but the slides and the demos' source code is available on my site.

The talk went really good, even though the crowd was rather tough :) Trying to "sell" Windows Presentation Foundation, a desktop Windows-only technology, to an audience of web developers, many of them using Java and open source technologies (and even one Adobe employee) sparkled some very interesting discussions. I can't say I convinced everyone (and it was most certainly not my intention), but I think everybody had a really good time. I know for sure that I did!

To all those who stayed until the end of my presentation, and even though mine was the last presentation of the day, thank you very much!! To those who couldn't stay, I hope you'll have fun checking the slides and the demos, and contact me if anything is unclear!!

De WPF Integratio (About WPF Integration)

Laurent Bugnion — Fri, 11 Apr 2008 20:38:56 GMT

Introduction

I've been posting a lot about Silverlight lately, but hey, here is a WPF post, and about WPF integration, no less.
Note: To fully understand this article, you should have a basic understanding of WPF, styles and templates, triggers, etc...

In my current project at work, I act as WPF Integrator. I am that dude who sits between the designers and the developers, and tries to avoid that they fight too much. Or something. Sometimes it works, sometimes it doesn't, you know how it is with kids. They need their freedom. But I digress.

One important task of a WPF Integrator is (drum roll) WPF integration. For us, this operation usually occurs when we have a design iteration. The way we create application components is (roughly) the following:

The Developer creates the component in Visual Studio. The component is composed of a main assembly (EXE or DLL), containing "functional XAML" and source code (code-behind), and a "Skins" DLL containing XAML resource dictionaries.
(Note: Because we don't want any source code into the "Skins" DLL, and to avoid circular references, we actually have a 3rd assembly called "Converters". As the name shows, this assembly contains the converters (and other helper classes) that are referenced from the Skins DLL).
Together with the WPF Integrator, they create a "raw" UI. That means a basic layout made of "functional XAML", according to the wireframes created by our user experience engineers.
(Note: "functional XAML" is the XAML code that is not strictly doing look&feel. For example, a Button tag is functional XAML, while the style and template it uses are "design XAML").
The WPF Integrator prepares the Skins DLL by exporting all styles to it (using Blend). We follow certain guidelines in naming all the components (styles, templates, DLL names, etc...) and also in the structure of the styles and templates (see below).
The Developers start what they do best, Developing. Meanwhile, the Designer do what they do best (let me hear you:) Designing! This is the Design iteration I was referring to before.
(Note: The Developer *only* works in the main assembly. The Designer *only* works in the Skins assembly.
If the Designer needs to change something in the main assembly, they contact the WPF Integrator to coordinate.
Similarly, if the Developer needs to change something in the Skins DLL, they contact the WPF Integrator to coordinate.
When a set of features are complete, the Developers' and Designers' work is integrated and tested.

Typically, we integrate the design to the application during design workshops, where a couple of Designers and Developers (and the WPF Integrator) sit together and work together, pretty much in an Extreme Programming spirit. These workshops are very intense and interesting, and usually allow fast progress in the application's look&feel.

Conventions, file structure, naming

A control refers to a Style which in turn refers to a Template (this is to facilitate the designers' job in Blend).
A control does *not* set its template directly, but always through a style.
If triggers are needed in the main assembly, the local style refers to a "BasedOn" style located in the Skins DLL.
A Style key is named like the control it refers to, suffixed with "Style". For example "MySpecificButtonStyle" or "ListBoxStyle" (for all ListBoxes), etc...
A Template key is named like the control it refers to, suffixed with "Template". For example "MySpecificButtonTemplate" or "ListBoxTemplate" (for all ListBoxes), etc...
(note: We use the "Template" suffix for ControlTemplate and DataTemplate).
The skin resources for a given control are stored in a resource dictionary file with the "Skin" suffix. For example, the control "MyUserControl"'s resource dictionary is named "MyUserControlSkin.xaml".

These guidelines help the designers to understand which Style and Template belong to which control. Note that Blend makes that task easier by allowing to navigate from the main assembly to the Skins assembly with a succession of clicks.

Typical Designer workflow

The very first task a designer must do when he gets the code is to understand its structure. This is where the conventions mentioned above help. Typically, they work this way:
(Note: You can download a sample application here, open the SLN file in Blend, and then open the main window (Window1.xaml))

Open the application's main window in Blend and check the logical tree.
If a user control is found, right-click on it and choose "Edit control" (fig 1). This opens the User Control XAML file in Blend.
(Of course, this fails if the User Control's source code is not available).
For any control they want to skin, select the control, and then choose the menu "Object / Style" (fig 2 and 3).
At this point, the style chosen can be local (for example if the Developer need to use a Trigger, etc. See listing 1). The Designers are trained to check the name of the file in which they are currently located (in Blend). If the file is named without a "Skin" suffix (for example MyPlugIn.xaml), they may not edit it. In that case, they look for a BasedOn style (fig 4). If they are currently located in a file with a "Skin" suffic (for example "MyPlugInSkin.xaml", then they may edit it (fig 5).
Once in the Style, they can select the context menu "Edit Control Parts (Template) / Edit Template". This opens the Control Template in Blend, where they can rework to look&feel of the control completely (including triggers, animations, etc...)

Figure 1: Edit control

Figure 2: Selecting a control

Figure 3: Edit style

<Button Content="GO"
        Grid.Column="1"
        Click="GoButton_Click">
  <Button.Style>
    <Style TargetType="Button"
           BasedOn="{StaticResource RoundButtonStyle}">
      <Setter Property="IsEnabled"
              Value="True" />
      <Style.Triggers>
        <DataTrigger Binding="{Binding ElementName=DirectoryNameTextBox,
                                       Path=Text}"
                 Value="{x:Static sys:String.Empty}">
          <Setter Property="IsEnabled"
                  Value="False" />
        </DataTrigger>
      </Style.Triggers>
    </Style>
  </Button.Style>
</Button>

Listing 1: Local style using a Trigger, Based On a skin style

Figure 4: Edit "based-on" style

Figure 5: Editing the style in the Skin file

Note: Here we see the advantage of setting the "Template" property in the Style instead of directly in the control: The Designer can see the "shape" of the control already in Blend, without having to rebuild.

Figure 6: Editing the template in the Skin file

The importance of Blend

This workflow would fail miserably without Blend. It can never be repeated often enough: You should keep your application Blendable! (as long as possible). Blend will fail to represent the UI in some circumstances. For example, if your application connects to a COM based component, this is something that Blend cannot handle. Similarly, if your application uses any kind of network service to get data, Blend won't be able to represent this data. This is where the MVVM (Model - View - ViewModel pattern comes handy: By enforcing a data-driven UI, you give the developer the possibility to create "design-time" data, i.e. data which is only used when the application runs in Blend (or in the Visual Studio WPF designer). I could talk about that for hours, and this jumps the scope of this post, but you can read more info about MVVM here:

John Gossman's blog.
Dan Crevier's blog.
Josh Smith's excellent article at CodeProject
Dr WPF's new Software Architecture Pattern: M-V-poo.
My presentation at TechDays 2008 in Basel (slides, source code).
And many more places on the web...

Using WinMerge as an integration tool

During these integration phases, I use WinMerge a lot. The reasons for using this merging tool are multiple:

It is probably the best merging tool currently available for Windows (if someone disagrees, don't hesitate to comment below!!).
Our Designers don't work in our source control infrastructure. They get a copy of the code, refactored as a standalone application. This allows them to test the application easily without having to install a whole networking system (our application is following a Service Oriented Architecture). The aplication they get features a test mode, allowing them to simulate certain conditions (again, see my TechDays talk and the source code for details). Because they work disconnected from the source control, a merging operation is needed.
The merging steps give me a good occasion to review the Designers and Developers work, and to understand it. This is an additional step towards code consistency and code quality (4 eyes review principle).

WinMerge is simply amazing, a must-use tool for a WPF Integrator (at least if you work according to a similar workflow as we do). It is free (amazing, when you see the quality of this tool), was clearly developed by people who needed such a tool and decided to create it (according to the "eat your dog food" idea), and can even be integrated into your favourite source control framework (yes, even ClearCase, which we are forced to use). You can compare folders, binary files, text files with a very clear user interface. All merging operations can be performed using the keyboard only, which is extremely ergonomic. Honestly, I love that tool.

By the way, I didn't mention it yet, but you can also edit both files you are comparing in WinMerge, and save both of them.

WinMerge, merging tool

Conclusion

Much has been written about the Designer-Developer workflow, the WPF Integrator role, the MVVM (or MV*) pattern, etc... In our project, we have the chance to use these principles in a real life situation. I can honestly say, I rarely had so much fun developing software ever. The only thing I can think of that made (almost) as much fun was the big ASP.NET project I worked on prior to this one. The Integrator role is a great place to be.

(Note: I also file this under Silverlight because WinMerge is also very useful for Silverlight integration, even though the Style and Template system is not as rich as in WPF yet).

Silverlight Bug: Transforms and OpacityMask

Laurent Bugnion — Fri, 04 Apr 2008 14:00:11 GMT

Introduction

In WPF, one of the best know effects is the "reflection" effect, where a scene reflects itself dynamically. It's a very cool feature, because it's really easy to realize, and it allows to reflect images, but also videos or other User Interface scenes. The key to this is to use a VisualBrush. Silverlight is not exactly as powerful as WPF, and doesn't have VisualBrush, but it has ImageBrush and VideoBrush, both of them allowing cool media reflection effects (these brushes can also be used for other things!).

The key to making a reflection is placing a picture (or a video), and underneath it, an element (typically a Border). Then, you set the background of this element (Border.Background) to an ImageBrush (or a VideoBrush) pointing to the source that you want to reflect. To make the reflection look more lifelike, however, you want to skew it (because the surface you reflect is forming an angle with the reflecting element); also, you typically use an OpacityMask and make it look as if the reflection was progressively disappearing on a non-perfect surface. Life is not perfect, people, so a perfect reflection doesn't look lifelike.

The issue

However, when creating such an effect, I noticed an issue causing skewed elements with an OpacityMask to disappear completely. The following code shows the problem:

<Grid>
  <Grid.ColumnDefinitions>
    <ColumnDefinition Width="200"/>
    <ColumnDefinition Width="*"/>
  </Grid.ColumnDefinitions>
  <Grid.RowDefinitions>
    <RowDefinition Height="100"/>
    <RowDefinition Height="*"/>
  </Grid.RowDefinitions>
  <Border Background="Red">
    <Border.OpacityMask>
      <LinearGradientBrush EndPoint="0,1" StartPoint="0,0">
        <GradientStop Color="#FFFFFFFF" Offset="0"/>
        <GradientStop Color="#00FFFFFF" Offset="1"/>
      </LinearGradientBrush>
    </Border.OpacityMask>
    <Border.RenderTransform>
      <SkewTransform AngleX="30" AngleY="0"/>
    </Border.RenderTransform>
  </Border>
</Grid>

Skewed Border, OpacityMask, Silverlight

Skewed Border, OpacityMask, WPF

Notes

Here are a couple of notes about this:

I simplified the code as much as possible to display the issue. Obviously this is not a reflection anymore, but I stumbled upon the issue when creating a reflection.
The issue is visible in Blend and also if you run the application.
This issue is not limited to Borders. It also occurs if you replace the Border with a Grid, for example.
The issue also occurs with other Transforms. Replacing the SkewTransform with a RotateTransform will reproduce the issue.
If you don't transform the element, the issue does not occur.
If you remove the OpacityMask, the problem does not occur.
If you give a Width and a Height to the element, the problem does not occur.
The same code in WPF runs correctly.

TechDays 08: Talked about WPF and now back home

Laurent Bugnion — Thu, 20 Mar 2008 22:02:58 GMT

The Swiss edition of the TechDays 2008 is over. It was a great success,many people came, and as far as I can say, people had a good time. I didn't attend any sessions though, because I hung out in the main area instead and met a number of people (some of them I knew from MIX or other occasions), and talked talked talked. Yesterday evening, there was a party, I didn't stay too late though because I wanted to be well rested for my talk this morning.

My talk titled "Siemens goes WPF, Lessons learned" went great. It was in the first slot of the day, starting at 9. Many people came (I didn't count, but the room was 90% full, I'd say). People even laughed at my lame jokes (since no designers came to the session, I was free to joke about them, bwahaha :) Seriously, I regretted that no designers attended, but it's not very surprising. TechDays are rather developer-oriented (something I hope will change in the future, and Microsoft will open up and invite more designers soon).

I had a lot of positive feedback after the session, but if any of you who saw me want to comment more (and I definitely accept negative comments, don't be shy), feel free to use the feedback or to email me.

Thanks to all who attended, and thanks for the nice words!

#Mix08 Session: Nerd + Art: Ten Code Snippets to Empower Your Inner Artist

Laurent Bugnion — Fri, 07 Mar 2008 06:12:53 GMT

Robbie Ingebretsen: "This is a creative experiment" "We didn't always look into best practices"
Talks about the Integrator role.
Nathan Dunlap: "Designers should probably use Visual Studio more" "It's a great tool to dive into the code,check the SDK..."
Snippets are distributed as a Snippet installer VSI file.
- Silverlight code snippets
- WPF code snippets
By the way, check Dr WPF's snippets too!
To access the Nerd snippets in the code, simply type "nerd". Displays the list of all snippets.
Custom Control to display image sequences, provided for free. "ImageSequencer.cs"
- Propery SourceFolder, points tothe folder containing the sequence of images
Snippet "Storyboard" allows to modify values of a storyboard from code.
Snippet "Sound player" provides a lightweight way to play sounds.
Value converters
- Provides a default implementation
Creating a new custom panel
- WrapPanel in Silverlight
DeepZoom snippet for Silverlight, looks pretty cool!
- Provides easy zooming into a DeepZoom prepared image.
Get the Snippets at www.blendables.com

MIX08: Keynote with Steve Ballmer and Guy Kawasaki (1)

Laurent Bugnion — Thu, 06 Mar 2008 08:08:19 GMT

The keynote is transmitted live at http://tinyurl.com/2x63xc

#MIX08 Session: Creating Rich, Dynamic User Interfaces with Silverlight 2

Laurent Bugnion — Thu, 06 Mar 2008 06:16:57 GMT

Karen Corby

NB: Code will be posted on Karen's blog

User control, motivations
- Re-use
- Modularization
- Encapsulation
Same concept as in WPF
No more need for "InitializeFromXaml()", good news. The "XAML hook" is done for us by the framework
KeyDown Event can now be handled on any component level, not just the application level like before
Databinding in Silverlight, how much sweeter can it get. Can't wait to play with it... Wondering how well the MVVM pattern can be used in Silverlight.
Oh yeah, flow layout is probably even sweeter than databinding.
Accessibility of controls
- Keyboard tab, focus, directional navigation
- Screen reader support based on UIAutomation (check Mark Rideout's videos)
Custom Control, motivations
- Separate the visual from the logic
- For default L&F
  - add generic.xaml file
  - set BuildAction to Resource
  - remove CustomTool build action
  - add ResourceDictionary with default L&F for the Custom control.
Styling
- Tweek minor visual characteristics
- Major difference to WPF: Styles can only be written once.
- Other difference: Application level styles not supported ("global styles")
- No "BasedOn" styles for the moment
- No support for triggers in SL 2, maybe later
Skinning
- Replaces the look of the control
- No big difference to WPF
DependencyProperties available in Silverlight (obviously)
Parts model:
- How to structure your controls
- Keep clear separation between logic and visuals
- Explicit contract about how logic and visuals interact
- It's a recommended pattern, but not enforced by the framework
- Will be supported by Blend 2.5
- Element Part
  - For example Scrollbar's UpButton, DownButton, Thumb, Track
- State Part
  - Stroyboard
  - Defines transitions between control's states
  - Control logic defines state machine starting and stopping the storyboards
- TemplatePart attribute for the Control class
- Parts are defined in the ControlTemplate
- Not everything in the ControlTemplate needs to be a Part
- OnApplyTemplate overriden in the control's code behind
- Use GetTemplateChild method to get the various parts inside the ControlTemplate
- Control logic handles the state transition
- This model will transition back to WPF eventually
Directional Navigation
- Uses HitTest API to determine the target control
- Allows using keyboard arrows to navigate between controls (not just using tabs)
DynamicResource not supported in SL2

Silverlight: Downloading the Beta 1 bits

Laurent Bugnion — Thu, 06 Mar 2008 03:49:20 GMT

Silverlight 2 Beta 1 runtime
- Download

Microsoft Silverlight Tools Beta 1 for Visual Studio 2008
(contains the SDK)
- Download

Microsoft Expression Studio 2 Beta
(contains Blend 2, Design 2, Web 2, Media 2 and Encoder 2)
- Download

Microsoft Expression Blend 2.5 March 2008 Preview
(can be installed side by side with Blend 2)
- Download

Microsoft® Silverlight™ 2 Software Development Kit Beta 1 Documentation
- Download

Source Code and Unit Tests for Silverlight 2 Beta 1 Controls
- Download