VBandi's blog : Silverlight, Windows Phone 7

WP7 – Changing Visuals Based on Phone Theme with ThemeToStateBehavior

vbandi — Sun, 29 Jan 2012 12:00:31 GMT

The built-in resources in Windows Phone 7 help a lot with automatically reflecting the selected theme of the phone. (See my earlier blog post: Being theme aware in Windows Phone 7 Silverlight apps). However, sometimes you want to be theme aware, but need more than the predefined resources. For example, you may want to have a generally blue background color, but want it to be a dark blue for the dark theme, and a light blue for the light theme. I created a little Behavior that allows you to do just this.

Here is how to use it:

Create a new WP7 application (or use your existing one)
Create a new Visual State Group with two Visual States in Expression Blend. Name them however you want, but I like to keep a naming convention for my states:

Change the visuals as you like fit for both themes. For example, I changed the background of the LayoutRoot to a dark blue color for the ThemeStates_Dark Visual State, and a light blue color for the Themes_Light state. For fun, I have also changed the page name text to say “dark side” and “light side”

To verify what the Light Theme looks like in Blend, you have to switch to the Device panel, and switch the Theme toggle to Light. This will change the values of the resources, and make the default text black.

If you are happy with how your app looks in the different themes, just add the ThemeToStateBehavior (code at the bottom) to the root of your visual tree:

Set the two themes for the dark and light theme in the Properties panel:

… And when you launch the app, you will see that it works as desired:

Based on the theme detection logic by Bart Wullems, here is the code for the behavior:

public class ThemeToStateBehavior : Behavior<Control>

    protected override void OnAttached()

        base.OnAttached();

        var isLightTheme = (Visibility)Application.Current.Resources["PhoneLightThemeVisibility"] ==

                            Visibility.Visible;

        Dispatcher.BeginInvoke(() =>

                                VisualStateManager.GoToState(AssociatedObject, isLightTheme ? LightState : DarkState,

                                                            true));

    [CustomPropertyValueEditor(CustomPropertyValueEditor.StateName)]

    public string LightState { get; set; }

    [CustomPropertyValueEditor(CustomPropertyValueEditor.StateName)]

    public string DarkState{ get; set; }

Enjoy!

SurfCube on Mango Part 4 – fighting with the ListPicker control

vbandi — Sun, 11 Sep 2011 18:16:24 GMT

On SurfCube, we are using the ListPicker control from the Silverlight for Windows Phone Toolkit. The latest (August 2011) version of this Toolkit has a bug – it doesn’t work in ScrollViewers. It simply does not open. First we thought the problem was with Pivots / Panoramas – then, stripping away the controls one by one, we found that it was actually the ScrollViewer that stole the tap event somehow.

After that, it was easy to find an existing solution at http://forums.create.msdn.com/forums/p/90708/543239.aspx#543239. What we did is package the code there into a nice small behavior (sorry for the weird formatting, just want to make sure it fits the screen):

using System.Windows.Interactivity;

using Microsoft.Phone.Controls;

namespace My3DBrowser.Behaviors

    public class ListpickerInScrollViewerFixBehavior :

                 Behavior<ListPicker>

        protected override void OnAttached()

            base.OnAttached();

            AssociatedObject.Tap += ListPickerTap;

        bool isOpen;

        private void ListPickerTap(
                object sender, System.Windows.Input.GestureEventArgs e)

            if (!isOpen)

                AssociatedObject.Open();

                isOpen = true;

            else

                isOpen = false;

And that’s it… just apply this behavior to any ListPicker that doesn’t behave correctly in a ScrollViewer.

Note: This is not a perfect solution. For example, after the ListPicker opens, the containing scrollviewer should scroll so that it is entirely visible. We “solved” this problem by putting the listpickers on top – if anybody has a better solution, I am all ears (eyes?)

SurfCube on Mango Part 1 – Passing the Smoke Test

vbandi — Tue, 05 Jul 2011 11:46:28 GMT

Note: If you don’t know what SurfCube is and would like to follow this post series: it is a popular Windows Phone 7 web browser with a 3D twist. Here is a demo video you should look at to understand what I am talking about. Better yet, download SurfCube, see for yourself how it works – and if this series is useful for you, please consider buying!

I have just submitted SurfCube 3.1 to the WP7 Marketplace yesterday. Just as many other WP7 developers, I am excited about Mango, and with 3.1 out the door (and will hopefully pass the Marketplace digestion process just fine), I was eager to see how SurfCube behaves on the new Mango Beta 2 SDK and on my phone. I have updated my LG Optimus 7 to Mango, and I just love the new OS! It is even more fluid, responsive and delightful than the original WP7 was. However, this post series is not about Mango – it is about my experiences moving an existing and fairly complex app to Mango.

