We designed it to integrate with Microsoft HealthVault, so all of this information would be stored securely in the cloud.

Richard Wulfenstein was our visual designer on the project, producing all of the Illustrator comps, helping map out the information architecture, and learning Expression Blend and XAML within the two weeks, to boot.

Joe McBride was the team’s lead developer, setting up the project with the Managed Extensibility Framework (MEF) and a flavor of Rob Eisenberg’s Model-View-ViewModel (MVVM) that kept everything wonderfully “Blendable” with design-time data throughout the project. He also cooked up some handy swipe-gesture Blend Behaviors for rolling your Panorama view (as you may have already seen on the blogs here).

Matthias Shapiro orchestrated our initial user research interviews, collaborated to develop our personas and scenarios, and pinch-hit with some of the early integration work.

Jason Alderman was the user experience designer on the project, working with Matthias to conduct user research and refine the scenario, leading the team in whiteboard sketch sessions, designing animations based on the existing samples, planning out the application flow and interactions, and integrating Richard’s comps into XAML.

It was a rewarding experience for all of us, and we’re excited to share it with you. Read more about the project and download the code here, and let us know what you think.

You can find a couple other great Windows Phone 7 videos by Roger Peters (SmartyP) here.

MIX10 “Effective Information Visualization in Silverlight

I’ll post the code from the presentation when I catch my breath.

• 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.

In this series of blog posts (tagged with UX Methodology), we at Veracity Solutions will try to elucidate how this process works for us.

This post is an effort to clear up some misconceptions about UX design and identify some common terms and roles to expect when doing UX design… especially within an Agile development environment.

The 5 Roles of User Experience

There are five terms that cover the tasks that can be expected in a project implementing effective user experience design. Keep in mind that this does not mean you need a small army to run your UX design initiative. Most UX designers can spearhead more than one of these roles. But it is important to remember that these roles each involve time (also known as money) and each role is important to the process.

Without further ado, the five UX roles are:

• User Research
• Information Architecture (IA)
• Interaction Design (IxD)
• Visual Design (VisD)
• UI Development (UI Dev)

For each of these roles, we will cover the following:

• Definition of the role (what it is, what it’s for, how it’s done)
• Deliverable (what do other people on the team see)
• Where in the dev process this role take place
• Tangible (profitable) benefits
• Silverlight/WPF technologies that facilitate this task

All of our work is done in using the Agile methodology and a good deal of it is done in Microsoft technologies. As a result, we’re focusing this series with those two concepts in mind. This doesn’t mean that people who work in non-Microsoft technologies will be lost at sea. Only that those who do use the Microsoft technologies will find additional information specific to WPF and Silverlight development.

The chart below is quick summary of how these roles fit together. The blocks indicate where the roles take place and the text near the arrows indicate what kind of deliverables come from each role and inform the next role or step in the design or development process. We’ll highlight how these roles work together in more detail in the coming posts.

For more on UX and Agile, make sure you read the Scott Barnes post Can You Mix UX with Agile and Anthony Colfelt’s Bringing User Centered Design to the Agile Environment.

More to come…

After my third or fourth viewing, I grabbed some of Robby’s helpful visuals so that I wouldn’t have to search through the videos for them. We’ve been using them internally and now, I relay them to you (with his blessings, of course).

UX Design Deliverables

Not all of these are formally necessary 100% of the time, but this chart gives a good overview of what kind of deliverables you can expect in a UX process and why they are valuable.

(click to enlarge)

User Experience Roles

Due in part to the newness of user design as a formal discipline, there are many terms used to describe roles and occupations for people involved in creating the user experience. Each of the circles in this diagram is a role, not an individual and it is perfectly reasonable to expect an individual to take on several of these roles (or all of them, if that individual is something of a polymath). But keep in mind that these roles are distinct and (as an example) you can’t expect to have a superb user experience if you don’t plan out time for your UX designer to do information architecture.

This little red book from Japan is written by Shigenobu Kobayashi, Japan’s leading color psychologist. Over fifteen years ago, he and his team at the Nippon Color & Design Research Institute matched 130 basic colors and over 1,000 color combinations to key image words to help designers express any mood, life-style or taste through color palettes alone.

Kobayashi’s work is particularly awesome because he categorizes three-color combinations along a “soft-to-hard/warm-to-cool” axis and assigns zones of color that match how we respond to the combinations.

This is only a tiny sample of the color combinations Kobayashi categorizes.

The biggest frustration for me has been the fact that the colors are assigned with a “hue/tone” assignment that I’ve never seen anywhere else. Example: One color is “GY/B”, which is a "green-yellow” hue and a “bright” tone. This is understandable, since Kobayashi wrote the book in 1990… long before a world of web design geeks. But I’ve never found a good resource for translating Kobayashi’s colors into RGB values.

So I made one.

