• Introduction to User Experience (UX) Design

User Research

Definition

User research means learning about your users – your customers – by gathering data and testing designs for the two purposes of discovery and evaluation. User research answers questions like the following:

• What is the user’s workflow for their job (or given tasks)?
• What do users want to ultimately do?
• What terminology do they use? (what’s their domain language?)
• How well does your software help users do what they need to do?
• How well does the software match users’ mental model of what they expect it should do?
• What parts of your software do users find confusing?
• What parts of your software do users love?

The data you get from user research is both quantitative (hard numbers and statistics that tell you what is happening) and qualitative (observed behaviors and user rationales that give you the context of why).

How it fits into Agile

The trick about Agile and UX is that Agile development already involves user research.

Agile has a discovery process, in which we gather user stories from actual users and map them into goals, activities, and stories on a story wall. Discovery is about learning how users do their tasks and how your software can help them do what they need to do efficiently.

We also do evaluations, in which we show our designs or working prototype code to the customer (as a user or user advocate) for feedback, at the end of each iteration. Usability testing has a reputation for being formal and summative (when everything is done), but it’s just as useful when formative (while you’re building things) and the Agile methodology (done right) actually has an insertion point where the user research that has been gathered can usefully inform the on-going product development.

Making it a more formal part of the process gives Agile development three benefits:

1. It makes getting feedback from users an explicit part of Agile development, so that we can get the info we need at the end of each iteration, throughout the design and development process, and make quick course corrections.
2. It gives us a “utility belt” of best practices for gathering data and evaluating software with users, so that the information we have is more accurate, and saves money and time.
3. The data we gather helps us make models of how users think and act, and having a rich model means that designing (and redesigning) is much more rapid.

User Research methods

User research gathers data through a variety of methods. The methods we most commonly advocate are:

Field observations (watching users’ behavior in context)

• semi-structured interviews (asking users both prepared and extemporaneous questions)
• data logging (collecting statistics on software usage)
• diary studies (asking users to record their experiences)

