Archive for the ‘ UX ’ Category

Windows Phone – Performance Best Practices

Performance issues is where we usually spend most effort in finding, so it is very important to understand how you find them, and how you prevent them in the first place.

This post will be fairly long containing some basic info about performance in apps and at the end go through some of the more common occasions where I usually see performance issues and how to fix them.

Let’s start with looking at the threading model.

Silverlight for Windows Phone has two threads that handle all the presentation related work. One UI Thread and one Composition/Render thread.

UI Thread

The UI thread is the main thread in Silverlight for Windows Phone and functions very similar to the UI thread for the Silverlight browser plug-in.

The UI thread handles all input, which includes touch, parse and create objects from XAML, layout calculations, data binding, draw all visuals (at least the first time they are drawn), rendering/rastering, process per-frame callbacks and execute other user code and event handlers.

Composition Thread

The composition thread is new for SL on WP7, it’s actually the only platform that has it (as far as I know) and is created to talk directly to the graphics processor, GPU. It basically feeds the GPU with textures to draw and handles transform (scale, rotate, translate) animations and plane projections.

The composition thread handles some work that the UI thread would normally handle, and therefore improves performance of Silverlight applications for Windows Phone. The composition thread combines textures and passes them to the GPU for drawing. Also storyboard-driven animations that run on the composition thread are automatically cached and handled by the GPU on the device in a process called auto-caching.

Note: To use the composition thread, scale transforms must be less than 50 percent of the original size.

In addition, opacity and clip property settings are handled by the composition thread. However, if an Opacity mask or non-rectangular clip is used on the animated object, these operations will be passed to the UI Thread. This means that even if the clip region is a rectangular shape but uses the PathGeometry the operations will be passed to the UI thread. So make sure to always use the RectangleGeometry for clipping paths if possible.

Animations and Threads

As mentioned previously, storyboard-driven animations are handled by the composition thread. This is ideal because the composition thread passes these to the GPU for processing. In addition, the composition thread can run more frequently than the UI thread if the CPU is overloaded.

Translate animation will run on the Composition Thread

There are times, however, when storyboard animations do not satisfy the requirements of your application. In this case, you may choose to drive animations in code. These animations are handled on a per-frame basis. In many cases, this is fine, but you should be aware of the implications of running animations on a per-frame callback.

Per-frame callbacks are handled strictly on the UI thread. Animations will update only as fast as the UI thread can process them, and depending on what else is happening in your application, the animations may appear less smooth than if they were running on the composition thread. Also, when you update animations in code, the elements are not automatically cached as they would be if they were updated in a storyboard. If you manually place a bitmap cache on these elements, the transformation and blending is passed to the GPU, but the animation is still being updated on a per-frame callback and processed by the UI thread. In these cases, the animation will update only as fast as the frame rate of the UI thread.

Color animations will run on the UI Thread and if blocked it will miss changing color


It is extremely important to think about threading and have a solid understanding of how critical the UI thread is, it already does a lot as it is, so extremely important not to do to much work on the UI thread then necessary .

Progress bar

One of the most common controls used to show an indication that something is taking time to process is the ProgressBar. Although not everyone knows that the progress bar that is shipped with the SDK is lacking performance, it is running all the animations on the UI thread and is not really a valid option for a progress indicator. If you need to place a progress bar somewhere in the application that is not at the top of the page, then you should use the PerformanceProgressBar that is shipped with the Silverlight Toolkit for WP7. But, that progress bar is not perfect either, it will actually continue executing the animations even if the progress bar is invisible. Toggle visible on and off is often how we show/hide the progress bar, but setting it to indeterminate will make the animation to continue even when it is hidden. So in this case you should also toggle the IsIndeterminate property using the same data binding you use to toggle it’s visibility.


<ProgressBar IsIndeterminate="{Binding IsProgressBarVisible}" Visibility="{Binding IsProgressBarVisible, Converter={StaticResource VisibilityConverter}}" >

The best option with respect to performance is to use the ProgressIndicator on the system tray on an application page. It performs very well and I have never had any issues with it, even when totally blocking the UI thread and have really advanced animations handled by the composition thread.

I often hear that we don’t want to use the ProgressIndicator since that requires the system tray to be visible and it will make the app look bad. But remember that you can set colors, opacity etc. on the system tray so it should not be to hard to design it to fit to the overall design. Changing the opacity on the system tray to something less than 1.0 will make the system tray hover over the page and let the page take the entire area, so you could also toggle the visibility of the system tray in the same way you toggle the progress indication.

Performance Counters


These counters are really important to use and understand, they are in great help when you try to find what the actual performance issue is. You enable/disable the performance counters by toggling EnableFrameRateCounter property in the App constructor.


Composite Thread – Aim for 60 FPS, it becomes red when under 30. 30 FPS doesn’t sound to bad, but MSFT has seen that the experience is not perfect when you come under that threshold, it just doesn’t look and feel good. So try to get at least 45 but aim for 60!

