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:

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.