Windows Phone 8: Principles for UI/UX and Bindings

12 min read

(For more resources related to this topic, see here.)

Principles for UI/UX

There are many dos and don’ts in Windows Phone UI development. It is good to remember that we have a screen with a limited size where the elements should be placed comfortably.

Fast and fluid

This is the main goal of Windows Phone UX. Starting with the phone menu, we can switch between tiles and application lists; if we touch an element action it is performed very fast. We have to remember while creating our own software about providing responsivity to user interaction, even if we need to load some data or connect to a server, the user has to be informed about loading. Going through our application, the user should feel that he or she controls and can touch every element. Many controls provide animation out of the box and we need to use it; we need to impress our users while seeing motion in our application. The application has to be alive!

Grid system

The following design pattern provides consistency and high UX to Windows Phone users. It helps in organizing the application elements. A grid system will provide unity across applications and will make our application look similar to the Windows Store application. Talking about the grid layout, we mean arranging the content using grid lines.

As we can see, the grid is where the application design starts. Each square is located 12 pixels from the other square. Single square has 25 x 25 pixels. In order to provide the best user experience to our application, we need to ensure that the elements are arranged appropriately. Looking at the left-hand side of the image, we find that each big tile contains 6 x 6 squares with 12 pixels margins.

Windows is one

When using a grid system and other design patterns for Windows Phone, porting to Windows Store will be possible and can be done more easily. Unfortunately at the moment, there are no common markets for Windows Phone application and Windows Store (applications for Windows 8 and Windows RT). The current solution is to create the application in a way that it allows portability to other platforms, such as separating the application’s logic from UI. Even then some specific changes have to be done.

Controls design best practices


  • Use a maximum of two words in the Button content; it can be dynamically set but should never be more than two words
  • To define content use system font
  • Use a minimum height of 40 pixels


  • A CheckBox text should present a clear choice to the user
  • If there are many choices, use the ScrollViewer and StackPanel control
  • It is recommended to use single or a maximum of two lines of content text
  • If the meaning of checkbox is not clear, use RadioButton or ListBox


  • Don’t place two hyperlinks close to each other because it will make it difficult to select either one
  • Hyperlink text should not be longer than two words
  • If some action can be reached by taping in text content, use HyperlinkButton instead of Button


  • Size (resolution) of the picture has to be really close or identical to the Image control size
  • Use gestures if it is possible
  • The Image controls displays JPEG or PNG images
  • Provide good quality images-non pixelated


  • Use ListBox with long list of items; for smaller lists use RadioButton
  • ListBox should be responsive so that it provides an immediate visual reaction for the user action
  • Use at least 12 pixels height with sans-serif font


  • Do not show too many controls on one page
  • Do not allow for a situation when more than one media (audio or video) is playing simultaneously


  • The Panorama control handles only portrait orientation
  • If you are using ApplicationBar with Panorama, make sure that the ApplicationBar control is in minimized mode
  • Do not use too many sections (PanoramaItems); use a maximum of 5 sections to avoid torturing the user with swiping
  • Panorama title can contain image and/or text
  • Use system font; an exception is when your brand uses custom font
  • First PanoramaItem should contain a left-aligned title
  • For section title use plain text
  • Do not use Pivot in PanoramaItem and Panorama in PivotItem
  • Horizontal scrolling can be difficult because of the default behavior of Panorama; use vertical scrolling instead
  • Good quality background photography makes for a very good users’ impression, but ensure that all content is readable

  • Background should be low contrast and dark

  • Background image can be maximally 1024 x 800 pixels and minimally 480 x 800 pixels to provide good performance


  • Do not place Pivot in PanoramaItem

  • Use a maximum of 4 Pivot items

  • Each PivotItem should not contain completely different actions; their functionality should be related

  • Do not use input controls because it disrupts the Pivot flick, if you want to create a form with editing controls, use a separate page that will contain the form

  •  Do not use controls that need swipe or scroll inside Panorama like Map, ToggleButton, or Slider because the Pivot default gesture handling it, can make it difficult for the user to use them


  • It is highly recommended to use a label that describes the state of the ProgressBar control-loading, launching, and failed


  • Avoid customization

  • Provide 2 short words as content text, with at least 12 pixels height maximally

  • Use ListBox if this control has more than 10 decisions to make

  • Bring user’s attention to the selected RadioButton control by making inactive those that are not selected


  • Avoid creating a situation where a user has too much content to scroll


  • Make sure that the Slider control is the appropriate size for comfortable use

  • Do not use Slider as a progress indicator

  • Do not put Slider too close to the edge of the screen because it can be difficult to select a value

  • It shouldn’t be used within Panorama or Pivot because Slider uses dragging gestures, whose usage is difficult in those containers


  • Make sure that the text in the TextBlock control looks clear and is readable


  • To improve the user’s experience, update the application content when the user enters text into TextBox; for example while filtering data

  • It is not possible to scroll rich text inputs

  • When it is likely that the user will enter a new value into TextBox, select all content on focus


  • LongListSelector is used for a large number of data items

  • Use at least 12 pixel Sans serif font


From the GUI and UX point of view, it is critical to make text clear and legible. Entire text should be properly contrasted to the background. The font used in Windows Phone, is Sans serif, which is widely used in web and mobile applications. The Sans serif font type has many fonts, which one should we use? There is no simple answer for that, it depends on the control and context in which we use the text. However, it is recommended to use Segoe UI, Calibri, or Cambria font types.

  • Segoe UI: This is best used in UI elements such as buttons, checkboxes, datepickers, and others like these.
  • Calibri: This is best used for input and content text such as e-mail messages. When using this font it is good to set the font size to 13.
  • Cambria: This font type is recommended for articles or any other big pieces of text, depending on content section, we can use 9, 11, 20 pt Cambria font.

