User Experience Design Process

User Experience becomes a Key Success Factor

In the past, we focused mainly on building products that fulfilled the functional requirements of the user. User experience was often considered late in the development process. But today the customer demands more than just a working product. Providing the right features is still the prerequisite for a good product, but to turn it into something extraordinary you need to provide a good user experience!

Providing a rich user experience is not a thing of fortune. It needs to be planed, designed and integrated into the development of a product. Designing a rich user experience is not only about make up your user interface by some graphics and gradients - its a much broader concept. Its about creating an emotional connection between the user and your software. It makes the user feel good and so he likes to continue using the software.

New Tools for Designers

Microsoft recognized, give development teams the power to create rich user experiences it needs a lot more graphical tool support than VisualStudio can provide today. So they decided to create a new tool suite - made for designers.

This tool suite is called Microsoft Expression. It consists of the four products:

• Expression Blend is built to create user interfaces in WPF and Silverlight. It builds the bridge between designer and developers. It can open VisualStudio solutions
• Expression Design is a leightweight version of Adobe Illustrator to create and edit vector graphics.
• Expression Media is built to encode, cut and enrich video files and optimize them for silverlight streaming
• Expression Web is Microsoft next generation of HTML and Javascript editor. Its the replacement for Frontpage.

Together they are a powerful package. The following illustration shows a sample workflow of integrating a vector image that is created by a graphics designer in Adobe Illustrator into a WPF project that is part of a VisualStudio solution.

Development Workflow of a WPF Project

Developing a WPF application with a rich user experience requires a lot more skills than just a requirements analyst that defines a list of use cases and developer that implements the software. You have to find out what the user really needs. This can be done by following a user centered approach.

1. Elicit Requirements

Like in any kind of software projects its important to know and focus the target of your development. You should talk to stakeholders and users to find out the real needs. These needs should be refined to features and expressed in use cases (abstract) or user scenarios (illustrative). Priorize the tasks by risk and importance and work iteratively. This work is done by the role of the requirements engineer.

2. Create and Validate UI Prototype

Creating a user interface prototype is an important step to share ideas between users and engineers to create a common understanding of the interaction design. This task is typically done by an interaction designer. It's helpful to only sketch the user interface in a rough way to prevent early discussions about design details. There are multiple techniques and tools to do this. Some of them are:

• Paper prototype
  Use paper and pencil to draw rough sketches of your user interface. No tools and infrastructure is needed. Everyone can just scribble thier ideas on the paper.
• Wireframes
  Wireframes are often used to sketch the layout of a page. It's called wireframes because you just draw the outlines of controls and images. This can be done with tools like PowerPoint or Visio
• Expression Blend 3 - Sketch Flow Sketch flow is a new cool feature to create interactive prototypes directly in WPF. You can use the integrated "wiggly style" to make it look sketchy. The prototype can be run in a standalone player that has an integrated feedback mechanism.
• Interactive Prototype The most expensive and real approach is to create an (reusable) interactive prototype that works as the real application but with dummy data.

It is strongly recommended to test your UI prototype on real users. This helps you to find out and address design problems early in the development process. The following techniques are very popular to evaluate UI prototypes:

• Walktrough
  A walktrough is usually done early in a project with wireframes or paper prototypes. The user gets a task to solve and he controlls the prototype by touching on the paper. The test leader than presents a new paper showing the state after the interaction.
• Usability Lab
  To do a usability lab, you need a computer with a screen capture software and a camera. The proband gets an task to do and the requirements and interaction engineer watch him doing this. They should not talk to him to find out where he gets stuck and why.

3. Implement Business Logic and Raw User Interface

4. Integrate Graphical Design

5. Test software

Roles

Buliding a modern user interface with a rich user experience requires additional skills from your development team. These skills are described as roles that can be distributed among peoples in your development team.

• Developer
  The developer is responsible to implement the functionality of the application. He creates the data model, implements the business logic and wires all up to a simple view.
• Graphical Designer
  The graphical designer is responsible to create a graphical concept and build graphical assets like icons,logos, 3D models or color schemes. If the graphical designer is familiar with Microsoft Expression tools he directly creates styles and control templates.
• Interaction Designer
  The interaction designer is responsible for the content and the flow of a user interface. He creates wireframes or UI sketches to share its ideas with the team or customer. He should validate his work by doing walktroughs or storyboards.
• Integrator
  The integrator is the artist between the designer and the developer world. He takes the assets of the graphical designer and integrates them into the raw user interface of the developer. This role needs a rare set of skills and so it's often hard to find the right person for it.

WPF Troubleshooting

During my time as a consultant I noticed, that there were typical traps in WPF, where developers can loose a lot of time. So I decided to make a hitlist of the most common mistakes and solutions how to resolve them. I hope this helps.

Layout

• Scrollbar is not active or visible
  
  • If your control is within a vertical stackpanel, it gives the control infinite height to layout. Consider replacing the stackpanel by a dockpanel.
• I created a data template and set HorizontalAlignment to Stretch but the item is not stretched
  • Set the HorizontalContentAlignment on the list to Stretch

DataBinding

• I changed a value, but the binding is not reflecting my changes
  • Check the output window in VisualStudio, if there are any binding errors.
  • Does your data support INotifyPropertyChanged?
  • Just firing a PropertyChanged event without changing the data does not work. Because the binding checks if oldvalue!=newvalue

Performance

• My list of items takes too long to render
  
  • Your list is not virtualized. This means, all items will be generated, even if they are not visible. To avoid this check the following points:
    • ScrollViewer.CanContentScrol must be set to False
    • Grouping must be disabled
    • You replaced the ItemsPanel by one that does not support virtualization
  • You are using a too complex data template.
• Animations cause a high CPU load.
  
  • WPF cannot use hardware acceleration and does software rendering. This can be because of the following points:
    • You have set AllowTransparency to True on your window.
    • You are using legacy BitmapEffects instead of fast pixel shaders (Effects).
    • Your graphics adapter or driver does not support DirectX

Custom Controls

• I created a custom control, but the template it not showing
  
  • Check if you have overriden the metadata of the DefaultStyleKeyProperty and set it to your type.
  • Check if your template is surrounded by a style and both have the right TargetType
  • Check if the resource dictionary that contains the default style is loaded
• I use {TemplateBinding} in my ControlTemplate, but is not working
  
  • In most cases you have to replace {TemplateBinding Property} by {Binding Property RelativeSource={RelativeSource TemplatedParent}}
  • You can only use TemplateBinding within the content of your control template. It will not work anywhere else!
  • If you want to access a parent property in the trigger, you have to use a normal binding, with relative source Self.
  • TemplateBinding works only within the VisualTree of the template. You cannot use it on items that are only in the logical tree. Neighter on Freezables or to do two-way binding.

Minimal Hardware and Software Requirements for WPF

Software Requirements

To run WPF on your machine you need to have at least the following software installed:

• Windows XP with Service Pack 2 or higher
• .NET Framework 3.0 or higher

Hardware requirements

There are no minimum hardware requirements for WPF. All the requirements comes from the complexity and effects used in your application.

You can take advantage of hardware acceleration when your graphics processor supports DirectX 9 or higher. I would recommend to look for a graphicadapter for which the vendor supports a WDDM driver.

Please note that some effects cannot be done in hardware rendering under Windows XP. For exmaple Windows withAllowsTransparency set to True and the use of BitmapEffects.

How to specify minimal hardware requirements

A simple way to specify minimal hardware requirements to ensure that your client has a good experience is the Premium Ready label from Microsoft. It ensures that the machine has at least the following equipment:

• > 800MHz Prozessor
• 512 MBytes RAM
• A DirectX 9 capable graphics adapter

Logical- and Visual Tree

Introduction

Elements of a WPF user interface are hierarchically related. This relation is called the LogicalTree. The template of one element consists of multiple visual elements. This tree is called the VisualTree. WPF differs between those two trees, because for some problems you only need the logical elements and for other problems you want all elements.

 
<Window>
    <Grid>
        <Label Content="Label" />
        <Button Content="Button" />
    </Grid>
</Window>
 
 

Why do we need two different kind of trees?

A WPF control consists of multiple, more primitive controls. A button - for example - consists of a border, a rectangle and a content presenter. These controls are visual children of the button.
When WPF renders the button, the element itself has no appearance, but it iterates through the visual tree and renders the visual children of it. This hierarchical relation can also be used to do hit-testing, layout etc.
But sometimes you are not interested in the borders and rectangles of a controls' template. Particulary because the template can be replaced, and so you should not relate on the visual tree structure! Because of that you want a more robust tree that only contains the "real" controls - and not all the template parts. And that is the eligibility for the logical tree.

The Logical Tree

The logical tree describes the relations between elements of the user interface. The logical tree is responsible for:

• Inherit DependencyProperty values
• Resolving DynamicResources references
• Looking up element names for bindings
• Forwaring RoutedEvents

The Visual Tree

The visual tree contains all logical elements including all visual elements of the template of each element.
 The visual tree is responsible for:


Rendering visual elements


Propagate element opacity



Propagate Layout- and RenderTransforms




Propagate the IsEnabled property.

Do Hit-Testing

RelativeSource (FindAncestor)

Programmatically Find an Ancestor in the Visual Tree

If you are a child element of a user interface and you want to access data from a parent element, but you don't know how many levels up that elemens is, it's the best solution to navigate up the tree until it finds an element of the requested type.

This helper does excactly this. You can use almost the same code to navigate through the logical tree.

 
public static class VisualTreeHelperExtensions
{
    public static T FindAncestor<T>(DependencyObject dependencyObject)
        where T : class
    {
        DependencyObject target = dependencyObject;
        do
        {
            target = VisualTreeHelper.GetParent(target);
        }
        while (target != null && !(target is T));
        return target as T;
    }
}
 
 

The following example shows how to use the helper. It starts at this and navigates up the visual tree until it finds an element of type Grid. If the helper reaches the root element of the tree, it returns null.

 
var grid = VisualTreeHelperExtensions.FindAncestor<Grid>(this);
 

Routed Events

Routed events are events which navigate up or down the visual tree acording to their RoutingStrategy. The routing strategy can be bubble, tunnel or direct. You can hook up event handlers on the element that raises the event or also on other elements above or below it by using the attached event syntax: Button.Click="Button_Click".

Routed events normally appear as pair. The first is a tunneling event called PreviewMouseDown and the second is the bubbling called MouseDown. They don't stop routing if the reach an event handler. To stop routing then you have to sete.Handled = true;

• Tunneling The event is raised on the root element and navigates down to the visual tree until it reaches the source element or until the tunneling is stopped by marking the event as handeld. By naming convention it is calledPreview... and appears before corresponding bubbling event.
  
• Bubbling The event is raised on the source element and navigates up to the visual tree until it reaches the root element or until the bubbling is stopped by marking the event as handled. The bubbling event is raised after the tunneling event.
  
• Direct The event is raised on the source element and must be handled on the source element itself. This behavior is the same as normal .NET events.
  

How to Create a Custom Routed Event

 
 
// Register the routed event
public static readonly RoutedEvent SelectedEvent = 
    EventManager.RegisterRoutedEvent( "Selected", RoutingStrategy.Bubble, 
    typeof(RoutedEventHandler), typeof(MyCustomControl));
 
// .NET wrapper
public event RoutedEventHandler Selected
{
    add { AddHandler(SelectedEvent, value); } 
    remove { RemoveHandler(SelectedEvent, value); }
}
 
// Raise the routed event "selected"
RaiseEvent(new RoutedEventArgs(MyCustomControl.SelectedEvent));

Introduction to XAML

XAML stands for Extensible Application Markup Language. Its a simple language based on XML to create and initialize .NET objects with hierarchical relations. Altough it was originally invented for WPF it can by used to create any kind of object trees.

Today XAML is used to create user interfaces in WPF, Silverlight, declare workflows in WF and for electronic paper in the XPS standard.

All classes in WPF have parameterless constructors and make excessive usage of properties. That is done to make it perfectly fit for XML languages like XAML.

Advantages of XAML

All you can do in XAML can also be done in code. XAML ist just another way to create and initialize objects. You can use WPF without using XAML. It's up to you if you want to declare it in XAML or write it in code. Declare your UI in XAML has some advantages:

• XAML code is short and clear to read
• Separation of designer code and logic
• Graphical design tools like Expression Blend require XAML as source.
• The separation of XAML and UI logic allows it to clearly separate the roles of designer and developer.

XAML vs. Code

As an example we build a simple StackPanel with a textblock and a button in XAML and compare it to the same code in C#.

 
<StackPanel>
    <TextBlock Margin="20">Welcome to the World of XAML</TextBlock>
    <Button Margin="10" HorizontalAlignment="Right">OK</Button>
</StackPanel>
 
 

The same expressed in C# will look like this:

 
// Create the StackPanel
StackPanel stackPanel = new StackPanel();
this.Content = stackPanel;
 
// Create the TextBlock
TextBlock textBlock = new TextBlock();
textBlock.Margin = new Thickness(10);
textBlock.Text = "Welcome to the World of XAML";
stackPanel.Children.Add(textBlock);
 
// Create the Button
Button button = new Button();
button.Margin= new Thickness(20);
button.Content = "OK";
stackPanel.Children.Add(button);
 
 

As you can see is the XAML version much shorter and clearer to read. And that's the power of XAMLs expressiveness.

Properties as Elements

Properties are normally written inline as known from XML <Button Content="OK" />. But what if we want to put a more complex object as content like an image that has properties itself or maybe a whole grid panel? To do that we can use the property element syntax. This allows us to extract the property as an own child element.

 
<Button>
  <Button.Content>
     <Image Source="Images/OK.png" Width="50" Height="50" />
  </Button.Content>
</Button>
 
 

Implicit Type conversion

A very powerful construct of WPF are implicit type converters. They do their work silently in the background. When you declare a BorderBrush, the word "Blue" is only a string. The implicit BrushConverter makes a System.Windows.Media.Brushes.Blue out of it. The same regards to the border thickness that is beeing converted implicit into a Thickness object. WPF includes a lot of type converters for built-in classes, but you can also write type converters for your own classses.

 
<Border BorderBrush="Blue" BorderThickness="0,10">
</Border>
 
 

Markup Extensions

Markup extensions are dynamic placeholders for attribute values in XAML. They resolve the value of a property at runtime. Markup extensions are surrouded by curly braces (Example: Background="{StaticResource NormalBackgroundBrush}"). WPF has some built-in markup extensions, but you can write your own, by deriving from MarkupExtension. These are the built-in markup extensions:

• Binding
  To bind the values of two properties together.
• StaticResource
  One time lookup of a resource entry
• DynamicResource
  Auto updating lookup of a resource entry
• TemplateBinding
  To bind a property of a control template to a dependency property of the control
• x:Static
  Resolve the value of a static property.
• x:Null
  Return null

The first identifier within a pair of curly braces is the name of the extension. All preciding identifiers are named parameters in the form of Property=Value. The following example shows a label whose Content is bound to the Text of the textbox. When you type a text into the text box, the text property changes and the binding markup extension automatically updates the content of the label.

 
<TextBox x:Name="textBox"/>
<Label Content="{Binding Text, ElementName=textBox}"/>
 
 

Namespaces

At the beginning of every XAML file you need to include two namespaces.
The first is http://schemas.microsoft.com/winfx/2006/xaml/presentation. It is mapped to all wpf controls in System.Windows.Controls.
The second is http://schemas.microsoft.com/winfx/2006/xaml it is mapped to System.Windows.Markup that defines the XAML keywords.
The mapping between an XML namespace and a CLR namespace is done by the XmlnsDefinition attribute at assembly level. You can also directly include a CLR namespace in XAML by using the clr-namespace: prefix.

 
<Window xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation”
        xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”>
</Window>

Dependency Properties

troduction

Value resolution strategy

The magic behind it

How to create a DepdencyProperty

Readonly DependencyProperties

Attached DependencyProperties

Listen to dependency property changes

How to clear a local value

Introduction

When you begin to develop appliations with WPF, you will soon stumble across DependencyProperties. They look quite similar to normal .NET properties, but the concept behind is much more complex and powerful.

The main difference is, that the value of a normal .NET property is read directly from a private member in your class, whereas the value of a DependencyProperty is resolved dynamically when calling the GetValue() method that is inherited from DependencyObject.

When you set a value of a dependency property it is not stored in a field of your object, but in a dictionary of keys and values provided by the base class DependencyObject. The key of an entry is the name of the property and the value is the value you want to set.

The advantages of dependency properties are

• Reduced memory footprint
  It's a huge dissipation to store a field for each property when you think that over 90% of the properties of a UI control typically stay at its initial values. Dependency properties solve these problems by only store modified properties in the instance. The default values are stored once within the dependency property.
  
• Value inheritance
  When you access a dependency property the value is resolved by using a value resolution strategy. If no local value is set, the dependency property navigates up the logical tree until it finds a value. When you set the FontSize on the root element it applies to all textblocks below except you override the value.
  
• Change notification
  Dependency properties have a built-in change notification mechanism. By registering a callback in the property metadata you get notified, when the value of the property has been changed. This is also used by the databinding.
  

Value resolution strategy

Every time you access a dependency property, it internally resolves the value by following the precedence from high to low. It checks if a local value is available, if not if a custom style trigger is active,... and continues until it founds a value. At last the default value is always available.

The magic behind it

Each WPF control registers a set of DependencyProperties to the static DependencyProperty class. Each of them consists of a key - that must be unique per type - and a metadata that contain callbacks and a default value.

All types that want to use DependencyProperties must derive from DependencyObject. This baseclass defines a key, value dictionary that contains local values of dependency properties. The key of an entry is the key defined with the dependency property.
When you access a dependency property over its .NET property wrapper, it internally callsGetValue(DependencyProperty) to access the value. This method resolves the value by using a value resolution strategy that is explained in detail below. If a local value is available, it reads it directly from the dictionary. If no value is set if goes up the logical tree and searches for an inherited value. If no value is found it takes the default value defined in the property metadata. This sequence is a bit simplified, but it shows the main concept.

How to create a DependencyProperty

To create a DependencyProperty, add a static field of type DepdencyProperty to your type and callDependencyProperty.Register() to create an instance of a dependency property. The name of the DependendyProperty must always end with ...Property. This is a naming convention in WPF.

To make it accessable as a normal .NET property you need to add a property wrapper. This wrapper does nothing else than internally getting and setting the value by using the GetValue() and SetValue() Methods inherited from DependencyObject and passing the DependencyProperty as key.

Important: Do not add any logic to these properties, because they are only called when you set the property from code. If you set the property from XAML the SetValue() method is called directly.

If you are using Visual Studio, you can type propdp and hit 2x tab to create a dependency property.

 
// Dependency Property
public static readonly DependencyProperty CurrentTimeProperty = 
     DependencyProperty.Register( "CurrentTime", typeof(DateTime),
     typeof(MyClockControl), new FrameworkPropertyMetadata(DateTime.Now));
 
// .NET Property wrapper
public DateTime CurrentTime
{
    get { return (DateTime)GetValue(CurrentTimeProperty); }
    set { SetValue(CurrentTimeProperty, value); }
}
 
 

Each DependencyProperty provides callbacks for change notification, value coercion and validation. These callbacks are registered on the dependency property.

 
new FrameworkPropertyMetadata( DateTime.Now, 
                       OnCurrentTimePropertyChanged, 
                       OnCoerceCurrentTimeProperty ),
                       OnValidateCurrentTimeProperty );
 
 

Value Changed Callback

The change notification callback is a static method, that is called everytime when the value of the TimeProperty changes. The new value is passed in the EventArgs, the object on which the value changed is passed as the source.

 
private static void OnCurrentTimePropertyChanged(DependencyObject source, 
        DependencyPropertyChangedEventArgs e)
{
    MyClockControl control = source as MyClockControl;
    DateTime time = (DateTime)e.NewValue;
    // Put some update logic here...
}
 
 

Coerce Value Callback

The coerce callback allows you to adjust the value if its outside the boundaries without throwing an exception. A good example is a progress bar with a Value set below the Minimum or above the Maximum. In this case we can coerce the value within the allowed boundaries. In the following example we limit the time to be in the past.

 
private static object OnCoerceTimeProperty( DependencyObject sender, object data )
{
    if ((DateTime)data > DateTime.Now )
    {
        data = DateTime.Now;
    }
    return data;
}
 
 

Validation Callback

In the validate callback you check if the set value is valid. If you return false, an ArgumentException will be thrown. In our example demand, that the data is an instance of a DateTime.

 
private static bool OnValidateTimeProperty(object data)
{
    return data is DateTime;
}
 
 

Readonly DependencyProperties

Some dependency property of WPF controls are readonly. They are often used to report the state of a control, like theIsMouseOver property. Is does not make sense to provide a setter for this value.

Maybe you ask yourself, why not just use a normal .NET property? One important reason is that you cannot set triggers on normal .NET propeties.

Creating a read only property is similar to creating a regular DependencyProperty. Instead of callingDependencyProperty.Register() you call DependencyProperty.RegisterReadonly(). This returns you aDependencyPropertyKey. This key should be stored in a private or protected static readonly field of your class. The key gives you access to set the value from within your class and use it like a normal dependency property.

Second thing to do is registering a public dependency property that is assigned toDependencyPropertyKey.DependencyProperty. This property is the readonly property that can be accessed from external.

 
// Register the private key to set the value
private static readonly DependencyPropertyKey IsMouseOverPropertyKey = 
      DependencyProperty.RegisterReadOnly("IsMouseOver", 
      typeof(bool), typeof(MyClass), 
      new FrameworkPropertyMetadata(false));
 
// Register the public property to get the value
public static readonly DependencyProperty IsMouseoverProperty = 
      IsMouseOverPropertyKey.DependencyProperty;    
 
// .NET Property wrapper
public int IsMouseOver
{
   get { return (bool)GetValue(IsMouseoverProperty); }
   private set { SetValue(IsMouseOverPropertyKey, value); }
}
 
 

Attached Properties

Attached properties are a special kind of DependencyProperties. They allow you to attach a value to an object that does not know anything about this value.

A good example for this concept are layout panels. Each layout panel needs different data to align its child elements. The Canvas needs Top and Left, The DockPanel needs Dock, etc. Since you can write your own layout panel, the list is infinite. So you see, it's not possible to have all those properties on all WPF controls.

The solution are attached properties. They are defined by the control that needs the data from another control in a specific context. For example an element that is aligned by a parent layout panel.

To set the value of an attached property, add an attribute in XAML with a prefix of the element that provides the attached property. To set the the Canvas.Top and Canvas.Left property of a button aligned within a Canvas panel, you write it like this:

<Canvas>
    <Button Canvas.Top="20" Canvas.Left="20" Content="Click me!"/>
</Canvas>
 

 
public static readonly DependencyProperty TopProperty =
    DependencyProperty.RegisterAttached("Top", 
    typeof(double), typeof(Canvas),
    new FrameworkPropertyMetadata(0d,
        FrameworkPropertyMetadataOptions.Inherits));
 
public static void SetTop(UIElement element, double value)
{
    element.SetValue(TopProperty, value);
}
 
public static double GetTop(UIElement element)
{
    return (double)element.GetValue(TopProperty);
}
 
 

Listen to dependency property changes

If you want to listen to changes of a dependency property, you can subclass the type that defines the property and override the property metadata and pass an PropertyChangedCallback. But an much easier way is to get theDependencyPropertyDescriptor and hookup a callback by calling AddValueChanged()

 
DependencyPropertyDescriptor textDescr = DependencyPropertyDescriptor.
    FromProperty(TextBox.TextProperty, typeof(TextBox));
 
if (textDescr!= null)
{
    textDescr.AddValueChanged(myTextBox, delegate
    {
        // Add your propery changed logic here...
    });
} 
 
 

How to clear a local value

Because null is also a valid local value, there is the constant DependencyProperty.UnsetValue that describes an unset value.

button1.ClearValue( Button.ContentProperty );