Software user interfaces are constantly evolving and improving. I remember back when I was still working with an early version of Windows and looking at Mac OS with envy. Then, I remember seeing Linux systems with radical new desktop interfaces. More recently, I found myself looking again at the Mac OS X Dock (see Figure 1-1) and wanting that for my Windows XP machine—to the point where I purchased a product that mimicked it. I was dedicated to Windows through it all, but I was envious of some of the user experiences the different environments offered.

Figure 1.1. The Mac OS X Dock feature

The evolution of the user interface continues in the Windows operating system. Perhaps the most prominent difference between Windows 7 and previous versions of Windows is user interface improvements. Microsoft was very intentional on improving the richness of the operating system. One example is the new taskbar, where large icons replace the text descriptions and when the user places the cursor over an icon will display a window thumbnail, as shown in Figure 1-2.

Figure 1.2. Windows 7 improved taskbar

Another user interface improvement in Windows 7 is the Aero Snap. This feature allows you to easily maximize your window by dragging it to the top of the screen, but it also allows you to drag the window to the left or right edge of the screen in order to tile the window to 50% of the left or right side of the screen as shown in Figure 1-3.

Figure 1.3. Windows 7 Aero Snap feature

These features reflect how operating systems have evolved over the years, but the same evolution pertains to all areas of development, and for just about all industries. It is now expected that applications not only contain necessary features, but that they also have slick user interfaces. However, while rich applications are now expected, it is not necessarily the priority for developers. Over the last decade, there has been a struggle to find the right balance of "rich" and "reach" in applications. If you consider standard desktop applications, the applications are installed on individual client machines. They allow for very rich and responsive user interfaces and additional features, such as offline support. Performance of the application depends on the machine on which it is installed. While desktop applications have a very rich experience, they have very small reach. The application needs to have a code base for each target platform, and every machine needs to have the application installed and maintained.

In contrast, we have web applications, which are HTML-focused programs designed to run within a browser and across platforms. For the Microsoft-based developer, this has recently meant developing with ASP.NET and building web services to offer services over the Internet. The focus of most of the logic and code has been placed on the server for the benefit of application performance. The price has been a poor user interface. These applications had excellent reach, but they were not very rich, as shown in Figure 1-4. Between these two extremes there is a clear gap between the technologies.

Figure 1.4. Rich and reach application comparison

To fill this gap, a new development approach has surfaced, as shown in Figure 1-5. This new approach is termed RIA (Rich Internet Applications), which is defined as a web application that has the features and functionality found in traditional desktop applications. Although there are a number of RIA technologies, including Microsoft's Silverlight.

Figure 1.5. RIA fills the gap between rich and reach applications

The concept of RIA has been around for quite some time, but the term rich Internet application was first used in 2002 in a Macromedia white paper. Before then, the terms remote scripting and X Internet were used to describe the concept.

Today, many different solutions fit the description of RIAs, but there is one consistent characteristic: all RIA solutions involve a runtime that runs on the client machine and architecturally sits between the user and the server.

In recent years, the technology that is most commonly used in RIAs is Flash. When Flash was introduced, it brought to the Web rich user experiences never seen before. However, due to the lack of tools allowing Microsoft .NET developers to integrate Flash into their applications, to those developers Flash just seemed like a tool for adding some pretty effects to a web page, but nothing functional.

Then a wonderful thing happened when Adobe purchased Macromedia. All of the sudden, Flash was married to some of the development tools offered by Adobe. Microsoft retaliated by announcing Silverlight, formerly known as Windows Presentation Foundation Everywhere (WPF/E). Silverlight is the technology that many .NET developers have been waiting for.

What exactly is Silverlight? And, what impact does Silverlight actually have on us as .NET developers? Well, I'm glad you asked.

As I explained in the previous section, all RIAs have one characteristic in common: a client runtime that sits between the user and the server. In the case of Microsoft's RIA solution, Silverlight is this client runtime. Specifically, Silverlight is a cross-platform, cross-browser plug-in that renders user interfaces and graphical assets on a canvas that can be inserted into an HTML page.

The markup used to define a Silverlight canvas is called Extensible Application Markup Language (XAML, pronounced "zammel"). XAML is an XML-based language that is similar to HTML in some ways. Like HTML, XAML defines which elements appear, as well as the layout of those elements. However, unlike HTML, XAML goes far beyond simple element definition and layout. Using XAML, you can also specify timelines, transformations, animations, and events.

The following is an example of a Silverlight canvas defined in XAML:

<UserControl
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        x:Class="FirstLookXaml.MainPage"
        Width="640" Height="480">

        <Canvas x:Name="LayoutRoot" Background="White">
                <Rectangle Height="119" Canvas.Left="75" Stroke="Black"
                   Canvas.Top="92" Width="183"/>
                <Ellipse Height="119" Canvas.Left="347" Stroke="Black"
                 Canvas.Top="92" Width="189"/>
                <Button Content="XAML Rocks!" Height="43" Canvas.Left="233"
                Canvas.Top="285" Width="161"/>
        </Canvas>
</UserControl>

Figure 1-6 shows this canvas in Microsoft Expression Blend, the design tool used to edit and create XAML for Silverlight applications. You can see that this XAML simply defines a rectangle on a canvas, as well as the properties associated with that rectangle, including its name, location, size, color, and border.

This simple example is just intended to give you an idea of what XAML looks like. You'll learn more about XAML in upcoming chapters. For now, let's continue by looking at the benefits of Silverlight.

Figure 1.6. A basic XAML canvas in Microsoft Expression Blend

Naturally, Silverlight offers all of the same benefits of RIAs, but there are a few features that set it apart from other RIA solutions, including the following:

Let's take a closer look at each of these benefits.

Small Runtime and Simple Deployment

Since Silverlight requires that a client runtime be installed on the client machine, it is vital that this runtime has a small footprint and downloads quickly. Microsoft worked very hard to get the installation size as small as possible. The developers clearly succeeded with Silverlight 1.0, as the download size is a tiny 1MB. For Silverlight 2, however, they had a harder chore ahead of them, since Silverlight 2 contains its own .NET Framework and object library. Microsoft went to each .NET Framework team and allocated it a size to fit its portion. The end result is astonishing—Silverlight 2 is approximately 4MB in size. In Silverlight 4, even with the large amount of new features that have been added to the Silverlight runtime, the file size is still less than 6MB.

As for pushing the Silverlight runtime out to clients, Microsoft has provided a very easy detection mechanism. If the client does not have the proper Silverlight runtime installed, it will display a logo, similar to the one shown in Figure 1-7.

Figure 1.7. Silverlight runtime required logo

When users click the icon in the logo, the Silverlight runtime will start to download. Once the runtime is finished installing, the Silverlight application is immediately available to the user.

In the past, setting up an environment to work with Microsoft's latest and greatest has been relatively straightforward, typically involving only the setup of the latest version of Visual Studio and the appropriate software development kit. However, with Silverlight, the situation is quite a bit different due to the introduction of many new tools. Let's look at the tools involved in setting up a Silverlight 4 development environment.

Silverlight continues to evolve and Microsoft continues to add new features to Silverlight in each version. There are many new features introduced in Silverlight 4. This section will go over some of those new features and will indicate where those features are discussed in this book.

In this chapter, you looked at the evolution of user interfaces in applications, as well as the history of RIAs. I then introduced Silverlight, talked about the benefits it brings to developers today, and how it fits into RIA solutions. Finally, you learned about the tools involved in developing Silverlight-enabled applications.

Now it is time to get your hands dirty and start building some Silverlight applications! In the next chapter, I will provide an introduction to Microsoft Visual Studio 2010, one of the primary tools used to build Silverlight applications.