We wanted to make sure that everyone using a Zune HD to access MSN, Bing, and many more Windows Live sites, has a fantastic web experience. This involved two teams in Dublin. The first team to start work on this was the Mobile Browse Platform team, MBP for short. MBP maintain a large database of mobile devices. Each device listed in the database comes with a bunch of capabilities which describe the device. These capabilities cover everything from JavaScript support through to touch screen and screen size information. All this raw technical information is needed by other teams to so that they can create fantastic web sites which work as intended on each device.

To collect this raw information the Mobile Browse Platform team worked really closely with the Zune team. The Zune team supplied MBP with raw information they needed. In return MBP studied the Zune browser, right down to the header information the Zune HD browser sends any website. The folks here in Dublin helped the Zune team tailor these headers, all small but important touches which ensure Zune users get a great web experience.
While the MBP team were finalising their Zune HD database entries, the Hotmail team started testing Mobile Hotmail on our Test Zune HD device. The Hotmail team made some small changes to ensure that Mobile Hotmail worked perfectly.
All this hard work ensures that from the moment the first customer uses their Zune HD to connect to Hotmail, MSN, Bing and other Windows Live services that they receive a first class experience.

Now to coincide with the launch of the Zune HD, the MBP team is making the same raw information about the Zune that Hotmail uses available to all ASP.NET developers. You can download this information for free, along with support for hundreds more devices at https://mbdf.codeplex.com.
We would like to congratulate the Zune team on a fantastic product. We are all looking forward to its success!

The rectangles representing the data are defined using a TreeMapItemDefinition (see the XAML below).  In this example, the item definition contains a TextBlock inside a Border.  The item definition specifies which of the node’s values determines the size of the rectangle (via ValueBinding) and which property contains the child nodes (via ItemsSource).

The Treemap contains a list of Interpolators, which can control the background colour (using a SolidColorBrushInterpolator) or properties such as font size (using a DoubleInterpolator).  The interpolator’s TargetName and TargetProperty specify which control and what property is modified by the interpolator and the DataRangeBinding specifies which of the node’s values is used to determine the interpolation point.

So how do we get different colours on the different sub-trees?  Well, we use a number of different item definitions, each with its own interpolator.  An ItemDefinitionSelector is used to select the item definition (and associated interpolator) to be used for each node.  A custom item definition selector, implemented in SegmentItemDefinitionSelector.cs, selects the red, the green or the blue item definition depending on the node’s sub-tree number (which I have called its “segment”).  Note how the border in each item definition has a unique name and each interpolator’s TargetName corresponds to one of the item definitions.

           <datavis:TreeMap ... >

                   <datavis:TreeMap.Interpolators>

                             ...

                             <datavis:SolidColorBrushInterpolator

                                                                 TargetName="Segment1Border"

                                                                 TargetProperty="Background" 

                                                                 DataRangeBinding="{Binding Value2}"

                                                                 From="White" To="DarkRed" />

                             ...

                   </datavis:TreeMap.Interpolators>

                   <datavis:TreeMap.ItemDefinitionSelector>

                             <local:SegmentItemDefinitionSelector>

                                      ...

                                      <datavis:TreeMapItemDefinition ItemsSource="{Binding Children}"

                                                                                                  ValueBinding="{Binding Value}">

                                                <DataTemplate>

                                                         <Border x:Name="Segment1Border" ... >

                                                                         <TextBlock Text="{Binding Name}" ... />

                                                         </Border>

                                                </DataTemplate>

                                      </datavis:TreeMapItemDefinition>

                                      <datavis:TreeMapItemDefinition ItemsSource="{Binding Children}"

                                                                                                  ValueBinding="{Binding Value}">

                                                <DataTemplate>

                                                         <Border x:Name="Segment2Border" ... >

                                                                        <TextBlock Text="{Binding Name}" ... />

                                                         </Border>

                                                </DataTemplate>

                                      </datavis:TreeMapItemDefinition>

                                      ...

                             </local:SegmentItemDefinitionSelector>

                   </datavis:TreeMap.ItemDefinitionSelector>

          </datavis:TreeMap>