UI Thread – Becomes red when counter is under 15

Video Ram – the number of textures that has been created for all objects, for example a button that has been rasterized to a texture and drawn on the screen.

Internmediate textures – textures that SL has created for us to improve performance. If two or more textures are placed on the same layer, then SL will create one large texture of it so that we do not have to send one texture for each object, instead SL will just send one large.

Fill rate – fill rate tells us how many pixels that we send to the screen in each frame. A fill rate of 1 means that 800×400 pixels are drawn in each frame. There will be performance implications if the fill rate comes larger than 3, to much pixels to process and we get a drop in frame rate.

Redraw Regions

Objects that are animated but does not change, that is, pixels in the image looks identical in each frame but the object is moving, then SL will not have to send all the pixels over and over again to the GPU to calculate what is to be drawn. Instead the composition thread will just animate the object and render the same texture over and over, just in new positions.

By enabling Redraw Regions, then each time SL need to re-calculated and send pixels to the GPU it will be shown by a color tint on the texture with different colors. If we see a lot of flickering then we now something might be wrong.

You enable redraw regions in the same way you enable performance counters, but by toggling the EnableRedrawRegions property.


If we have a lot of flickering and want to remove that due to performance hit, then what we want is to cache the texture on GPU and only tell it to move the object and draw it again, we do not want to send the same pixels over and over again when they are not changing.

Recall in the section above about performance counters and intermediate textures, these sound really good but there might be times when intermediate textures means performance issues. If we have one or more moving objects on the same layer as for example a button, then SL will try to be smart and create an intermediate texture out of these, but since we are animating the objects the intermediate texture needs to be recalculated in each frame and sent to the GPU, so we get a performance drop due to that.

In this case we want to do two things, first of all make sure that pixels for an object that is not changing is not sent to the GPU in each frame and also prevent an intermediate texture from being created since it doesn’t add anything, just gives us worse performance.

The solution to this is setting cache mode. SL is smart and does this for us, but not in all types of animations. If we use a per-frame callback for animations then SL will not cache the texture for us. You set the cache mode manually by setting


for each object you want to cache.


Look at the left part, a lot of redrawing is done while the rectangle is animating to the right

Fill Rate

So fill rate tells us how many pixels we send to be processed in each frame. It’s important to understand that fill rate will increase by 1 if you explicitly set background color on the page. So setting background color on pivots, panels etc. is something you should avoid unless you really need to.

Bitmap Cache sounds like a “silver bullet” if you look at the above example about redraw regions. So shouldn’t we just set cache mode on all objects?

It sounds like a good idea, but the answer is NO! Caching an object means that we increase fill rate since each object becomes its own object that needs to be rendered. And an increased fill rate means a drop in UI thread FPS. For example, if we have an application with a background image of a sky, then several of other images that builds up the scene like trees, hills, bushes, birds etc. If we then set explicit caching on all objects then we will have several layers that the GPU needs to render, even if the texture for one object is not even visible since some other object is drawn in front of it. But if we do not set cache mode explicitly then SL will be smart and create one intermediate texture for us and cache just ONE texture instead of one for each object.

So it really depends on your app, and you have to be smart on when to use and not use bitmap cache, be ware of fill rate. So USE performance counters, use redraw regions etc. to figure out if your app is performing well or not.

Data serialization/deserialization

A Windows Phone app has the possibility to store data on “disc” where all I/O operations are working through Isolated Storage. WP7 works in a sandboxed environment separated from all the other apps on your phone, so it is “safe” to store application specific data on the phone without worrying about other apps accessing your data.

There is a specific API that makes it possible to save application settings as objects in isolated storage really easy, which facilitates storing simple objects a lot.

IsolatedStorageSettings.ApplicationSettings[yourKey] = yourObject;

Even though it is simple to store objects in application settings, you will probably need to serialize and deserialize more advanced/complex objects in isolated storage throughout the application lifecycle. Below are some common occasions when you need to serialize and deserialize data.

  • App Launch – Deserialize
  • App being dormant/tombstoned – Serialize
  • App being reactivated – Deserialize
  • App being terminated – Serialize

So what do we have to think about when serializing data? The most important thing is how long it takes to serialize/deserialize data and when you do it.

First of all there are certification requirements that could be jeopardized and eventually hinder your app from being accepted to marketplace.

Launch Time, your main screen of the app needs to be rendered and shown within 5 seconds and the user needs to be able to interact with your app within 20 seconds.

Activation Time, if an app is deactivated (for example the user clicks the hardware Start button) and later activated, then the app needs to start with the same criteria as app launch time.

Most of our apps will have to save lists of object that you need to cache for quick access when the user returns to your application. This means that we need to serialize data to XML/JSON or some other format when the app is de-activated and when the user returns and the app is re-activated, data needs to be deserialized from isolated storage to a list of objects.