An example of each of the these fonts is as follows:

  • 11 pt Segoe UI font
  • 13 pt Calibri font
  • 11 pt Cambria font

Tiles and notifications

My friend who is the owner of a company that creates mobile applications, once said to me that 50% of an application’s success depends on how nice and good looking the icon/tile is. After thinking about it, I imagine he was right. The tile is the first thing that a user sees when starting to use our application (remember what I said about first impression?). The Windows Phone tile is not only a static icon that represents our application, but it can be live and show some simplified content as well. A default tile is a static icon and can display some information such as message count after it updates, and it returns to the default tile only after another update.

An application tile can be pinned to the Start screen and set in one of 3 sizes:

  1. A small tile is built from 3 x 3 grid units. It is half the width and height of medium tile. It was introduced in Windows Phone 8 and 7.8 update of Windows Phone 7.

  2. Only a medium-size tile was available in Windows Phone 7. Every application pinned to the Start screen starts with medium tile.

  3. Along with the small tile, a large tile was introduced in Windows Phone 8.

Why we should use the tile that is updating (live tile)? Because the tile is the front door of our application and if it gives some notification to user it really says, “Hey! Come here and see what I’ve got for you!”. An updated tile assures the users that our application is fresh and active, even if it has not been run for some time.

  • If we want to allow the user to pin our application in large/wide tile, we should provide a wide image, point it in the application manifest, and mark the Supports wide size option. There are some good practices which are worth following.
  • If our application has the content that is refreshed at least once every few days and can be interesting for the user, we should enable our application to use wide tile; if not it is not necessary.
  • Forget about the wide tile if the application doesn’t use notifications.

There are three available tile templates that will help us to create tiles as follows:

  1. Iconic template which is mainly used for e-mails, messaging, RSS, and social networking apps.
  2. Flip templates that are used in an application gives the user a lot of information like weather application.
  3. Cycle template for galleries and photo applications that cycles 1 to 9 images in a tile—applicable only for medium and wide tile.


Basically, binding is a mechanism that the whole MVVM pattern relays on. It is very powerful and is the “glue” between the view and the exposed fields and commands.

The functionality that we want to implement is shown in the following diagram:


We are going to use the Model class for storing data about users.

public class UserModel:INotifyPropertyChanged
private string name {get;set;
public string Name { get;
name = value;
public string LastName { get; set{(…)} }
public string Gender { get; set{(…)} }
public DateTime DateOfBirth { get; set{(…)} }
public event PropertyChangedEventHandler PropertyChanged;

One thing that we still have to implement is the property changed event subscription for all fields within this UserModel class.


Now, UserModel will be wrapped into UserViewModel. Our ViewModel will also implement the INotifyPropertyChanged interface for updating View when the VieModels object change.

public class UserViewModel:INotifyPropertyChanged
public UserModel CurrentUser { get; set; }
public string FullName
if (this.CurrentUser != null)
return string.Format("{0} {1}",
this.CurrentUser.Name, this.CurrentUser.LastName);
return "";
public List<string> ListOfPossibleGenders
= new List<string>(){"Male","Female"};

As we can see, UserModel is wrapped in two ways: the first is wrapping the entire Model and some properties that are transformed into FullName. The FullName property contains Name and LastName that comes from UserModel object.


I’m going to create a view, piece by piece, to show how things should be done. At the beginning, we should create a new UserControl object called UserView in the Views folder. We will do almost everything now in XAML; so, we have to open the UserView.xaml file and add a few things.

In the root node, we have to add namespace for our ViewModel folder.

Because of this line, our ViewModels will be accessible in the XAML code.


It sets DataContext of our view in XAML and has its equivalent in DataContext. If we wish to set DataContext in the code behind, we have to go to the constructor in the .cs file.

public UserView()
var viewModel = new SampleViewModel();
this.DataContext = viewModel;

A better approach is to define the ViewModel instance in XAML because we have intellisense support in binding expressions for fields that are public in ViewModel and the exposed model.

As we can see, ViewModel contains the CurrentUser property that will store and expose the user data to the view. It has to be public, and thing that is missing here is the change notification in the CurrentUser setter. However, we already know how to do that so it is not described.

<TextBlock Text="Name"></TextBlock>
<TextBox Name="txtName" Text="{
Binding CurrentUser.Name, Mode=TwoWay }">
<TextBlock Text="Lastname"></TextBlock>
<TextBox Name="txtLastName" Text="{
Binding CurrentUser.LastName , Mode=TwoWay}">
<TextBlock Text="Gender"></TextBlock>
<ListBox Name="lstGender" ItemsSource="{
Binding ListOfPossibleGenders}"
SelectedItem="{Binding CurrentUser.Gender, Mode=TwoWay}">

The preceding example shows how to set binding using the exposed model as well as list or property that was implemented directly in ViewModel. We made all these things without any code behind line! This is really good because our sample is testable and is very easy to write unit tests We use the TwoWay binding mode that automatically populates the control value and then the edit control value of the ViewModel property also gets updated.


Creating complex applications that will be intuitive and simple to use is really hard without the knowledge of the UI and UX principles that were described in this article. We covered a huge part of XAML— bindings.

Resources for Article :

Further resources on this subject:


Please enter your comment!
Please enter your name here