Usability testing puts designs (sketches, or prototype code) in front of users, and then uses all of the methods above to get feedback and evaluate design decisions. [We've written far more information about these methods over here.]

What deliverables can I expect from User Research?

Data gathering gives us the information we need to build a model of the users. This generally manifests itself in personas (write-ups describing the different typical users of your software) and in the user stories of an Agile story wall. As further data is gathered, the stories may change, and the story wall is an evolving model for a user’s workflow and needs.

Evaluation findings and raw data are kept in whatever system the team is using to document design. We recommend a wiki or blog as a repository for user research findings (and as a journal of design decisions for the rest of the UX design).

Findings should identify problems that need fixing and provide data to support the finding.

Example: a wiki page with video that shows a user getting confused when trying to submit a form on a specific screen of your application. (There should be video of both the person’s reaction and the screen they see.)

User research informs decisions and makes recommendations, but should not prescribe how to fix the problems identified.

Keep in mind that there is no such thing as “fixing problems proactively”. Every piece of software is going to have problems and every piece of software is going to need to have the experience fixed. Many people have the idea that a good enough UX designer will be able to spot problems with their magical designer intuition and fix them without any contact with the target users. While there are best practices in terms of layout, color, type and flow, it is impossible to build a perfect application on the first try.

Where in the development process does User Research fit?

User research should occur throughout the entire design and development process. Before any coding begins and iterations begin in earnest, it is a vital component for properly identifying stories and the tasks associated with them.

For more specific information about how to implement the various user research tasks into the development process, see the chart in “User Experience and App Workflow”.

What benefits can I expect from User Research?

As mentioned before, user research is already a native part of Agile methodology; you’re not buying something extra by doing user research. If you don’t do it, you’re taking something OUT of Agile and weakening the strength of the methodology in the process.

As stated above, formalizing user research helps you set up an infrastructure for getting feedback on a more regular basis so that you can be more agile, and helps you be the most efficient and get the most accurate data when gathering feedback from users. User research helps you better understand the needs of your customers, identify software requirements, prioritize features and drive product strategy. This results in spending appropriate time and money on features that deliver the greatest return on investment (ROI).

(Silverlight/WPF technologies have some specific ROI benefits for gathering data. See below.)

How do Silverlight/WPF technologies help me with User Research?

The biggest aspect of the current Silvelright/WPF technogies that aids in user research is the SketchFlow application that comes as a part of Blend 3 (and later versions).

In early product planning and development,  SketchFlow lets you mock-up an interactive prototype that you can put in front of users in order to quickly collect feedback. While the system is not yet perfected, it offers significant savings over traditional shoe-leather data gathering.

For more developed projects, it is possible to hook Google Analytics into Silverlight projects and let it listen for certain events. However, the most effective (and cheapest) method we’ve found is the old fashioned methods of user interviews and observation.

Additional User Research links

D. Chisnell. Usability Testing Demystified. (2009)
http://www.alistapart.com/articles/usability-testing-demystified/
Straight-forward explanation of what usability testing is, how to do it, and why it doesn’t need to be formal summative testing.

S. Krug. Don’t Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition. (2005)
http://www.amazon.com/exec/obidos/ASIN/0321344758/ref=nosim/advancedcommonse
S. Krug. Rocket Surgery Made Easy: A Do-It-Yourself Guide to Finding and Fixing Usability Problems. (2009)
http://www.amazon.com/exec/obidos/ASIN/0321657292/ref=nosim/advancedcommonse
Excellent books, with some of the best advice on low/no-budget usability testing we’ve seen.

R. Jones, N. Milic-Frayling, K. Rodden, A. Blackwell, “Contextual Method for the Redesign of Existing Software Products,” International Journal of Human-Computer Interaction, 2007, 22(1-2). (Original paper dated 2004.)
http://research.microsoft.com/apps/pubs/default.aspx?id=70095
Great practical overview of many of the methods described above, courtesy Microsoft Research.

Behaviors are easily the coolest thing that has ever happened to anything.

Perhaps I overstate my case somewhat. But they’re still pretty cool.

To me, a wonderful example is the ability to let designers/developers get some really cool functionality out of the Silverlight or WPF slider.

Now, one might normally think that there is a simple way to make your slider values to snap to an integer or to some incremental number (perhaps base 2 or base 10). Alas, one would be wrong. There have been a couple solutions to this problem (see here and here), but they usually involve creating a new slider subclass with the additional functionality if you really want the interaction to be reusable.

However, behaviors makes all this unnecessary. What is even better is that there is no code difference between WPF and Silverlight on this one. That’s right… this tutorial and the code that goes with it works exactly the same in Silverlight as it does in WPF.

SnappingSlider Behavior (SnappingSlider.cs) – Works for Silverlight and WPF

WPF SnappingSlider Behavior (All Project Files)

Silverlight SnappingSlider Behavior (All Project Files)

You can also download the behavior here (just the cs file) which would make me happy because it ups my street cred among the Silverlight homies (says the whitest man on earth).

If you want to learn how to create it yourself, let’s get started.

In your project in Blend, right-click on the project and go to “Add New Item…”

Choose “Behavior” from the list and type in the name of the behavior you want to create

This is where Blend is way cooler than Visual Studio… it gives you pretty much all the code and imports all the appropriate references for creating a behavior. So, first change the behavior associated object type to a Slider:

public class SnappingSlider : Behavior<Slider>

And go into the inside the OnAttached method, enter the following code:

AssociatedObject.ValueChanged +=new System.Windows.RoutedPropertyChangedEventHandler<double>(AssociatedObject_ValueChanged);

Hint to Code Newbies: If you get to the “+=” part and hit the Tab key twice it will add the necessary code.

Inside the AssociatedObject_ValueChanged method, I added the following code:

private voidAssociatedObject_ValueChanged(objectsender, System.Windows.RoutedPropertyChangedEventArgs<double> e)
{
   //Let the slider be equal to the Maximum and Minimum values
   if((e.NewValue != AssociatedObject.Maximum) && (e.NewValue != AssociatedObject.Minimum))
    {
       //Using the Minimum value as a starting point, only allow values that are
        //   a multiple of the SmallChange value. If you want to simply round to
        //   integers, set it so that:
        //   SmallChange = 1
       doublecalcValue = Math.Floor((e.NewValue – AssociatedObject.Minimum) / AssociatedObject.SmallChange);
        calcValue = (calcValue * AssociatedObject.SmallChange) + AssociatedObject.Minimum;
        AssociatedObject.Value = Math.Round(calcValue);
    }
    else
    {
        //Sometimes it hiccups on me, so I used this to catch those
        AssociatedObject.Value = Math.Round(e.NewValue);
    }
}

Once you have that code in place, build the project (menu option Project –> Build Project).

Now you should have the behavior available in the “Assets” tab under “Behaviors” (at the bottom of the picture below).

Just drag it onto your Slider and set the Minimum, Maximum and SmallChange properties appropriately. Remember that SmallChange is the value is that is acting as your increment controller.

As a case study, let’s look at an SVG file of the US counties. (You can find a link to the SVG here. Here is the file converted to XAML if you just want to download that and not mess with any of this other stuff. Special thanks to Nathan Yau of Flowing Data and @SimonRegenbogen for helping me find this.)

The SVG is about 1.6 MB, but when I convert it to XAML, it sees a size reduction of about 20-25%.

You’ll notice that the Adobe Illustrator-to-XAML export is about 100 KB smaller than the Expression Blend Illustrator Import. What’s the difference?

1. AI-to-XAML preserves path layers and grouping – In the native import version, all the paths are imported into a single Canvas. This makes it really hard to isolate paths and work with them individually. The AI export version groups into separate Canvases so that each state is it’s own canvas. Very handy.
2. AI-to-XAML preserves some metadata – all the paths in the AI-to-XAML version have a comment preceding the path that contains some (not all) of the naming metadata from the SVG file.
3. AI-to-XAML spaces code out better – Here is a sample of the data from the AI-to-XAML version:


And here is the same path in the native import.



You’ll notice three things: the first is the metadata (already noted). The second is that the export plug-in has spaced the paths to make them easier to read. The third is something you’ll notice if you’ve spent a lot of time working with XAML paths… the point data is spaced out in a way that makes it much more readable.  Overall a much better XAML experience.

4. AI-to-XAML maintains less path data fidelity – The AI-to-XAML converts to 3 decimal places, while the native import converts to 4 decimal places. But this isn’t necessarily a bad thing. Here is a corner of Sacramento County zoomed in 6400%.



Now let’s change the path data by a hundredth of a unit, from X=35.366 to X=35.376



The difference is almost imperceptible… even at this level of magnification. Changing it by a thousandth of a unit is going to make almost no difference that users will be able to see.

Conclusion: I’m going to continue using Mike Swanson’s Adobe Illustrator to XAML Export plug-in because it is awesome. If you don’t have or can’t afford Adobe Illustrator, the default import isn’t bad, but it is missing a good deal of potentially valuable functionality.

(Note: The project is in Silverlight, but if you copy and paste the code into a WPF project, it should work without any changes)

Have you ever wanted to create a Path programmatically or create a Path in code behind or dynamically build a Path or hand code a Path in Silverlight or WPF?

Yes, I just said the same thing 4 different ways, but I’m trying to cast a wide net for Google to catch. One of the biggest troubles I have when I’m trying to do something new is that I don’t always know the proper terminology, so I try to think of all the ways people might want to ask the question.

I’ve been playing around with a good number of information visualization concepts recently and one thing that I’ve found that I needed was the ability to create a path programmatically.

One way to do that is to tackle and fully grok the Path data code system. (Good guides to it are here and here.) This system is really cool, but (unless I’ve missed something) they cannot be animated.

I wanted to build a path based off a data set, but that means that I have to build it programmatically. I didn’t find a lot of useful stuff on how to do this, so I thought I’d throw some out there.

First, because I’m a XAML guy, I’m going to provide a simple XAML example of a Path that can be animated:

<Path x:Name="MyPath" Fill="#FFA30000" Stroke="Black" Width="100" Height="100">
    <Path.Data>
        <PathGeometry FillRule="EvenOdd">
            <PathFigure IsClosed="True" StartPoint="0,0">
                <LineSegment Point="0,100"/>
                <LineSegment Point="100,100"/>
                <LineSegment Point="100,0"/>
            </PathFigure>
        </PathGeometry>
    </Path.Data>
</Path>

This path is a simple square and looks like this:

Now, let’s assume you want to recreate this programmatically using a collection of points that represent X,Y coordinates. If you’re using an ObservableCollection of Points (like I am) you can use the following method to return an the appropriate path.

Path createPath(ObservableCollection<Point> rawData)
{

    Path FinalPath = new Path();
    PathGeometry FinalPathGeometry = new PathGeometry();
    PathFigure PrimaryFigure = new PathFigure();

    //if you want the path to be a shape, you want to close the PathFigure
    //   that makes up the Path. If you want it to simply by a line, set
    //   PrimaryFigure.IsClosed = false;
    PrimaryFigure.IsClosed = true;
   
    PrimaryFigure.StartPoint = rawData[0];

    PathSegmentCollection LineSegmentCollection = new PathSegmentCollection();

    for (int i = 1; i < rawData.Count; i++)
    {
        LineSegment newSegment = new LineSegment();
        newSegment.Point = rawData[i];
        LineSegmentCollection.Add(newSegment);
    }

    PrimaryFigure.Segments = LineSegmentCollection;
    FinalPathGeometry.Figures.Add(PrimaryFigure);
    FinalPath.Data = FinalPathGeometry;

    return FinalPath;
}

Once you have the path in place, you can just add it to your layout and it should show up. If you’re still confused, you can download the project that I created this in and walk through the rest of it yourself.

This tutorial is done entirely in Blend and without a line of code.

Step 0) (for the DataGrid only)

