Thanks for Saying Thanks!

A few months back, I received a nice email from the folks at SEP for my blog notes on SEP TeamWorks. It’s nice to know that someone is paying attention:

My name is Adam Scroggin and I am the product owner for SEP TeamWorks.  I came across your blog today (http://www.bryancook.net/) and just wanted to say thanks for the write ups you did.  If there are any features you want added, feel free to contact me.

Keep on writing! Adam

Adam Scroggin | Software Engineering Manager

Appreciate the feedback, Adam. I have a few more blog posts to add regarding using the tool with TFS. I’m sure you’d be happy to learn that teams within my organization continue to adopt the tool for its ease of use.

Unhandled exceptions in WPF applications

When it comes to unit testing there are a few areas of the application where I am comfortable not getting coverage. There are some areas of the application, typically in the UI, that are generally difficult to unit test but can be easily verified if you run the application manually. There are a few other places where testing is very difficult to validate such as the global error handler for your application. For the global error handler, you have to live with some manual testing and assume you’ve got it right.

Today I discovered one of my assumptions about the global error handler was completely wrong. My app was crashing and displaying error messages; I assumed it was crashing, logging to a file and exiting politely. It was not. And as always, I’m writing this as a reminder for you and myself.

As most know, the best place for a global exception handler is to attach an event handler to the DispatcherUnhandledException event of the application. It’s important to set the the Handled property of the UnhandledExceptionEventArgs to true to prevent the app from crashing.

However, this will only capture exceptions on the UI thread. All other exceptions will look for an event handler on that threads’ stack. If no event handler is found it will bubble up to the AppDomain’s handler. So to capture these exceptions you should add an event handler to the AppDomain’s UnhandledException event.

In contrast to the UnhandledExceptionEventArgs, UnahdledException does not have a Handled property. I assumed that the purpose of this handler was so that we could log the error and go on about our business. As it turns out, if your code reaches to this event handler it is completely unrecoverable. As in Bill Paxton, “Game over, man!” – your app is going to crash and show a nasty error dialog. The only way to prevent the dialog is to use Environment.Exit(1);

namespace MyApplication
{
    public class MyApp : Application
    {
        private static ILog Log = log4net.LogManager.GetLogger(typeof(MyApp));

        protected override void OnStartup(StartupEventArgs e)
        {
            base.OnStartup(e);

            // handle all main UI thread related exceptions
            Application.Current.DispatcherUnhandledException += DispatcherUnhandledException;

            // handle all other exceptions in background threads
            AppDomain.CurrentDomain.UnhandledException += AppDomainUnhandledException;
        }

        void DispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
        {
            // prevent unhandled exception from crashing the application.
            e.Handled = true;

            Log.Fatal("An unhandled exception has reached the UI Dispatcher.", e.Exception);

            // shut down the application nicely.
            Application.Shutdown(-1);
        }

        void AppDomainUnhandledException(object sender, UnhandledExceptionEventArgs e)
        {
            var ex = e.ExceptionObject as Exception;

            Log.Fatal("An unhandled exception has reached the AppDomain exception handler. Application will now exit.", ex);

            // This exception cannot be handled and you cannot reliably use Shutdown to gracefully shutdown.
            // The only way to suppress the CLR error dialog is to supply "1" to the exit code.
            Environment.Exit(1);
        }
    }    
}

If you want to gracefully exit the application regardless which thread created the Exception, the recommended approach is to:

• Handle the exception on the background thread.
• Marshal the exception to the UI thread and then re-throw it there.
• Handle the exception in the Application.DispatcherUnhandledException handler.

There’s no easy way out here and means you need to fix the offending code. My recommendation is to use the AppDomain UnhandledException as a honey pot to find issues.

High five.

DeploymentItems in Visual Studio 2012

A frequent concern with writing unit tests with MSTest is how to include additional files and test data for a test run. This process has changed between Visual Studio 2010 and 2012 and it’s become a source of confusion.

Background

With Visual Studio 2010 and earlier, every time you ran your tests Visual Studio would copy all files related to the test to a test run folder and execute them from this location. For local development this feature allows you to compare results between test runs, but the feature is also intended to support deploying the tests to remote machines for execution.

If your tests depend on additional files such as external configuration files or 3rd party dependencies that aren’t directly referenced by the tests, you would need to enable Deployment in your testsettings and then either specifying the deployment items in the testsettings file or marking each test with a DeploymentItemAttribute.

What’s changed in Visual Studio 2012?

Visual Studio 2012 has a number of changes related to the test engine that impact deployment. The most visible change is that Visual Studio 2012 no longer automatically adds the testsettings file to your solution when you add a Test project. The testsettings file can be added to your project manually, but it’s generally recommended that you don’t use it as it’s for backward compatibility and not all features within Visual Studio 2012 are backward compatible. Microsoft Fakes for example are not backward compatible.

The biggest change related to deployment is that Visual Studio 2012 tests run directly out of the output folder by default. This adds a significant speed boost for the tests but it also means that if your tests are dependent on files that are already part of the build output, you won’t need to enable deployment at all.

Another interesting change is that if you include a DeploymentItemAttribute in your tests, Deployment will be automatically enabled and your tests will run out of the deployment folder.

More information can be found here.

.props files and NuGet 2.5

My last post showed a very simple PowerShell script to automate project properties as part of a NuGet package. Shortly after posting, I exchanged a few tweets with some very smart people. The suggestion was that there’s a new feature in NuGet 2.5 that can pull .props and .targets files directly into your project without having to resort to powershell scripting. I had to try this.

So, I created a .props file:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <AssemblyOriginatorKeyFile>mykey.snk</AssemblyOriginatorKeyFile>
        <SignAssembly>true</SignAssembly>
    </PropertyGroup>
</Project>

And put it in a new package:

Then added my shiny new package to a new project.

…And nothing happened.

…At first. I had to unload and reload the project to see the changes.

<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="..\packages\StrongKey2.1.0.0\build\StrongKey2.props" Condition="Exists('..\packages\StrongKey2.1.0.0\build\StrongKey2.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">x86</Platform>

I’m thinking, for my example anyway, that powershell is better suited for this?

Manipulating Projects with NuGet Powershell scripts

I’ve been playing with hosting NuGet packages on our internal NuGet server a fair bit recently and encountered some interesting feedback from a colleague: none of our packages are signed with a strong-name. Gasp! Strong naming is definitely something that falls under the you really should bucket but gets quickly put in the not today simply because it’s a pain. If you’re familiar with the concept, the challenge with strong-naming is that if you give one assembly a strong-name then all dependent assemblies must also have one. This quickly cascades into a lot of repetitive tasks.

The pain of repetitive tasks is something that NuGet handles really well, so why not put my signing-key in a nuget package to automate this process? The concept of this package is extremely straight forward:

1. Add my snk file to the project as content
2. Manipulate the project properties in the install.ps1 script

I’ve really been wanting to write some PowerShell scripts for NuGet packages for a while now, but haven’t had the opportunity. My initial thought was to manipulate the project as an Xml document, but abandoned that approach as some research showed that Visual Studio would prompt the user to reload the project.

After some Googling, I came across a HaaHa (Haack/Hanselman) presentation at MIX11, where Scott’s AddMVC3ToWebForms package had some dirty hacks to manipulate the project. There’s a really good discussion in the NuGet forums that suggests using MSBuild API is a good approach to manipulate the Project properties only if what you want isn’t directly available from the Visual Studio API. 

Fortunately for me, manipulating the properties I wanted was dead easy so my script couldn’t be simpler:

param($installPath, $toolsPath, $package, $project)

$project.Properties.Item("AssemblyOriginatorKeyFile").Value = "mykey.snk";
$project.Properties.Item("SignAssembly").Value = "true";

$project.Save();

Few handy tips I discovered while writing this…

You can get access to the $project variable using the Package Manager Console:

$project = Get-Project

You can list the details of your objects using the get-member cmdlet:

$project | get-member

And you can get a dump of the current values, and list of properties easily:

$project.Properties
$project.Properties | select Name

Well, that’s all for now. Let’s hope this is the start of some awesome PowerShell NuGet badassness for you.

Happy Coding'.

Working with TFS work items in Excel

Visual Studio ships with a pretty good query engine that you can use to retrieve a list of work items, but if you need to change the filter criteria frequently or calculate totals for estimates or remaining work, Visual Studio can’t cut it on its own. Fortunately, the integration between TFS and the Microsoft Office suite is fantastic and we can export our data into Excel with a few simple clicks.

Hey, if you’re reading this because you’re a project manager at my office and I sent you this link, you’ll need a few things on your machine for this to work:

1. Download a copy of Visual Studio Team Explorer.  It’s basically a slimmed down shell of Visual Studio without all the code editing features and it includes all the goodies for you to query work items and export to Excel.  If you have Visual Studio installed, you can skip this step.
   • Visual Studio Team Explorer for Visual Studio 2012
   • Visual Studio Team Explorer for Visual Studio 2010
2. You’ll need read permissions to the TFS Team Project. Reach out to your friendly IT support for this.
3. If you’ve never connected to the TFS server before, you’ll also need the TFS Server name, Team Project Collection name, and Team Project name.

There are two ways to get TFS work items into Excel:

• Import TFS Work Items into Excel
• Export TFS Work Items from Visual Studio or Team Explorer into Excel

Importing TFS Work Items into Excel

Let’s assume that you’ve never connected to TFS before. Managing this from Excel is actually pretty easy.

1. Open Excel and create a blank workbook
2. Select the “Team” option from the Ribbon. If “Team” isn’t available in the Ribbon, you haven’t installed Team Explorer. (see above)
3. Select the “New List”.
   
4. The Connect to Team Foundation Server dialog will appear.
   
5. Click the Servers button. The Add/Remove Team Foundation Server dialog will appear.
   
6. Click the Add button to open the Add Team Foundation Server dialog.
   
7. Fill in the server name and details provided to you by IT. You’ll know you’ve entered the right information when the Preview matches the information provided.
   
8. After all the connection information is provided, select the appropriate Team Project Collection, and the Team Project that you want to use.
   
9. Finally a dialog appears that lets you select an existing TFS query.
   
10. Once you’ve selected, the query, click OK. Voila!
    

Exporting TFS work items to Excel from Visual Studio

Exporting your favorite query from Visual Studio to Excel couldn’t be easier. Simply run the query and then select “Open in Microsoft Office –> Open Query in Microsoft Excel”

Famous Last Words

Here’s a few tips with working with work items Excel:

• At any time you can get the latest by clicking the “Refresh” button
• If you make changes, you can push them back to the server by clicking the “Publish” button. (You’ll need write permissions for this)
• This worksheet is tied directly to the server, so don’t forward the spreadsheet to individuals that don’t have access to the data. For this, copy the entire worksheet to another worksheet.

Using Areas & Iterations in SEP TeamWorks

TFS supports a concept that allows you to organize your work items into different functional areas and chronological iterations, called Areas & Iterations. This post shows you how you can use these features to groom your Work Items using SEP TeamWorks.

Areas & Iterations in TFS

Areas & Iterations can be accessed from the Team Explorer.

Visual Studio 2012

Selecting this item opens a single dialog that allows you to configure both Areas & Iterations. Note that you’ll need to be an administrator for your Team Project in order to make changes.

Areas

The following shows an example of functional areas for a product.

Iterations

The following shows an example of Iterations.

Both Areas & Iterations can be nested so you can structure them any way you want. The system is also flexible if you delete an item you’ll be prompted to select a new value work items that would be impact.

Querying Work Items based on Path

When you query Work Items, you can find all items within the hierarchy.

Using Swim Lanes with SEP TeamWorks

SEP TeamWorks doesn’t have any built in mechanism to filter your TFS queries, but it has a fantastic feature that let’s you group content using swim lines.

Swim Lanes can be turned on any query (except hierarchical queries), simply right-click (long-press on your touch device) to open the context-menu and choose Edit Swim Lanes. You can also access the swim lanes from the Options button in the UI.

You can create Swim Lanes for most fields, assuming that the Work Items in the Query support the fields you’re grouping by:

Here’s the same query with a swim lane enabled for Iteration Path.

Where swim lanes really shine is you can use them to edit your work items without opening them simply by dragging them into another lane.  Here’s some great examples:

• Bug Triage: write a query that pulls back all new bugs then use swim lanes for Severity, Priority, Found In or Triage status. 
• Product Planning: write a query for all User Stories then use swim lanes for Area path, Iteration path, Risk, Story Points
• Grooming the backlog: write a query for all Tasks then use swim lanes for Activity, Area, Assigned To, Remaining Effort

As you can see, with a little bit of planning and some creativity you can customize the tool to fit your needs. In the upcoming posts, I’ll look at common queries and exporting information out of TFS into other formats.

Until then, Happy Coding.

Using User Stories with SEP TeamWorks

When I first started with Kanban over a year ago, the post-it notes on my whiteboard represented Tasks and Bugs, which for the most part worked great. The two main challenges raised by the team, were:

• Developers had a hard time visualizing related tasks, which made it difficult to organize and plan effort. We also had the risk of being unable to deploy because some related tasks were unfinished.
• Project Managers had a hard time reporting progress on high-level features. Although they had access to the Kanban board, organizing a status report from low-level tasks and bugs wasn’t sufficient.

Kanban is intended to be an adaptive process, meaning that it’s not a full-featured methodology and you pretty much have to add your own rules and concepts to it so that you can adapt it to your needs. Other methodologies, like Scrum, have solved my problem by using User Stories to represent high-level features that you can group related tasks under. Developers could see related tasks; project managers could report progress on Stories – win / win. The only remaining challenge was how to represent User Stories on a whiteboard? (How do you associate post-it notes with a Story? Do Stories move on the board like Tasks do? If a few of the tasks for a Story are “ready for test” does the status of the Story change?)

I struggled with this challenge until I switched over to a digital Kanban board which afforded us the ability to produce different queries over the same data. We’re using TFS 2010 as a repository and SEP TeamWorks as a front-end to visualize task effort.

Querying and Displaying User Stories

The Agile Process Template used by TFS 2010 includes a User Story work item type which you can link tasks to in a Parent-Child relationship. You can write a simple query to obtain all parent-children tasks. 

Note that the TFS query that I’m using is a Work Items with Direct Links query, which allows me to pull back Children tasks as well as Related bugs. I also don’t nest my User Stories – this technically works within TeamWorks, but it seems a little odd and needs some further investigation.

SEP TeamWorks supports hierarchical tasks out of the box. Stories and their children are represented as swim lanes, with the first column representing the Story.  Note that because Stories are broken into swim lanes, you can’t use TeamWork’s swim lane feature to further refine the query. If this is something you want, you’ll have to set up different TFS queries.

Adjusting Kanban Workflows

While the workflow that I’m using for Tasks and Bugs would work for User Stories, it seems a little heavy to duplicate the process for Stories. I simplified the flow to make it easier to manage and for reporting status.

The flow for my Tasks and Bugs, which I’ve outlined in my previous posts, is:

• Proposed
• Active
• Selected
• In Development
• Ready for Test
• Testing
• Acceptance
• Closed.

For my User Stories, I’ve simplified it to:

• Proposed: the story does not have all the details, yet.
• Active: the story is well defined and is actionable.
• In Development: the story is being developed or validated by developers
• Testing: development has completed and the testers are running their test cases
• Acceptance: test cases are complete and its ready for client review
• Closed: the feature has been accepted / shipped / etc.

Note that SEP TeamWorks uses the Status column from all Work Items into its UI so I’ve repurposed my existing status definitions to simplify things.

Daily Operations

As mentioned previously, having our Kanban board as software solution allows us to query and represent the data in different ways. I use a combination of three different queries for my daily operations:

• Product Planning: I query only User Stories which allows me to see the high-level status of the project at a glance. I heavily use Areas & Iterations (I’ll blog about this next) to help organize and plan the project.
• Iteration Backlog: I use a hierarchical query as shown above to represent the current iteration.  This query allows me to see the detailed status of the Story
• All Work Items: This query returns all Tasks and Bugs and it resembles the Kanban board I’ve fallen in love with. This query allows me to see bottlenecks, developer allocations, etc.

Conclusion

Having User Stories has made a big difference for how we track and organize our effort, but it’s not without its challenges. There’s a special knack to writing stories and it takes some practices to get used to the format, which I’ll have to blog about later. For now, I hope that this post shows you how easily it is to introduce Stories into your Kanban flow.

Until next time, happy coding.

New updates for SEP TeamWorks

For the last 8 months, I’ve been using SEP TeamWorks as a front-end for my all digital, TFS-backed Kanban board. The experiment has been relatively successful, and I’m constantly revamping my model to make it fit for our style of projects. The real success of using Kanban with this tool has to be its adoption to other projects within the organization. While my hand-waving evangelism has played a part, this expansion is largely due to the position of my desk: I’ve been sitting directly between the Project Management group and the developers and see a fair amount of foot traffic every day. Every developer, project manager, designer and executive has walked by my multiple-monitor, touch screen environment and eventually, like bees to honey, they ask, “what the hell is that??”

While I’m very pleased to see Kanban adoption within our organization, I’m also very glad to see that SEP is using an iterative release cycle for their TeamWorks product. Late last year they added an auto-update feature and now surprise updates makes it feel like it’s Christmas all year long.

Here are two of my favorite new features from the latest release:

Revamped “Add new” menu

There are two ways you can add new work items inside TeamWorks.  The first way is through a main menu at the top of the screen; the second is a context-menu that you can bring up on an existing work item. This context-menu option has been completely reworked.

The new version opens a dialog window that let’s you specify the WorkItem Type (Bug, Task, etc) and relationship (Parent, Child, Related, etc) to the current item.

This dialog is very similar to how it appears within Visual Studio, which means I can do more from the touch screen. The other clear advantage to using the context-menu is that the newly created work item inherits the iteration and area of the linked item.

Card Editor

This release has a brand new feature that allows you to edit the appearance of your Kanban cards. This is a very simple but very welcome addition to the tool.  The tool allows you to customize the fields and layout for each type of card, and you’re able to reuse your layouts from other queries or projects.

Here’s an example of a Task that I’ve customized by placing the Remaining Work field in the bottom right hand-corner, horizontally right-aligned.

Here’s a few customizations that I’ve used on my most recent project:

• User Stories: add the Story points to the bottom of the card
• Tasks: Original Estimate, Completed Work, Remaining Work
• Bugs: Priority and Severity

Well, that’s all for now. I’ve got Inglorious Basterds queued up on my DVR and a nice cool drink waiting for me.

Happy Coding.

Turtles all the way down

A while back I had a heated passionate debate about dependency injection with a colleague. He was concerned about the lifetime of objects and which object had the responsibility of creating the other. While some of his points were valid, I took a position that a lot of that doesn’t matter if you allow the Inversion of Control container to manage this for you – simply push dependencies through the constructor. The argument, comically, sounded a bit like this:

Colleague: “But who creates these dependencies?”

Me: “That doesn’t matter. Put them in the constructor, let the container take care of that.”

Colleague: “Ok, so who creates this object?”

Me: “Again, doesn’t matter. It’s placed in the constructor of it’s parent, along with any other dependencies it needs.”

Colleague: “Arrrg! Who creates that object??”

Me: “Dude! It’s turtles all the way down.”

The reference “turtles all the way down” is to what I believed to be an Iroquois cosmological myth that the earth is flat and rests on the back of a great tortoise, which in turn rests on top of a larger tortoise that is on top of a larger tortoise, etc, etc… all the way down. I recently discovered that source of this expression is unknown and there are many different variants of this theme. The best variant is the Hindu belief that the earth sits on top of a tiger or elephant, which is on top of a tortoise, which is then, well, …uh, suppose we change the subject?

Over the years, I’ve adopted this expression to represent a fundamental lesson I was taught in object oriented programming: “objects should not have a top”. That is, objects should be open ended, allowing them to be extensible or mixed-in to other different applications and implementations. Our objects should be aware of their dependencies but not in control of their implementation or lifetime, and the framework that glues them together should be abstracted away. This idea is echoed by the Open/Closed principle and the Dependency Inversion principle, and it is demonstrated every time we write automated tests – the first consumers of our designs.

In my analogy, turtles all the way down accurately describes how I feel we should design our objects, but to my colleagues credit it doesn’t reflect that at some point there must be a reckoning point – someone must know how to assemble the parts to make a whole. I suppose Aristotle would point to an unmoved mover, responsible for the order of the universe. Douglas Adams would point to the man behind the man that probably has another man behind him. I’d point to some top-level application service that has the configuration that magically wires everything together.

It feels good to know there’s some sort of finality to the infinite regress problem: our application glues it all together.  So maybe now we can catch up on our sleep, knowing that we don’t have to realize infinity before we can close our eyes. At least until we see our application as part of a batch process in a much larger service, hosted in the cloud, resting on the back of a very large turtle.

Happy coding.

A few helpful TDD links

A few months ago, I had an interesting discussion about TDD with a colleague. When I returned to my desk I quickly sent him a list of links that I thought he’d find useful.

Today, I found it while cleaning up my email. I think you might find it useful, too.

I came across Miško Hevery’s blog through the Google Testing Blog.

• I’ve referenced his Singletons are pathological liars on many occasions
• His Guide for Writing Testable Code sums up many concerns that I often encounter.

A few of my posts that you might enjoy:

• Working with existing tests
• Static is dead to me
• Make it work, make it right, make it fast
• A week long series to build a test using only TDD: Guided by Tests

Windows Xaml–Triggerless

I was surprised to learn that Xaml for Windows Store applications does not have support for Triggers. Triggers within WPF (DataTriggers, EventTriggers) are a simple way to introduce interactivity to a user control such as changing the display properties when an event or data condition is satisfied. Since Triggers are declared using Xaml syntax, functional behavior can be introduced by modifying a style rather than writing code in the code-behind.

In recent years however, WPF has introduced the Visual State Manager (VSM) concept, which originally grew out of the SilverLight and WPF Toolkits before being rolled into .NET 4.0. The Visual State Manager is much easier to use because it groups previously unrelated triggers into more meaningful semantic states (MouseOver, Pressed, Normal, Disabled, etc). Triggers have played a less important role in WPF development since this time, but there were still occasions where a Data or Event Trigger made sense.

Unfortunately, triggers were not included in Xaml for Window Store applications. (Technically, EventTrigger is included but it only supports the FrameworkElement.Loaded event). So where does this leave us?

Here’s a few options:

• Implement a custom Control with specialized Visual States. Obviously not ideal but probably the most technically correct implementation.
• Implement an attached behavior (an attached property that listens to control events).
• Leverage ports of the Expression Blend Behaviors (System.Windows.Interactivity and Microsoft.Expression.Interactivity). There are a few promising starts, including Windows.UI.Interactivity, which looks like a direct port of System.Windows.Interactivity.

Personally, I’m a fan of the expression Blend Behaviors, especially the InvokeCommandAction which is immensely useful when building MVVM applications. I’ll post more about these with some examples soon.

Until then, happy coding.

Visibility Hidden Behavior for WinRT

In my last post, I lamented the loss of the Hidden in the Windows.UI.Xaml.Visibility enumeration. Here’s an ultra-simple attached property that simulates Hidden by changing the opacity and hit testability of the element:

using Windows.UI.Xaml;

namespace Blog.VisibilityHiddenDemo
{
    public class VisibilityHiddenBehavior : DependencyObject
    {
        public static readonly DependencyProperty IsVisibleProperty = 
            DependencyProperty.RegisterAttached("IsVisible", typeof(bool), typeof(VisibilityHiddenBehavior),
                new PropertyMetadata(true, OnIsVisibleChanged));

        public static bool GetIsVisible(DependencyObject obj)
        {
            return (bool)obj.GetValue(IsVisibleProperty);
        }

        public static void SetIsVisible(DependencyObject obj, bool value)
        {
            obj.SetValue(IsVisibleProperty, value);
        }

        private static void OnIsVisibleChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
        {
            var element = d as FrameworkElement;
            if (element != null)
            {
                var visible = (bool)e.NewValue;
                element.Opacity = visible ? 1 : 0;
                element.IsHitTestVisible = visible;
            }
        }        
    }
}

Free as in beer.

Happy coding.

Windows Xaml - No Where to Hide

With thanks to my current project, I finally have a chance to build a Xaml based Windows Store application. On the whole, I think the platform is great but it seems like a complete reboot of the developer ecosystem. Favourite tools like Reflector and WPF Snoop don't have a home and it reminds me of the first few years when .NET first came out. It's going to take a little while for us all to fully understand the change and how to make the most of it.

For today I thought it would be fun to start a new series of posts related to all the gotchas I've discovered working with Windows.UI.Xaml. Today's gotcha, Visibility.

One of the first observations you'll find working with Xaml for Windows store applications is that it is not WPF. WPF has matured into the System.Windows namespace over the last six years. Windows.UI.Xaml is brand-new -- it looks like WPF but it has some interesting changes.

Today's change: Visibility.

Under WPF, the System.Windows.Visibility enumeration has three possible values:

Visible	Display the element.
Hidden	Do not display the element, but reserve space for the element in layout.
Collapsed	Do not display the element, and do not reserve space for it in layout.

Visible seems straight forward enough, but the difference between Hidden and Collapsed is significant. The difference is shown using the Rectangle in this example:

<Window x:Class="Blog.VisibilityHiddenDemo.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <StackPanel Orientation="Vertical">

        <Rectangle Width="100" Height="100" Fill="Green" 
                   Visibility="Visible" />
        <TextBlock HorizontalAlignment="Center">Some Content</TextBlock>
        
    </StackPanel>
</Window>

When the Rectangle is Visible it appears on the screen as expected.

When the Rectangle is Hidden it doesn't appear, but it still takes up space.

When the Rectangle is Collapsed it's at though it never existed.

For applications that target Windows RT, Windows.UI.Xaml.Visibility has only two possible values:

Visible	Display the element.
Collapsed	Do not display the element, and do not reserve space for it in layout.

It makes we wonder why the folks at Microsoft decided to drop "Hidden" from the API. Ultimately, someone lost the debate and now we're left with an enumeration that is familiar to developers but is even more awkward that the original. Strange indeed.

So what does it mean that we have no Hidden? In the majority of cases, toggling between Visible and Collapsed is exactly what you want. But occasionally, you do want to remove something from the UI without changing the layout. For example, showing a button on the screen only when required.

So we don't have Hidden in Windows.UI.Xaml. Here's a few alternatives:

Opacity / IsHitTestVisible

One alternative to Hidden is to change the element’s opacity to zero thereby making it transparent. But beware, transparent objects are still present on the screen and can be interacted with, so if you’re hiding an interactive element such as a button, you’ll also want to set the IsHitTestVisible property to False.

Alternate Layouts

Rather than relying on the Hidden to preserve layout, another alternative is to use a different layout. Here are a few hacks that I’ve used:

Canvas Control

You can use a Canvas control and set the Canvas.Left and Canvas.Top attached properties on the children controls to position the controls exactly where you want. This seems a little heavy-handed and might only work if the content has a fixed size.

Relative positioning using Margins

The Grid control has a simple, dirty hack: if you don’t specify the Grid.Row or Grid.Column attached properties the element will default to the first column and row. You can achieve a form of relative positioning by putting multiple controls in the first position and then use margins to offset their position.

<Grid>
   <Button Width="50" Visibility="Hidden">
      <Image Source="/images/back.png" />
   </Button>
   <TextBlock Margin="55,0,0,0"
              Text="Text offset by margin" />
</Grid>

Grid-based layout

Another approach to preserving layout when Hidden is to explicitly define the layout. Again, heavy-handed if all you need is collapsed visibility.

<Grid>
   <Grid.ColumnDefinitions>
        <ColumnDefinition Width="50" />
        <ColumnDefinition />
   </Grid.ColumnDefinitions>

   <Button Grid.Column="0" Visibility="Hidden">
     <Image Source="/images/back.png" />
   </Button>

   <TextBlock Grid.Column="1"
        Text="Text in 2nd column" />
</Grid>

Well, that’s all for now. I’ll continue to post finds on Windows 8 Xaml under the WinRT hash tag.

Happy coding!

NuGet PackageRestore is awesome

It’s safe to say I’m a NuGet fan.  I’ve been using and following NuGet since the original Nubular days, but somehow I missed the significance of the Package Restore feature announced in version 1.7. I’ve had a chance to try it out. Simply put, it’s awesome.

Package Restore is a feature that allows your project to download and install packages as they’re needed, which means you don’t have to commit these packages into your source control repository. Java developers will recognize this feature as something similar to Maven, which has been around for while, but for .NET this is a very welcome change.

Enabling the feature in Visual Studio is pretty simple, just bring up a context-menu on the Solution Explorer and choose “Enable Package Restore”. Once enabled developers (and your build server) don’t even need to have NuGet installed to take advantage of this, they simply need an environment variable “EnableNuGetPackageRestore” defined.

The impact this feature has on your development team is subtle, but very powerful, and after using it on my current project I’m realizing how crippling our previous approach has been.

Up to this point my usage of NuGet has focused around the initial stages of the project, when the solution and dependencies are initially being put together. In this scenario, I’m checking the packages NuGet installs into my source control which means other developers (and my build server) have everything they need to compile the solution after they’ve got the latest source from the server.

Checking libraries into source control exposes a few interesting, and a bit too common, pain points:

• Upgrading packages isn’t easy because developers may manage the dependencies for projects manually, even if they have NuGet installed. In a way, I can’t blame the developers for doing this because this is, after all, how we’ve been managing our dependencies for years. But ultimately this practice defeats the purpose of using NuGet in the first place: I can’t upgrade all my projects in my solution to a newer version of the package if there are projects that NuGet isn’t aware of.
• Source control can get bloated with different versions of packages over time. If developers are using NuGet to manage their packages, they might forget to remove old versions in the repository. It takes a bit of extra discipline to stay on top of this.
  • Side note: depending on the connection between your build agent and server this bloat is potentially slowing down your build.
• Developers can still experience problems where their Local workspace isn’t current. This problem happens fairly frequently, if a developer isn’t getting the latest copy of the packages folder on a regular basis.

Over the past few weeks, I’ve found the package restore feature addresses these concerns, plus a few extra perks:

• We’re more open to trying out new packages because there’s less operational overhead. Developers don’t have to worry about breaking the build because they forgot to check in required assemblies, and the impact to remove the dependency is limited to the project file and config file. Less operational overhead makes the team more flexible to change when necessary.
• There’s new found desire to move existing dependencies to NuGet packages. NuGet has helped our team visualize the relationship between our dependencies which plays into how we’ll update and manage our packages, but it also automates the dependency management. For example, the process of duplicating a project’s dependencies when setting up a test project is greatly simplified. Once these benefits are realized, you’ll being to scrutinize the dependencies in the solution that aren’t managed by NuGet. In some cases, this has led us to create packages for our reusable libraries – which is so awesome because this will benefit our project and the organization as a whole. And that’s cool.

So there you have it. If you’re not using NuGet, you should download it and give it a try. If you’re already using it but not leveraging Package Restore I challenge you to give it a spin – does it make your team productive? Leave a comment below!

Happy coding.

Hosting a Dependency Injected WCF Service

I was having a discussion with a colleague today about how I use my blog as my digital memory or to save keystrokes when helping others. A few moments later, we were debugging a problem that I was convinced I had solved before. Strangely, I have no blog post for this.

So here it is.

Let’s say you’ve got an application and you’d like to expose a part of it on the network. Maybe you want to allow your mobile phone to control your app, or maybe you want two applications to talk to another. There are lots of possibilities here. Within the Microsoft space, one of the best ways to do this is through WCF. From an implementation perspective, it’s all about the ServiceHost.

Let's say the service looks something like this:

using System.ServiceModel;

namespace Example
{
    public class Service : IService
    {
        public string SayHelloTo(string person)
        {
            return String.Format("Hello {0}", person);
        }
    }

    [ServiceContract]
    public interface IService
    {
        [OperationContract]
        string SayHelloTo(string person);
    }
}

And the code to host the service looks something like this:

using System.ServiceModel;

public Example
{

    [TestClass]
    public class ServiceTests
    {
        [TestMethod]
        public void WhenServiceIsHosted_UsingTypeNameAndConfigIsPresent_ShouldConfigureTheServiceWithValuesInTheAppConfig()
        {
            var host = new ServiceHost(typeof(Example.Service));
            
            host.BaseAddresses.Count.ShouldBeGreaterThan(0,
                "The service host was not configured.");
            
            // optionally, if you had to launch it
            // host.Open();
            // Console.ReadLine();
            // host.Close();
        }

    }

}

This all good for basic services. But what if your service is assembled using constructor injection? You won't be able to simply pass the Type to the ServiceHost constructor.

[TestMethod]
public void WhenServiceIsHosted_UsingInstanceAndConfigIsPresent_ShouldConfigureTheServiceWithValuesInTheAppConfig()
{
    Service serviceInstance = ConstructService(); // omitted for clarity
    var host = new ServiceHost(serviceInstance);

    host.BaseAddresses.Count.ShouldBeGreaterThan(0);
}

Only, this test fails! It seems that by passing an instance of our service to the ServiceHost the values in our app.config are not being read.

To correct this issue, the service is configured as singleton and requires us to decorate our concrete implementation of that service with a ServiceBehavior attribute, and configure the InstanceContext for our instance as a Singleton.

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
public class Service : IService
{
    // ....
}

Bam! Passing tests.

Marking Kanban Items as Blocked

Sometimes items in your Kanban workflow reach a state where they cannot proceed. Maybe they’re have a dependency on another item; maybe there’s an issue or pending decision. When this happens, you want to increase the visibility of these issues by marking them as blocked.

Fortunately, the SEP Teamworks tool which I mentioned in my last post, supports such a feature. Simply right-click (or on a touch device, tap-and-hold) and use the context-menu to mark it as blocked.

Simple, right? Well, the first time I tried this feature, the tool crashed. Turns out that you must have a Blocked field in your work item definition.

Adding this field to your work item definition is easy.

1. Retrieve the work item definition from your TFS server using the witadmin exportwitd command:
   
   

   witadmin exportwitd /collection:<server-name> /p:<project-name> /n:Task /f:Task.xml

2. Insert a new field definition into the FIELDS node. Note that the namespace doesn’t matter. As TFS doesn’t contain a definition for Boolean fields, you must set it up as a string with Yes/No values.
   
   

   <witd:WITD application="Work item type editor" version="1.0" xmlns:witd="http://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef">
     <WORKITEMTYPE name="Task">
   
       <!-- edited for clarity -->
   
       <FIELDS>
   
         <FIELD name="Blocked" refname="Custom.Blocked" type="String">
           <ALLOWEDVALUES expanditems="true">
               <LISTITEM value="Yes" />
               <LISTITEM value="No" />
              </ALLOWEDVALUES>
              <DEFAULT from="value" value="No" />
         </FIELD>
   
       </FIELDS>
     </WORKITEMTYPE>
   </witd:WITD>
   
   

3. (Optional, but highly recommended) If you want to change the Blocked field outside of the SEP Teamworks tool (such as inside TFS), you’ll need to describe the field inside the FORM node. The syntax is relatively straightforward:
   
   

   <witd:WITD application="Work item type editor" version="1.0" xmlns:witd="http://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef">
     <WORKITEMTYPE name="Task">
   
   
       <!--edited for clarity -->
       <FORM>
   
          <Control Type="FieldControl" FieldName="Custom.Blocked" Label="Blocked:" />
   
       </FORM>
   
     </WORKITEMTYPE>
   </witd:WITD>

4. Lastly, push your changed work item definition back to the server using the witadmin tool:
   
   

   witadmin importwitd /collection:<server-name> /p:<project-name> /f:task.xml

With these changes in place, the SEP Teamworks tool puts a visual over blocked items.

My next post will look at some other handy customizations to the TFS work flow.

Configuring SEP Kanban board

In my last post, I showed how I’ve modified the State field of my TFS Work Item definitions to resemble my Kanban workflow.  This post we’ll take a look at how I’ve configure my digital board and highlight the pros and cons of my current approach. Maybe you’ll find this useful, maybe you’ve got some recommendations – either way, I’d love to hear from you.

Setting things up

1. Download and install the SEP Digital Kanban board: http://www.sep.com/labs/teamworks/
2. Run the MSI. Defaults all the way through.
3. Run the app. You’ll need to configure the board with a few settings.

4. Pick a server:
   
   

5. Select your TFS Server:
   
   
   
6. Select your TFS project and select a Query that returns all your work items. I have a small query to return only Tasks and Bugs: 
   
   
   
7. In order to get the workflow correct, you’ll need to manually order the States of the Work Item. Change the Work Item States –> Order.
   
   
   
   
   
   The Item states should be in this order:
   
   
   • Proposed
   • Active
   • Selected
   • In Development
   • Ready for Test
   • Testing
   • Acceptance
   • Closed
     
     
8. Depending on your Project collection, you may have additional work item definitions with their own states. You may have to turn off any states that aren’t included in our work item states. (This screen shot shows Resolved, Design and Ready states have been turned off)
   
   
   
9. Set up some limits.
   
    

Cool Features

Touch enabled: While the main feature that I was interested in was representing my tasks in TFS, what sold me on this tool was the fact that it was designed for touch. My HP TouchSmart now operates as our digital kanban board.

Swim lanes: Another great feature is the ability to view the features in their own collapsible Swim Lane. There are many great uses for swim lanes such as grouping by Area, Iteration, Priority, Assigned to, Triaged, etc. Most scalar value fields can be used. What’s also great about this feature is that you can simply drag a work item into a swim lane to assign that field value. This makes it easy to keep your work items organized.

Create or Edit Work Items: The tool takes advantage of the form layouts defined in the work item definition, so you can get the same TFS Team Explorer editor experience right on your Kanban board. Large buttons at the top of the user-interface make it simple to add new bugs or tasks as they arrive, and I can open an item from a context-menu to get or edit details about the task at hand.

Caveats and Annoyances

Tasks and Bugs: Unfortunately, I’m only tracking Task and Bug work items because these are the items that I’ve customized. I would like to Use Stories where I describe the work as a high level story and then realize that effort in tasks. At the moment, I’m using TFS 2008 which doesn’t support hierarchal tasks, so I’m kind of stuck on that.  If I could track hierarchal tasks, I’m not entirely sure how I would use this tool – where should the Stories appear on the board if only some of the development tasks are complete?

No sub-columns: One of the features that this tool lacks is that ability to create sub-columns. Ideally I would like to treat Development as one column with two sub-columns (“In Development” and “Ready for Test”) and put a WIP limit on Development. Having this capability highlights testing bottlenecks and would ensure that the development team is invested in seeing their completed efforts are delivering into the client’s hands.

No central configuration: While I’m sure that the target usage for this application is to use it on a touch-device as a whiteboard replacement, the tool doesn’t offer any means to save the configuration externally or toggle between configurations. This is a minor annoyance because most of my team members are jumping on board with this tool to provide their status updates. Also, as I have multiple projects, a means to jump between configurations would be ideal.

All in all, it’s a great resource.

My next post will talk more about customizations to the Work Item definitions that support my workflow.

Using Kanban with TFS

I’ve been actively campaigning for Kanban within our organization. This means giving lunch info-sessions, lending my ear to projects that need a boost, speaking with management and project managers. What I find so fascinating is that people get charged by such a simple concept. It can’t be this easy – but it is – and it’s applicable to most projects. Really? Really.

I’m thrilled to see people “get it”, because it’s easy to draw parallels between work as a pipeline and continuous delivery. Concepts like “push-to-deploy”, continuous integration and regression testing graft directly to parts of your workflow. And while the core concepts of continuous delivery aren’t prerequisites to Kanban, they are certainly mutually beneficial. By leading with Kanban, it’s easier to see value proposition of continuous delivery.

A common theme from all my discussions is I strongly recommend teams “resist the urge to replace a whiteboard with software”. Software can be a trap if applied too early to the process. Pick the wrong tool and you’ll spend your time worrying about tooling rather than the issues that are preventing you from delivering value. Nothing beats the immediate, tactile capabilities of a post-it note moving from one column to another. Focus on the workflow, foster adoption within the team, optimize and then find software to fit your needs. It should rarely be the other way around.

Unless of course, your team is remote.

I’ve heard of some innovative ways to get around this limitation, including a webcam pointed at your Kanban board. This seems like too far a stretch for me, and it’s time for my project to move our spreadsheets and post-it notes into a more centralized digital format.

While there are many cloud-based solutions, a critical feature for me is to own the data. And integrate directly with Visual Studio. (Okay, two key features). Team Foundation Server does Work Items. Let’s start there.

Customizing Work Item Definitions

Out of the box, the definition for Task has all the fields we need to implement our Kanban workflow. The main customization that we need to make is to the State field: we’ll model the various stages of our workflow using this field.

Our current workflow looks something like this:

• Proposed: This is our backlog
• Active: Items that will be included in this release.
• Selected: These are items that we will develop next.
• In Development: Items being actively worked on.
• Ready for Test: Development is complete and is pending deployment or verification.
• Testing: Items that are being validated by testers.
• Acceptance: Items at are ready for client review.
• Closed: Completed items.

We’ll need to model these various states in our work item definition, which we can retrieve from TFS using the following command line:

witadmin exportwitd /collection:https://<tfs-server-name> /p:<project-name> /n:Task /f:task.xml

Our State field is represented in the work item definition as:

<witd:WITD application="Work item type editor"
           version="1.0"
           xmlns:witd="http://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef">

  <WORKITEMTYPE name="Task">

    <FIELDS> <!—- simplified for clarity -->

      <FIELD name="State" refname="System.State" type="String" reportable="dimension">
        <HELPTEXT>The workflow state of the task</HELPTEXT>
      </FIELD>

    </FIELDS>

    <WORKFLOW> <!-- simplified for clarify -->

      <STATES>
        <STATE value="Proposed" />
        <STATE value="Active"/>
        <STATE value="Selected" />
        <STATE value="In Development" />
        <STATE value="Ready for Test" />
        <STATE value="Testing" />
        <STATE value="Acceptance" />
        <STATE value="Closed" />
      </STATES>

    </WORKFLOW>

  </WORKITEMTYPE>
</witd:WITD>

Transitioning between States

One of the powerful features of customizing the work item definition is the ability to define rules that govern how the item transitions between states.  There is a bit overhead to define these transitions and it can become cumbersome if you have a lot of states, but overall this is a good exercise to formalize what each column means and why something would move from one state to another.

State transitions are fairly easy but there are a few small caveats:

• You must provide a default state (transitioning “” to “Proposed”)
• Each transition must have a default reason, plus any number of additional reasons.
• Any transition that is clearly not defined is not supported.

There are a lot of neat features that you can define here, some of which will have to wait for another post, but here’s a quick excerpt that demonstrates state transitions:

<witd:WITD application="Work item type editor" 
           version="1.0" 
           xmlns:witd="http://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef">
    <!-- edited for clarity -->

    <WORKFLOW>
        <!-- snip -->
        
        <TRANSITIONS>
            <TRANSITION from="" to="Proposed">
              <REASONS>
                <DEFAULTREASON value="New" />
              </REASONS>
            </TRANSITION>
            <TRANSITION from="Proposed" to="Active">
              <REASONS>
                <DEFAULTREASON value="Scheduled in Release" />
              </REASONS>
            </TRANSITION>
        
            <!-- not shown:
                proposed -> development
                proposed -> closed

                active -> selected
                active -> development
                active -> proposed
                active -> closed
    
                selected -> development
                selected -> active

                development -> ready for test
                development -> selected
                development -> active

                ready for test -> testing
                ready for test -> development

                testing -> acceptance
                testing -> ready for test
                testing -> development
                testing -> selected
                testing -> active

                acceptance -> closed
                acceptance -> active

                closed -> active
             -->
    </WORKFLOW>

</witd:WITD>

With our customizations in place, we can push our work item definition back to TFS:

witadmin importwitd /collection:<server-name> /p:<project> /f:task.xml

Now when we open a Task definition, we see that the State transition drop-down is constrained by the transitions we’ve defined and the Reason column is prepopulated with our reasons.

Visualizing TFS Work Items in a Kanban tool

TFS has a rich API and many integrations available (especially with Office stack) but I certainly wouldn’t have gone through all of this trouble if there wasn’t a replacement for my whiteboard and post-it notes.

I recently found this free tool, provided by SEP, that does most of things I want. Because the application supports touch, I’m able to put my HP TouchSmart to good use.

My next post will talk more about setting up the SEP teamworks tool.

A week with Windows Phone 7

I realize I’m probably a bit late to the party on this blog post as Windows Phone 8 is around the corner, but worth writing about anyway.

I've been an iOS boy for a long time, starting with my trusty 3G in 2008 and my iPhone 4 in late 2010. But when my iPhone 4 was stolen, my options here in Canada were pretty limited. I could either replace my iPhone 4 for over $600, or count the months remaining on my 3 year contract until I could afford an upgrade, where each month was a $20 savings from the $600. Disappointed and rejected, I reluctantly plopped a new SIM into my old iPhone 3G and over the course of a few months I began to realize the crushing effect of Apple's development philosophy: "Long live new hardware! Old hardware be damned."

I got tired waiting, and on a whim I scanned kajiji for used phones. I stumbled upon a lightly used Nokia Lumina 710 for a little over $100 – a bargain compared to my iOS options. As a windows developer who knows a thing or two about WPF and XAML, I couldn't resist.

First impressions

Although I want to focus on the Windows Phone operating system, I need to remark on the device a bit. As a phone, the Nokia performs well, fits comfortably in your hand, has a bright screen and a decent 5 megapixel camera. This device features a dedicated button for the camera which can bring the device out of stand-by so that you can use it as a camera, a feature all phone should have if they don't already.

It seems like a funny feature to showcase, but I'm quite impressed by the speakerphone, which takes up sizeable area of the lower back of the phone. I’ve found this feature to be lacking in both my iPhone and iPad, but now I can actually use the speakerphone to have conversations with people in the room, or hear the dialog in a YouTube video.

My only complaint is that the hardware buttons at the bottom of the device can't be used to bring the device out of stand-by – that feature is exclusively owned by the power button on the top. I don't know if this behavior is something specific to this Nokia device, but I find myself pressing these buttons constantly – an old habit that this iOS'er is certainly having a hard-time breaking.

User Interface

So far, I'm really quite impressed with my Windows Phone. From a look-and-feel perspective, the interface is a slick metro theme. Scrolling is smooth and transitions between screens are animated. Most importantly, applications start quickly and are responsive.

Hardware Buttons

Windows phones have three hardware buttons: "back", "windows", "search". The windows button can be pressed at any time and returns you to the Start screen where you can launch applications. More on the search button later.

If you’re used to iOS where navigating through an application is done through software-based buttons, the “back” button seems like an oddity the first time you use it.  Most applications in Windows Phone rely on the back button to provide backward navigation, similar to the behaviour of the back button in a web browser. However, if the application has reached its initial starting point, the back button will close the application and return you to the start screen.  If you have multiple applications open, the back button will close the current application and return you to the previously running application – this seems peculiar at first.  Alternatively, you can press-and-hold the back button which will allow you to switch between applications, much like switching tabs in your browser.

It's funny that after relying on software-based buttons in iOS for so long, I was reluctant to switch to hardware-based buttons for aesthetic reasons and it took a while to get used to. Once you've acclimatized to having these buttons, you realize that most applications take advantage of this concept so their user-interfaces aren't cluttered with software buttons. The Windows Phone operating system builds upon this by providing a consistent place in applications for software buttons, called the app bar, located at the bottom of the screen just above the hardware buttons. These two concepts work really well together and they quickly become second nature.

After a few days, I found myself wanting to tap the left-side of my iPhone whenever I picked it up.

Customization

On the iPhone, you can tell a lot about someone’s personality not only by the way they've customized the outside of the device but by the way they've arranged their applications: what's on their home screen? what's in the dock? With Windows Phone, i can drag tiles around to personalize my start screen, though it doesn't have the same feeling as folders and multiple screens on iOS. I'm not saying this is bad, it's just different. It’s stripped down simple. So simple, it works brilliantly.

Apart from the start screen, I can swipe to the right to bring up a full list of applications, which are sorted alphabetically. It's easy to find an application if you know its name, but grouping them by category or folder like Windows 8 would be a huge step up. It took iOS a few releases to introduce folders, maybe a future release will support this.

The phone also supports a simple theming concept which is comprised of a background and accent colour. The theme is based on the concept that darker colours use less power for the OLED screen. The accent colour is picked up by most applications and changes the colours used by the main home screen.

You can also customize the images on the lock screen and customize ringtones and other sounds. (I am so freaking bored with iPhone’s notifications and reminders.)

Live Tiles / Start Screen

In Windows Phone, the tiles are "live", meaning that each application can provide additional information to the Start screen. Whereas iOS applications are limited to small numeric overlays overtop of their applications (a handful of Apple applications like Weather and Calendar update their icons to reflect current conditions and date), Windows Phone allows applications to fully customize the front and back of their tiles.

As you would expect, the Weather application shows an icon for the current weather conditions with the current temperature and the Calendar application shows the time and details of your next appointment. Some of the apps provide a much more interesting display, like the Contacts app creates an animated mosaic of my friends cover photos, or the Photos app which rotates through some of my favourites.

Where the Live Tiles feature rocks is that some applications let you pin individual elements of the application to the Start screen. Most notably, I pinned my wife’s contact card to the start screen which shows me her photo and recent activity. Other apps, like FourSquare let you pin things like locations. It’s a mix between developer flexibility and user customization.

In the end, the Home Screen becomes more than just a launching point for your favourite applications – it’s a personal dashboard that provides meaningful information at a glance. This is extremely powerful.

The Social Connection

Windows Phone is touted as being great as a "social" phone, and it's easy to see how that connection is made. When you first turn the device on, my first inclination is to setup my address book. I started with my Google account because this holds my contacts, email and a few personal calendars. Easy.

But Windows Phone also natively supports Facebook. Following the same process to hook up my Google account, I plugged in my Facebook credentials and something magical happened: the phone merged my overlapping contacts between online providers (Facebook, Google, Windows Live, Twitter, LinkedIn) into a single holistic view. Not just their contact details, but their status updates and online photos are instantly available from their contact card. This alone is pretty awesome but it goes one further – all contact touch-points from the phone are also seen in the history for the contact: emails, phone calls, text messages are all in one place.

The social network integration in the phone runs deep. All of my Facebook photo albums are immediately available from the phone’s photo gallery. I can post to twitter, Facebook and LinkedIn simultaneously. The built in Camera application lets you post pictures and videos to Facebook with a single click. I’ve been more active on Facebook this month without ever launching Facebook. Cool.

Other Perks

There are many other neat features in Windows Phone 7, but here’s a few notables:

• Predictive Text: While iOS doesn’t provide auto-correct suggestions until you’ve misspelled or typed most of a lengthy word, WP7 provides a list of possible words above the keyboard as you type. The list is scrollable left/right and often provides suggestions that are exactly what you need, or darn close.
• Search: One of the hardware buttons is for “search” which at first glance is just a shortcut for Bing. However, at the bottom of the search interface are three software buttons: one provides a handy feature to search by speaking to the device, the second leverages a built-in QR-Code (and MS-Tag) scanner, the third is a music search that can identify the currently playing song.
• Speech: A slightly hidden feature, if you hold the windows key down for a second, a dialog will prompt you for voice commands. It’s not quite Siri, but you can text a message to someone without looking at the screen.
• Office: Windows Phone 7 ships with a mobile version of Office, complete with OneNote.
• Copy/Paste: While iOS didn’t have this until several releases in, the copy/paste feature within Windows Phone is pretty intuitive. And, it’s part of the initial release (jab, jab).

Drawbacks

Much like iOS users pined for Copy-Paste, Windows Phone has a few short comings.

• Screen Capture. Surprisingly, Windows Phone does not let you take pictures of the current screen. This is a bit baffling, but apparently coming in the next release. There’s a way to get screen-captures of the device but it requires the device to be registered with a paid-developer account. (That sucks. I will post screen-shots once I get my accounts sorted out)
• App Store. This is by far the biggest challenge for the platform as the lack of applications makes it clear that this is the forgotten player in this space. Although I hope to write a few applications, the platform currently lacks the critical day-to-day apps like online-Banking. These apps are desperately needed, but with the upcoming Windows 8 and overlapping Windows 8 Phone release eminent, it’s likely we’ll see a catch-up effect in the App Store.

Conclusion

I dig the Windows Phone platform. And if you get a chance to play with one, give it a shot – it will surprise you.

The real question is whether I will buy a Windows 8 phone or an iPhone 5 when it’s announced in a few months. Depends on what happens in the iPhone space, but it’ll have to be really convincing.  I’m more than willing to try out the next generation of Windows 8 phones.