Wednesday, December 1, 2010

Performance Optimization on Phone 7

A preview of an article I wrote for Code magazine. For the rest you'll need to wait for the magazine to come out. (oh and this is the unedited version so don't get to upset about things like passive voice or other what I call minutia)

For those of you that know me, you might wonder why I would be writing an article on Performance Optimization for Phone 7, I mean sure it’s Silverlight; and phone 7 has this coolness factor but I always talk about User Experience right? So what gives you ask?

Well when it comes down to it, without performance you don’t have much to experience. The dirty little secret is that performance optimization is a critical often ignored part of good user experience design more so when we are talking about a device barely bigger then a pocket calculator. Time and time again I’ve seen user studies where users see nothing changed for 2 seconds and they navigate away or otherwise assume the application is broken or the device is broken or the web page is broken. Users have no patience and the worst part is that 99% of performance optimization is… wait for it… managing user expectations or in other words ‘perceived performance’

Perceived Performance

Perceived Performance, what is that all about? Perceived performance is the difference between letting the user know that your app is doing something (by say using a loading animation) verses just a black screen. In fact much of the requirements around getting Windows Phone 7 applications into the market place are about perceived performance. Take the preloaded image that is included in your default project, if you don’t have one of those preloader images in your application then your application had better be bleeding fast or no market place for you. Applications only get a few seconds before they have to be up and loaded. For building ‘perceived performance’ and a great user experience start here with a custom preloader. Don’t just go with the default from visual studio either:



Figure 1: Default Splash Screen Image From Visual Studio

Start by building anticipation on phone 7 for your application with making this default preloader screen cooler or more ‘engaging’. You’ll note that in the default project this file is called ‘SplashScreenImage.jpg’. When you edit this file make sure it stays a ‘JPG’ too. JPG rendering on phone7 is much faster than PNG’s and certainly don’t stick other formats on your phone. The one exception to this would be using PNG’s when you need transparencies for example when making app bar icons. Here is an example of a great preloader that builds anticipation:




Figure 2: Customized Splash Screen Image

In this case the user is so caught up in the preloader that in this example the user generally wants to figure out how to get back to this preloader screen. Not only does this build anticipation but the user is generally so engaged that they don’t even notice the slow load and even might complain it loads to fast.

Perceived performance is about engaging the user quickly even if you app isn’t ready and this was one example. If you expect to sell your app your UX (User Experience) needs to be more than just a pretty face it needs to be highly optimized even if that just means perceived optimization. Let’s look at other ways we can make our apps scream.


9/10s of the law

Perception is 9/10s of the law figuratively but after the splash screen what is next? After your splash screen or preloader is thrown up on the screen next your app has the chance to load. Making sure you app loads quickly is critical again to over all perceived performance. In practice this means that your constructor should not execute more than it needs to quickly get something up. If you start some doing some huge work in your constructor then you are going to quickly start blocking your UI. Don’t do real work in the constructor as this will slow your UI loading. The less code between your preloader image and the app the better, but you ask what if I have a real app that needs to do real work?

Ok fine you’ve written a real app that needs to do some real work before it start working. Again part of managing user expectations is about ‘perceived performance.’ This doesn’t mean your app can’t do real work on such an under powered device (compared to my dual proc quad core 64-bit, liquid cooler desktop dev box), it just means you have to do it more intelligently. Our first real trick in learning to do this other then learning what not to put in your constructor is to use elements that are pushed onto the composition thread to keep people waiting.

What? Composition Thread? What is that about?

Threading on Phone 7

A big part of performance on the phone 7 is understanding the threading model. On the phone 7 we don’t get back ground process’s that we can run when our apps are not on the screen but we do get a few tricks that allow us to do some simple threading in the app. Basically on the phone you have 2 threads, the UI (User Interface) thread that is basically your app plus you have can some user defined threads but you also have this idea of a composition thread which you don’t have direct access to but you can take advantage of.

What is cool about the composition thread is that it is not blocked by the UI thread. If you have work that can be done on the composition thread it can continue even if your app is completed blocked via the UI thread doing some huge work. Typically you might have a waiting animation or a progress bar when something like this happens.

Say our app is loading something and we block our UI thread so we and the default progressbar control that is build into the Phone 7 Silverlight framework like this... (the rest will be in Code Magazine)

No comments:

Post a Comment