This serialization and deserialization can take time and if we do it in Application_Launching or Application_Activated event handlers then we could end up with performance issues at app startup. You need to think about where and when you need the data, make sure long running processing is done in background workers to prevent blocking the UI. For example, if you have a lot of data that you need to deserialize when starting your app, your app is useless without it, then think about other “dirty tricks” of how to fool the user into believing that your app is starting quickly. Perhaps use a second splash screen, you could even make the second splash screen look like your app (that is take a snapshot of your app en store it as a jpeg) and show that while you are deserializing data.

It is also important to select the correct serialization type, there are several options where some of them are shown in the table below with metrics showing how long it takes to serialize/deserialize 200 objects and 18 000 objects.

Isolated Storage Demo (executed on phone)

200 serialized 200 deserialized 18000 serialized 18000 deserialized
XML 76ms 174ms 6.1s 14.4s
DataC 149ms 191ms 12.9s 16.3s
DataCJSON 131ms 98ms 11.1s 8.4s
JSON.NET 63ms 147ms 5.2s 12.7s
Sharp 282ms 101ms 10.7s 9.6s

Note that this is just how it turned out in my sample app, the numbers could be totally different for your objects so you need to profile and try out different formats before you decide what format you should serialize data to. Most common is using JSON.NET in my experience.


As with serialization and deserialization to and from isolated storage, it is equally important to think about the size of messages that you send and receive over the wire. So use the above table to figure out what type of message to send when creating web services that are consumed from your Windows Phone application. It’s really simple to create a RESTful web service that provides JSON formatted output, so start with that unless you need a specific format.

Below is a screen shot of the message size for different types of message formats. (the sample app fetches all the suppliers that exists in the Northwind database)


JSON data sent: {“Address”:”49 Gilbert St.”,”City”:”London”,”CompanyName”:”Exotic Liquids”,”ContactName”:”Charlotte Cooper”,”ContactTitle”:”Purchasing Manager”,”Country”:”UK”,”Phone”:”(71) 555-2222″,”PostalCode”:”EC1 4SD”,”SupplierID”:1},{“Address”:”P.O. Box 78934″,”City”:”New Orleans”,”CompanyName”:”New Orleans Cajun Delights”,”ContactName”:”Shelley Burke”,”ContactTitle”:”Order Administrator”,”Country”:”USA”,”Phone”:”(100) 555-4822″,”PostalCode”:”70117″,”Region”:”LA”,”SupplierID”:2},{“Address”:”707 Oxford Rd.”,”City”:”Ann Arbor”,”CompanyName”:”Grandma Kelly’s Hom… and so on…

WebClient vs HttpWebRequest

WebClient is a wrapper class around the HttpWebRequest class that is used to perform Web service requests. WebClient can be easier to use because it returns result data to your application on the UI thread, and therefore your application does not need to manage the marshaling of data to the UI thread itself. However, if your application processes the web service data on the UI thread, the UI will be unresponsive until the processing is complete, causing a poor user experience, especially if the set of data being processed is large.

My suggestion is to use HttpWebRequest instead of WebClient and process the resulting data on the asynchronous request thread and then use BeginInvoke to marshal the data to the UI thread.

Making Large Numbers of Requests for Small Amounts of Data

To preserve battery life, the operating system will turn off the device’s radio after a preconfigured timeout interval. If an application is going to make a large number of requests for small amounts of data, I recommend that these requests be executed in parallel instead of serially. This helps to ensure that the device’s radio stack will not go to sleep, avoiding the lag incurred when the radio is powered on and off for each request and also saving battery life. Although there is a limit on maximum outbound network calls the rest will be queued and processed as soon as possible.

Where does it usually go wrong?

Below I’ll try to summarize some of the common performance issues that I have encountered and how to fix them.


Performance issues at startup is probably the most common problem I encounter when helping customer with their apps and causes everything from failed marketplace submissions to users giving up on your app since it takes to long to load and you end up with bad reviews and in worst case no one using your app.

Imagine that you start an app, see the splash screen and eventually the app is shown quickly, but it is really jerky, doesn’t seem to respond to user input and so on. These are the performance issues you really need to think about to fix. So what is actually going on at startup?

Assemblies are loaded and jittered, objects are instantiated and loaded and so on. Although the problem usually doesn’t reside here but it could. More common is what happens after that and all processing that needs to be completed before the app is “done” and fully ready for usage, deserialization of state (tombstone), loading UI (which means XAML parsing, element creation, layout calculations, redering etc).

So what can we do and what should we do to increase app startup time?

1. use a Splash screen and load data during startup. But if the app loads really quickly then you should perhaps remove the splash screen, only use if you need it. Don’t spend time designing the super cool and awesome looking splash screen since it could be so that the app starts really quickly and the user will not really see it to long. I have actually heard about cases when developers has put a Thread.Sleep() during startup to make sure the splash screen is visible longer. Not a good approach :) When the app is loaded you continue loading data that should be shown in background threads and when done publish/display it on UI using the dispatcher.