Go to Code Plex and download the WPF Toolkit. Extract to a convenient location.

Right-Click on the References folder in your project tab and click “Add Reference…”

Navigate to the location you extracted the WPFToolkit.dll file, select it and hit OK.

Step 1) Select the ComboBox you wish to change and edit the ControlTemplate by right-clicking and selecting “Edit Control Parts (Template) –> Edit a Copy…”

Step 2) Find the ItemsPresenter. This is what would normally display our ItemsSource.

We’re going to get rid of it. And the ScrollViewer for good measure.

Step 3) Where the ScrollViewer is, put in a ListView or a DataGrid, whichever one you’re using.

Now, go the properties of that ListView or DataGrid and click on the box to the right of “ItemsSource”

and, in the resulting menu, select “Template Binding –> ItemsSource”.

Set the DataContext of the ListView or DataGrid to the DataContext of the parent ComboBox using the same process.

And… you’re done! Open the ComboBox and you will see that you can select items in the ListView or DataGrid in the ComboBox dropdown and see those items change the selection of the ComboBox.

You’ll notice that this is probably not yet an ideal solution. For example, when we select an item, the dropdown doesn’t automatically close. Your best bet is to use the SelectionChanged event to trigger some logic to close the ComboBox dropdown.

One of the things we had to do was swap out ControlTemplates so that we could display a caret to indicate ascending or descending lists. We ended up deciding on ControlTemplates over DataTemplates because the DataTemplates would only work for ListViews that had no custom DataTemplates for the headers. We’re doing all sorts of crazy stuff with our headers and we need to preserve our DataTemplates, so this wasn’t an option.

