The Road to XAML

by Matt Stein on March 16, 2009

Design teams working on projects that employ a purely sequential development process – such as the waterfall model – are challenged to deliver the right solution the first time. This is unrealistic with regard to user-centered design methods, which rely on an iterative feedback-and-refinement loop. On a sequential project, however, requests for changes to a design that is already in the Development phase are weighed directly against stability, performance, and overall completeness. What if designers could own more of the UI work that developers normally must do, for example change the layout of a dialog, adjust the look of a control, or change a few text strings?

Enter XAML.

XAML stands for eXtensible Application Markup Language and was created by Microsoft. It is currently the primary mechanism for declaratively creating the user interface in a Windows Presentation Foundation (WPF) application.  WPF is part of the .NET 3.0 framework. Why discuss these very technical things in a design blog post? The answer is simple: because XAML is designed for designers. It has other uses of course, but one of its main tenets is that XAML enables the separation of UI and logic (code).

That is a very powerful concept! In this and future posts, I will explain how a few of us at Autodesk are using XAML in our design process as a way to enable design refinement during the Development phase.

Separation of UI and Code

What does it mean to have a separation of UI and code? Typically in an application, code for the UI and code for the logic and data handling is tied up together. The two might be in separate files, but it doesn’t mean they are separate. The UI is created by using code. For example, code to create a button can look something like this:

Button okButton = new Button();

What if you want to change the location of the button or the appearance of all the buttons in a dialog? There is code for that too. Inevitably, as we refine designs through usability tests and customer validation, we create the need for someone to make changes to code. Using XAML, we designers can make our own UI changes without the need to rely on the programmers. Let’s look at some XAML to see a simple example of how this works.

XAML is XML and is stored in a file with an extension of .xaml. The following snippet of XAML adds a ingle button to a grid:

  <Grid> 

    <Button Name="myButton" Width="130" Height="35">

This is a Button

    </Button>

  </Grid>

This XAML creates the following output when displayed:

 
What if we wanted to add an image inside the button? This is easy to accomplish in XAML:

  <Grid> 

    <Button Name=”myButton” Width="135" Height="40">

    <StackPanel Orientation="Horizontal">

      <Image Width="30" Height="30" Source="icon-checkmark.gif"/>

      <TextBlock VerticalAlignment="Center" Margin="2">This is a button</TextBlock>

    </StackPanel>

    </Button>

  </Grid>

The updated XAML produces the following:

As you can see, most of the attributes in the XAML are easy to understand: Width and Height, for example. The basics are accessible enough for any designer to manage; more technically oriented designers can go deeper with XAML for additional control of UI elements.

So how does XAML help to separate the UI from the logic? Notice there is nothing in the XAML snippet that relates to event handling, which is still mostly handled in the code along with anything logic oriented. The look and feel of the user experience – ranging from the location of controls to rollover animation effects - is all handled in XAML.  Designers can even control button- click behaviors as long as the associated events affect UI elements that are also defined in the XAML.

A single attribute of the Button creates a bridge between the UI and the logic, which enables the separation. The ‘Name’ attribute (in this case “myButton”) enables a developer to handle all events for the button, for example the click event.  A developer makes changes to the click event in the code file; a designer changes the look-and-feel and location in the XAML file. The Name of the button in the XAML or the code file must remain unchanged by the designer or developer.

Many simple design tweaks such as change of location and appearance are easy with XAML, but these examples only begin to tell the story of XAML and WPF. In future posts, I will describe how designers use animation, control templates, data binding and styles in XAML to take full control over the user experience.

For a more comprehensive examination of XAML and the designer/developer relationship, check out this article by Karsten Januszewski and Jaime Rodriguez.