2. Use a second copy of the splash screen and show that as the first thing in your app with a progress bar if you need to load data from a web service or do something that takes time. But try to avoid this since the user wants to get into your app quickly and immediately start interacting with it. And even if you use a second splash screen with a progress bar you cannot take all the time you want, a max of 3-4 seconds, after that the user will start loosing his/her patience.

3. Keep the assembly size small of all the assemblies that are being loaded at startup. If your assemblies contains complex and demanding constructors, make sure to refactor and move the code to separate assemblies. If the app contains a lot of media like images, videos etc. then think about if you can set “build mode” as Content. If build mode is set to “embedded resources” then they will be loaded each time and make the loading of assemblies heavier, as build mode “Content” then assemblies will be loaded a lot quicker and content will be loaded “on demand”.

4. Keep your XAML clean and as simple as possible, try creating a small visual tree as possible to optimize layout calculations and rendering. Delay creation of controls to a later time when they are really needed and shown. For example in a Panorama all items will be loaded and kept in memory, which means that if you have 5 panorama pages, then all pages will be parsed, loaded and rendered (measure, arrange, bind etc.) on all UI if you do not create a custom page/control virtualization. You could optimize this by only loading the first and +/- one page and when the user pans load adjacent panorama pages and controls.

The Pivot control is using virtualization by default. 3 pages are loaded and kept in memory, current, previous and next pivot page.

One way is to set page visibility as Collapsed until they are needed (this means that they will not even be in the visual tree). But remember that even if you set visibility as Collapsed calculations and processing will still happen before they are eventually hidden from UI. A better approach is to remove XAML and manually add it when needed.

5. A somewhat strange but pretty cool solution is to take a screen shot of the app where you have hidden all dynamic data and then use that as a “second splash screen” while the app warms up loading data etc. and then do a nice fade from “splash screen” to the actual app with live data. In this way we are tricking the user to think that the app starts really quickly, loads some data and shows it. But be aware, this solution could give the wrong feedback to the user since the users cannot interact with the app directly if not done correctly.


When we now have followed all the advices above and the app starts really quickly we often hit the next common performance issue and that is with lists. It often feels like lists are not scrolling fast enough and are a bit jerky, they simply doesn’t perform good enough.

The problem is probably not that the lists doesn’t scroll fast enough, more common is that the phone doesn’t have time to render the UI while you are scrolling quickly.

Long lists are using virtualization by default, which means that SL will keep 3 full “pages” of elements in UI and memory and while we are scrolling new “pages” will be loaded as needed, which means parsing XAML, generating new objects, inserting these into the visual tree, layout calculations, measure, arrange, bind and so on. So there is a lot that needs to be done and if SL doesn’t have time to process this then, bam, you get black “pages” that show up and it feels like the list doesn’t scroll fast enough.

So what should we and can we do to optimize lists?

1. If the list is short, less that 3 full pages, then you should try to use a regular stack panel instead of a virtualizing stack panel (easily accomplished with templates). Using a stack panel all objects will be loaded immediately and you get a perfect scrolling experience.

2. Try to delay loading and processing while you are scrolling, you might end up with scrolling past objects that you will not even see in the end and then it is useless to loaded and process these objects. For example, if you have a list of images that are downloaded from Internet and when you scroll past a lot of images quickly then you do not need to load the images since the user will not even seem them when he/she stops scrolling. Listening to the scroll event is trivial and easy to implement.

3. Another problem is XAML itself. Windows Phone will not cache Data Templates and Control Templates after they are parsed, so by making simpler XAML and binding to less properties you will increase performance. Make sure you do not set properties in XAML that are default values, since that only adds more processing and try to avoid having objects as Collapsed that you don’t even need, they will add processing and eventually a performance hit.

4. Try to avoid value converters in data bindings. Data binding is a low-level operation and if you need to call external code to calculate values then you will have to pay for that. Instead use a ViewModel approach and add convenience properties that gives you the value directly. It is often really easy and possible to add more properties to your ViewModels to contain all the values your UI needs to show, and in the end not use value converters in lists at all.

5. If you still need really advanced XAML and perhaps different XAML for different items in the list then there are some more advanced techniques to use.

A ListBox will by default recycle containers, which is good, we want that to keep our memory footprint low, but there are scenarios where Data Templates becomes really advanced and you might end up with several visuals that are Collapsed or a very complex UI. Again, this means a lot of parsing, object creating etc. that in the en will be hidden for the user. A common solution I usually try to follow is to create one simple base data template that only contains the parts that always will be visible on all items in the list and then manually in code behind decide what XAML should be in the item and manually add them to the visual tree.

The process is fairly simple:

a) start with a “dummy control” with a Control Template that shows elements that are always visible for all list items.