The link below is a recreation of the color guide at the beginning of “Color Image Scale”. I scanned in the pages, color corrected as best I could and found the RGB values for each color. It is obviously not a hard-and-fast guide, but I think it’s a good starting place for figuring out how to directly apply the Color Image Scale to your applications or projects. There is a “small” version that comes in at about 1100 x 900 and a larger version that is 1900×1080.

Larger 1080p resolution version of Color Image Scale RGB values

Hope that helps anyone who has found Color Images Scale as useful as I have.

By the way, if you need additional help on in depth Silvelright animation, check out Jeff Paries’ excellent Foundation Silverlight 2 Animation.

In response to this dearth, this is a tutorial on how to create a storyboard in code (specifically C#). Basically, I’m just going to show a XAML animation (which is what I’m used to dealing with because Blend builds them for me) and then show how to create that animation in C#.

This animation will animate the first point in a path to the X,Y coordinate 1,1.

XAML animation:

<Storyboard >
    <PointAnimationUsingKeyFrames 
      BeginTime="00:00:00" 
      Storyboard.TargetName="myPath" 
      Storyboard.TargetProperty="(Path.Data).(PathGeometry.Figures)[0].(PathFigure.Segments)[0].(LineSegment.Point)">
        <EasingPointKeyFrame KeyTime="00:00:01" Value="1,1" />
    </PointAnimationUsingKeyFrames>
</Storyboard>

C# animation:

//Code equivalent of: <Storyboard>
Storyboard myNewStoryBoard = new Storyboard();

//Code equivalent of:
//<PointAnimationUsingKeyFrames
//    BeginTime="00:00:00"
//    Storyboard.TargetName="myPath"
//    Storyboard.TargetProperty="(Path.Data).(PathGeometry.Figures)[0].(PathFigure.Segments)[0].(LineSegment.Point)">
PointAnimationUsingKeyFrames myPointAnimation = new PointAnimationUsingKeyFrames();
myPointAnimation.BeginTime = new TimeSpan(0);
Storyboard.SetTargetName(myPointAnimation, myPath.Name);
Storyboard.SetTarget(myPointAnimation, myPath);
Storyboard.SetTargetProperty(myPointAnimation,
    new PropertyPath("(Path.Data).(PathGeometry.Figures)[0].(PathFigure.Segments)[0].(LineSegment.Point)"));

//Code equivalen of:
// <EasingPointKeyFrame KeyTime="00:00:01" Value="1,1" />
EasingPointKeyFrame targetKeyFrame = new EasingPointKeyFrame();
targetKeyFrame.KeyTime = KeyTime.FromTimeSpan(TimeSpan.FromMilliseconds(1000));
targetKeyFrame.Value = new Point(1, 1);

//Add the keyFrame to the animation
myPointAnimation.KeyFrames.Add(targetKeyFrame);

//Add the animation to the Storyboard
myNewStoryBoard.Children.Add(myPointAnimation);

//Now your storyboard is ready to go… just start it
myNewStoryBoard.Begin();

There is not, as far as I know, any way to assign a x:Name property to an object in code. Why? Because if you created the object in code, you should already have a way of accessing it. So the example above is an animation that is looking for a path named “myPath” that is already in the XAML.

If you created your path programmatically (it doesn’t exist in the XAML, but exists in the code), replace this line:

Storyboard.SetTargetName(myPointAnimation, myPath.Name);

with this line.

Storyboard.SetTarget(myPointAnimation, myPath);

where myPath is of type Path and refers to the actual Path you want to animate.

First thing I learned was that you cannot use TemplateBinding in a Storyboard (I think). I asked this question on Stack Overflow and I haven’t gotten an answer. But I’m pretty sure that in Silverlight you cannot use TemplateBinding to attach a property to a KeyFrame value. This means that you have to have a pointer in the control code the allows access to the KeyFrame so you can update the value.

I’ll walk through the conceptual part of animating a property in a Custom Control in Sivlerlight and then walk through the code to it.

Step 1: Create a PART to your control to hold the Storyboard and a PART to hold the KeyFrame you want to manipulate

I cover how to make a PART to your control here because it was too much to put into a single blog post. You’re going to want to make your Storyboard a PART that is accessed via resources (via MyControlName.Resources[MyStoryboardName]) and your KeyFrame should be a PART that is accessed the normal way (via the GetTemplateChild(MyKeyFrameName) method).

Step 2: Create the DependencyProperty you want to drive the animation

Yet another chance for me to endlessly flog Robby Ingebretsen’s awesome Silverlight Code Snippets. If you use these, use ‘sldpc’, which is the DependencyProperty with a property changed callback. We want to manually fire the animation when the property changes, so we’re going to do that in the callback.

If you don’t want to use Robby’s stuff, here’s the code for a DependencyProperty with a property changed callback. Because my visualization animates the color, I called my property “Fill”.

public SolidColorBrush Fill
{
    get { return (SolidColorBrush)GetValue(FillProperty); }
    set { SetValue(FillProperty, value); }
}

public static readonly DependencyProperty FillProperty =
    DependencyProperty.Register("Fill", typeof(SolidColorBrush), typeof(County),
    new PropertyMetadata(new SolidColorBrush(Color.FromArgb(0, 0, 0, 0)), new PropertyChangedCallback(OnFillChanged)));

Step 3: Hook up a property changed callback and run the animation

Then, all you need to do is go into the property changed callback that you have created and assign your the new valie of the property to the keyframe value of the animation you want to run. Then run the animation.

private static void OnFillChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
    MyControlType thisControl = d as MyControlType;
    if ((thisControl != null) && (thisControl._myStoryboard != null))
    {
        SolidColorBrush newBrushHolder = (SolidColorBrush)e.NewValue;

        thisCounty._myKeyFrame.Value = newBrushHolder.Color;
        thisCounty._myStoryboard.Begin();
    }
}

