That Don't Suck
A 5-Day Training Class
Morning 1: Introduction
Lecture: Introduction of students and structure of class.
Quick look at problems of current user interface
implementation stemming from original Windows GDI
design. Goals of WPF – broad integration, resolution
and size independence, hardware acceleration, rich
composition and customization, separation of
appearance from behavior, convenient and widespread
data binding. Structure of a WPF application.
Generation of a WPF project in Visual Studio,
examination of the XAML and other files produced.
Instantiation of WPF objects via XAML elements,
setting of WPF object properties via XAML
attributes, mapping of XAML namespaces onto .NET
namespaces. Using Reflector to view XAML compiled
into BAML format. Loading and parsing XAML at
runtime. Use of Type Converters and Markup
Generate and set up VS projects for students' own
WPF development projects. Examination of basic
structure and XAML utility applications.
Afternoon 1: Fundamental Structure
Lecture: Examination of sample program that accompanies the
textbook. Logical and visual trees in WPF,
differences between them. Examination of logical and
visual trees in this sample application using a
viewer application. Note that the logical tree does
not change without programmer intervention, but that
the visual tree easily can (such as by the user
applying a different theme). Examination of property
value inheritance, watching property values flow
down the visual tree until overridden, examination
of classes where this behavior is deliberately
broken. Use of attached properties, examination of
an example in which a StackPanel provides FontSize
and FontStyle properties to TextElement objects
within it. Examination of RoutedEvents and event
handlers. Tunneling and bubbling of RoutedEvents.
Use of AttachedEvents.
Examine visual tree of students' prototype or
Morning 2: Controls
Lecture: Introduction to WPF Controls; content, items, range,
and text controls. Use of an arbitrary object as
content in a content or item control. Classes of
buttons, use of ButtonBase class. Other content
controls, such as label and tooltip. Containers with
header. Examination of the ContainerControl class,
classes derived from it such as ListBox and
ComboBox. Concept of a Selector. Customizing items
contained in an ContainerControl. ListView and Tab
controls. Menus and Toolbars. Range controls,
examination of Slider and ProgressBar. Text
Examine choices and select controls for students'
prototype or production applications.
Afternoon 2: Layout
Lecture: Problems of laying out
controls for a wide and changing set of display
resolutions. Need for layout containers with
different properties. Examination of Canvas,
StackPanel, WrapPanel, DockPanel, and Grid classes.
Examination of options for holding child controls.
More detailed examination of the Grid class, as it
is the most versatile and most widely used.
Specifying numbers of rows and columns, sizing and
spanning rows and columns. Using GridSplitter to
allow manual sizing of grid cells. Options for
clipping child controls. Scrolling and scaling in
layout containers. Putting it all together: creating
a Visual Studio-like, collapsible, dockable,
Examination of layout options for students'
prototype or production applications. Select layout
of students' choice, work with options of that
Morning 3: Styles and Templates
Lecture: Concept of separating appearance from behavior.
Example showing customization of individual buttons,
demonstration of the tedium of doing it this way.
Example showing same combination of properties
converted into a style and referenced from the
individual buttons via its key. Use of the
TargetType attribute in a style. Automatic
application of styles to controls via omitting key,
“implicit style”, requires exact match. Adding
property and data triggers to styles, combining
trigger conditions. Concept of complete replacement
of control appearance, use of a template. Use of
triggers in templates. Scoping of styles and
templates. Respecting properties in a template, such
as content and size, visual state such as Enabled.
Combining templates and styles. Extension to
ItemTemplates and DataTemplates.
Work out a strategy for styles and templates in
students' prototype or production applications.
Afternoon 3: Data
Lecture: Examination of the dependency property
structure of WPF. Notification callback for change
in a property. Use of the DependencyProperty and
ObservableProperty class. Change notification and
Trigger class. Concept of a binding object,
examination of the WPF Binding class. Using a
Binding in XAML, specifying Path property. Binding
to other XAML properties, specifying the
RelativeSource. General case of binding to any
property of any .NET object. Implementing the
INotifyPropertyChanged interface, use of the
ObservableCollection class. Binding to ListBoxes and
ComboBoxes, managing the SelectedItem property. Use
of DataContext as default source of data for
Explore and discuss the options for data binding in
students' prototype or production applications.
Implement the most promising option.
Using WPF for Good and Not Evil
the power of Windows Presentation Framework into the
hands of developers who are unschooled in the art of
user interface design is like giving liquor and
Corvette keys to teenage boys. It's fun for them,
temporarily, but the end results aren't pretty. “The
first time they see it, they will think it is cute.
The eleventh time they see it, they will think about
killing you,“ writes etiquette columnist Miss
Manners. Users don't give a flying fish about their
applications in and of themselves. Never have; never
will. They only care about accomplishing the tasks
that they bought the software to get done, so that
they can get on with eating and making love and
living their lives. Forget about color gradients and
button radii. Learn how to use WPF's power to
accomplish good things that your users actually care
about, not useless nonsense that does nothing but
titillate the rococo vanity of socially misfit
We will examine the Family.Show
WPF application, often cited as a paragon of good
WPF design. We will study its use of three separate
WPF features: color gradients, motion, and
re-looking of controls. We will see cases in which
the app uses each of these features well, quickly
and easily improving the user experience far beyond
anything Windows Forms could do. And we’ll also see
different parts of the very same app using the very
same WPF features to degrade the user experience, in
once case inflicting genuine physical, not just
mental, pain on its user. We will discuss the
underlying principles that cause each instance to be
good or bad.
Lab: Examine your
proposed designs or your existing products in light
of the examples in this lecture. Identify usages of
advanced graphical features that help the user and
those that do not. Propose strategies for converting
the latter into the former.
Afternoon 4: Writing User Stories
Storytelling is the main way in which the human
species communicates. It is likewise the best way
in which the interaction of a user with a
program is discussed and specified. We will discuss
building a user interface from a collection of user
stories. We will define a user story, discussing
what they are and are not. We’ll look at the choices
for the length and details of a user story, and
derive principles for handling stories that
are too long or too short. We’ll examine some
examples of good and bad user stories. We’ll examine
and work with different ways of tracking stories –
index cards versus programs, advantages and
disadvantages of each. Once we know what good
stories are, we’ll discuss ways of gathering the
information we need to write good ones. We’ll
discuss the sorts of information you can elicit from
direct interaction with users, such as interviews,
and the types that you can’t get directly from them
but can only get from observing them in action. We
will examine the construction of users’ goals and
constraints, what the users think they are and what
they really are. Finally, we’ll discuss extracting
information from participants in the process who are
not actual users – their managers, for example, or
problem domain experts or regulatory personnel.
Write three separate user stories for the design of
your product. Expand and document them as much as
permitted by the available time.
5: Testing on
never know how well anything works until you test
it. Somehow this principle often gets lost when it
comes to the user experience. What is obvious to a
developer who uses an application all day every day
is opaque to a casual user, or even a non-casual
user who doesn’t understand (or want to understand)
a program’s internal workings. User interfaces need
to be tested early and often so their efficacy, or
lack therefore, can be determined.
We’ll discuss the timing of user
interface testing, learn why waiting until the beta
(or even alpha) phase is never enough. We’ll
consider the frequency of testing iteration versus
the number of users; why more tests with fewer users
in each are better than fewer tests with more users.
We’ll address the issues and difficulties of
recruiting the test subjects, and the pitfalls of
Jakob Nielsen’s ideas on “hallway usability
testing”. We’ll see how important is the exact
wording of the tasks that you set for users and the
data that you put in front of them. And because the
user interface will evolve quickly as data becomes
available, we’ll discuss ways of generating
prototype user interfaces quickly. Finally, we’ll
discuss the art and science of making changes to the
user interface based on what you learn during your
testing, and strategies for handling the resistance
that inevitably arises.
Lab: Perform a
quick usability test on your company’s existing or
proposed products. Discuss the information that you
collect as a result, the lessons that it teaches,
and the changes that you would make to your product
as a result.
Instrumentation For Knowing Thy User
Lecture: The most
important principle of user experience design is
“Know Thy User, for He Is Not Thee.” However, it is
very difficult to know exactly what users think of
your application – what they find easy to use,
what’s hard, what makes sense to them and what
doesn’t. If you ask them, they don’t know, or can’t
remember, or don’t want to admit they can’t use your
application, or don’t want to insult you. Even
finding users to ask is difficult, and current
techniques such as focus groups almost always
produce unrepresentative results.
The only way to know for sure is
to instrument your application so that it reports
user experiences over many sessions. This talk
will discuss ways in which this can be done and the
design decisions that need to be made to accomplish
it successfully. User experience tracking is
different from other kinds of program
instrumentation – it has to be very light, so that
it doesn’t degrade performance at all. Which
sorts of events should you record? How do you
convince users to opt in for data collection? How do
you send and store the data, and how do you analyze
it? A sample user experience tracking framework will
be demonstrated. The silent majority has a lot to
say, if you know how to listen to them.
Lab: Examine a
working application containing a user
instrumentation framework. Follow the flow of
information from instrumented application to
database to designer. Discuss how you would
instrument your own applications.