b) create an Attached Property for the control.

c) set the value for the attached property using regular data binding and in the implementation of the attached property and “Property Changed” event handler you generate/create the UI elements needed for the specific item and manually add them to the visual tree.

6. Use third party list controls. There are several developers that has tried to tackle the performance issues with lists, some are good some are not so good, they all seem to have good and bad “features”.

a) DeferredLoadListBox, by David Anson. This list uses a regular stack panel and delays loading of controls. But there is an issue with this control (unless that is fixed in later version then I have tested) and that is that items are not unloaded when they are not used/visible which means that if you have a really long list and scroll a lot, you will hit a memory problem.

b) LongListSelector is an ItemsControl in Silverlight Toolkit that virtualizes the list without using a VirtualizingStackPanel, you can even tweak some parameters like how many pages to keep in memory and how fast it should scroll.

c) LowProfileImageLoader is another awesome control by David Anson and this class helps us with preventing that we load images on the UI thread. This one I have used a lot and think it is a really great asset.

d) LazyListBox by Peter Torr, it basically delays work until we are not scrolling.

So try them out and pick one that suits your needs.


Problems that usually occur is that the UI doesn’t really feel like it responds to user interaction, it might be hard to pan in a panorama or change pivot, you might have to try several times before anything happens. These are really common in several apps I have used and is extremely frustrating every time.

Issues like this most likely is due to that the UI thread has to much to do, remember that the UI threads is responsible of handling touch, parsing and creating objects, rendering/rastering visuals, processing per-frame callbacks etc. so the UI thread has a lot to do as it is, and if we start to do to much work on it our app will have to pay for it. But it can also happen if we do to much work in background threads which also might result in UI thread gets to little time to process.

So what can we and should we do?

1. Simply stop processing to much work on the UI thread, make sure you move any heavy work to a background thread. If you still have issues since the work is to heavy anyway, then you can add artificial sleeps to give the UI thread some slack. Simply add a 1 ms second sleep, Thread.Sleep(1); , and the UI thread will perform a lot better. A 1 ms sleep is something that the users will most likely not see or know about.

2. Use PerformanceProgressBar or ProgressIndicator

3. Try not to use color animations since these will be executed on the UI thread. You can often accomplish the same effect by animating the opacity, but remember that animations with OpacityMasks will be executed on the UI thread so try to avoid using opacity masks on objects that are animated often. I’m not implying that you should never use opacity masks, but you need to think about the consequences. If you need an opacity mask then there is a simple trick that you can use. Place the object in a Canvas and set the CacheMode to BitmapCache and then animate the container instead of the object itself.

4. Use RectangularGeometry for clipping paths on objects that are animated or drawn often, all other types of paths will be sent to the UI thread for processing.

5. Popup is also rendered on the UI thread, might want to change this to a simple Panel where you set z-index and toggle it’s visibility instead, you will get a lot better performance and even support for orientation change in your app.

As I wrote in my previous post about the importance of UX, the perception of how the user thinks your app performs is key. UX is King! So all the “dirty tricks” your can think of are valid, as long as the users gets the impression that your app is performing really well, then all tricks are valid. So be creative and think about how can we trick the user into believing that your app is super fast.

Background Agents

You have the possibility to schedule one Background Agent per application which is executed while your app doesn’t have focus. Each background agent can execute one or both of the following:

Periodic Task – is executed approximately each 30 min or so and is allowed to execute for 25 seconds, use less than 6MB of memory and is automatically un-scheduled if it has more that two adjacent crashes.

Resource Intensive Task – executed if the phone is charging, has WiFi or USB pass through (connected to the computer), the screen is locked and the battery is over 90% charged. So this will most likely occur for example while you are charging your phone during night. A resource intensive task is allowed to execute for approx. 10 minutes and use a maximum of 6MB of memory.

In any of the tasks you can do/access the following

  • Titles
  • Toast
  • Location
  • Network
  • R/W ISO Store
  • Sockets
  • Most of the framework API

The following is not allowed

  • Display any UI
  • Use XNA
  • Access the microphone or camera
  • Sensors
  • Play media (only use background audio API)

I usually ask myself, do I really need a background agent?

If you do, then make sure you do not have any important functionality in them since there are several ways to disable them or prevent them from even being executed:

  • to many are already running, you cannot schedule any more
  • not available at all on 256MB devices
  • prevented by the user in settings
  • battery is to low


You should think about background agents like Batman and Robin, Batman does all the important stuff (your app) while Robin is there once now and then and helps out doing some really simple stuff (your background agent), but Batman is so awesome so he can always handle everything himself, not dependent on Robin at all. You should implement your app the same way, they have to function to a 100% without background agents. I usually try to avoid using background agents in the first place since there are so many cases that could prevent them from being executed in the first place and instead invest in a Push Notification solution.

Location in background agents

