(For more resources related to this topic, see here.)
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.
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!
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.
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.
Button |
|
CheckBox |
|
HyperlinkButton |
|
Image |
|
ListBox |
|
MediaElement |
|
Panorama |
|
Pivot |
|
ProgressBar |
|
RadioButton |
|
ScrollViewer |
|
Slider |
|
TextBlock |
|
TextBox |
|
LongListSelector |
|
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.
An example of each of the these fonts is as follows:
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:
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.
There are three available tile templates that will help us to create tiles as follows:
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;
set
{
name = value;
RaisePropertyChanged();
}
}
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
{
get
{
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.
<UserControl.DataContext>
<models:UserViewModel/>
</UserControl.DataContext>
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()
{
InitializeComponent();
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.
<StackPanel>
<TextBlock Text="Name"></TextBlock>
<TextBox Name="txtName" Text="{
Binding CurrentUser.Name, Mode=TwoWay }">
</TextBox>
<TextBlock Text="Lastname"></TextBlock>
<TextBox Name="txtLastName" Text="{
Binding CurrentUser.LastName , Mode=TwoWay}">
</TextBox>
<TextBlock Text="Gender"></TextBlock>
<ListBox Name="lstGender" ItemsSource="{
Binding ListOfPossibleGenders}"
SelectedItem="{Binding CurrentUser.Gender, Mode=TwoWay}">
</ListBox>
</StackPanel>
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.