In any case, I was having no luck finding the resource when I named it this way:

<ControlTemplate x:Key="MyCustomControlTemplate" TargetType="{x:Type GridViewColumnHeader}">

I was using the following code to try and find the resource.

ControlTemplate myNewTemplate = (ControlTemplate)Resources["MyCustomTemplate"];

However, we were able to solve the problem by naming the resource this way

<ControlTemplate x:Key="{ComponentResourceKey TypeInTargetAssembly={x:Type local:MyCustomListView}, ResourceId=MyCustomControlTemplate}"
         TargetType="{x:Type GridViewColumnHeader}">

And then using this code to access it.

ComponentResourceKey myCustomTemplateKey = new ComponentResourceKey(typeof(SortableListView), "MyCustomTemplate");
ControlTemplate myNewTemplate = (ControlTemplate)this.TryFindResource(myCustomTemplateKey);

Just thought I’d pass it along.

Normally, I’ve been creating listviews that look like this:

<ListView x:Name=”MyListView”
               ItemContainerStyle=”{DynamicResource MyListViewItemContainerStyle}”>
    <ListView.View>
         <GridView ColumnHeaderContainerStyle=”{DynamicResource MyListViewHeaderStyle}”
                         ColumnHeaderTemplate=”{DynamicResource MyGridColumnHeaderTemplate}”> 