And now every time you change that value in the control, it will animate to the new value. Simple as that.

But sometimes, you (and by “you”, I mean me) need help figuring out how to create a PART for a control because, let’s be honest, you don’t do it all the time and no one has a blog post on just this little part of control building.

If you’re wondering what a PART is, here’s a short explanation: A PART is a naming convention that allows a control (code) to make a contract with the control template (XAML) in Silverlight. The control says to the template, “I’m going to be doing something programmatic with this part, so it better be there”. The template responds, “Here’s that part you wanted.”

I not actually talking down to anyone, this is really how my brain works.

There are basically five steps in creating a PART. I think you can actually do it in less, but I’m trying to follow what I think is proper coding practice. In this tutorial, we’re going create parts out of a Button and also a Storyboard (partly because there are different ways to assign a PART if it is in located in the control resources like a Storyboard is).

Step 1: Define the control template parts you’ll need

Outside of the control class we need to add the TemplatePart attributes. Inside the class, we need to define the names of the UI objects we’re going to turn into parts as well as create some corresponding objects in the control so we can access those PARTs.

[TemplatePart(Name = MyControl.StoryboardString, Type = typeof(Storyboard))]
[TemplatePart(Name = MyControl.RootElementString, Type = typeof(FrameworkElement))]
[TemplatePart(Name = MyControl.ButtonString, Type = typeof(Button))]

public class MyControl : Control
{
    private const string StoryboardString = "PART_MyStoryboard";
    private const string RootElementString = "PART_RootElement"; 
    private const string ButtonString = "PART_MyButton";

    private Storyboard _targetStoryboard;
    private FrameworkElement _rootElement;
    private Button _targetButton;

What we’re going to do here is remarkably stupid because I don’t have the creativity right now to do something cool. When we press the button, we’ll play the storyboard. We need the RootElement because… you’ll see in a moment.

Step 2: Make sure you have a XAML template properly named to correspond with the part

We have three parts we’re getting here, so this is a stripped down template that just has the three PARTs named appropriately. If the names are not the same as the strings above, it will not work.

<StyleTargetType="local:MyControl">
    <SetterProperty="Template">
        <Setter.Value>
            <ControlTemplate TargetType="local:MyControl">
                <Grid x:Name="PART_RootElement">
                    <Grid.Resources>
                        <Storyboard x:Name="PART_MyStoryboard">
                           <!– Whatever animations you want here –>
                       </Storyboard>
                    </Grid.Resources>
                    <Button x:Name="PART_MyButton" />                       
                </Grid>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

Step 3: Assign the XAML PART to the code PART in the OnApplyTemplate method

Now we just have to write a custom OnApplyTemplate method that will grab the XAML elements and assign them to objejcts within the control code. There are two key methods you’ll use. The first is GetTemplateChild, which will pull out any UI element in the XAML that is named and not in the resources.

If you want to get something in the resources, you need to refer to the UI element that holds those resources. This is why we needed the root element as a PART. So, enough of my blabbing… here’s the code:

public override void OnApplyTemplate()
{
    base.OnApplyTemplate();

    _rootElement = GetTemplateChild(MyControl.RootElementString) as FrameworkElement;
    //Make sure we actually got the template applied.
    if (_rootElement != null)
    {
        _targetStoryboard = _rootElement.Resources[MyControl.StoryboardString] as Storyboard;
        _targetButton = GetTemplateChild(MyControl.ButtonString) as Button;

        _targetButton.Click +=new RoutedEventHandler(_targetButton_Click);       

    }
}

Now we have all the PARTs assigned so we can do something like adding an event handler to the Button so that, when it is clicked, it runs the storyboard.

void  _targetButton_Click(objectsender, RoutedEventArgs e)
{
     _targetStoryboard.Begin();
}

And that’s how you add a PART… both in the regular XAML template and in the resources of the template.