Step 0 – running SurfCube 3.1 on Mango

So, after installing Mango Beta on the phone, the first thing to try was see how SurfCube ran on it without any changes whatsoever. Here is the good part: scrolling is butter smooth, even the long history list is perfectly responsive. The web browser scrolling was sometimes a bit jerky on Nodo, but it is perfect on Mango. The cube’s rotation is faster, too, although it was pretty good on Nodo already. And the new IE9 engine is noticeably faster. Not just “well, it feels snappier, but it may just be my imagination” faster. More like “wow, that IS fast!” All in all, a huge gain in general performance, smoothness and user experience.

Of course, multitasking and fast app switching didn’t work. You have to recompile and modify your app a little bit for that. I also had some crashes, especially around viewing videos (more on this later). But the biggest issue is that our context menu didn’t work. Some of SurfCube’s most advanced features are behind the context menu: opening links in new or background tabs, saving images from the web, sharing a page via Twitter or Email, etc. And it doesn’t work at all. It seems like the Javascript “oncontextmenu” event does not work on Mango, not even in Internet Explorer (we are using the WebBrowser control, which relies on IE9 rendering and running scripts). If things don’t get better, this could end in SurfCube losing some of its most useful features in Mango I have been in touch with Microsoft about this issue, so I am hoping this will be resolved in time.

Step 1 – Compiling SurfCube for Mango

So, to get the multitasking and other new features working, the first step is to recompile your application for Mango. In theory, this should be as easy as flicking this switch to 7.1 in the project’s properties:

Then I was greeted with this rather scary dialog:

OK, I am on a different TFS branch anyway, so let’s go for it!

But it doesn’t build, I get some ambiguous reference errors for GestureEventArgs – no wonder, it was used from the Silverlight Toolkit for Windows Phone 7, and now it is built into the SDK. So I open up the relevant source files, and fix it with some ReSharper magic:

I am going to go with the Toolkit gesture for now, so I select the second option, and Resharper inserts the code:

using GestureEventArgs = Microsoft.Phone.Controls.GestureEventArgs;

to the top, and all is right.

After trying to compile again, I get a warning:

'My3DBrowser.Controls.WatermarkedTextBox.WatermarkProperty' hides inherited member 'System.Windows.Controls.TextBox.WatermarkProperty’

All right, TextBox now has a Watermark property, we can throw out our own WatermarkedTextBox control. Nice, but I will ignore it for now. But I also got an error:

error CS1705: Assembly 'Microsoft.Expression.Interactions, Version=3.8.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' uses 'System.Windows.Interactivity, Version=3.8.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' which has a higher version than referenced assembly 'System.Windows.Interactivity, Version=3.7.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

Well, it looks like some other assemblies have been updated too, like System.Windows.Interactivity. So, let’s replace it:

Remove it, and add the right version:

By the way, if the above Add Reference dialog is from the Visual Studio Productivity Power Tools, which is pretty much a must have tool!

So, now we can compile, right? Well, yes, it compiles!

========== Build: 5 succeeded or up-to-date, 0 failed, 0 skipped ==========

So, let’s try to run it! It starts, but crashes before the first screen is loaded:

MarketPlaceSearch Action is the same code I shared earlier. What is important right now is that is uses the WP7 RTM, 3.7.5.0 version of the System.Windows.Interactivity dll, and needs to be updated to Mango. The exception is not very helpful – it is not really a type not found, but a type loading error in this case. This class is in a different project, which has to be updated to WP 7.1 as well. After doing that and replacing the reference for the WP7MarketplaceTools project (where the referenced MarketPlaceSearchAction is), we can try compiling and running again:

Next problem: WrappedException. This is really a mystery to me. After loading the app, the it comes from the UpdateLayout of a WebBrowser Control (which I had to call manually in WP7). Luckily just removing the call seems to work for now, but this definitely is a breaking change (or bug).

And finally, the app starts!

Or so it seems – because we have another one of the WrappedException error, again. It happens when our AdControl switches visual states at startup:

     System.Windows.dll!MS.Internal.XcpImports.CheckHResult(uint hr) + 0x1e bytes
     System.Windows.dll!MS.Internal.XcpImports.UIElement_UpdateLayout(System.Windows.UIElement element) + 0x10 bytes
     System.Windows.dll!System.Windows.UIElement.UpdateLayout() + 0x6 bytes
     Microsoft.Expression.Interactions.dll!Microsoft.Expression.Interactivity.Core.ExtendedVisualStateManager.GoToStateCore(System.Windows.Controls.Control control, System.Windows.FrameworkElement templateRoot, string stateName, System.Windows.VisualStateGroup group, System.Windows.VisualState state, bool useTransitions) + 0x101 bytes
     System.Windows.dll!System.Windows.VisualStateManager.GoToState(System.Windows.Controls.Control control, string stateName, bool useTransitions) + 0x52 bytes