I did this because I didn’t know exactly how to assign these styles and templates to the ListView Style. In the style, ColumnHeaderContainerStyle and ColumnHeaderTemplate are not properties of the ListView, they are properties of the GridView… which you can’t create a style for.

Instead, you can encapsulate all the information above in the following style.

<Style x:Key=”CustomListViewStyle” TargetType=”{x:Type ListView}”>
      <Setter Property=”GridView.ColumnHeaderContainerStyle” Value=”{DynamicResource MyListViewHeaderStyle}” />
      <Setter Property=”GridView.ColumnHeaderTemplate” Value=”{DynamicResource MyGridColumnHeaderTemplate}” />
      <Setter Property=”ItemContainerStyle” Value=”{DynamicResource MyListViewItemContainerStyle}” />
</Style>

Problem solved.

In the meantime, I’m making available for download a Resource Dictionary with the Blend ScrollViewer style as I’ve approximated it. (You may have to right-click “Save As…” on that file since IE will do its darndest to open it up.) Just load the resource dictionary into your project and set

<ScrollViewer Template=”{DynamicResource BlendScrollTemplate}” />

Note: This is not the “real” Blend styles… just my rendition/approximation.

In the meantime, here’s the overview for the ScrollViewer. When you look at a template of the ScrollViewer (right-click on the ScrollViewer, got to “Edit Control Parts (Template) -> Edit a Copy…“) you should see something like this:

If you want to change something about the main content area (highlighted below), you’re probably going after the PART_ScrollContentPresenter

If you want to style the corner (highlighted below), look at changing the Corner Rectangle.

If you want to style the HorizontalScrollBar and/or the VerticalScrollBar (highlighted below), you should right-click on either the PART_VerticalScrollBar or the PART_HorizontalScrollBar and go to “Edit Control Parts (Template) -> Edit a Copy…”

A point of note: Because of the way Blend works, it can be difficult to visually style a Vertical and Horizontal ScrollBar in the same Template. Don’t create another template. It’s a waste of time and will make your resources a pain to navigate. I’ll go over exactly what to do in a little bit.

The ScrollBar template should look something like this:

If you want to style the ScrollBar thumbs (the bars you would drag to scroll, highlighted below), you’ll need to change the template for the “Thumb” in the PART_Track. Note: Unless you’re doing something really complex, you should only need to style the Thumb control one time. You don’t need different styles for the vertical and the horizontal.

If you want to style the directional buttons (highlighted below), you will need to change the templates for the first and last “RepeatButton” controls (the ones that aren’t in the PART_Track) using the right-click -> Edit Control Parts (Template) -> Edit Template. (This template should already be copied into your resources.) Again, unless you’re doing something complex, you should only need to style this button one time.

If you want to style the empty area that allows for fast scrolling, you will need to change the style for the two RepeatButtons in the PART_Track (DecreaseRepeatButton and IncreaseRepeatButton)using the right-click -> Edit Control Parts (Template) -> Edit Template. You should only need to do this one time and then apply that style/template across the all the instances of this button.

Over the next couple weeks, I’ll try to put up posts going over how to style all of these into the Blend style. I’ll update this post pointing to the more in-depth tutorials as I go along. Until I get around to doing that, feel free to download the ResourceDictionary with the Blend styles in them.

 I’ve recently come up against a problem in which we were attaching a doubleclick event to our listview, only to discover it fires when we did something like click on the scrollbar quickly. Since we only wanted it to fire when we were double clicking on the listview item, we had to come up with some way of figuring out where in the listview the user had clicked.

Mike’s code made it easy… I’m reproducing our permutation of it here:

First, we put our event pointer in the XAML like so:

<ListView MouseDoubleClick=”ListViewDoubleClick”>

Then we put this in the code behind:

protected void ListView_MouseDoubleClick(object sender, RoutedEventArgs e)
{
     //grab the original element that was doubleclicked on and search from child to parent until
    //you find either a ListViewItem or the top of the tree
    DependencyObject originalSource = (DependencyObject)e.OriginalSource;
    while ((originalSource != null) && !(originalSource is ListViewItem))�
     {
          originalSource = VisualTreeHelper.GetParent(originalSource);�
     }
       //if it didn’t find a ListViewItem anywhere in the hierarch, it’s because the user
      //didn’t click on one. Therefore, if the variable isn’t null, run the code
      if (originalSource != null)
      {
         //code here
      }
} 

That’s it!

The solution ended up being so easy in WPF that I thought I’d post it here.

I’m in a two-birds-one-stone mood, so we’ll do this for both the listview, which will also cover a more traditional scrollviewer. Let’s start with our ever friendly listview.

At the very sight of this thing, with a stylus in hand, your average lefty is thinking to him or herself “I wonder if I can do my work upside down?” Let’s show them that we love and accept them just as they are.

The first thing we’re going to do is create a new template for this sucker, so right click on your listview and go to “Edit Control Parts (Template) -> Edit a Copy…”

Now we’re looking at the standard listview template. Mine looks like this:

Let’s dig right into the ScrollViewer. If you’re doing this from the listview (like I am) then creating a template for the listview has already created a template for the scrollviewer. If you’re starting from a basic scrollviewer, you can pretty much start right here.

For the purposes of making this thing easy to work with in Blend, go ahead and set the HorizontalScrollBarVisibility and VerticalScrollBarVisibility to Visible.

And then “Edit Control Parts (Template) -> Edit a Copy…” (or “Edit Control Parts (Template) -> Edit Template” if it is available).

We are now looking at the guts of the ScrollViewer Control.

ListView ScrollViewer will look like this:

The normal ScrollViewer will look like this:

For our purposes, they’re functionally the same. It is actually a fairly simple control… basically just a Grid panel with the columns and rows set up like so:

<Grid.ColumnDefinitions>
      <ColumnDefinition Width=”*“/>
      <ColumnDefinition Width=”Auto“/>
</Grid.ColumnDefinitions>

<Grid.RowDefinitions>
      <RowDefinition Height=”*“/>
      <RowDefinition Height=”Auto“/>
</Grid.RowDefinitions>

The scrollBars are set up so that their visibility is tied to (duh) the visibility that is set on the control. But what this does is it means that when they are collapsed… they Grid reclaims the space that they were taking up.

Now… here’s the hilarious part… in order to make this ScrollViewer left handed, all you have to do is swap the Grid.Columns:

<Grid.ColumnDefinitions>
      <ColumnDefinition Width=”Auto“/>
      <ColumnDefinition Width=”*“/>
</Grid.ColumnDefinitions>

You’ve now switched the columns so that the left handed column is auto. Here’s a list of the Grid.Column realignments you’ll need to make:

Change Column to “1″:

• PART_HorizontalScrollBar
• All DockPanels (ListView only)
• PART_ScrollContentPresenter (ScrollViewer only)
• Corner (ScrollViewer only)

Change Column to “0″:

• PART_VerticalScrollBar

Basically, swap everything from in the two columns.

Done.

If you want to make this a more robust control, I recommend creating a ScrollViewer with an additional dependency property (IsSouthPaw or something). Make it so that your Grid has three columns:

<Grid.ColumnDefinitions>
      <ColumnDefinition Width=”Auto“/>
      <ColumnDefinition Width=”*“/>
      <ColumnDefinition Width=”Auto“/>
</Grid.ColumnDefinitions>

And then you can just create a trigger that swaps the column placement of your PART_VerticalScrollBar. Such a trigger will look something like this. And by “something”, I mean “exactly”.

<Trigger Property=”IsSouthPaw” Value=”True“>
      <Setter Property=”Grid.Column” TargetName=”PART_VerticalScrollBar“  Value=”0” />
</Trigger>

Go forth and make Ned Flanders proud.

By the way, I listen to pop punk whenever I write my tutorials and I just thought I should let Senses Fail know that they can probably get away with about 80% less “dying cat” screaming and still put out good music. You know… because they’re probably WPF programmers on the side and they’ll probably read this to solve all their left-handed scrollbar needs.