if you need to get hold of the geo location in a background task then you might end up not getting them in time. Since a periodic task only has a few seconds to execute them you might not have time to start the GeoCoordinationWatcher to get the exact position. What you can do is to create a GeoCoordinationWatcher object and them immediately get the location, you will then get a cached position that the phone caches for you automatically around each 15 minute or so. Not accurate but might be good enough.

ISO store is available for background agents and is the same used as for the app, so you can easily share information between the app and your background agent. Although there are cases where the agent may try to access the same file in isolated storage at the same time as your app. If you start to or could encounter these types of issues then you should use a Mutex.

Debug background agents using

ScheduleActionService.LaunchForTest(“task name”, TimeSpan);

In that way we can schedule our task to execute each minute or some other timespan that is suitable for testing instead of waiting for 30 minutes. If you start your app debugging and exit the app by pressing the hardware Start button then Visual Studio will not stop debugging so you can easily place break points in your OnInvoke method to debug your task.


Re-Schedule often, each time you start your app since a scheduled agent will be removed after 2 weeks by the phones OS.

Do NOT implement critical functionality in a background agents since it is not sure that your agent will even execute.

if you need a more secure functionality to execute some code now and then to update Tiles or show Toast notifications then evaluate if you cannot use Push Notifications

Well that’s it for now regarding Performance Best Practices for Silverlight Windows Phone apps. There is so much to think about when it comes to performance optimizations, but this post might have given you something to think about and at least gotten your attention on how important it is and that you should always think about it while developing apps for The phone.

Happy Coding!


Modern UI – UX is King!

That user experience (UX) and usability of apps is important is probably nothing new to most of us, hopefully. More and more focus is put on a great design and user experience when it comes to app development. So why is UX so important and how can we improve our performance and user experience in our applications?

So isn’t it enough just to develop an app that solves all the users needs?


Well it might, although users are becoming more and more aware of design, usability and structure in app usage, especially when it comes to consumer apps. Although the same goes for business apps, the requirement for a perfect UX is not as high as it is for a consumer app, that is at least my experience.

We are often experts in using new technologies and platforms but not so good at design. Many businesses invest in branding their application to add their flavor and feel to it, but too often without having a meaningful user experience. We are adding design for the sake of designing, and not thinking about what the users really need, how they feel, thinks or acts when using your application.

At my current company we use a tagline, “Useful, usable and beautiful”.


First of all the app needs to be useful, it needs to integrate business-value and user-value successfully into the experience. Don’t add functionality just because you can, you should have a good reason why you add it. To much functionality (if not designed properly) will drive the app to be un-useful.


Make sure the app is usable with all the functionality that you have selected to have. Design an intuitive and logic interaction model specific for the user and device. The experience on a Windows Phone, with respect to screen size etc. is totally different than it is on a web site browsing on your PC.


Let’s face it, we all enjoy using a beautiful application. But making the app beautiful means that you need to bridge an emotional connection between the user and brands via digital channels.

Most of us who develop apps for Windows Phone know about Modern UI (a.k.a. Metro) design (if not you should definitely read about it, perhaps these articles at MSDN is a good start) and follow it pretty good, at least I see more and more apps where the designers have really thought about Modern UI design. We have a good understanding of what frameworks to use to make the app development rapid and good. Although an app that doesn’t look good and have a good user experience will probably not get good feedback and reviews no matter how useful the app is, while an app with limited functionality that looks extremely good and is easy to use, will get top reviews and feedback.

This phenomena is due to that users are really aware of what is beautiful and what is good user experience, even if the users have no clue of how to design or create an app that has all of that. It’s something conscious. But if the performance in your app is bad, it takes time to start, you don’t have enough feedback to the user when something is happening, it’s jerky and doesn’t always seem to respond to user interaction, in these cases it doesn’t matter how cool or good looking your app is, it will still get bad reviews and eventually not be used at all.

The emotion/feeling of how well your app performs is key, Remember UX is King! If you can trick the user into believing that your app performs well, then do it!

My next post will be about some performance best practices I follow when implementing Silverlight apps for Windows Phone.

Happy coding!

Windows Phone – Reactive Extensions (Rx)

In my previous post I talked about how important it is to use page transitions and animations in your application to increase the overall user experience. Wouldn’t it be nice if we could extend this experience a bit, and take it to the next level of user feedback and interaction.

Fortunately there is a framework called Reactive Extensions (Rx) that enables us to do all kinds of super cool stuff in our applications.

This post will show how easy it is to use the Reactive Extensions framework to increase the user experience when loading data from services and showing it to the user in a more elegant way.

Reactive Extensions (Rx)

First of all, Reactive Extensions is a library to compose asynchronous and event-based programs using observable collections and LINQ-style query operators. You can start learning about Rx at MSDN if this is new to you:

In the sample project that I’m going to build, I will simulate a call to a web service to fetch data, and when data is returned I will populate a ListBox with the data. The items will be added one by one to the list with a nice subtle animations to give feedback to the user that items are being added to the list. I will simulate fetching from different services and add them result items to the list as soon as they arrive.

1. Create the Phone project

You start by creating a Windows Phone 7.1 project using the “Windows Phone Databound Application” template.

This will give you all the needed UI automatically, we will just refactor it and change so that it uses loading animations and Reactive Extensions when displaying the items to the user.

2. Change the UI

Now let’s change the Item Template for the ListBox so that each row has a solid background color (will be easier to see the animation) and finally add an animation/storyboard that is executed when a row is loaded (using event trigger).

The final ItemTemplate:

        <Grid x:Name="TileGrid">
                <EventTrigger RoutedEvent="Grid.Loaded">
                                Duration="0:0:0.5" To="0" />
                                Duration="0:0:0.5" To="1" />
            <StackPanel Margin="0,0,0,17" Width="432" Height="78" Background="{StaticResource PhoneAccentBrush}">
                <TextBlock Text="{Binding LineOne}" TextWrapping="Wrap" Style="{StaticResource PhoneTextExtraLargeStyle}"/>
                <TextBlock Text="{Binding LineTwo}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextSubtleStyle}"/>
                <PlaneProjection CenterOfRotationX="0" CenterOfRotationY="0"
                        RotationY="-90" />

If we run the application now, we already see an animation for the loaded event.

But all items are loaded at the same time. What if we wanted each row to be loaded one by one with a 200 millisecond delay? How would we do that?
One option is to use a background worker that has a 200 millisecond sleep in each loop that adds an item to the Items collection that is used as ItemsSource on the ListBox.
Let’s try that and see how it would look like and then later simplify the source code using Reactive Extensions.

3. Add item loaded delays
Start by refactoring the MainViewModel.cs LoadData() method to hold the sample data in a temporary list (so that we can use that list in our background worker to finally add them one by one to the Items collection)
Hint: to change the source code on multiple rows at the same time, you can hold down the Alt key while highlighting text in the editor to select parts of the text on multiple rows and then type on your keyboard to change the text on multiple rows at the same time. Realy nice feature :)

The final source code with BackgroundWorker:

    public void LoadData()
        // Temporary hold the items in memory
        ObservableCollection<ItemViewModel> items = new ObservableCollection<ItemViewModel>();

        // Sample data; replace with real data
        items.Add(new ItemViewModel() { LineOne = "runtime one", ... });
        items.Add(new ItemViewModel() { LineOne = "runtime two", ... });
        items.Add(new ItemViewModel() { LineOne = "runtime three", ... });
        items.Add(new ItemViewModel() { LineOne = "runtime sixteen", ... });

        this.IsDataLoaded = true;

        // Create background worker that adds all items to the Items collection with delays
        var worker = new BackgroundWorker();
        worker.DoWork += delegate(object sender, DoWorkEventArgs args)
            // Loop through all the items
            for (int i = 0; i < items.Count - 1; i++)
                // Create a slight delay and add each item to the Items collection
                    () =>
        worker.RunWorkerCompleted += delegate(object sender, RunWorkerCompletedEventArgs args)

If we run the application now we have a nice animation for each row when they are added to the Items collection

4. Add Reactive Extensions (Rx)
So the above use of background worker is working just fine, but can we simplify the source code using Rx?
First of all to use Rx you need to add the following references to the project

  • Microsoft.Phone.Reactive
  • System.Observable

and the following using statements

    using Microsoft.Phone.Reactive;
    using System.Linq;

Then finally remove the Background Worker code section and replace with the following code and also add the method AddItem

    public void LoadData()

    // Convert the result to an Observable sequence
        // Add selector method that selects each item with 200 ms delay
        .Zip(Observable.Interval(TimeSpan.FromMilliseconds(200)), (d, t) => d)
        // asyncrounously notify observers using the current dispatcher
        // subscribe a value handler to an observable sequence

    private void AddItem(ItemViewModel item)

If we run the application now we have the same result as expected. Although the source code is now a lot nicer, and we don’t have to worry about cross thread issues, index out of bound when looping through the items etc. This is just a really simple useage of Rx framework, but there is a lot more cool stuff you can do with it. Perhaps I’ll write a post later on a more complicated scenario.


You should always pay attention to performance on the phone when using animations and transitions. If we enable draw regions we can see that during loading the list box items are redrawn several times, although this is OK in this simple application but something to pay attention to.

    // Show the areas of the app that are being redrawn in each frame.
    Application.Current.Host.Settings.EnableRedrawRegions = true;

Happy Coding!

Windows Phone – Animations and Transitions

Microsoft is introducing a fresh approach on UI design and user experiences based on the Metro design language and principles. Even though you follow the Metro design guidelines you are according to me only half-way there to a perfect design and user experience. If you think about all the out of the box experiences on the phone you realize that they feel a lot more alive than most of the apps you download from the marketplace. How is that? The simple answer is user experience through transitions and animations. Animations and transitions on the Windows Phone platform are fundamental elements that are deeply rooted in the UI concept.