Well, all right – I will deal with this issue later, and turn off the ads for now. Just let me see the app running!

And it works!

Awesome! Let’s play around a little bit, and test YouTube playback – it crashes. Oh maaaaan. Here is the exception:

Not too helpful, is it? No usable call stack, no source code, and “Unspecified error” is not the most useful exception either. So, let’s put on the Sherlock hat and start to play detective.

After clicking on the video, the app is supposed to bring up the video player UI. If I disable the code that makes the player visible, the app doesn’t crash. So, the problem must be somewhere in the video player UI! Here is what it looks like in Blend:

Oops, not too nice… luckily in Blend, when we edit the code, the designer surface immediately updates. I removed everything in the main Grid to make sure the problem was indeed in it, and the designer was fixed:

So, I started to add and remove lines and chunks of code, until I managed to pinpoint the problem: the two Coding For Fun RoundButtons we are using for the “play/pause” and the “fill screen” functions. I removed those, and the app worked, video played. However, I didn’t want to leave it at that, and found out that there actually is a new Coding For Fun Toolkit released along with the Mango Beta 2 SDK. So, I have replaced the toolkit, and behold – we now have a working SurfCube video player! And the new emulator can playback H.264 videos, so I can show you what it looks like:

Summary

Getting an existing project to run on Mango is certainly not a trivial task with the Beta SDK. Apart from fixing library references, the biggest problem seems to be with the WrappedExceptions and other unspecified errors. These seem to be beta bugs for me, and mostly happen during the layout / measure cycle. But is is nothing a little detective work cannot fix.

Other than that, Mango is really pleasant from a developer point of view. The apps run much smoother, consume less memory. My biggest problem with lists (which is considered to be the Kryptonite of WP7 apps) is resolved, and 3rd party apps can now feel just as responsive and smooth as their native friends. Just check out the official Twitter app on Mango to see the difference. (my friend, René Schulte recorded a comparison video, too).

Next up in the blog post series: multitasking, fast app switching, then the real fun begins as I start to add Mango features to SurfCube. What Mango features should SurfCube take advantage of? Let me know in the comments!

Response.MVVM is now available via NuGet!

vbandi — Thu, 31 Mar 2011 10:34:45 GMT

About a year ago, I wrote an article for SilverlightShow, titled “A Designer-friendly Approach to MVVM”. The article introduced VSMChangerBehavior which allows tying enums in the ViewModel to Visual States in the View. Another Action shown off there is the CallDataContextMethodAction, which calls a method in the DataContext with a twist – if such a method is not found, it can travel up the visual tree, and call the methods there.

We have used both the VSMChangerBehavior and the CallDataContextMethodAction in many projects since. We fixed a couple of bugs, and today, we are releasing them as a NuGet package to make it easier than ever to add these handy utilities to your project.

The package supports WPF, Silverlight and Windows Phone 7 projects. We are also publishing another package with a sample control and ViewModel to show off how the workings.

To add the package to your project, do the following:

Install the latest NuGet package manager from www.nuget.org. (this package requires V1.2)
Open a WP7, WPF or Silverlight project
Right click on References, and click Add Library Package Reference

Search for the package called “Response.MVVM”

Click Install to install the library or the sample. The sample also installs the library, and adds the Samples\Response.MVVM folder to your solution :

To see how it works, add the SampleControl.xaml to your application, and run it. Here it is in a Windows Phone 7 application:

That’s it! Enjoy!

Handling WP7 orientation changes via Visual States

vbandi — Tue, 08 Mar 2011 15:14:22 GMT

It is pretty well known that an app can be notified of the phone’s orientation changes via the PhoneApplicationFrame.OrientationChanged event. However, if you are as serious about sharing the work between the designer and the developer as I am, you will not be happy with this – the changing of the layout should be the responsibility of the designer, not the developer.

Of course, the best way to achieve the different layouts is via Visual States. You can define two states like this in Blend:

And move your controls around. For example, in SurfCube V2.2, we wanted to have the tabs and the tab buttons below each other in Portrait mode, but in a totally different arrangement in Landscape.

In this example, the buttons are placed inside a WrapPanel, and the WrapPanel’s Row and Colums are changed – in Landscape, they are moved to the first column of the second row. You can even throw in some fluid state changes for added effect. This is all nice, but how do you switch between the two states?

The first idea that comes to mind is to use GotoStateActions, triggered by the OrientationChanged event. Unfortunately, you cannot attach an event to the PhoneApplicationPage:

(In the above screenshot, the invisible mouse cursor points to the PhoneApplicationPage.)

Even if this worked, we would have problems – the tab page shown above is actually a UserControl, which doesn’t have the OrientationChanged event.

Behaviors to the rescue!

Like so many times before, behaviors are here to save the day. By creating a simple OrientationToStateBehavior (ok, so the name is not so simple), designers can once again have total control over how they want the UI to look in the different orientations. Just attach the behavior to the UserControl:

Set up the different states for the different orientations:

And that’s it!

As for the code of the behavior, you can find it below.

The most interesting parts are:

OrientationChanged is global for the entire phone, so we are using the main application frame for this. However, the root visual may not be available at the time the behavior gets attached, so we enqueue the setup code into the UI thread via a Dispatcher.BeginInvoke code.
If you precede your string properties with
System.Windows.Interactivity.CustomPropertyValueEditor(CustomPropertyEditor.StateName),
Expression Blend will provide the user with a dropdown menu of the Visual States in the current control.

The rest is pretty self-explanatory, enjoy Windows Phone 7 coding!

   1:  using System;

   2:  using System.Windows;

   3:  using System.Windows.Controls;

   4:  using System.Windows.Interactivity;

   5:  using Microsoft.Phone.Controls;

6:

   7:  namespace My3DBrowser.Behaviors

   8:  {

   9:      public class OrientationToStateBehavior : Behavior<UserControl>

  10:      {

  11:          public OrientationToStateBehavior()

  12:          {

  13:              IsEnabled = true;

  14:          }

15:

  16:          protected override void OnAttached()

  17:          {

  18:              base.OnAttached();

  19:              InitWhenReady();

  20:          }

21:

  22:          private void InitWhenReady()

  23:          {

  24:              PhoneApplicationFrame main;

  25:              Dispatcher.BeginInvoke(() =>

  26:              {

  27:                  main = Application.Current.RootVisual as PhoneApplicationFrame;

  28:                  if (main != null)

  29:                  {

  30:                      main.OrientationChanged += MainOnOrientationChanged;

  31:                      SetState(main.Orientation);

  32:                  }

  33:                  else //If rootvisual is still not set, wait some more

  34:                      InitWhenReady();

  35:              });

  36:          }

37:

  38:          public bool IsEnabled { get; set; }

39:

  40:          [CustomPropertyValueEditor(CustomPropertyValueEditor.StateName)]

  41:          public string PortraitUpStateName { get; set; }

  42:          [CustomPropertyValueEditor(CustomPropertyValueEditor.StateName)]

  43:          public string PortraitDownStateName { get; set; }

44:

  45:          [CustomPropertyValueEditor(CustomPropertyValueEditor.StateName)]

  46:          public string LandscapeLeftStateName { get; set; }

  47:          [CustomPropertyValueEditor(CustomPropertyValueEditor.StateName)]

  48:          public string LandscapeRightStateName { get; set; }

49:

  50:          private void MainOnOrientationChanged(object sender, OrientationChangedEventArgs orientationChangedEventArgs)

  51:          {

  52:              if (IsEnabled)

  53:                  SetState(orientationChangedEventArgs.Orientation);

  54:          }

55:

  56:          private void SetState(PageOrientation orientation)

  57:          {

  58:              string stateName = "";

59:

  60:              switch (orientation)

  61:              {

  62:                  case PageOrientation.PortraitUp:

  63:                      stateName = PortraitUpStateName;

  64:                      break;

  65:                  case PageOrientation.PortraitDown:

  66:                      stateName = PortraitDownStateName;

  67:                      break;

  68:                  case PageOrientation.LandscapeLeft:

  69:                      stateName = LandscapeLeftStateName;

  70:                      break;

  71:                  case PageOrientation.LandscapeRight:

  72:                      stateName = LandscapeRightStateName;

  73:                      break;

  74:                  default:

  75:                      throw new ArgumentOutOfRangeException();

  76:              }

77:

  78:              VisualStateManager.GoToState(AssociatedObject, stateName, true);

  79:          }

  80:      }

  81:  }

Notifyting the ViewModel when a WP7 PivotItem is displayed

vbandi — Sun, 23 Jan 2011 02:49:55 GMT

While trying to reduce the loading time for our SurfCube 3D Browser app, I realized that loading a 100 or so history items to a ViewModel property directly bound to the UI may not be the best idea. It takes up a long time (like 0.5 seconds) to render the items in the list, and the user may never see the history during his / her session. The solution is obviously to load the items only when needed.

In the upcoming version of SurfCube, we will have a Pivot for choosing between Favorites and History. This is what the top side of the Cube looks like:

For most browsing sessions, the user won’t even visit the history at all. I only want to spend precious CPU cycles on rendering the history when needed. So, I need a way for my ViewModel to know when to actually load the history items to the ObservableCollection bound to the list on the History PivotItem.

Unfortunately, the PivotItem control does not expose any event that fires when it is activated. Technically, we could use the Pivot’s SelectionChanged event here. But the arguments of the event are PivotItems – and knowing about UI controls is a big no-no for VIewModels.

Well, Triggers to the rescue! By creating a simple trigger, and adding it to the PivotItem, we should be able to notify the ViewModel that it’s time to fill the ObservableCollection with data. Here is the code for the Trigger:

   1:      public class PivotItemActivatedTrigger : TriggerBase<PivotItem>

   2:      {

   3:          protected override void OnAttached()

   4:          {

   5:              AssociatedObject.Loaded += (o, eventArgs) =>

   6:                  {

   7:                      var parentPivot = AssociatedObject.Parent as Pivot;

8:

   9:                      if (parentPivot == null)

  10:                          throw new InvalidOperationException("Parent of a PivotItem should be a Pivot");

11:

  12:                      parentPivot.SelectionChanged += (sender, args) =>

  13:                          {

  14:                              if (parentPivot.SelectedItem == AssociatedObject)

  15:                                  InvokeActions(null);

  16:                          };

  17:                  };

  18:          }

  19:      }

The Action we are invoking can be anything. Since I want to notify the ViewModel, I am using the CallDatacontextMethodAction as described in my older article “A Designer-friendly Approach to MVVM”.

After the Trigger is added to the project, this is how I am using it in Blend:

First, I drop the CallDatacontextMethodAction on the historyPivotItem.

Then click the New button for the TriggerType:

Select PivotItemActivatedTrigger in the dialog, then click OK:

Finally, enter the method name:

One word of advice though: the trigger actually fires in the middle of the Pivot’s animation. If what you are doing in the EnsureHistory method is longer than a dozen or so milliseconds, make sure you fire up a background thread to do it.

Please let me know if you found this tip useful!

Behaviors for accessing the Windows Phone 7 MarketPlace and getting feedback

vbandi — Fri, 07 Jan 2011 23:38:41 GMT

Encouraging the users of your WP7 app to rate or buy your application, view other apps by you or just send a feedback email can make or break an app. However, the MarketPlace API can be a little confusing, and takes a little time to figure out which method does what. You can’t even try and see for yourself, because most MarketPlace actions don’t work until you actually have the app published.

In this blog post I am going to share the code we use in our SurfCube 3D Browser for the above tasks. To be precise, I am sharing four Actions that can help you, and have passed the MarketPlace a few times.

To use these behaviors, just add the attached source code or binary to your project, recompile, and use them as any other Action in Blend – drag and drop them on the FrameWorkElement you want to perform the action, and set the properties.

Here is what the About screen of SurfCube looks like:

It is possible that invoking the MarketPlace or the email program can take a little time. Users get impatient, and click on the link again, causing an Exception saying that the app is already dectivated, can’t invoke Launchers. The solution is to make sure the links are only clicked once, by disabling the Action, so that a repeat invokation won’t crash your application. Note, that all four actions cause you application to Tombstone, so plan accordingly.

The MarketPlaceReviewAction

This Action is added to the “Rate this app” link, and has no parameters. It opens the MarketPlace showing your app and the rating interface.

The MarketPlaceDetailsAction

This Action is not used in SurfCube – it opens the MarketPlace and shows the details of your app. The underlying MarketPlaceDetailTask API can show another item, but you would have to extend the Action to accept parameters.

The MarketPlaceSearchAction

This action is used in the “Other apps from Kinabalu Innovation” link, and can really help cross-promoting your apps. Just set the SearchTerm property to your publisher name, and the other apps will be displayed. Here is my setup:

The SendEmailAction

The Send feedback link allows the user to send an email. Tapping it will bring up a new email, pre-filled with the To, Subject and Body properties. I just attached the SendEmailAction to the hyperlink, and I set the properties:

At another point of the application, I am asking for feedback about the future TAB support in the browser. I am using the same SendEmailAction with different parameters there:

Users usually leave the subject of the email unchanged, so I immediately know when I got a feedback from the app.

Summary

You can download the sample application here. It contains the source code of the above mentioned behaviors and a little WP7 app using them.

Well, that’s it. I hope you find these little Actions useful!

Being theme aware in Windows Phone 7 Silverlight apps

vbandi — Tue, 14 Sep 2010 17:29:00 GMT

Windows Phone 7 users can customize their phones by choosing between a dark and a light background, and tons of accent colors. The Windows Phone 7 UI Design and Interaction Guide tells us, that it is good to be theme-aware. For example, if the user selects a light background with red accent color, the application should also display its content on a light background with a red accent color.

Built-in Controls

The built-in Silverlight colors do a good job of reflecting the phone theme out of the box. For example, the Slider control always uses the accent color as the fill color. Here is a slider in the default dark/blue theme:

And here is the same slider in light/red theme:

Drawings, shapes

If you want to draw a shape (for example, a rectangle or an ellipse) in a theme-aware manner, you can invoke some built-in resources. This ellipse will always have the accent color as its fill color:

Here is the ellipse in the default theme:

And here it is in the light/red theme:

You can use similar resource binding techniques in your own controls to make them theme-aware. There are tons of color resources defined, you can see them in Expression Blend:

Being theme-aware in code

Sometimes, you cannot just bind to resources, you need to actually use the colors in your code. For example, you may need to draw something on a WriteableBitmap, using the accent color. The same resource can be used from code like this:

Color accent = (Color)Resources["PhoneAccentColor"];

To draw a pixel on the WriteableBitmap with this color, you need to access the WriteableBitmap’s Pixels array (more information here), and set one of its items to an integer value. The following code shows how you can calculate the value based on the accent color acquired before:

uint accentColor = (uint)accent.A * 0x1000000 + 
                   (uint)accent.R * 0x10000 + 
                   (uint)accent.G * 0x100 +
                   (uint)accent.B;

Now, to set the upper left corner of the WriteableBitmap to this color, all you have to do is:

myWriteableBitmap.Pixels[0] = (int)accentColor;

Small step for a little colored pixel, but a giant leap for Theme Consistency!

Designing the Windows Phone 7 “Mix Zoomery” app

vbandi — Sun, 11 Jul 2010 21:26:26 GMT

Summary: this blog post details the design decisions and some technical information behind the Windows Phone 7 Mix Zoomery app.

Some of you may have heard of Zoomery, which is the Deep Zoom framework of my company (Response). Some of you may have even seen our Mix Zoomery demo, which allows browsing of all 130 presentations and 3271 slides of the Mix’10 conference. This is what it looks like:

Ever since I have heard that Windows Phone 7 would include deep zoom I wanted to see how Zoomery worked with it. So, what better way to find out than to port one of our latest samples over to the phone?

Armed with the WP7 SDK, I started to make it happen. It was fairly difficult to find some free time to work on the project, but at the end, after about 2 days of net working (which took me weeks to do ), I was finally satisfied with the result enough to create a quick screen capture video, upload it to YouTube, and tweet about it.

Here is the video:

WP7 Mix Zoomery App video

Shameless plug: the reaction was overwhelmingly positive. Until now, the video has been seen almost 2000 times. More than 20 peeps tweeted about it (excluding me, but including WP7 demigod Charlie Kindel). There are two English articles (WMPowerUser.com came up with the title “Zoomery.com MIXes up Deepzoom” and MobiletechWorld’s article “Browse all the MIX 2010 presentations with Deepzoom on Windows Phone 7”), one Polish article, and a Chinese one here (translated).

So, I’ve decided to ride the wave, and write about how the app came to be – that is what this blog post is about.

Technical details

Heard the saying “If you are a Silverlight developer, you are already a Windows Phone 7 developer”? Well, it is true. In fact, it is so much true, there is not a lot I can write about the technical side. That is why this post is called “Designing the WP7 Mix Zoomery app” – most work went into the design, not the implementation.

For example, I could easily reuse the deep zoom tile set I have created earlier for the web version of the application. The WP7 app uses the same tiles, from the same server, with the same metadata. What is more, I could reuse the entire “DeepZoomHelper” class that we have been developing for years – it handles the panning and zooming, the filtering, sorting, metadata handling within the Zoomery framework. I created a new WP7 Silverlight class library project, linked in the files from the web version, and it worked. I did add some "#ifdef WP7” though to get rid of things like the floating zooming toolbar that is created for notebook users without a mouse wheel:

I also disabled the automatic refreshing of the property for the “currently centered” item during panning, because we don’t need it in the WP7 version, and it does tax the weaker mobile CPU somewhat. (On the desktop version, there is an event that fires every time the centered item is changed, to allow showing the info panel). I could also reuse the metadata-parsing logic for the details page.

So, if I could reuse the server side Deep Zoom generator, and the client side DeepZoomHelper library, what did I have to do?

Designing the UX

The majority of the work was adopting to the different form factor and interaction mechanisms of the phone. It goes without saying, that the phone is not just a small PC. I had to start thinking about the user experience from scratch.

I wanted to transfer as much of the feature set and experience of the original application, as possible. So, here is what I wanted the app to do:

View all presentations, grouped by key topics
Navigate by zooming and panning
Filter the presentations by any word in the title, tags, presenter or abstract
Review detailed info on every presentation
Navigate to related presentations (by tags or presenters)
Watch the streaming video of any presentation in high or lower qualities
I decided not to have the “front row view” functionality at this time – it will be fun to tie some perspective transforms to an accelerometer, but this is not something that I wanted to venture into without a real device.

As for the UX, I wanted to fit the app to the nice Metro UX as much as possible. This means that content is king - there are no fancy adorners, animations and typography are where the wow factor should live. Metro is also an authentically digital experience – a Metro app does not want to look like a real-world device. A true WP7 app also honors the WP7 way of navigation: namely, the back button, which should always take you back to the previous screen. I also wanted the app to honor both landscape and portrait mode.

Let’s see how the above challenges were tackled!

View all presentations, grouped by key topics

This was the easiest. The abovementioned DeepZoomHelper library and the zoom tile set I created earlier for the web app just worked, out of the box. Luckily, as the main topic of the Mix10 conference was Windows Phone 7, I already had the presentations rendered in a nice, Metro-like way, and using the Segoe font, so there was nothing to do here.

Navigate by zooming and panning

This one was more tricky. Obviously, the best way to do zooming on a phone is to use two finger gestures. Unfortunately, I don’t have a phone, nor a multitouch monitor, so I was not able to test this approach. Instead, I opted for a Zoom in and Zoom out button in the Application Bar (the separate area on the bottom of the WP7 screen). Clicking on the buttons calls the same zoom methods in our helper library as the mouse wheel does in the web version.

After playing with it for a while, I left these buttons in – even if I have the pinch gesture implemented, these buttons would work well for one handed usage (when you don’t have another hand available to hold the phone or you can’t put it down on a table and use two fingers). The buttons also help discoverability – even if a novice user does not think of trying the pinch gestures, he will certainly press the buttons on the bottom to figure out what the app does.

Panning is also important – fortunately, I didn’t have to do anything to make it work. The DeepZoomHelper already was listening to the mouse events, and single touch gestures are nicely translated to mouse events. Nice!

Filtering

The web version of the app can filter the presentations by any word that is in the title, tags, presenter or the abstract of the presentation. You may notice, that as soon as the filtering takes place, the categorized view disappears, and you have a different, filtered view:

The WP7 app behaves exactly the same way. It filters after every character entered – but if this turns out to be too slow on a real device (it is slow on the emulator), it can easily be changed to perform filtering after the entire filter phrase has been entered.

On the web app, the filter textbox is always visible. However, I didn’t want to waste precious reading / browsing space on the WP7 screen, so I decided to hide the Filter UI, and only show it when the user specifically requests it by pressing the magnifying glass icon in the Application Bar.

The filter UI consists of a text entry field, and a clear filter button. The later does not exist in the web version, because it is too fun to see presentations come back as you remove characters one by one from the filter. However, on the phone, typing is much more painful, so I decided to add the clear button there.

A part of the filter UI is the software keyboard that shows up when the focus is in the textbox. This means that there is not much space left to watch the presentations come and go as you type or delete characters. (I guess this is one more reason to have the filtering only happen after Enter is pressed…) I am using the “Search” input scope for the TextBox. This replaces the Enter key with the right arrow key on the keyboard, and indicates the user that by pressing it, they are going to go to another place in the application.

On the technical side, the search UI is implemented as a separate Visual State Group, and show / hide animations are defined as state transitions:

There is a 0.6 second transition with Cubic easing, for a nice appear / disappear effect (did I mention that I love easings?).

Note: It would be great to use the hardware search button instead of putting it on the Application Bar. Unfortunately, it seems like WP7 won’t allow 3rd party apps to override the behavior of the physical Search button (at least in V1). This is very unfortunate – the physical Search button acts as one would expect it to act in the OS itself – it allows for contact search while viewing the contact list, for example. Not allowing similar behavior for third party apps makes these apps less discoverable, and increases user frustration, when pressing the button takes them out of the currently running app all the way to Bing. Of course, they can always press the back button, but still, this is a frustrating experience! To make things worse, by the time the search button will be overridable by apps in V1.1 or V2 or whenever, users will be trained not to experiment with it. Please, Microsoft, if you can add just one thing until release, make it the overridable search button! Don’t let our users be trained to ignore it!

Details info

Perhaps the biggest difference between the UX of the web and the WP7 app is how the presentation details are shown. On the web, whenever a presentation fills in a big enough part of the screen, a panel comes in on the right, and shows the information, . On the WP7 app, we don’t have the luxury to sacrifice so many pixels. So, I have added another button to the App Bar, which shows the information for the currently centered presentation. I was considering using an information icon (a lowercase i in a circle) for this, but decided that users would mistake it for an about-like menu item, and would miss the gateway to the most useful part of the application – the presentation details and the video features. Therefore I opted for the more interesting right arrow, hoping that users would get the “proceed” meaning.

I admit, there is some room for improvement here. The discoverability of this feature is not good – the arrow is unchanged from the moment the application starts, and while all the zooming and panning action is going on on the screen, the little arrow at the bottom is forgotten. The solution would be to only show the arrow when there is an active presentation to show the details of, or even add some attention-grabbing animation to the “proceed to the details” button. The developer is supposed to be able to enable / disable / hide the App Bar buttons, but these features are not working in the current bits. Before I can decide on how to make this part right, I will need to see the app on a real device (to see how much more I can put on the CPU), and also, I will have to see if there are any animations for enabling a button or make it visible.

So, what happens if the user does press the “Proceed to details” button? Well, he / she is taken to the next screen, where – surprise – the details of the centered presentation are displayed:

This is a no-nonsense, text-only screen. The title of the session is displayed on top, followed by the presenters, links to the videos, the abstract, tags and finally, a link to the mix website. The blue text is active (it is actually displayed using the active system color, so if the user prefers red or green, this screen would show the active text in red or green).

Clicking on a presenter or a tag takes the user back to the main deep zoom screen, filtered by the specific presenter or tags. This allows for a quick way to find related presentations. However, clicking on a video link launches the default video player of the WP7 OS, with either the high or the normal bandwidth video from the Mix website.

The details screen is implemented as another visual state in the app. The transition between the main and the details view looks like the the default rotation transition on the phone to keep it consistent with the underlying OS. By default, the details view has a perspective transform applied to the Y axis of –105 degrees. When the details view is activated, the main view is rotated by 90 degrees along the Y axis, and the details view is rotated to 0 degrees, thus occupying the phone’s screen. This trick works well when there are only a few statuses that need to be switched. Using Blend’s transition preview functionality, it is fairly easy to finetune this animation without launching the app.

To navigate back to the main deepzoom view, the user only has to press the physical Back button. By default, the back button would go back to the start screen (or wherever the app was launched from). The WP7 UI Guidelines allow the back button to be overridden, if we are using it to dismiss a dialog or navigate within the application to a previous view. That is exactly what is happening here. Not at all coincidentally, when the user presses the back button while playing a video (or viewing a presentation’s link), they get back to the WP7 Mix Zoomery application via a very similar animation. This consistency makes the WP7 media player look like it is part of the app, and thus I did not need to implement video playback like I had to do in the web version.

Note: I love the WP7 Back button. Just think of how often you use the Back button in the browser – the physical back button on the phone has the same role. This is an area where the WP7 OS has an advantage to the iPhone, where every app has to have its own back mechanism, often putting the back button on different places. On WP7, the back button has to be the leftmost button below the screen, which is the most convenient place for your thumb if you are holding the phone in your right hand, but also very easy to reach when the phone is in the left hand. I know that the Android OS also requires the presence of a physical back button, but it still does not specify where the button should be according to this post.

Summary

The greatest challenge in porting an application from the web / desktop version of Silverlight to WP7 is that the latter demands a totally different approach to the user experience. You can expect an almost complete rewrite here, but almost none, when it comes to the business logic, client-server communication, models, server side, etc. However, the existing Silverlight development skillset you or your team has is almost 100% percent transferable – the new concepts (such as the Application Bar, the gestures, the sensors, etc.) are easy to grasp. In my opinion Microsoft made the right bet choosing Silverlight as one of the two development platforms for Windows Phone 7, making over 500,000 Silverlight developers WP7 developers overnight.