Our team is very excited to have had the opportunity to finally release our Treemap.  Hopefully this blog has given enough of an intro to encourage you to download the toolkit and give it a try.  Please let us know what you think.  A special thank you to David Anson and the Silverlight Toolkit team for their help in making this release a reality.

Gareth Bradshaw is a Program Manager on Microsoft’s Global Product Development – Europe team in Dublin, Ireland. He holds a BA(Mod.) in computer science and a PhD in computer graphics from Trinity College Dublin.

In November I wrote about our Silverlight Treemap which visualises hierarchical data as a set of nested rectangles.  Microsoft’s Global Product Development - Europe team has now released this control through the Silverlight Toolkit.  You can read more about this control here.

Marek plans to blog regularly on:

1) Ready to use, generic architectures to address interesting problems, which will include working code.
2) Short posts about certain aspects of Silverlight/C# programming.

In his first post, Marek outlines how to create generic animated panels in Silverlight 2 and 3.

Here’s a short extract from Marek’s first post:

I’ve always had mixed feelings toward animations in cases of generic controls, panels or item controls. From one side it is extremely easy to define standard animations associated with visual states. From the other implementing any more sophisticated animation means that a generic control becomes a user control. In this first article in series I shall present ways we know in our team to make Framework Elements with non-trivial animations without sacrificing theirs genericness. In short - it is easy to create a generic FrameworkElement, but it is hard to create such with advanced animations so it is still generic. In part number one we shall deal with animations in Panels. (Read the full post)

Then we call in the SDETs. SDETs are Microsoft’s answer to the question of how to achieve and maintain quality for our customers when shipping software and services that scale to tens of millions of users. The SDET is tasked with both product quality and team productivity. The SDET uses their development skills to build systems that advocate for the customer in all aspects of a project, from inception through to shipping. SDETs act as a key interface between customers and the engineering team and are the real “last line of defense” before a product goes out the door. The SDET has accountability for ensuring the product is ready to ship or if it needs more time, and he or she is responsible for blowing the whistle if something looks wrong.

As SDETs, we spend most of our time writing code for automation frameworks and testing tools, whether running on a mobile phone, a virtual PC image, or across a data center of thousands of servers. We develop tools that improve productivity and uncover bugs; many of these tools are highly sophisticated and widely utilized both inside and outside of Microsoft. For example, we develop tests that evaluate system security, performance, resilience, functionality, standards compliance, and accessibility, to name a few broad types. Under the banner of productivity, for instance, we have written a tool for improving CSS cohesion and manageability for serving to mobile devices. Of course, we sometimes do need to rely on manual testing to evaluate for things like usability or interoperability corner cases. In those cases, we often rely on the input and assistance from the rest of the engineering team, taking advantage of Microsoft’s quality-conscious culture.

I’m proud to say that at Microsoft, SDETs solve the big problems of ensuring our products work for all of our customers and our development and quality processes are as efficient as possible. So, the next time you consider what it means to “be in test” or “be a tester” and whether that’s a good job for a software developer, think about Microsoft and the SDET role.

Chris Woods, a program manager on our team in Dublin, presented a session on this service at the MIX ’09 conference (click here for Chris’s video presentation), and you can read more and download the file off our CodePlex site here.

This solution was originally developed for Hotmail, Live Search, and other Windows Live and MSN services, and is used extensively within Microsoft. This represents a major opportunity for the .NET developer community.

Sami’s presentation will detail how to write code so that it will be amenable to unit testing. One key point is that by writing testable code, the code also becomes more maintainable and reusable.

Justin’s presentation, on “The Software Quality Discipline at Microsoft,” described how Microsoft’s R&D teams approach software quality, including different roles, processes, tools, and strategies. Click here to download the slides from his talk.

Diego’s paper, “Aspect-Oriented Procedural Content Engineering for Game Design”, discussed how aspect oriented programming techniques can be used to drive the content creation process for 3D scene rendering by mapping each data peculiarity to the code to generate it. Click here for more information on the conference.