Animations and Transitions

Animations is probably one of the most important features of Windows Phone. Most developers and customers I have talked to in the past tend to see animations as something extra fancy that you don’t need in an application, especially not in a LOB (line of business) application. I would argue and say that they are as important in a LOB app as in any other app.

Animations and transitions extends the user experience by giving subtle feedback to the user on what is going on, what is happening and to what is about to happen. It increases the overall experience.

A lot of applications are really static, no specific feedback to the user for any actions they perform, transition between pages and so on. The apps would feel much more polished and alive if the designers would spend time on creating subtle proper animations and transitions.

The Silverlight toolkit makes page transitions and user feedback super easy to implement. But be careful, overdoing animations will only annoy the users and detract the user experience.

Let’s go through how simple it is to add page transitions to your application.

  • First of all you need to install the Windows Phone Toolkit
  • add a reference to Microsoft.Phone.Controls.Toolkit to your project
  • in App.xaml.cs locate the InitializePhoneApplication method and change the RootFrame from a regular PhoneApplicationFrame to a TransitionFrame
        RootFrame = new Microsoft.Phone.Controls.TransitionFrame();
  • you have now prepared your application to use any of the page transitions provided by the toolkit.
  • finally add a page transition to your page. Either add xaml code to each page (which eventually leads to a lot of copy-paste) or create a Style that you reference in each page.

Xaml in each page

Start by creating a name space to the Windows Phone Toolkit


add the following xaml to the page. This example uses the Turnstile transition. A good sample application that shows all the different page transitions is found at codeplex:

… >
                <toolkit:TurnstileTransition Mode="BackwardIn"/>
                <toolkit:TurnstileTransition Mode="ForwardIn"/>
                <toolkit:TurnstileTransition Mode="BackwardOut"/>
                <toolkit:TurnstileTransition Mode="ForwardOut"/>

Better approach with Styles

To make the transitions easier to maintain, and easier to switch between different page transitions when trying out your application, I would suggest you to create a style resource for each different page transition you want to use.

    <!--Application Resources-->
        <Style x:Key="TurnstilePage" TargetType="phone:PhoneApplicationPage">
            <Setter Property="toolkit:TransitionService.NavigationInTransition">
                            <toolkit:TurnstileTransition Mode="BackwardIn"/>
                            <toolkit:TurnstileTransition Mode="ForwardIn"/>
            <Setter Property="toolkit:TransitionService.NavigationOutTransition">
                            <toolkit:TurnstileTransition Mode="BackwardOut"/>
                            <toolkit:TurnstileTransition Mode="ForwardOut"/>

Then in each page where you want to use a page transition (note that we could omit x:Key to make this an implicit style and default for all pages) you simply reference the wanted page style in the following way

<phone:PhoneApplicationPage Style="{StaticResource TurnstilePage}" ... >

Enhance user actions with visual feedback

It’s also a good practice to add feedback to the user when he or she presses a button or selects an item in a list that performs an action. This can easily be done by using the Tilt Effect.


Adding page transitions to your app is really simple and increases the user experience a lot, but as noted before, be careful, overdoing animations and transitions will make your app annoying and potentially get really bad ratings.

Happy Coding!

Windows Phone Mango – Tombstoning and life cycle

Before Mango the Windows Phone application could be in four states, Running, Deactivate, Tombstoned and Activate. In Mango there is a new state called Dormant. This extra state is there to provide us with fast app switching. It is important for the developer to understand the Windows Phone application life cycle and to understand what actions the developer needs to take at each state and event to provide an application that is responsive and provides a consistent experience.

The following overview explains the life cycle of Windows Phone applications and all the actions the developer should take and be aware of.

Windows Phone Life Cycle - Image taken from MSDN

Continue reading

Localization in WP7

I just wrote a blog on how I localized a WPF application in a nice way. You can read that post here: Localization in WPF

What about Windows Phone , how to do localization for Windows Phone? Microsoft has some great articles about localization for Windows Phone. You can read them here: Globalization and Localization for Windows Phone. They give you some good best practices and also one way of doing localization, although I would like to do localization in a similar way as I did for WPF, and lucky me you can do that! :)

Let’s go through step-by-step how I did it.

Continue reading

WP7 and using hardware search from IE

Kudos to my friend Kristofer who just hinted me about a nice feature that I didn’t know of.

  1. Browse to a page in IE
  2. Tap on any word to mark/highlight the word
  3. Hit the Hardware Search button on the phone

You will now search for the highlighted word(s) using Bing. It’s all these tiny features that makes the WP7 phone so cool. Although have no idea if this is something that only works with the NoDo update or not since I didn’t try this before the update.

%d bloggers like this: