For everyone who wants to take a look, here are the slides for my MIX10 information visualization talk.
MIX10 “Effective Information Visualization in Silverlight
I’ll post the code from the presentation when I catch my breath.
This is the second post in a series on User Experience design. See other posts here:
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:
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).
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:
User research gathers data through a variety of methods. The methods we most commonly advocate are:
Field observations (watching users’ behavior in context)
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.]
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.
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”.
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.)
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.
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.
One of the most sought after aspects of line-of-business development in recent months has been the desire to create not just an application but an experience that appeals to and compels the users of the application. At the same time, there is no aspect of development that is more poorly understood in terms of planning, expectations and deliverables than UX design and development.
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.
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:
For each of these roles, we will cover the following:
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…
Here are Veracity, we’ve spent a not-insignificant amount of time working through an appropriate way to implement user experience design (UX design) into our projects. I have found a huge amount of inspiration from Robby Ingebretsen’s MIX 09 talk on Design Fundamentals for Developers. Watch it. Then watch it again. Then grab the audio and make it the start-up, shut-down and error sound on your machine. Robby is a fantastic speaker and has thought an enormous amount about user design for software in the real world. Also, check out Robby’s blog here.
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).
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)
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.
If you’re a designer, you’re almost certainly interested in color. And if you’re interested in color, you could hardly do better than to pick up a copy of Shigenobu Kobayashi’s Color Image Scale. Fellow designer Kevin Hale has some more of the skinny on this fantastic design resource:
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.
One of the things that I’ve gotten somewhat frustrated in my Silverlight and WPF work is the fact that sometimes (not often, but sometimes), I really need to build a storyboard or keyframe animation programmatically. Especially if you’re doing anything relating to information visualization and you need to create animations for path points, it can be impractical to build a XAML animation and change the values to whatever you need.
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.
For my recent visualization, I created a custom control in Silverlight that animated the color of a Path every time a “Fill” property on the control was changed. I thought I would pass along my learning from this process.
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.
There are about a dozen videos and tutorials on how to create a custom control in Silverlight 3. (Here’s my favorite, from Karen Corby. Skip to about 47 minutes for the tutorial part.)
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.
UPDATE: It turns out that in WPF, there is an easier way to snap the slider. For integers, simply check the “IsSnapToTickEnabled” and set your TickFrequency accordingly. Which means that this behavior is really only useful for Silverlight, which doesn’t have those properties.
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…”
![clip_image001[4]](http://www.designersilverlight.com/wp-content/uploads/2009/09/clip_image0014.png)
Choose “Behavior” from the list and type in the name of the behavior you want to create
![clip_image001[6]](http://www.designersilverlight.com/wp-content/uploads/2009/09/clip_image0016.png)
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).
![clip_image001[8]](http://www.designersilverlight.com/wp-content/uploads/2009/09/clip_image0018.png)
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.
One of the things that I’ve been doing as I was working on my Florida Crime Rate data visualization was finding vector maps of the US and converting them into XAML. Pretty much everything I found that was free was in SVG format, so I would pull that into Adobe Illustrator and then export into XAML using Mike Swanson’s really awesome Adobe Illustrator to XAML export plug-in. But I wanted to take a moment and say why I’m still using this plug-in instead of the default Expression Blend Import for Illustrator.
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.)
![clip_image001[5]](http://www.designersilverlight.com/wp-content/uploads/2009/09/clip_image0015.png)
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?
![clip_image001[9]](http://www.designersilverlight.com/wp-content/uploads/2009/09/clip_image0019.png)
And here is the same path in the native import.
![clip_image001[7]](http://www.designersilverlight.com/wp-content/uploads/2009/09/clip_image0017.png)
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.
![clip_image001[11]](http://www.designersilverlight.com/wp-content/uploads/2009/09/clip_image00111.png)
Now let’s change the path data by a hundredth of a unit, from X=35.366 to X=35.376
![clip_image001[15]](http://www.designersilverlight.com/wp-content/uploads/2009/09/clip_image00115.png)
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.
