Managing Data and Media in Microsoft Silverlight 4: A mashup of chapters from Packt's bestselling Silverlight books

By Gaston C. Hillar , Gill Cleeren , Kevin Dockx and 7 more
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Layouts and General Content Organization

About this book

Microsoft Silverlight is a programmable web browser plugin that enables features including animation, vector graphics, and audio-video playback – features that characterize Rich Internet Applications. However, Silverlight is a great Line-Of-Business platform and is increasingly being used to build data-driven business applications. This book will enable .NET developers to get their finger on the pulse of data-driven business applications in Silverlight.

Managing Data and Media in Silverlight 4: A mashup of chapters from Packt's bestselling Silverlight focuses on showing .NET developers how to interact with, and handle multiple sources of data in Silverlight business applications, and how to solve particular data problems following a practical hands-on approach, using real-world examples. This book is a collections of media and data based chapters from Packt’s best selling Silverlight books:
1. Silverlight 4 User Interface Cookbook
2. Microsoft Silverlight 4 Business Application Development: Beginner’s Guide
3. Microsoft Silverlight 4 Data and Services Cookbook
4. Microsoft Silverlight 4 and SharePoint 2010 Integration
5. Microsoft Silverlight 4: Building Rich Enterprise Dashboards
6. 3D Game Development with Microsoft Silverlight 3: Beginner's Guide

The book starts with discussion on layouts and content organization and covers all the options available to access data and communicate with services to get the most out of data in your Silverlight business applications, at the same time providing a rich user experience. Understand sophisticated data access techniques in your Silverlight business applications by binding data to Silverlight controls, validating data in Silverlight, getting data from services into Silverlight applications and much more! Discover the tips, tricks and hands on experience to create, customize and design rich enterprise dashboards with Silverlight from a distinguished team of User Experience and Development authors.

This book contains real-world examples that depict various techniques for interacting with data and services provided by this powerful business collaboration platform, for the enterprise and the Internet. The book ends with an appendix covering 3D Game Development.

The TOC with parent books in brackets:

Chapter 1: Layouts and General Content Organization (Silverlight 4 User Interface Cookbook)
Chapter 2: Handling Data (Microsoft Silverlight 4 Business Application Development: Beginner’s Guide)
Chapter 3: An Introduction to Data Binding (Microsoft Silverlight 4 Data and Services Cookbook)
Chapter 4: Advanced Data Binding (Microsoft Silverlight 4 Data and Services Cookbook)
Chapter 5: The Data Grid (Microsoft Silverlight 4 Data and Services Cookbook)
Chapter 6: Talking to REST and WCF Data Services (Microsoft Silverlight 4 Data and Services Cookbook)
Chapter 7: Interacting with Data on the SharePoint Server (Microsoft Silverlight 4 and SharePoint 2010 Integration)
Chapter 8: Interacting with Rich Media and Animations (Microsoft Silverlight 4 and SharePoint 2010 Integration)
Chapter 9: Building Dashboards in SharePoint and Silverlight (Microsoft Silverlight 4: Building Rich Enterprise Dashboards)
Chapter 10: Data Access Strategies (Microsoft Silverlight 4: Building Rich Enterprise Dashboards)
Appendix: Working with 3D Characters (3D Game Development with Microsoft Silverlight 3: Beginner's Guide)

Publication date:
February 2012
Publisher
Packt
Pages
526
ISBN
9781849685641

 

Chapter 1. Layouts and General Content Organization

Note

This chapter is taken from Silverlight 4 User Interface Cookbook (Chapter 1) by Vibor Cipan.

In this chapter, we will cover:

  • Liquid versus fixed layouts

  • Navigation pane and how to create one from scratch

  • Window management and positioning

  • Wizards

  • Progressive disclosure—showing additional controls on demand

  • Control docking with Dock Panel

  • Journal navigation

  • Tabs

  • Status bar area

Introduction

Before we start building any application, regardless of being a web application built with Silverlight or a typical desktop application built with Windows Presentation Foundation, we will be faced with making some very basic and extremely important decisions. Will our application be able to scale to all of the different screens and resolutions or are we going for a fixed size? Other than that, how are we going to navigate through data presented in our application? How do we deal with windows and their positions, sizes, and states? We might go further and ask ourselves—can we conceive our application as the number of steps that users have to go through to complete one or more tasks? In that case, we might consider using the wizard UI pattern—how to create wizards and use Aero Wizard guidelines instead of older and obsolete Wizard97 guidelines.

What will happen if we present too much data and information to the users, especially the data is irrelevant at the moment? It might lead to user confusion and dissatisfaction. Then, we can consider using the progressive disclosure and interesting UI patterns, which will help us cope with the "control and data overload" challenges.

When we change the screen resolution or resize our windows or pages (please note that throughout this book these terms are being used to designate both, windows as parts of desktop applications and pages as parts of web applications, and in many cases UI patterns are same for both of those), controls might need to change their position, or even size. How do we implement and efficiently use control docking and scaling in those scenarios?

Tabs are really useful: they enable us to put different content and controls on them. but despite them being so well-known, they are often misused and their usage can lead to a user's frustration. How do we use tabs properly and avoid having our users being frustrated and unhappy with our UI?

Often, applications need to communicate information to their users. Some use pop-up windows, message boxes, or status bars. When should you consider using a status bar in your applications and when might it be a better idea to use some other UI pattern?

This introduction has asked a lot of relevant questions. Now, it's time to proceed to some concrete answers and patterns.

 

Introduction


Before we start building any application, regardless of being a web application built with Silverlight or a typical desktop application built with Windows Presentation Foundation, we will be faced with making some very basic and extremely important decisions. Will our application be able to scale to all of the different screens and resolutions or are we going for a fixed size? Other than that, how are we going to navigate through data presented in our application? How do we deal with windows and their positions, sizes, and states? We might go further and ask ourselves—can we conceive our application as the number of steps that users have to go through to complete one or more tasks? In that case, we might consider using the wizard UI pattern—how to create wizards and use Aero Wizard guidelines instead of older and obsolete Wizard97 guidelines.

What will happen if we present too much data and information to the users, especially the data is irrelevant at the moment? It might lead to user confusion and dissatisfaction. Then, we can consider using the progressive disclosure and interesting UI patterns, which will help us cope with the "control and data overload" challenges.

When we change the screen resolution or resize our windows or pages (please note that throughout this book these terms are being used to designate both, windows as parts of desktop applications and pages as parts of web applications, and in many cases UI patterns are same for both of those), controls might need to change their position, or even size. How do we implement and efficiently use control docking and scaling in those scenarios?

Tabs are really useful: they enable us to put different content and controls on them. but despite them being so well-known, they are often misused and their usage can lead to a user's frustration. How do we use tabs properly and avoid having our users being frustrated and unhappy with our UI?

Often, applications need to communicate information to their users. Some use pop-up windows, message boxes, or status bars. When should you consider using a status bar in your applications and when might it be a better idea to use some other UI pattern?

This introduction has asked a lot of relevant questions. Now, it's time to proceed to some concrete answers and patterns.

 

Fluid layout


There are two basic types of layouts that I want to consider here. First is the "fixed" layout, which basically means that all of the elements on your page or window will remain of the same size, irrespective of the screen resolution or other form factor. Then, there is "fluid" layout, which is good for enabling your content to adjust in a size that is appropriate for the current screen resolution, page dimensions, or generally the form factor that your users will be using.

I am going to show you how to create a simple example of fixed and fluid layout in Silverlight. After that, I will give you some guidance on when to use fixed and when to use fluid layouts.

Getting ready

Start your Expression Blend 4 and then select New project... From the dialog that appears select Silverlight and then Silverlight Application, make sure that Language is set to C# and Version is 4.0. At the end hit OK.

Note

Some recipes in this chapter are dealing with WPF, not with Silverlight. However, ideas, methods, approaches and user experience guidelines are applicable to both technologies.

Now we will see how to create a fluid layout design.

How to do it...

We will create two examples: the first one will demonstrate fluid layouts and the second one, fixed layouts.

  1. 1. After you have created your new project, under the Objects and Timeline pane, you will see UserControl and LayoutRoot. LayoutRoot is a grid control hosted in UserControl.

  2. 2. Click on UserControl and change its height and width to Auto. To do that, go to Properties | Layout and change these properties. You will notice that they are set to 640 and 480 by default. Click on the little cross-arrows to set them to Auto.

  3. 3. Now, let's change the background color of LayoutRoot. Click on it in the Objects and Timeline pane, then go to Properties pane, navigate to the Brushes section, click on Background, select Solid color brush (second icon in the row), and select any color.

  4. 4. Press F5 or go to Project | Test Solution.

  5. 5. Your default web browser will start and you will see that the entire surface is covered in the color that you have previously set for your UserControl. Try resizing the browser and you will see that the surface is still completely covered with the selected color.

  6. 6. Close your browser and return to Blend.

  7. 7. Now we will add some objects on top of LayoutGrid and explore their behavior.

  8. 8. Change the design-time size of your UserControl by clicking and dragging handlers. Be sure to select UserControl before you start resizing. Note that this is changing only the design-time dimensions; run-time dimensions are still set to Auto.

  9. 9. On the toolbox (usually a left aligned, vertical stripe with a number of different controls and tools), locate and select the Rectangle tool. You can also select it by pressing the M key. Draw several rectangles on top of LayoutRoot.

  10. 10. Again, press F5 to start your project.

  11. 11. Play with your web browser now. Try changing the height and width and notice the behavior of the rectangles; they will also change their dimensions. You don't need to think about the mechanics behind this behavior right now.

  12. 12. Close your browser and return to Blend again.

How it works...

How does it really work? The first step was changing the width and height properties of our UserControl to Auto. By doing so, we have allowed it to stretch automatically and fill in all available space. Simple as that! As our LayoutRoot is Grid control and its height and width properties have been set to Auto as well, LayoutRoot has also filled in all available space. We have just changed its color to make it more distinguishable. That is why our browser has been filled with LayoutRoot.

After that, we added several rectangles to our LayoutRoot. And here is where some interesting behaviors start. Depending on the position of rectangles, some of them have been aligned horizontally or vertically to different sides of LayoutGrid. You can easily check that by clicking on them and then looking at HorizontalAlignment and VerticalAlignment under the Layout section within the Properties pane. Depending on that alignment, rectangles have been resizing when you have resized your browser. This was a very basic illustration of a liquid type of layout. We implement such a layout by using the grid control. Next, we will see how to make a fixed layout design.

How to do it...

The steps are the same as those of the previous example—the creation of liquid fluid layout. I will assume that you have followed those directions and will take it from there.

So, the main difference will be that instead of using Grid for LayoutRoot, we will use Canvas.

  1. 1. Right-click on LayoutRoot in the Objects and Timeline pane and from the menu, select Change Layout Type | Canvas.

  2. 2. Hit F5 to test your project.

  3. 3. Try resizing your browser again. Notice that the rectangles are keeping their positions as well as their dimensions intact. No matter what you do with your web browser size, they will be the same.

How it works...

What happened after we changed our Grid control to Canvas type of control in the second example? All our rectangles have retained their size and positions, no matter what we have done with browser. The reason lies in the fact that Canvas control used the so-called "absolute positioning" and no layout policy is being applied to its child elements (rectangles in our case). You can literally consider it as a blank canvas.

There's more...

To summarize, if you require maximum layout flexibility, you will use Grid control. It employs a number of different rules that can be applied to its child elements. For fixed layouts, which are not dependent on the screen size or resolutions, you will use Canvas control with absolute positioning.

More info about grid sizing, rows, and columns

The grid is a truly versatile control and it enables you to build very flexible and sometimes complex layouts.

A really important concept includes the possibility of dividing the grid into rows and columns, so that you get even more flexibility for your layouts. With grid control selected, position your mouse pointer over its border. You will notice that the mouse pointer will change its appearance and look like the following screenshot. You can click to add gridlines and define columns and rows in that way.

Now it is important to understand that the grid supports three ways of defining sizes for columns and rows—fixed, star, and auto.

Fixed sizing uses exact pixel values to define row or column dimensions and means that they will not resize. Star sizing is using relative dimensions. In fact, it just indicates that width should be relative to the other star-sized columns (or rows, for that matter).

Consider the following examples:

<ColumnDefinition Width="0.5*"/>
<ColumnDefinition Width="0.5*"/>
<ColumnDefinition Width="*"/>
<ColumnDefinition Width="*"/>
<ColumnDefinition Width="1000*"/>
<ColumnDefinition Width="1000*"/>

These three definitions will have the same column width. They will be identical with each column occupying the same amount of space.

Now, consider this sample:

<ColumnDefinition Width="1000*"/>
<ColumnDefinition Width="2000*"/>

Here, the second column will be exactly two times bigger than the first one—a ratio of 2:1.

Auto sizing means that the elements contained in a grid will also resize when the parent element resizes. It also means that the size of that column or row will depend on the size of the object that is located in that specific column or row.

In XAML code, those definitions can look like this:

<Grid x:Name="LayoutRoot">
<Grid.ColumnDefinitions>
<ColumnDefinition Width="69"/>
<ColumnDefinition Width="0.52*"/>
<ColumnDefinition Width="Auto"/>
<ColumnDefinition Width="69"/>
</Grid.ColumnDefinitions>
</Grid>

If you omit the width definition, Blend will automatically use star sizing.

More detailed information about Grid and Canvas panel controls can be found in the Microsoft Expression Blend User Guide. Just hit F1 to access it within your application.

When to use fixed and when to use fluid layouts

As you might have guessed already, there is no definite suggestion as to whether you should use only one of those layout types. Most likely, you will be using both of them. For example, message boxes or some dialogs will not benefit from resizing, but general application workspaces and web pages might want to look into using the most or all the space available to them in a meaningful manner. Also, if you need to preserve some fixed positions, you will use a fixed layout system.

However, there are some proven practices outlining the usage of fixed and fluid layouts.

Fixed layout works well for message boxes displaying information or errors to end users. They will not benefit significantly by adding the ability to resize them. Same goes for dialog boxes presenting users with progress on operations such as file copying or deleting. Keep their sizes fixed. Of course, you will ensure that they look good at different screen resolutions by testing them. You can even try to optimize content positioning, depending on the current screen resolution, but you should not allow users to resize those types of windows. If you consider web environments (you can apply the same principles here), all those modal windows, pop-up dialogs, and message boxes should be of a fixed size.

When it comes to fluid layouts, the situation is more complex and it is more challenging to give design guidelines. But generally, you should use liquid layout type in cases where your application and dialog boxes can benefit from more space available to them. If you are building a file browser, you should implement the "liquid layout" system and use all available space to show as many files and folders as possible, so that your users can select them without scrolling too much. The same goes for web pages—in general, you would want to use as much space as possible for your content. But you should be aware that there are limits. You can put your textual content on the web page in liquid layout and enable it to resize together with your web browser and use the extra space available to them. But from the usability point of view, lines of text that are too long will decrease readability dramatically. Today, screen sizes are often over 20 inches and the trend of increasing sizes will continue into the future for some time—does that mean that you should enable your text or controls to scale accordingly? Absolutely not! The general rule is that your line of text should not be longer than about 66 characters. The reason for that is the fact that the human eye struggles with reading lines longer than that. I recall seeing that suggestion in The Elements of Typographic Style written by Canadian typographer, Robert Bringhurst. If you apply some good fonts and think about the overall appearance, you can go up to 75 characters, but don't go over that.

What I like to do is define three sizes for my UI elements: preferred (which is basically default or optimal) size, minimum size, and maximum size. Preferred size is the size that the specific UI element will have on a given screen resolution. Minimum size is the size that will be the smallest size each element can scale to. For example, you can choose to set the minimum size of your window to 800 by 600 pixels and optimize all controls within it to fit into that. Also, by setting maximum size you can ensure that your form and controls will not stretch too much (as I suggested a moment ago when talking about text length). The great thing is that WPF and Silverlight also support these sizes and you can set them for each control you add to your UI.

Other suggestions for dealing with controls in liquid layouts include keeping navigation elements (in web pages) anchored to top and left margins. Controls such as text boxes, tables, grids, and list views should increase their lengths and possibly even widths but again, recall what I have said in the previous paragraph about too long text lines—same applies to all controls. If you are using background colors, patterns, or similar elements, they should fill the new space completely and that is the only case where you should use all space available.

It is also important to think about what will happen if your window or web page gets too small for its content. As I said earlier, set the minimum size for each and every control including container controls such as windows or pages. Optimize the layout for that case. If you don't do that, your controls might become inaccessible during run-time, aesthetic dimension will be also destroyed, and your application will become practically useless or extremely hard to use.

Most WPF and Silverlight controls will adjust nicely by adding scrollbars to help adapt to these changes, so that will spare you from implementing all that logic by yourself.

Don't be afraid to put some constraints on liquid layouts, sometimes too much flexibility will harm your user's experience though your intentions were quite the opposite. I am a firm believer that by limiting certain aspects of UI flexibility we are actually helping our users and building better experiences.

See also

  • Control docking with DockPanel

 

Creating a navigation pane from scratch


If you have ever used Microsoft Outlook 2007 or even earlier versions (and the chances for that are pretty high), then you are already familiar with the concept of the navigation pane.

Navigation pane consists of two major parts—content and buttons. Depending on the selected button, the content part will be changed. The content part can host a number of different controls, such as tree view.

In this recipe, I will show you how easy it is to use tab control from WPF and create a basic navigation pane control that resembles the look and feel of the Outlook's navigation pane.

However, be sure to understand that this is not a replacement for third-party navigation pane controls, which offer much better and richer functionalities; but of course, all those goodies come at some price.

So, if you need a really simple navigation pane, let's say for your prototyping efforts, then you can use this recipe and create one. If you are creating a commercial, line-of-business application, then you should consider getting one of those fully blown controls available on the market.

That being said, this recipe is useful even if you go and buy third-party controls because general usage ideas and guidelines are equally applicable. And, it does seem surprising at the moment, but basic guidelines used for tabs may be applicable to a navigation pane pattern too.

Getting ready

Start your Expression Blend 4 and then select New project... From the dialog that appears, select WPF and then WPF Application. Make sure that Language is set to C# and Version is 4.0. At the end hit OK.

How to do it...

  1. 1. After your new WPF project has been created, you should notice that under the Objects and Timeline pane, Window and LayoutRoot grid controls are visible.

  2. 2. Go to Asset Library and draw a TabControl on top of LayoutRoot. With TabControl selected, go to the Properties pane and set all margin values to 0 and Width to 250. This will align the tab control to the left-hand side and stretch it from the top to the bottom of your window, giving it a specified width.

  3. 3. Right-click on TabControl under the Objects and Timeline pane and from the drop-down menu, click on Add TabItem. Repeat this once again so that you end up with four tab item controls added under the TabControl parent. Your visual tree should look somewhat similar to the following screenshot:

  4. 4. Now select each TabItem and under the Properties pane, locate the Common Properties section and Header property. For each tab item, type the header value. You can go with the values found in Outlook 2007, for example, Mail, Calendar, Contacts, and Tasks.

  5. 5. Select TabControl and under the Common Properties section, change TabStripPlacement to Bottom. If you now go and press F5 to test your application, you will notice that tabs are located at the bottom. We are still fairly far away from the complete navigation pane found in Outlook but you can start to see where we are heading.

  6. 6. The next step is modifying the control template of the tab control. Right-click on TabControl and from the drop-down menu, click on Edit Control Parts (Template) | Edit a Copy... —a new dialog Create Style Resource will appear. Keep the default Name (Key). Notice the possibility to define this template on an application- or document-wide scope. Also, you can create a separate resource dictionary and use that file for all specific styles and templates. I will choose that approach this time and will use the same file for all other styles that I am going to create in this recipe. So, click on New... and accept the defaults from the new dialog. Now hit OK on the first dialog, and just make sure that under the Define in section, the resource dictionary is selected with the name of the RD file that you have just created.

  7. 7. Now you are in template editing mode. If you now take a look at the Objects and Timeline pane, you will notice that the scope has been set to TabControlStyle1—our TabControl template. This enables us to modify the look of our controls without making an impact and destroying their functionality.

  8. 8. Click on HeaderPanel and notice that HeaderPanel is of the TabPanel type. You can see that at the very top under the Properties pane. We need to change TabPanel to StackPanel. To do that, press F11 to switch to "XAML" or "Split" view, which will enable you to edit the XAML code. Locate the following line:

    <TabPanel Margin="2,2,2,0" x:Name="HeaderPanel" Grid.Column="0" Grid.Row="0" IsItemsHost="true" Panel.ZIndex="1" KeyboardNavigation.TabIndex="1"/>
    
  9. And change it to:

    <StackPanel Margin="2,2,2,0" x:Name="HeaderPanel" Grid.Column="0" Grid.Row="0" IsItemsHost="true" Panel.ZIndex="1" KeyboardNavigation.TabIndex="1"/>
    
  10. 9. Now save all your files and go to the Window1.xaml file (basically, your main file).

  11. 10. Press F5 to test your application now and notice that the tabs are now stacked pretty much in the same way as they are in Outlook 2007: one above the other.

  12. 11. Let's go and make more changes. Select all tab item controls (CTRL + click) and then change their height to 32. Also, change the left and right margin values to -2. Now, your navigation pane is starting to look like a real one from Outlook.

  13. 12. Take a look at the There's more... section (of this part) for further possibilities of customization and changes.

How it works...

The key for understanding how this pattern and recipe works is pretty simple. The navigation pane control seen in Outlook is nothing more than TabControl with tabs stacked vertically, and that's the whole truth. We have added simple TabControl to our artboard and decided to change its control template.

Once we were there, everything became pretty simple and straightforward. First step was to change TabPanel to StackPanel. Literally, we just changed one thing in the whole of XAML code and our tabs have stacked vertically one above other, which is the basic characteristic of StackPanel as a control.

After that everything else was pretty much just cosmetics treatment. We've changed the tab item's height to 32 and we have made some changes to the Margin property in order to align and stack each and every tab item nicely.

Again, I find it necessary to repeat that this is not a replacement for third-party navigation pane controls that are offering better and richer functionalities.

There's more...

In this section, I will show you how to add more functionalities and even further customize your navigation pane.

Hosting content into specific tabs

Remember that we have changed the control template of our TabControl but that the functionality has been preserved completely. As a consequence, the process of hosting and adding different content to tabs is the same as it is for regular tabs.

  1. 1. Let's continue from the last step in our recipe. If you expand any TabItem under the Objects and Timeline pane, you will notice that it is comprised of two major parts—Header and Grid. Click on Grid to make it active.

  2. 2. Now you can add any control from Asset Library or any other object like you would on any other grid-like control. Try experimenting by adding different controls. In the code sample that you can download from this book's website, I've added a simple TreeView control under the Mail tab.

How to align header text to left

Again, I will take it from the last step. So, our next challenge is to left-align labels such as Mail, Calendar, and others. To do this, we will need to edit a control template for the TabItem control.

  1. 1. Right-click on any tab item, let's say the first one with the Mail label. From the drop-down menu, click on Edit Control Parts (Template) | Edit a Copy..., and the Create Style Resource dialog will appear. Accept the suggested Name ( Key) and under the Define in section, select Resource dictionary. You'll remember that we defined our resource dictionary earlier as a single location where we will keep all our templates and styles. When ready, click on OK.

  2. 2. Now we are able to edit the template for our tab item. If you take a look at the Objects and Timeline pane, you will see the visual tree for our TabItemStyle1. Expand all nodes until you can see an object called Content (which is of ContentPresenter type). Click on it and go to the Properties pane. Locate the Layout section and you will see the HorizontalAlignment and VerticalAlignment properties. They are surrounded with a yellow border, and from them, you can see a little, yellow square, which indicates that these values have been bounded to the control template.

  3. 3. We want to set our own bindings. Click on the little square and from the drop-down menu click on Reset. Do this for both the HorizontalAlignment and VerticalAlignment properties.

  4. 4. Now, set Left as the value for HorizontalAlignment and Center for the VerticalAlignment property.

  5. 5. If you now go and hit F5, you will notice that the Mail label has been left-aligned, but that is not the case for the rest of the labels. The reason for this is the fact that in previous steps we have edited a copy of the control template and applied it to only the first tab item.

  6. 6. In order to get all labels left-aligned, go to your Window1.xaml file and under the Objects and Timeline pane, right-click on the next tab item. From the drop-down menu, select Edit Control Parts (Template) | Apply Resource | TabItemStyle1.

  7. 7. Repeat the same procedure for the rest of the tab item controls and then hit F5 to test your application. Now all the labels are left-aligned.

  8. 8. Note that you can also add other controls in our TabItem style, for example, images.

When to use navigation pane?

As its name implies, the navigation pane is a control or pattern (if you like) that is focused on navigation. But what type of navigation? Is it the same as journal navigation?

First and foremost, a pattern or control (if you prefer calling it that) is never used alone. It is (or should I say, it must be) used as part of a wider navigation concept. While a regular tab control with specific tabs is useful for property pages, dialogs, and different types of content organization, the navigation pane is great for application-specific navigation.

In the real world, it means the following—you will position the navigation pane on the left-hand side of your application. When you click on specific buttons (tabs that is), they will expose content in their upper "container" part. In our recipe, that was the TreeView control added on the Mail tab.

The most relevant and interesting things happen when users click on different items within the container part of a navigation pane. Then, application-wise navigation occurs. If you have challenges picturing this, go to Outlook and simply try clicking on Mail, and after that on the Inbox, Outbox, or Sent Items folders. You will notice that the right-hand part of your application changes. Virtually the same pattern is available in Microsoft Dynamics products such as NAV or AX, and many others as well.

I've mentioned earlier that most guidelines and suggestions that I've outlined for tabs hold true for the navigation pane as well. However, I will reiterate some of them and also point out some differences right here:

  • Tabs (or buttons) such as Mail, Calendar, and so on must be linear in their structure, which means that there is no hierarchy in their organization—Mail is not a parent of Calendar and so on. Simply put, each and every tab or button must be mutually independent. But you are free to host hierarchy-based controls such as a "tree view" within your navigation pane.

  • The navigation pane is for navigation. It's not a regular tab control used for organizing your content, controls, and properties. It's not a wizard too: don't ever use it as a control that should guide users through wizard-like processes.

  • The first tab or button should be the one that is most likely to be most used and it should be selected by default. Again, using Outlook as a sample, the first tab is Mail —the one that is being used the most.

  • Feel free to use icons. That was not something that I've been encouraging in the case of tabs, but here, you have enough space and you don't have to be afraid that you will make too much of a visual clutter. Sure, that holds true only if you use nice, clear, recognizable, and understandable icons.

  • Don't use any kind of terminating or similar type of button within the container part of a navigation pane; no OK, Cancel, or Apply buttons here. It's called the "navigation pane" and it should do just that—help your users to navigate to or expose different parts of your application and help them get their jobs done quickly.

  • Have I mentioned that in your real life applications, you should use full-blown, third-party navigation pane controls and not this? We've created a really basic one here? This was a nice learning example and all of the suggestions stated here are applicable to real-world commercial navigation pane controls. And yes, I'm not really able to give you any suggestions on which control you should use, but there are numerous vendors offering them and I'm sure you will find them easily on the Internet.

See also

  • Tabs

 

Window management and positioning


Often overlooked or even completely ignored, window management presents the basic of any window based desktop application. Though this recipe will be focused on WPF and desktop applications, today, window management plays an important role in web environments as well where different types of modal, dialog, and message box windows are appearing. As a consequence, most ideas and general guidelines presented here might be quite useful for web solutions as well.

This recipe will cover several basic ideas and approaches regarding window placement, their positions, and size.

As there are several concepts being described here, I have, when it seemed appropriate to do so, created smaller sub-recipes that are building on previous ones.

WPF provides a fairly rich window management model but it is upon developers and designers to come up with the right usage and interactions involving windows. This recipe aims to help you with that challenge.

Getting ready

Before we proceed any further, it is a good idea to define several concepts that we will be using and relying on during this recipe. You can think of this as a small dictionary and it is compatible with Microsoft UX guidelines for Windows Vista and Windows 7 operating systems.

  • Top-level or Primary window: It has no owner window, meaning that this is the one that is displayed on the taskbar and in most cases, can be considered to be the main application window.

  • Owned or Secondary window: It has an owner window and as a general rule, it is not displayed on the taskbar.

  • User initiated window: It is always being displayed as a direct result of a user's actions. Action can be clicking on some buttons, commands, menu items, and so on. Also, there are program-initiated windows—ones that are initiated by an application itself without user's action—and system-initiated windows—ones that are initiated by the underlying operating system itself.

  • Contextual window: It is type of a user-initiated window but with a very strong relationship to the UI object, from which it was invoked and launched. Context is extremely important here and positioning often plays a very important role (it will be covered in this recipe).

So, let's start. We are going to explore window management and that's why I will be using WPF. Start your Expression Blend 4 and then select New project... From the dialog that appears selectWPF and then WPF Application, make sure that Language is set to C# and Version is 4.0. At the end hit OK.

Title bar controls and window borders - How to do it...

After your new WPF project has been created, you should notice under the Objects and Timeline pane that the Window and LayoutRoot grid controls are visible.

  1. 1. Before doing anything, hit F5 and your application will start. Your window will look like this:

    You will see the icon, title, minimize, maximize, and close buttons. If you click on the icon, the system menu will appear. Positioning the mouse cursor on the window borders will allow you to resize the window.

  2. 2. Click on Window | Properties and locate the Common Properties section.

    Changing the icon: By changing the Icon property, you can change the look of the window icon. You can use a number of picture formats—ICO, PNG, BMP, JPG, TIFF, and GIF. Feel free to choose any picture that is available to you for testing purposes. The selected picture will be automatically added to your project.

    Setting the ResizeMode: WPF supports several resize modes and you can select them from the ResizeMode drop-down list. You can pick anything between NoResize, CanMinimize, CanResize (which is the default choice), and CanResizeWithGrip. Select CanMinimize.

  3. 3. The ShowInTaskbar property enables you to choose whether your window will appear on the Windows taskbar. As in this case our window is the primary window, we will want it to appear on the taskbar so leave the ShowInTaskbar property checked.

  4. 4. By setting the Title property, you can set your window title. Set the Title property to Our Main Window.

  5. 5. Now locate the Appearance section and WindowStyle property. From the drop-down list, you can select one of the following options: None, SingleBorderWindow, ThreeDBorderWindow, and ToolWindow. Select SingleBorderWindow, which is the default choice.

  6. 6. Hit F5 now and your window will appear. It should resemble the following screenshot:

    You can see that the icon, title, and control buttons have been affected. We decided to set the ResizeMode property to CanMinimize and users now can minimize the window, but there is no ability to change its size (positioning the mouse cursor over the borders does not enable us to resize it) or maximize it (the Maximize button is disabled). And as you have enabled the ability to display window in the taskbar, you can easily locate it there (like it is the case with most other Windows applications).

Window sizes and states - How to do it...

In this recipe we will deal with window sizes and different states.

  1. 1. With your window selected (under Objects and Timeline pane), go to Properties and locate the Layout section and Height and Width properties.

  2. 2. Set the Width to 250 and Height to 480. Values are in pixels and they will define the size of your window during the runtime.

  3. 3. Now, click on the little arrow pointing downwards (Show advanced properties) and some more properties under the Layout section will be exposed. Locate MinWidth, MinHeight, MaxWidth, and MaxHeight. You can enter your values here and limit the window's maximum and minimum values for both height and width. By default, all minimum values are set to 0, and all maximum values are set to infinity. For the test, set MinWidth and MinHeight both to 200.

  4. 4. Now go to the Common Properties section and set the ResizeMode to CanResizeWithGrip. We want to test the MinWidth and MinHeight effects but in order to do that we have to set ResizeMode to either CanResize or CanResizeWithGrip.

  5. 5. Hit F5 now to test your application. You will notice the resize grip in the lower-right corner. Try sizing your window; you will notice that you cannot resize it to be smaller than 200 by 200 pixels.

  6. 6. Close the window and return to Blend.

  7. 7. Under Common Properties, locate the WindowState property. Click on the drop-down list and you will see following choices: Normal, Minimized, and Maximized. Select Maximized and hit F5 to start your application.

  8. 8. Your application will now start Maximized. If you click on Restore Down, it will be restored to the dimensions you have previously set for its Height and Width properties.

Window positioning - How to do it...

Let's investigate the window positioning options now. As I am going to continue this recipe from the previous one, I will just go to the WindowState property and set it back to Normal before I do anything else.

  1. 1. Okay, now we are ready to continue. With your window selected, go to the Layout section and locate the Left and Top properties. Set Left to 100 and Top to 150. Now when you press F5, your application will start and your window will be positioned 100 pixels from the left and 150 pixels from the top.

  2. 2. Close your application and return to Blend. Now under Common Properties, locate WindowStartupLocation. The drop-down list offers you several choices— Manual, CenterScreen, and CenterOwner. Select CenterScreen and hit F5.

  3. 3. In this case, your application will be automatically centered on your screen and the Left and Top properties that you have set before will be just ignored giving an advantage to the CenterScreen choice set for the WindowStartupLocation property.

Title bar controls and window borders- How it works...

Typical title bar controls are icon, title, and minimize, maximize, and close buttons. Expression Blend allows you to set and manipulate all of them by changing the number of properties described in this recipe.

While Icon and Title and really simple and understandable, let me invest some time and explain the different ResizeMode and WindowStyle properties.

ResizeMode

ResizeMode is a property that is used to describe window behaviors and abilities when resizing is in question. You can control how and if, at all, a user can resize your window. Your choice is reflected in different combinations of Minimize, Maximize, and Close buttons as well as on the ability to resize window by clicking and dragging its borders.

ResizeMode can be set to one of the following values: NoResize, CanMinimize, CanResize, and CanResizeWithGrip.

Let me describe them briefly.

  • NoResize will render your window as non-resizable and only a Close button will be presented in the title bar, allowing users to only close the current window. Positioning the mouse cursor over borders will not allow for any resizing.

  • CanMinimize is the choice that we have taken in our recipe. With this choice, a window can be closed, minimized, and then restored after previous operations. Though both the Minimize and Maximize buttons are shown, the Maximize button is disabled so the user can click only on the Minimize or Close buttons to terminate the window. There is no option to resize the window.

  • CanResize is the default choice. All buttons (Minimize, Maximize, and Close) are present and enabled. Users are able to resize a window by positioning the mouse cursor over its borders—it is the most flexible option available.

  • CanResizeWithGrip allows for the same interaction as CanResize with the addition of the resize grip that appears in the bottom-right corner of the window.

WindowStyle

WindowStyle is a property in charge of the window's border appearance. There are four different possible styles at your disposal: None, SingleBorderWindow, ThreeDBorderWindow, and ToolWindow.

Let's describe them in more detail:

  • None, as its name suggests, shows no title bar and border. All you can see is a simple client area.

  • SingleBorderWindow is the default choice: it shows a window with its standard controls and has a simple, single border.

  • ThreeDBorderWindow is same as SingleBorderWindow but with a pseudo 3D border and it is much heavier in its appearance, as you can see.

  • ToolWindow is a specific window type—a thinner border and a title bar with only a Close button available. However, it is resizable. It is often used as a secondary window for applications with a number of tools and options exposed in them (such as palettes and tools in Paint.NET).

Window sizes and states - How it works...

Blend allows for a really great number of options related to window sizes and their management.

The easiest and simplest way to set up your window's size is to set its Height and Width properties. However, you can use even more advanced properties such as MinWidth, MinHeight, MaxWidth, and MaxHeight. You can change those properties and limit the window's maximum and minimum values for both height and width. By default, all minimum values are set to 0, and all max values are set to infinity.

WindowState

By setting the WindowState property, you can control the appearance of the window in one of the three possible states: normal, minimized, and maximized.

  • Normal state is the default state. In this state a window can be moved and resized, if it is resizable.

  • Minimized state means that the window is collapsed to its taskbar button (in the default case, when ShowInTaskbar is set to True). If it is set to False, the window will collapse to its minimum possible size and place itself in the bottom-left corner of the desktop. It cannot be resized by using a resize grip or by dragging the border although it can be dragged around your desktop.

  • Maximized state means that the window will be expanded to the maximum size it can take. It cannot be resized by using a resize grip or by dragging the border.

Window positioning - How it works...

There are two main ways to go about window positioning. The first one includes setting the Left and Top property, which enables you to precisely position your window on the screen, while the other approach requires setting the WindowStartupLocation property.

WindowStartupLocation

The WindowStartupLocation property handles the initial location of your window. Every window's position can be described with the Left and Top property relative to desktop. You can also use one of the available options for this property: Manual (default), CenterScreen, and CenterOwner.

  • Manual startup location means that the window will be displayed based on Left and Top property values. In case they have been omitted, the underlying operating system will position the window on a specific location.

  • CenterScreen will position the window exactly at the center of the screen on which it was opened. It will ignore Left and Top properties in case they have been set previously.

  • CenterOwner works in a manner similar to CenterScreen but instead of positioning the window on the center of the screen, it will consider the center of the window that opened it as its startup location.

There's more...

This section will show you some more ideas and approaches that you should consider and take into account while designing and using windows as objects in your solutions.

What is the minimum screen resolution you should be targeting?

This is one of the most challenging questions presented in this book, though it seems to be very simple. Today, on the market, you can find a huge variety of different monitors and supported resolutions—from small netbooks to huge, widescreen monitors. Obviously, there is not a single "works for all" resolution. However, when you are designing your application, you must answer this question.

At the time of writing, the minimum supported resolution for Windows OS is 800×600 pixels, though I can't really remember when was the last time I saw some desktop or notebook computer running on this resolution (netbooks might be an exception, for sure).

Taking all this into account, I would strongly suggest that all your fixed size windows do not exceed the 800×600 dimension and the rest of the windows, ones that can be resized, should be optimized for 1024×768 resolution. It is your responsibility to invest time and explore how resizable windows and their content (UI controls) will behave in 800×600 resolution.

Good designers will try to accommodate their application's design and layout for different resolutions so that in case of a higher resolution, your users can benefit from a bigger workspace. As always, it is a question of the right balance and compromise between possibilities, wishes, and limitations.

If you are one of the rare guys around who knows that your application will be used on exclusively higher resolutions, then you have a nice challenge of creating an application that can take the full advantage of additional screen space.

General window usage guidelines

As I've mentioned in previous paragraphs, all your fixed size windows should not exceed the 800×600 dimension and the rest of the windows, ones than can be resized, should be optimized for 1024×768 resolution. If your application has some critical parts and it is supposed to be used in a safe mode environment, you might need to lower the bar and design for 640×480 resolution, but honestly, such cases are really rare, and practically non-existent in typical consumer applications.

When you are testing your windows, use the following table:

DPI / Percentage

Resolution

Performs well?

96dpi 100%

800 × 600

 

120dpi 125%

1024 × 768

 

144dpi 150%

1200 × 900

 

Under the Performs well? column, insert Yes or No based on the following criteria:

  • Are there any layout problems?

  • Do you notice control clipping, text readability problems, or anything related?

  • How do icons and bitmaps perform? Are they stretched? What about alignments?

  • Can users access each and every command in all tested cases?

It is better to use larger initial window sizes and use the space effectively (your users will appreciate that). It's a much better solution than trying to fit everything into a small space.

Don't go over 66 characters for text elements.

Windows User Experience Interaction Guidelines suggest that "centering" the window means biasing vertical placement slightly towards the top of the monitor, and not placing the window exactly in the middle of the screen. The reason for this is that our eyes are naturally more biased towards the top of the screen. However, that difference is quite small—you can go for 45% from the top of the monitor or owner window and 55% from the bottom.

If the window that you are launching is contextual (remember, I've explained this term at the very beginning of this recipe), then you can go and display it near the object (button, let's say) that it was launched from. Take into account that you should place it out of the way so that the source object is not obscured; if possible, position it offset down and to the right.

If your window is being launched from the notification area or system tray, you should display it close to that area too.

If your window can be described as a process dialog (one that contains a progress bar—for example, file copy dialog), then you should place it in the lower-right corner of the active monitor, but not as close to the notification area as was the case with the windows launched from that area.

If your window is an owned (secondary) window, then you should initially display it centered on the top of the owner window (you can use the WindowStartupLocation property and set it to CenterOwner, or you can use the 55% : 45% rule for centering the window (as described in an earlier guideline).

See also

  • Journal navigation

  • Fluid versus fixed layouts

 

Wizards


If implemented correctly, wizards can really do some magic for your users and make them happier and satisfied. This recipe goes after desktop-based wizards. I will show you how to implement them using the WPF and provide you with some Microsoft Aero Wizard guidelines.

As was the case with the navigation pane pattern, a large number of different vendors are able to provide you with pre-built, fully capable desktop-based wizard frameworks implementing a number of rich functionalities.

I will show you how to build a simple wizard but you are encouraged to explore third-party options. However, the guidelines and suggestions I will be giving here are applicable to those third-party products, so do yourself and your users a favor and try to take the most out of these suggestions.

Getting ready

As I've already mentioned, we are going to build a desktop-based wizard in this recipe, and that's why I will be using WPF. Start your Expression Blend 4 and then select New project. From the dialog that appears select WPF and then WPF Application. Make sure that Language is set to C# and Version is 4.0. At the end hit OK.

How to do it...

There are several page types that can be used in wizards. They are:

  • Getting started page (optional)

  • Choice page

  • Commit page

  • Progress page (optional)

  • Follow-up page (optional)

Before you start building and implementing your wizard system, you should have a clear understanding of the task flow and user's actions. In this recipe, I will just mimic some typical wizard behavior but be sure to read the How to use and implement wizards section in this chapter.

OK, let's start with our building process—in this recipe, I will build a typical choice page. After your new WPF project has been created you should notice that under the Objects and Timeline pane, Window and LayoutRoot grid controls are visible.

  1. 1. Click on the window and then under the Properties pane, set its Height to 429 and Width to 549 pixels. Set its Title to Add Printer. Also under the Common Properties section, locate the ResizeMode property and set it to NoResize.

  2. 2. From the Asset Library, draw a Border control on top of LayoutRoot. Click on Border control and set the following under the Properties pane:

    • Set the Width to Auto, Height to 40

    • Set all margin values to 0

    • Set HorizontalAlignment to Stretch

    • Set VerticalAlignment to Bottom

  3. 3. Under the Appearance section, set the BorderThickness value for Top to be 1.

  4. 4. Under the Brushes section set the following colors:

    • For Background: Solid color brush—RGB (240,240,240) or HEX (#FFF0F0F0)

    • For BorderBrush: Solid color brush—RGB (223,223,223) or HEX (#FFDFDFDF)

  5. 5. If you now hit F5 and start your application, you will notice that Border control is docked to bottom, looks gray with a bit darker top border. This is the area that we will refer to as to the command area.

  6. 6. In the command area, we put at least one Commit button to commit to the task or proceed to the next step. We will add two buttons now—Next and Cancel. But as Border control can have only one child control, we need to add a Grid control and then draw our buttons on top of that Grid control.

  7. 7. With the Border control selected, from toolbox or Asset Library draw a grid control on top of Border controls itself. Under the Properties pane, set the grid's height and width to Auto, and all margin values to 0. That will stretch the grid and make it completely fill in the available space within Border control.

  8. 8. As grid is an extremely versatile and flexible control, we can now add our buttons on it. Select the grid and draw two buttons on it.

  9. 9. Call the first button btnNext and second one btnCancel. You can change their names by selecting them and then under the Properties pane (at the very top), you will find the Name property.

  10. 10. Select btnCancel, find the Content property, and set it to Cancel. Set Width to 65 and Height to 23. Choose Right as the HorizontalAlignment and Top for VerticalAlignment. For margin values, use 0 for Left and Bottom, 10 for Right, and 8 for Top; this should position our btnCancel nicely.

  11. 11. Now, let's change some properties for btnNext. Set the Content property to Next. Also, set the Width to 65 and Height to 23. Choose Right as HorizontalAlignment, and Top for VerticalAlignment. For margin values, use 0 for Left and Bottom, 85 for Right, and 8 for Top. And under the Common Properties section, locate the IsEnabled property and uncheck it.

  12. 12. Press F5 now and your wizard should look close to the one in the following screenshot:

  13. 13. So far so good. It's good to point out at this stage that you will have to use code to manipulate when the Next and other buttons are enabled, which will depend on the current progress and the context of your wizard.

  14. 14. Now we need to add the main instructions. It's basically a text label that summarizes what to do in the current wizard page. We can use Label as a control for this. So, draw a label (you can get it from Asset Library or toolbox) on top of the LayoutRoot and set the following properties:

    • Set Name to lblMainInstruction

    • Set Foreground color to RGB (0, 51,153) or HEX (#00003399)

    • Set both Width and Height to Auto

    • Set HorizontalAlignment to Left, and VerticalAlignment to Top

    • For margin values, set Left to 32 and Top to 14

    • Finally, set Choose a local or network printer for the Content property

  15. 15. These settings will always be the same for the main instructions for each and every wizard step. Only exception is the Content property, which must change appropriately.

  16. 16. As you remember, the page that we are currently working on is called "choice page". We have a main instruction, a command area, and now we will design the content area that hosts other controls and objects.

  17. 17. We will use regular buttons for this part although for the wizard pattern you should use command links.

  18. 18. We will use two buttons that will provide users with choices.

  19. 19. Draw two buttons; name the first button btnLocalPrinter and the second one btnNetworkPrinter.

  20. 20. Let's set the following properties for btnLocalPrinter:

    • Under Brushes section set Background to No brush

    • Set Height to 58

    • Set HorizontalAlignment to Stretch and VerticalAlignment to Top

    • For margin values, set 50 for Left, 10 for Right, and 55 for Top

    • Set HorizontalContentAlignment to Left and VerticalContentAlignment to Top (You might need to click on Show advanced properties to display these properties.)

    • Under Padding, set Left to 20, Right and Bottom to 1, and Top to 6.

    • Set Content to Add a local printer.

  21. 21. Now set the following properties for btnNetworkPrinter:

    • Under the Brushes section set Background to No brush

    • Set Height to 58

    • Set HorizontalAlignment to Stretch and VerticalAlignment to Top

    • For margin values, set 50 for Left, 10 for Right, and 145 for Top

    • Set HorizontalContentAlignment to Left and VerticalContentAlignment to Top (You might need to click on Show advanced properties to display these properties.)

    • Under Padding, set Left to 20, Right and Bottom to 1, and Top to 6.

    • Set Content to Add a network, wireless or Bluetooth printer

This basically sets the stage for your further improvements and customizations. The next steps are defining other page types and adding interaction logic between them. I will describe those page types and typical considerations that you need to take into account and address when designing and implementing your wizards.

How it works...

It is of utmost importance for you to have a clear understanding of your wizards' purpose and flow. Don't go and start designing and implementing wizards before you have that. You need to come up with a logical flow, specific page designs, and then start designing. However, the page that you will be designing (in almost 100% of cases) will be a simple choice page. In the last recipe, I've outlined the basic idea of how to design a page and now we will dig a bit into some technical details.

First of all, we have set ResizeMode to NoResize in order to keep our windows' dimension fixed (429 by 549 pixels, in our example). As a consequence, we get only a Close button on our window. Guidelines do allow implementation of resizable windows for wizards but I am generally opposed to that approach and I will explain the reason for this under the There's more... section.

Okay, in the next step, we have used Border control for designing the command area of our choice page. As border, as a control, can have only a single child element, we have added grid as a child element of Border and then hosted Next and Cancel buttons within grid control (which can accept as many child elements as you need).

You must pay special attention when it comes to handling Next, Cancel, Apply, and other buttons or commands that will appear in this area; this includes taking care if they are enabled, disabled, visible at all times, and so on. I am outlining those guidelines later on, so be sure to check them out.

After we have designed the command area, we are ready for setting up the main instruction—the text label that is used for summarization of what to do in the current wizard window. It is really important to make it as understandable as possible so that users can understand what is being done in this specific window just by reading the main instruction.

Next step was designing the content area—the main area of your wizard page where you usually place commands and where the most attention of your users will be focused on. We have added two "command links". (I am putting them under quotes for a reason: they are not real action or command links, what I have done basically is just changed some of the properties of regular buttons.

There's more...

As you've learned so far, wizards can be fairly complex and incorporate numerous page types given wizard's purpose. In this section, you will gain much more insights about those types and when and how to use and implement them. Again, this is WPF recipe but the general ideas, user experience considerations and design itself can be easily applied to Silverlight itself.

Brief overview of different wizard page types

In this recipe, I've guided you through the process of designing the very simple, even incomplete, choice page as a part of the wizard. According to the general UI guidelines, all wizard pages have a title bar, main instruction label(s), a content area, and a command area. In the previous recipe, we have designed all parts of our choice page except for the title bar. The fact is that the title bar for the so-called "Aero Wizards" looks pretty different from the one we have defined—it comes with an extended glass surface with the name of the wizard, the Back button in the upper-left corner, and a Close button with optional Minimize or Maximize buttons.

Anyway, let's go through the typical wizard page types.

There are several typical wizard page types:

  • Getting started page (optional)

  • Choice page

  • Commit page

  • Progress page and (optional)

  • Follow-up page (optional)

Getting started page

It is optional and its purpose is to outline the prerequisites or to explain the purpose of the wizard. But the general suggestion is not to use this page if all of the necessary information can be shown on the first choice page.

Choice page(s)

Wizards usually have more than one choice page; they are used with the purpose of gathering information from users in order to complete a specific task. A general suggestion is to use wizards if you know that users will be presented with more than two choice pages. If, however, you are dealing with one or two choice pages, you should consider using the regular dialogs and not the wizard because it is a pretty heavy UI pattern.

Commit page

This type of page looks quite similar to the regular choice page but there is one significant difference: after a user commits an action, there is no going back; in other words, action cannot be undone. That also means that the commit page does not have a Next button; it has buttons that clearly state commands such as Connect or so.

There is no common agreement as to whether there should be only one or more commit pages in a single wizard. However, personally I am a strong supporter of the single commit page idea.

Progress page

If during the wizard there is going to be an operation that will take four or more seconds, you should use the "progress page" type. It is optional, in the sense that if your operations will be shorter than four seconds, you are fine to drop the progress page.

They are, in most cases, called after the Commit page and with a progress bar animation (or some other operation's progress indicator such as custom animation); they are good indicators of the operation's progress for the end users.

When an operation is done, the wizard should advance automatically to the next wizard page.

Follow-up page

This type of page is optional and is being used to provide users with final results or outcomes.

I am not a big fan of "Thank you" pages. Stick to the task and get to it; your users will appreciate that much more than Thank you for installing this device, especially if it has taken them longer and you are just prolonging that with a useless "Thank you" page.

To design resizable wizards or not

Although Microsoft says that usage of resizable wizards is fine under Aero Wizard specifications and guidelines, I would advise you to be careful when you decide to go for resizable wizards.

Let me make it clear that I am not completely against it but I would suggest and play safe and use ResizeMode = NoResize.

I guess that my strongest argument for this would be having buttons in the command area always positioned in the same location. Imagine the scenario where you can go through your wizard just by clicking on Next several times. It is much faster if the Next button is in that case positioned at the same location. Of course, in this case, I am pointing out the problem where you are changing your wizard's dimension on a page-by-page basis. However, having wizards resizable so that they can leverage extra space available might be good idea.

Again, I'd say play it safe; optimize them for minimum resolution supported under Windows Vista or Windows 7 (800 x 600), and don't go for some wild resizing behaviors.

When to use wizards

I bet you all remember older wizards; you can find them if you are still using Windows XP or with some third-party applications that are just breaking all known UI or UX guidelines for wizard applications under Windows Vista or Windows 7. Older wizards were based on a standard called Wizard97 and that "97" is not there for no reason, so we should think about the year we are currently in.

Anyways, new wizard standards are in place and some of the changes include more flexible page layout and text formatting, and removal of the really unnecessary Welcome or Congratulations or Finish pages. (I bet those are not being missed by anyone.)

Some other pillars are the prominent main instructions with the great idea of unifying the earlier heading and subheading. Also, implementation of command links is a nice way of enabling users to have immediate and generally more expressive choices, thus eliminating the usage of several UI controls such as radio buttons followed with a Next button.

Navigation within wizards is more aligned with the one that is usually found on the Web and within Windows Explorer. In our recipe, we have not implemented that kind of navigation but you can read about it in the Journal navigation recipe of this chapter.

You might have noticed that the Back button is not present in the command area, rather it is now located in its new standard location— upper-left corner. I've had several opportunities listening to people saying that in the beginning, this was a bit distracting to them but now they actually see the point; more focus is being given to commit choices.

Guidelines
  • Don't go for wizards like there is no tomorrow. Wizards are considered as heavy user interface elements and should be used sparingly. They are used for multi-step tasks, especially if they are not frequently performed. You might consider some other alternatives to wizards—dialogs, task panes, and others.

  • The Next button is used only when advancing to the next page but without commitment, which means that the Back button is always available and presented after the Next button. According to Microsoft's guidelines, advancing to the next wizard page is considered a commitment when its effect cannot be undone by clicking on Back or Cancel buttons. Sounds quite logical, doesn't it?

  • Commit buttons are as specific as possible; for example, you should use captions such as Print or Connect instead of Finish or Done. Generic labels such as Next should not be used because they are suggesting the next step and not a commit command. However, there are two exceptions: Finish can be used when there is a collection of settings to be applied and if specific responses (Get, Save, and so on) are generic. The Commit button should always start with a verb, never a noun.

  • Command links are here for choices, not commitments. They are unifying the collection of radio buttons and the Next button. So when you are using command links, hide or disable the Next button but leave the Cancel button. This was exactly the case in our recipe where we have used two command links.

  • Wizard is a tricky term; never use "wizard" in wizard names. But it is fine to use "wizard" when referring to it as a specific UI element.

  • User choices must be preserved. This means that when users make a specific selection, then clicks Next, and after that Back, previous selections should be preserved.

  • Forget about "welcome", "get started", and similar types of pages. Make the first page fully functional whenever possible. There are some exceptions but resort to them sparingly. You can use "getting started" pages only in situations where there are some prerequisites that are necessary for successful completion of the wizard, when the purpose of the wizard may not be clearly understandable from the first choice page, and you don't have enough space on first choice page for additional explanation. In any of these exceptions, the main instruction text should be Before you begin: and never some version of welcome, let's get started, or anything like that.

  • Forget about "Thank you" or "Congratulations" pages, too. Wizard's final results should be clear and apparent enough for the users that you can just close the wizard after the final Commit button. You can resort to "follow-up" pages if you think that there are some usual follow-up tasks that users are likely to do as a follow-up. However, in that case, avoid using familiar, simple, everyday tasks. Follow-up pages are necessary after progress pages to indicate task completion. But again, if the task is long running (I'd say longer than five minutes) and can be performed in the background, then just close the wizard on the "commit" page and resort to notifications (such as balloons) to give a final feedback to the end users.

  • Commit pages are used to make it clear when users are committing to the task. As a general rule, the commit page is the last page of choices and it does not contain the Next button. Rather, the Next button is relabeled in a way that is described in the guideline about commit buttons (mentioned above). Sometimes, if the wizard was used for a really risky task or there is a significant doubt that the users have understood their selections, you might want to use a summary page and outline all of the selections and choices of the users, so that they can review them and act upon them.

See also

  • Action or command links

  • Journal navigation

 

Progressive disclosure—showing additional controls on demand


In some cases, your user interface needs to host a large number of different controls and present them to the end user. Instead of showing all the available controls at the same moment, you can take an approach where you will progressively disclose more controls on user's demand. This can save you some valuable space and, at the same, increase a user's productivity.

Now I will show you how to implement this UI pattern in a simple WPF application. As always, the same methods, ideas, and principles can be applied to your Silverlight application as well.

Getting ready

Start your Expression Blend 4 and then select New project... From the dialog that appears select WPF and then WPF Application. Make sure that Language is set to C# and Version is 4.0. At the end hit OK.

How to do it...

After your new WPF project has been created you should notice that under Objects and Timeline pane, Window and LayoutRoot grid controls are visible.

  1. 1. Click on Window and under the Properties pane change the following things:

    • Under the Layout section, set Width to 350 and Height to 240

    • Under Common properties, set Title to Files Search Sample

      We will create a simple file search application but without real functionality.

  2. 2. On the toolbox, click on Asset Library | Label. Draw a label on your application. With the Label control selected, under the Properties pane locate the Content property (it is under the Common properties section) and set its content to Enter file name:. You can set its height and width to Auto (under the Layout section).

  3. 3. Now add the TextBox control in the same way and position it under the previously added Enter file name: label. Go to the Text property under Common properties and set it to none.

  4. 4. Add the Button control, position it right next to the TextBox control, and set its Content property to Search.

  5. 5. Now you will go and add an Expander control. Select it from Asset Library, draw it, and position it below the TextBox control on your form. Set its height and width to Auto.

  6. 6. In the Objects and Timeline pane, click on the Expander control so that you can access the Grid control contained within it. Double-click on the Grid control to make it active. We will add our additional controls into this Grid control. Under the Layout section, set Height to 80.

  7. 7. Once again, go to Asset Library and select the CheckBox control. Draw it onto the grid surface (be sure to make it this way, CheckBox must be the child element of the Grid control contained within Expander control). Repeat the procedure and add one more CheckBox control and position it below the previous CheckBox control.

  8. 8. Select the first CheckBox control and change its Content property to Search archived files, and set the Content property of the second CheckBox control to Search files in Recycle Bin.

  9. 9. Ensure that the IsExpanded property of the Expander is set to false (unchecked) under the Common Properties section. We want to keep Expander collapsed. Also, change Expander Header content to Show advanced options.

  10. 10. Hit F5. When your application starts, click on Show advanced options and your application should look like the following screenshot:

How it works...

Our sample application outlines the basic idea of progressive disclosure. We have created a simple file search interface where a user enters the filename and clicks on Search to search for files. That is the basic use case and it is available right after the user starts the application.

By clicking on Show advanced options, users are presented with two more options that can refine their search results. I have assumed that majority of users will want to use basic search options and just smaller number of them would be interested in searching for archived files or files in the Recycle Bin.

In this example, a progressive disclosure pattern has been implemented using the Expander control. The Expander control consists of two major parts—header and grid. The Header part contains a chevron and label (we changed its content to Show advanced options). The Grid part can be considered as a container in which you should put all of the controls that you want to disclose progressively to the end user. In this example, we have added two CheckBox controls with options to refine our search—they are not visible right away and therefore, they are not adding any visual clutter and distraction to users. If users do not want to use them, they can easily collapse the Expander control and hide those options.

There's more...

The first part of this recipe has introduced to the basic idea of progressive disclosure. What follows are more details and design and user experience considerations you should take into account when designing and implementing this pattern in your application.

Changing the expander control's header label

For the users to have a better understanding of the actions being performed and the changes being made when they click on chevron, it is highly recommended to change label from Show advanced options before clicking on the chevron to Hide advanced options after the user has clicked. Same goes for the other way around.

To achieve that, we need some code. As we have created our project as a WPF C# project, we will obviously write our code in C#.

  1. 1. Under the Objects and Timeline pane, click on the Expander control. We will now change its name so that we can access its properties through the code easily.

  2. 2. Under the Properties pane, type expOptions in the Name field.

  3. 3. We will want to execute different code when users collapse it and when it expands our Expander control. To do that, we will define event handlers for the Collapsed and Expanded events.

  4. 4. Click on the Events icon under the Properties pane and you will be presented with a number of events. Let's add our event handlers for Collapsed and Expanded events. To do that, you will just have to type in the name for those event handlers and once you press the Enter key, Visual Studio will start and allow you to add code logic. You can use expOptions_Collapsed and expOptions_Expanded as names for your events.

  5. 5. Add the following code:

    private void expOptions_Collapsed(object sender,RoutedEventArgs e)
    {
    this.expOptions.Header = "Show advanced options";
    }
    private void expOptions_Expanded(object sender, RoutedEventArgs e)
    {
    this.expOptions.Header = "Hide advanced options";
    }
    
  6. Everything what we are doing here is changing the content within the header part of our expOptions control.

  7. 6. Press F5 now and try clicking on the chevron and note how the label will change its content, making it easy for users to understand what has happened and what will their next action cause.

When to use progressive disclosure

Many developers tend to expose each and every command and feature that they have built into their solution. Some even go as far as to argue that by doing that they will actually show to the end user how powerful and feature-rich their application is. I'd be happy to say that this story was just my exaggeration but I have witnessed such situations too many times. So, we are facing a challenge on how to enable users to use our application and make it feature-rich, but at the same time not to make it too cluttered.

Guess what—users will not judge your application's power by the number of buttons, icons, and other UI elements that you have exposed to them. They will judge it, among other things, by how easy it was for them to get to the most needed options really quickly. That will make them feel that they are in control and will result in significant productivity gains.

So, what to do?

The first step is to identify the commands and controls that your users will use in most cases. Make a list of all use cases and assign a value to each of those use cases describing how likely users are to use that very option. You must ensure that users should be able to perform about 70-80% of the use cases easily, without having to look for hidden options within your UI. Of course, that percentage can scale depending on certain specifics, but practice has shown that the aforementioned range works very well. Okay, now you have a list with controls and use cases that your users will use in 70 80% of cases, and the rest will be used much less often. This is a great input and you can use it from this point on to define the look and feel of your UI.

Add those most commonly used controls on your windows or pages.

Remember, these are the ones that will be used frequently by your users, so ensure that they are visible and easily accessible. Now, create a separate section and add the rest of the controls to that section. Hide it and make it hidden by default to your end users. But, be sure to allow users to get to those options in a single click. You might consider using buttons with captions such as More details... or even chevrons (>>) as a part of the button or other control that is being used to show those hidden controls.

It is extremely important that users are able to hide and show sections with additional controls with a single click. If you show additional controls by clicking on Show advanced options, then be sure to enable users to get out from those advanced options by clicking on a button saying something like Hide advanced options.

As I said earlier, controls that are being placed in this "hidden section" will be used rather infrequently, but you must ensure that your users will be able to access them and leave them easily.

If you are using chevrons instead of buttons (and that is what I do personally because I feel that they are visually lighter than buttons, and besides that, buttons are usually associated with launching other windows or executing commands), you must take care of rearranging their "pointing direction" after a user clicks on them.

They should always point in the direction of the action being performed, which means the following: if the chevron is pointing down, when the user clicks on it, additional commands should appear below that chevron and now the chevron should point up.

That will always give a clear understanding to the user what will happen when they click on the chevron. I strongly suggest that you use labels that will reinforce users' understanding of the actions being performed.

Look

Behavior when user clicks

Section will expand, hidden options will be shown, and chevron will change its direction to up, and text will change to something like Hide advanced options

Section will collapse hiding the previously exposed options and chevron will change its direction to down, and text will change to something like Show advanced options

See also

  • Responsive enabling

  • Contextual fade-in/-out

  • Progressive disclosure-showing additional controls on demand

 

Control docking with DockPanel


Windows Presentation Foundation comes with DockPanel —a really versatile control allowing you to architect and create layout areas within which you can position and organize child elements.

When building your user interface, often you will want to ensure that specific controls and parts of your UI are always docked on the top, left, bottom, or right side. For example, the command bar area is usually docked at the top and the status bar is usually docked at the very bottom of your application.

A good practice is to use the DockPanel control as a root control and organize other panel and layout types of controls within it. Of course, you can always think about employing some different approaches and using controls such as Grid, but the DockPanel control brings you docking capability right out of the box.

In this recipe, I will show you some basic principles that you should be aware of when thinking about using the DockPanel control.

Getting ready

Start your Expression Blend 4 and then select New project... From the dialog that appears select WPF and then WPF Application. Make sure that Language is set to C# and Version is 4.0. At the end hit OK.

Note

Apart from WPF, DockPanel is available as a Silverlight control as well. In order to be able to use it, you need to have Silverlight Toolkit installed. The introductory part of this book contains all the information you need to know about how to obtain Silverlight Toolkits and use controls contained in it.

How to do it...

Once your new WPF project has been created you should notice that under the Objects and Timeline pane, Window and LayoutRoot grid controls are visible.

  1. 1. Right-click on LayoutRoot and in the pop-up menu click on Change Layout Type | DockPanel. This is the fastest way for us to use DockPanel as our root control. Of course, another possibility is to click on Asset Library located on the toolbox and then select and draw DockPanel as control.

  2. 2. Click on LayoutRoot to select it and under the Properties tab, within the Layout section make sure that the LastChildFill property is set to false (unchecked).

    Now, let's go and add several rectangles on our LayoutRoot so that we can understand basic layout principles.

  3. 3. Select Rectangle from the toolbox and draw it onto your LayoutRoot. With the first rectangle selected, under the Properties panel, locate the Layout section and from the Dock drop-down list select Top. Set Width to Auto and Height to 55.

  4. 4. Now draw another rectangle. Instead of selecting and typing in values, we can set the dock position in a different way. Select Rectangle and drag it towards the top. You will notice a large four-way cursor showing you directions for possible docking locations of your object. Dock this second Rectangle at the bottom.

  5. 5. Set the Width property to Auto and Height to 40.

  6. 6. Repeat this procedure for two more rectangles, but align them to the left and right side respectively. Set Height to Auto for both of them. For the left docked rectangle set the width to 200, and for the right docked rectangle, set the width to 170. Set different fill colors for each rectangle so that they are easier to notice and recognize.

  7. 7. Press F5 and start your application. It should look similar to the one in the following screenshot:

    • Now let's go one step further and add the Grid control to the central part of our application. But now, we want our Grid control to completely fill in the available space on the form, so that we can utilize it later; for example, when we decide to extend our application.

  8. 8. From the toolbox, select and draw the Grid control on the LayoutRoot control. Under Properties and under Brushes, select any color for its Background property. The purpose of this color selection is only to make our Grid control a bit more distinctive.

  9. 9. Now select the LayoutRoot element (the easiest way to do this is to select it under the Objects and Timeline panel just by clicking on it) and under the Properties pane, locate a property called LastChildFill, and make sure it is checked.

  10. 10. Select the newly added Grid control and set its Height and Width properties to Auto.

  11. 11. Press F5 and you should get a layout that looks close to the one in the following screenshot:

Try resizing the form and you will notice that all our rectangles are keeping their positions docked to defined sides, and the central part (Grid) is filling in all the available space. I will explain this kind of behavior in more detail in the following paragraph.

How it works...

The first thing we did after starting a new project was change the layout type. The default layout type is grid, but we wanted to use DockPanel so that we could explore its behavior.

DockPanel enables us to dock specific child elements. In our example, we have added several rectangles and set their Dock property. It was obvious that we could dock our objects in two different ways—by manually setting the Dock property within the Properties pane or by simply dragging child objects over a large four-way cursor.

We have set specific heights and widths for child objects, but please take into account that in order to achieve that your docked control will scale appropriately, you need to set Auto for its Height or Width properties, depending on their docking direction.

At the very beginning of our recipe, we have set the LastChildFill property to false (unchecked it). the idea behind the LastChildFill property is to enable the last child element added to DockPanel to fill the remaining space. We achieved exactly that when we added Grid control and set the LastChildFill to true (checked it).

So just to summarize: DockPanel arranges its child elements so that they fill a particular edge of the panel. What happens if you set up multiple child elements to have the same docking direction? They will simply stack up against that edge in order.

There's more...

Change the docking order of child elements

Once you have added child elements to your DockPanel you might want to change their order. That procedure is fairly simple.

  1. 1. Make your DockPanel active; the easiest way to achieve that is by double-clicking on it or selecting it under Objects and Timeline.

  2. 2. Click the child element and simply drag-and-drop it on the desired position (you are not dragging-and-dropping child elements on the artboard). Now you are dealing with them within the Objects and Timeline pane. Note that by doing this you are not changing the docking orientation; you are changing only the z-order. It is also sometimes called stack order.

Try experimenting with this and you will notice that the actual docking order is pretty important when it comes to the overall UI layout. The reason for that is that when elements fill up the panel (and that usually happens when we set their heights and widths to Auto), some parts might be cut off depending on the screen and child element size.

Change the orientation of a dock panel

Sometimes you will face situations where you want to change the docking orientation for specific child elements after you have already set them. You can do that by following these instructions:

  1. 1. Make your DockPanel active: the easiest way to achieve that is by double-clicking it or selecting it under Objects and Timeline.

  2. 2. Click the child element and simply drag-and-drop it on the desired docking position on your artboard. Once you start dragging elements you will notice a large four-way cursor showing you docking directions. Now you only need to drag the element over the direction arrow you want. You will notice that the direction arrow that you select is highlighted indicating the docking direction.

    • Another way of changing the docking orientation is to select child element and under the Layout section in the Properties pane, select Top, Right, Bottom, or Left from the Dock drop-down list.

Personal view

I will say it bluntly—I am not a big fan of the DockPanel control. Although it is a great and simple-to-use control that enables you to create a basic layout for your UI, I will always prefer the Grid control as my control of choice when it comes to layouts. The Grid control is slightly more complicated, but it is more flexible as well. Anything you can do with DockPanel can be done with the Grid control, and then some.

Of course, DockPanel gets its credit when we talk about simplicity, and really, if your basic UI structure is really simple and you need to get things done in a fast and simple manner, consider using the DockPanel instead of Grid. Use Grid and other controls within DockPanel, work on their docking positions, and you will probably be able to create the UI you were looking for. If that doesn't work, you can always rely on Grid—the most powerful of all WPF or Silverlight layout controls.

See also

  • Fluid versus fixed layouts

 

Journal navigation


Journal navigation enables you to utilize "back and forward" metaphors usually seen in web browsers even for your desktop (WPF) applications. As humans, we are often found in positions where we are thinking in a linear way and we tend to associate web page navigation and other UI related concepts with that.

As web browsers do support this kind of navigation by default, more challenging is to achieve this kind of behavior for desktop (WPF) applications. In this recipe, I will show you how to utilize this model and enable users to go back and forth in their navigation history within your WPF application.

Getting ready

Start your Expression Blend 4 and then select New project... From the dialog that appears select WPF and then WPF Application. Make sure that Language is set to C# and Version is 4.0. At the end hit OK..

How to do it...

When you create your new WPF project in Expression Blend, you are presented with the Window object. In order to implement journal navigation pattern, you need to use Page.

For this example, we will add two pages and show how to navigate between them and retain the navigation history.

  1. 1. Click on the Project pane and then right-click on the name of your project. From the drop-down menu choose Add New Item....

  2. 2. A dialog box will appear showing you your possible choices. Select Page. Leave the name as it is (Page1.xaml) and be sure to have the Include code file option checked.

  3. 3. Repeat the procedure and in the same way, add Page2.xaml to your project. Now your project tree should look like the one in the following screenshot:

  4. 4. Now right-click on Page1.xaml and from the drop-down menu, select Startup. This will make Page1.xaml a startup object—the first one to appear when you start your application.

  5. 5. If you now hit F5, you should be able to see your Page1.xaml completely blank, but notice the navigation chrome with back and forward navigation buttons (sometimes also called "travel buttons") added automagically. It is not functional at this moment, but very soon you will be able to use it.

  6. 6. Let's change some properties and make our pages look a bit more distinctive so that we can recognize them easily later.

  7. 7. We will start with Page1. Under the Objects and Timeline pane, select the Page object. On the Properties pane, locate Common Properties, find the Title and WindowTitle properties, and set them both to First page.

  8. 8. Repeat the procedure for Page2, but now set the Title and WindowTitle properties to Second page. (I will explain the difference between Title and WindowTitle properties later on.)

  9. 9. Now, let's add a button on Page1. We will use that button for navigating from Page1 to Page2. To add a button, locate it on the toolbox or add it from Asset Library and draw it on your Page1.

  10. 10. On the top of the Properties pane set its Name property to btnNavigate. Also, find the Common Properties section and change the Content property to Navigate to other page.

  11. 11. Now, we need to add some code that will enable us to really navigate to the second page when a user clicks on this button. Basically, we will define an event handler for the Click event.

  12. 12. Under the Properties pane, locate the Events icon and click on it.

  13. 13. Under Click, type in btnNavigate_Clicked —the name of your event handler. Hit Enter and Visual Studio will enable you to type in the code needed.

  14. 14. Add the following code in the event handler:

    private void btnNavigate_Clicked(object sender, RoutedEventArgs e)
    { ((NavigationWindow)(Application.Current.MainWindow)).Navigate( new System.Uri("Page2.xaml", UriKind.RelativeOrAbsolute));
    }
    
  15. 15. And add the following line at the very beginning of the code:

    using System.Windows.Navigation;
    
  16. 16. Note that Page2.xaml is the file name we are navigating to. Now hit F5 and when the application starts, click on Navigate to other page.

  17. 17. Note the changes in the navigation chrome. Explore it by clicking on the back and forward buttons or drop-down menu.

How it works...

We have added two Page items to our project: Page1.xaml and Page2.xaml. The basic idea of this recipe was to show you how to navigate from Page1.xaml to Page2.xaml.

By setting Page1.xaml as the startup page, we have ensured that it will be the first page to be shown when the application starts.

We have added a button and called it btnNavigate and associated the Click event handler.

There is only a single line of code that enables navigation between pages:

((NavigationWindow)(Application.Current.MainWindow)).Navigate( new System.Uri("Page2.xaml", UriKind.RelativeOrAbsolute));

However, first we need to add a simple using directive:

using System.Windows.Navigation;

The great thing about implementation of the journal navigation pattern is that the navigation chrome is automatically being updated. When I say that I am thinking about the fact that the back and forward button and the drop-down menu are being updated based on the current navigation context. This pattern is often seen in applications such as web browsers, Windows Explorer in Windows Vista and Windows 7, or in Microsoft Dynamics NAV and AX line of products.

There's more...

Journal Navigation pattern is very useful. Sometimes, however, you will want to remove the navigation chrome, or you might be wondering what's the difference between Title and WindowTitle properties. The following section will explain you that and provide you with even more information.

Removing the navigation chrome

At some point, you might consider removing the navigation chrome and replacing it with your own implementation of the same. Although I won't be going into details and explaining how to replace it with your own, I will show you how easy it is to remove the navigation chrome with just a single line of code.

All you need to do is add this line of code:

this.ShowsNavigationUI = false;

As an example, and for demonstration purposes only, I've added a new button and called it btnRemoveNavigation and attached a new Click event handler called btnRemoveNavigation_Clicked. So my complete code looks like this:

private void btnRemoveNavigation_Clicked(object sender, RoutedEventArgs e)
{
this.ShowsNavigationUI = false;
}

If you now go and hit F5 to start your project and then click on Remove navigation, the navigation chrome will disappear.

Though you can remove the navigation chrome and navigation functionality will stay intact (one that you have implemented by adding event handlers), your users will suffer immensely if you don't implement some sort of navigation UI (that is, if your application is based on this pattern).

You must ensure that simple, easy-to-use, and noticeable navigation chromes exist at all times while your users are using an application based on this pattern.

Difference between Title and WindowTitle

In Step 8 of this recipe, I've mentioned that there is a difference between Title and WindowTitle properties. So, what's the deal?

Both Title and WindowTitle are Page properties located under the Properties pane, in the Common properties section.

The Title property sets a title for a specific page. What you enter here will be displayed in the navigation chrome (including a drop-down menu).

WindowTitle sets the title for a specific Window object. Basically, this means that whatever you enter for the WindowTitle property will be displayed at the top of the window—in the title bar.

When to use journal navigation

As people tend to think linearly (probably based on their everyday experiences with time flow and similar concepts), we also appreciate the ability to navigate through our applications in the same way. Journal navigation is a good pattern that provides us with a mechanism that can be used to go back and forth in the navigation history of our application.

We experience software in the same, more or less single thread, single timeline manner. For example, recall using the web browser of your choice—when you are navigating from one page to another, you have the impression that the main view is being changed. Implementation of journal navigation enables us to track and revert to those views or pages in a pretty simple and straightforward manner.

Journal navigation is not only good (or should I say mandatory) for web browsers but it is also a good choice for a number of different needs. Wizards, desktop, or RIAs (Rich Interactive Applications) are just some of the typical, potentially good candidates for this pattern. Windows Explorer in Windows Vista and Windows 7 uses this same pattern. Microsoft Dynamics NAV and Microsoft Dynamics AX are also great examples; they are combining journal navigation with breadcrumb bars.

So, the basic principle about when to use journal navigation as a pattern is a situation where you want to enable the no forward-only navigational experience, and instead, you are to utilize abilities to go back and forth, thus enhancing the experience of moving from one page to another.

Good practice suggests that you concentrate on three main areas when dealing with the journal navigation implementation. Luckily, when you are using WPF Page and the recipe described here, they are (mostly) all being taken care of, but just for your reference, I will describe them.

The first field is surfacing the navigation chrome (user interface). It has to be obvious to the end user that they are dealing with the navigation UI. I've explained how easy it is to remove the default navigation chrome, but you must use some sort of navigation UI. Good practice is also to enable users to get access to back and forward buttons via the keyboard and not just by clicking with the mouse.

As you can say by your own intuition or from your personal experience, when interacting with different applications, having a consistent, clear, and easy-to-use navigation system is crucial. It certainly enables users to feel more in control and empowered when using your application.

Second important thing is to have some sort of history so that users can easily see where they have been previously and navigate through their history. In our recipe, that list is easily available by clicking on an arrow pointing downwards, which exposes a drop-down menu with the list of visited pages.

The third and probably most important thing to take care of is the context of your application. Do you want to enable users to navigate back and forth or do you require a one-way task flow? What happens if your users navigate back while some action is still in progress: will you cancel the action, continue the action, or do something else? How will you notify your users?

Never, and I mean never, use the Back button as an undo operation! Use a specific, single, understandable command for an undo operation. I've seen too many applications trying to use the Back button as a replacement for the undo command, and bluntly said, they "suck". You don't want your application to be characterized as the one that "sucks", do you?

See also

  • Wizards

 

Tabs


Tabs provide a simple way of presenting sets of controls or documents on separate, labeled pages. They are quite popular and most commonly associated with typical property windows. On the Web, they are also very popular as a means for content organization.

As a very general guideline, tabs are used when you are dealing with too much information on one page (it doesn't matter if it is a web or desktop application), which basically creates confusion making the specific content difficult to find and focus on.

Getting ready

Start your Expression Blend 4 and then select New project... From the dialog that appears select Silverlight and then Silverlight Application. Make sure that Language is set to C# and Version is 4.0. At the end hit OK.

How to do it...

In this example, we will add the Tab control as a part of our Silverlight 4 project:

  1. 1. After you have created your new project, under the Objects and Timeline pane, you will see UserControl and LayoutRoot. LayoutRoot is a Grid control hosted in UserControl.

  2. 2. The Tab control is not a part of the "default" Silverlight controls, so in order to use it, we have to add a reference to it. After you installed the Silverlight 4 SDK, you have obtained a library that contains a number of controls, among them TabControl.

  3. 3. Under the Project tab, go to References | Add Reference....

  4. 4. The Add Reference dialog box will appear. Navigate to a file called System.Windows.Controls.dll, which is usually located in a path similar to: C:\Program Files\Microsoft SDKs\Silverlight\v4.0\Libraries\Client.

  5. 5. Select the file and click Open.

  6. 6. Now you will see System.Windows.Controls.dll under your References folder.

  7. 7. Now, go to Asset Library available on the toolbox. Be sure to check Show All. Now you should be able to locate TabControl.

  8. 8. Click on TabControl and draw it on the artboard.

  9. 9. Take a look at the Objects and Timeline pane and expand the visual tree so that you can see all parts of the TabControl.

  10. 10. Let's add the third TabItem to our TabControl. Right-click on TabControl under the Objects and Timeline pane and from the drop-down menu, click on Add TabItem. Now you should see the third TabItem added to your TabControl.

  11. 11. Click on the first TabItem and under the Properties pane, locate the Header property (located under Miscellaneous section), and type in First tab. Do the same for the second and third TabItem typing Second Tab and Third Tab, respectively. Your tab control should look like the one in the following screenshot:

  12. 12. As you will have noticed under the visual tree, each TabItem is comprised of the Header part and Grid. The Grid part is basically the Grid control in which we can put any content we want.

  13. 13. Select First tab and add two buttons (add them from the toolbox or Asset Library). Change their content (Properties pane, Common Properties section, Content property) to Button 01 and Button 02. Be sure that you have selected the Grid element of the specific TabItem to ensure that the buttons will be added to exactly that TabItem.

  14. 14. Repeat the same procedure: adding one button to the Second tab and one to Third tab. Set their content to Button 03 and Button 04 respectively.

  15. 15. With this, you must have got a pretty clear understanding of how you can add controls to different TabItems and how to add TabItems as well.

  16. 16. Now hit F5 or go to Project | Test Solution.

  17. 17. Your default web browser will start and you will see your tab control. Try clicking on different tabs and notice that you can see only the content that you have added to a specific Grid under specific TabItem.

How it works...

As TabControl is not a "default" Silverlight 4 control; we had to add a reference to the System.Windows.Controls.dll file (that file is part of the Silverlight 4 SDK pack). After adding the reference, TabControl has been added to our Asset Library and is available for use from there like all other controls.

Right after you have drawn TabControl on the artboard, you will notice two tab items (colloquially called just "tabs"). By right-clicking on TabControl and using the option Add TabItem you get the opportunity to add more tab items.

It is a general suggestion that you don't add more than seven tabs. Take a look at the There's more... section where I will go deeper into general guidelines for using tab as a control.

The next step was adding titles for specific tabs. As shown earlier, specific TabItem is comprised of Header and Grid parts. By clicking on TabItem and locating the Header property, you have got the possibility to change the title for a specific TabItem. We have used just provisional titles, First tab, Second Tab, and so on.

The next step was adding the specific content to specific tabs. Technically speaking, that content is hosted within the Grid control. That, of course, means that all layout, formatting, and other Grid-related mechanisms and properties are applied to all controls hosted. Grid is, without doubt, the most powerful layout control available in WPF and Silverlight.

By hitting F5 and starting your web browser you got the opportunity to explore tabs and associated buttons (controls).

There's more...

In the first part, you've been introduced to the tab control and its main characteristics. Now, you'll learn how to further customize the control itself and also get the professional and insightful guidelines for using the tabs in your real life applications - no matter what are you using, WPF or Silverlight.

Changing tab orientation

Tabs are most commonly oriented horizontally, but TabControl, which is used in our example, supports different orientations.

I will assume that you are continuing from the previous TabControl example.

  1. 1. Select your TabControl under the Objects and Timeline pane. Under the Properties pane, locate the TabStripPlacement property under Miscellaneous. The drop-down list offers you the following options: Left, Top, Right, and Bottom.

  2. 2. Select Left.

  3. 3. You will notice that the tab orientation has been changed. Hit F5 and investigate a new look within your browser.

As a small digression, Last.fm, a popular music and radio community website, uses this kind of layout for its profile page's design and I find it to be highly usable and pleasing.

Adding icons in tabs

In the When to use tabs? paragraph, I will give guidelines regarding the usage of icons in tabs, so be sure to understand when it is correct and acceptable to use icons in tabs.

Again, I will take it from our initial example where we have added TabControl and three TabItem elements (tabs).

Currently, there is no property like Icon for each TabItem, but we can add them manually by modifying the Header part of TabItem.

  1. 1. Let's just modify the Header for the First tab and you can apply the same method for the rest of them.

  2. 2. The idea is to add Image control and TextBlock into Header and then to place an icon into Image control and set the content of TextProperty to First tab. We want Image and TextBlock controls to be stacked horizontally, so we will put them in the StackPanel container.

  3. 3. Double-click on Header under the first TabItem; this will make it active. Now from the toolbox or Asset Library add StackPanel. Set its Height and Width to Auto and Orientation to Horizontal. You can do this by going to the Properties pane and locating them under the Layout section.

  4. 4. Now select the newly added StackPanel and add Image control and TextBlock. The easiest way do to that is just by locating them under the toolbox or Asset Library and double-clicking on them. They will be automatically added to the selected container, StackPanel in our case.

  5. 5. Select Image control and under Properties locate the Common Properties section. Find the Source property and click on Choose an image button (ellipses). From the dialog box, select an image—the one that you want to add as an image. I suggest using the PNG image with dimensions of about 16x16 pixels.

  6. 6. Now select TextBlock and change its Text property, which is under the Common Properties section within the Properties pane. Set it to First tab.

  7. 7. If you now take a look at the XAML code of the selected TabItem, it should look similar to this:

    <basics:TabItem.Header>
    <StackPanel Height="Auto" Width="Auto" Orientation="Horizontal">
    <Image Width="16" Height="16" Source="Help and Support.png"/>
    <TextBlock Text="First Tab" TextWrapping="Wrap"/>
    </StackPanel>
    </basics:TabItem.Header>
    
  8. 8. Structure, as can be seen under the Objects and Timeline panel, looks like this:

  9. 9. Press F5 now and your TabControl should look like this:

When to use tabs

I've already mentioned that tabs are usually good in situations when we are dealing with large amounts of information on a single page or window and, as a consequence, users are having difficulties finding, using, and focusing on specific content and possibly, tasks. Tabs are really handy in such situations, as they allow us to break up related pieces of information and organize them on individual tabs, making them available one at a time.

According to Microsoft's own Windows user experience guidelines, there are several questions that are to be asked when deciding whether you should use the tabs as control. They can be summarized as follows:

  • Can all your controls comfortably fit on a single page? If so, there's no need for tabs, and the same. The same holds true if you are using just one tab—do not use tabs just to use them. You might be tempted to do so thinking that this would make your application or web application more professional, but the reality is quite the opposite.

  • Are you using tabs to organize settings and numerous options? Be sure to check if the changing of the options on one tab affects options and settings on other tabs. Each and every tab must be mutually independent. If that is not the case, use wizard pattern.

  • From the hierarchical point of view, ask yourself: Are the tabs mostly peers (on the same levels) or do you have a clear hierarchy organization among them? Tabs must have a peer relationship, never hierarchical. Just think about it: they are linearly represented—an orientation that is implying the same hierarchy levels.

  • Are you using tabs for wizard-like step-by-step processes where the first tab represents starting point and tabs that follow are next steps in the process? If that is the case, again, wizard is the appropriate pattern.

This list, of course, is far from comprehensive but offers you some initial guidelines.

Real-world metaphor

Tabs are taken from the real world and they do aim to leverage familiarity that most users have from tabbed folders. As we do use tabs in the real world to group related documents, the same idea must be used in the world of user interfaces.

We benefit from organizing related elements and content onto individual tabs. Furthermore, you should think about the order of your tabs and set them in a way that will make sense to your users. Among other things, that is the reason why tabs are pretty popular events on the Web as navigational controls, although that is not and should not be their primary role.

Implementation guidelines

In most cases, tabs will be presented horizontally or vertically. How do we decide? Again, Microsoft's and other UI guidelines suggest, among other things, the following:

  • Horizontal tabs should be used if you plan to use seven or fewer tabs and all tabs fit in one row.

  • Vertical tabs are good for cases when you are dealing with eight or more tabs or if using the horizontal tabs would require more than one row (the case might be that you have five tabs but with very long labels in their header).

  • Forget about using scroll bars for horizontal tabs. This pattern has poor discoverability while usage of scrolling for vertical tabs is acceptable. General idea is to have all tabs always visible. If you have too much content which must fit on a single tab, then put a scrollbar on that specific tab, not on the window that is hosting your tab control.

  • By default, make your first tab selected in all cases. Exclusion from this can be only a specific case when users are likely to start from the last tab that they have selected before dismissing a window or page with tabs. In that case, make the last tab selected to persist on a per-window, per-user basis. My personal experience is that your exceptions like these are extremely rare and you will probably do a better job just by ensuring that the first tab is always selected for users.

  • Don't use and put icons on tabs' headers. They add visual clutter and consume screen space. You might be tempted to use them hoping that they will improve users' comprehension but that is rarely the case.

    However, there are some cases when icons might be fitting:

    • Icons you are using are standard symbols, well known, and widely recognizable, and understandable

    • Use icons if there is not enough space to display significant labels

  • Place the terminating buttons (OK, Cancel, Apply, and so on) on the area outside the tabbed area, onto the dialog. A good example for this is given in the following screenshot:

By doing that you will avoid confusion in respect to the scope of the actions being carried away when user clicks on those buttons. Actions triggered by clicks on terminating buttons placed outside the tabbed area are applied to the whole page or window.

See also

  • Wizards

 

Adding a status bar area


The area at the bottom of the primary application window can be used for a status bar—control that is suited for displaying the current state of the window and accompanying actions, background tasks, or some other contextual information.

In this recipe, I will demonstrate how to add the StatusBar control to our WPF application and share some guidelines regarding the implementation and usage of this pattern.

Getting ready

Start your Expression Blend 4 and then select New project... From the dialog that appears, select WPF and then WPF Application. Make sure that Language is set to C# and Version is 4.0. At the end hit OK..

How to do it...

  1. 1. Once your new WPF project has been created, you should notice that under the Objects and Timeline pane, Window and LayoutRoot grid controls are visible.

  2. 2. Go to Asset Library and from there click on the StatusBar control. Draw it onto your artboard. Note that the StatusBar control will probably be hidden, so you should make sure that the Show All option, located at the Asset Library dialog, is checked.

  3. 3. Select StatusBar by clicking on it. Now we will set up some properties. Go to the Properties pane and under the Layout section change the following:

    • Set Width to Auto and Height to 24

    • Set HorizontalAlignment to Stretch (last icon in the row)

    • Set VerticalAlignment to Bottom (third icon in the row)

    • Set all values for Margin to 0

  4. 4. Your StatusBar should now appear docked to the bottom of your window and stretched from side-to- side.

  5. 5. As you can notice, StatusBar looks completely blank. Let's add a single line at the top of our StatusBar just to make it appear more distinct from the rest of the window surface.

  6. 6. Under the Appearance section, set 1 for the Top Border value. Now under Brushes section, locate the BorderBrush, and click on it. Now click on the Solid color brush icon and pick some kind of dark gray. You can also enter RGB values: 123,123,123 or HEX: #FF7B7B7B.

  7. 7. Your StatusBar should now have a simple gray border at the top.

    Let's add some controls to our StatusBar. However, note that I am just adding random controls now and not following specific guidelines; those can be found under the There's more... section and you should refer to them when designing and implementing the status bar pattern.

  8. 8. Right-click on the StatusBar control and from the drop-down menu, select Add StatusBarItem; this will add the simplest possible item to your StatusBar.

  9. 9. Now, click on StatusBarItem to select it and under the Properties pane locate the Common Properties section. Enter Ready for the Content property.

  10. 10. In order to change the Content property of StatusBarItem during the run-time, we need to assign it a name. At the top of the Properties pane, you will find the Name field; type myFirstItem in that field.

  11. 11. Now add a Button control on top of the LayoutRoot control. To do that, select LayoutRoot under the Object and Timeline pane and then from the toolbox or Asset Library draw a simple button on your artboard.

  12. 12. Give it a name btnChangeStatus (follow the same directions given under Step 26).

  13. 13. Set its Content to Change Status (This property is located under the Properties pane, in the Common Properties section).

  14. 14. The next step is adding an event handler that will change the Content property of StatusBarItem.

  15. 15. With Button selected, click on the Events icon under the Properties pane and you will be presented with a number of events. Let's add our event handlers for the Click event. To do that, you will just have to type in the name for those event handlers and once you hit Enter, Visual Studio will start and allow you to add code logic. You can use btnChangeStatus_Clicked as a name for your event.

  16. 16. Add the following code:

    private void btnChangeStatus_Clicked(object sender, RoutedEventArgs e)
    {
    this.myFirstItem.Content = "Status has been changed!";
    }
    
  17. 17. Press F5 and your application will start. Click on Change Status and note that the text in your status bar area has changed.

How it works...

After the StatusBar control was added, I set several of its properties. I've set the height to 24 (it was fairly arbitrarily defined in this particular case), and I've also set the HorizontalAlignment to Stretch (to ensure that the StatusBar will consume all the horizontally available space). Also, VerticalAlignment has been set to Bottom (to ensure that StatusBar will dock to the bottom). By setting values of all margins to zero, I've ensured that there will be no empty space around the status bar when docked and stretched.

In order to make the StatusBar a bit more distinct (and to show a really simple way of customizing the control), I've changed the top border width and color.

With all the positioning and the look set, the next step was to add a very simple element to the StatusBar—StatusBarItem. Later, I will demonstrate how you can add a number of other different elements to StatusBar, but StatusBarItem was the simplest to do and it served me well to show you how to update its Content property via code.

This pattern might be used in real applications to update status messages during runtime, but in case your development knowledge is more advanced, you can take it to a more advanced level. But the idea remains the same: give the name to StatusBarItem and change its Content property.

There's more...

Status bar can be used to host more different controls to help you build better and more solid user experience for your users. In this section, you will learn how to do exactly that but you will also gain knowledge and valuable guidelines for implementing and designing user interfaces which are utiling StatusBar control.

Adding other controls to StatusBar

The previous example showed how to add the simplest of all elements to StatusBar. However, Blend enables you to add a number of other different controls to your StatusBar.

You can take it from the last point in the first example.

  1. 1. Select the StatusBar control and under the Properties tab, locate the Common Properties section. Click on the ellipses button near Items(Collection) and the Collection Editor (Items) dialog will appear. At the bottom, click on the arrow pointing downwards near Add another item. From the list, select Separator, and press Enter.

  2. 2. Repeat the procedure but this time select Button control from the list.

  3. 3. In the right-hand part, scroll down to Common Properties and type Button Content in the Content property. Press Enter.

  4. 4. Click on OK and now press F5 to start and test your application. Now you should be able to see a button with the Button Content label in your StatusBar control.

  5. 5. If your button is not completely visible, try changing the StatusBar Height property to, let's say 32. Press F5 now and your application should like the one in the following screenshot:

    • What if we want to add controls that are not listed in the drop-down list the we have seen in the Collection Editor? For example, how can we add the ProgressBar control?

  6. 6. Under Objects and Timeline pane, select the StatusBar control. Now go to Asset Library and pick the ProgressBar control. The next step is just to draw the ProgressBar control on top of your StatusBar control.

    Alternatively, you can just draw the ProgressBar control on your artboard and simply drag-and -drop it on top of the StatusBar. If you press the Alt key while dragging, ProgressBar will be added as an element of the StatusBar.

Take into account, if you want to be able to set or get properties from objects added to StatusBar control, you need to name them and use that name when referencing them from code.

Adding SizeGrip to StatusBar

Size grip is a commonly seen and used pattern: it enables you to grab a corner of your window and pull it to resize the window. Here is how to add a size grip to your status bar and enable resizing.

I will just continue from the last example. So, return to Expression Blend.

  1. 1. Under Objects and Timeline, select Window.

  2. 2. Go to the Properties pane and locate the Common Properties section. You will find the ResizeMode property there.

  3. 3. Click on the drop-down list and select CanResizeWithGrip.

  4. 4. You will now notice the size grip at the bottom-right corner of your window, on top of the StatusBar control.

  5. 5. Press F5 to start your application. Position your mouse cursor over the size grip and try resizing the form. As simple as that, zero lines of code!

When to use status bar

A status bar should be used in cases where you want to provide status information to your users but without harsh interruption of their main activities. It is generally located at the very bottom of the main (primary) application window and stretches from left to right with no margins, though specific exceptions might occur.

Information provided in a status bar is usually related to the current window's state, possible tasks in the background, or some contextual information.

The single most important thing is that a status bar should be used to provide information to the end users without interrupting them, which also means that information provided in a status bar should not be extremely critical or something that requires immediate attention. So, displaying status of loading a web page is fine, but letting the user know that a virus has been found on their C drive is something that requires immediate attention and should not be communicated through status bars.

Usually, a status bar uses simple text or images (icons) to communicate information, but a number of other controls can be also used. A progress bar (indicator) is one of them and it is often seen in web browsers showing the loading process of a web page. Also, menus for commands and options can be used in status bars.

However, status bars have one disadvantage: they are not easily discoverable. It is fairly easy to overlook them or even to completely ignore them. What can you do to "fix" this? I hope you are not thinking about using some aggressive animations, blinking, vivid icons, or some other means of grabbing users' attention. Recall what I said a few lines earlier: information provided in the status bar should not be extremely critical or something that requires immediate attention.

Ensure that the information you are placing into the status bar is relevant and useful and if that is not the case, well, then don't use the status bar. Also, if a user must see the information, then don't put it in the status bar—the status bar is not for critical information.

So, to summarize, use the status bar for relevant and useful information, but never for critical information!

Implementation guidelines

As always, throughout this book, the implementation and other guidelines provided here are not 100% comprehensive, rather they are suggestions and proven practices extracted from various resources. However, the ones presented in this book are those most commonly used and by following them you will avoid common pitfalls and ensure solid quality.

  • A status bar should be presented only on the primary window of your application. You should never use status bars on all of the windows of your application.

  • Don't use status bars as places to describe usage of controls on your UI. In the past (and I still see that sometimes), there was a trend to display information relevant to specific controls in the status bar. For example, if you positioned your mouse pointer over the printer icon, you would get something like Click here to print current document in your status bar. You should use tooltips for this pattern, never the status bar. Same holds true for menu items.

  • Is the information that you want to display in the status bar critical and/or does it require immediate action? If so, then don't use the status bar for it. Consider a dialog or message box, they will break the flow and grab user's attention.

  • Although it's not a rule (because of their relatively low discoverability), status bars might not be suitable for programs intended primarily for users who are beginners.

  • When using icons in the status bar, always choose easily recognizable designs. Also, use icons with more unique shapes; if possible, avoid rectangular- or square-shaped icons. You can use tooltips for icons that are not accompanied by related labels.

  • Don't change the status bar content too often. Status bars should present up-to date information, but they should not appear noisy or distracting.

  • When using textual labels, make them concise. Don't use bold, italic, underline, or colors to put emphasis on status bar text labels. That will only add visual clutter and noise without really helping the users and communicating valuable information.

About the Authors

  • Gaston C. Hillar

    Gaston C. Hillar is Italian and has been working with computers since he was 8 years old. Gaston has a Bachelor's degree in computer science (graduated with honors) and an MBA.

    Currently, Gaston is an independent IT consultant and a freelance author who is always looking for new adventures anywhere in the world.

    He was a senior contributing editor at Dr. Dobb's, and has written more than a hundred articles on software development topics. He has received the prestigious Intel® Black Belt Software Developer award eight times. He has written many articles about Java for Oracle Java Magazine.

    Gaston was also a former Microsoft MVP in technical computing. He lives with his wife, Vanesa, and his two sons, Kevin and Brandon.

    Browse publications by this author
  • Gill Cleeren

    Gill Cleeren is Microsoft Regional Director (http://www.theregion.com), Silverlight MVP (former ASP.NET MVP) and Telerik MVP. He lives in Belgium where he works as .NET architect at Ordina (http://www.ordina.be/). Passionate about .NET, he’s always playing with the newest bits. In his role as Regional Director, Gill has given many sessions, webcasts and training on new as well as existing technologies, such as Silverlight, ASP.NET and WPF at conferences including TechEd Berlin 2010, TechDays Belgium – Switzerland - Sweden, DevDays NL, NDC Oslo Norway, DevReach Bulgaria, NRW Conference Germany, Spring Conference UK, Telerik Silverlight Roadshow in Sweden, Telerik RoadShow UK. He is the author of Packt’s Microsoft Silverlight 4 Data and Services Cookbook and is also the author of many articles in various developer magazines and for SilverlightShow.net and he organizes the yearly Community Day event in Belgium. He also leads Visug (http://www.visug.be), the largest .NET user group in Belgium. You can find his blog at http://www.snowball.be and on Twitter by following @gillcleeren.

    Browse publications by this author
  • Kevin Dockx

    Kevin Dockx lives in Belgium and works at RealDolmen, one of Belgium's biggest ICT companies, where he is a 30-year old technical specialist/project leader on .NET web applications, mainly Silverlight, and a solution manager for Rich Applications (Silverlight, Windows Phone 7, WPF, Surface, HTML5). His main focus is on all things Silverlight, but he still keeps an eye on the new developments concerning other products from the Microsoft .NET (Web) Stack. As a Silverlight enthusiast, he's a regular speaker on various national and international events, like Microsoft DevDays in the Netherlands, Microsoft Techdays in Portugal, NDC Oslo Norway, and Community Day Belgium. He is the author of Packt’s Microsoft Silverlight 4 Data and Services Cookbook and also writes articles for various Silverlight-related sites & magazines. His blog, which contains various tidbits on Silverlight, .NET, and the occasional rambling, can be found at http://blog.kevindockx.com/, and you can find him on Twitter as well: @KevinDockx.

    Browse publications by this author
  • Todd Snyder

    Todd Snyder has been a software developer/architect for over 16 years. During that time, he has spent several years as a consultant providing technical guidance and leadership for the development of enterprise class systems on the Microsoft Platform. At Infragistics, he is a principal consultant that focuses on the design and construction of RIA and n-tier based applications. Todd is the co-leader for the New Jersey .Net user group (http://www.njdotnet.net/) and is a frequent speaker at trade shows, code camps, and Firestarters.

    Browse publications by this author
  • Joel Eden, PhD

    Joel Eden, PhD has been working in the area of user experience and design methods for over 10 years. Currently a Senior Interaction Designer working on UX Tools at Infragistics, Joel spent three years in the Infragistics Services group, consulting for external clients. Prior to Infragistics, he worked at multiple design agencies in the Philadelphia area, as well as working at Lockheed Martin’s Advanced Technology Labs. Joel holds a B.S. in Computer Science, and a Ph.D in Information Science, both from Drexel University.

    Browse publications by this author
  • Jeffrey Smith

    Jeffrey Smith has been a Visual Designer for six years. During that time he has been an Art Director at various agencies and studied special effects and animation at NYU. A convert from flash and flex he has been working with .NET technologies for the past two years, specializing in WPF and Silverlight. At Infragistics, he is an UX Visual Designer that focuses on the design, implementation and User Experience. You can view some of his work at http://www.thinksinkstudio.com.

    Browse publications by this author
  • Matthew Duffield

    Matthew Duffield is a .NET architect designing and developing enterprise applications. He specializes in .NET with an emphasis on WPF, Silverlight, and WP7 development. He is a Microsoft MVP in Client Application Development and has an MSCD.NET certification. He also works in business intelligence, designing and developing solutions for data warehouse and data mining initiatives. You can read his blog at mattduffield.wordpress.com and follow him on Twitter at @mattduffield.

    Browse publications by this author
  • Cameron Albert

    Cameron Albert is an independent software development consultant with over ten years of experience, specializing in Microsoft technologies such as Silverlight, WPF, WCF, SQL Server and ASP.NET. Having worked in the medical, insurance and media/entertainment industries Cameron has been involved in a variety of development solutions featuring a broad range of technical issues. Cameron also dabbles in game development utilizing Silverlight and maintains a blog detailing his exploits into the development world here:  http://www.cameronalbert.com

    Browse publications by this author
  • Frank LaVigne

    Frank LaVigne has been hooked on software development since he was 12, when he got his own Commodore 64 computer. Since then, he's worked as developer for fi nancial fi rms on Wall Street and also in Europe. He has worked on various Tablet PC soluti ons and on building advanced user experiences in Silverlight and WPF. He lives in the suburbs of Washington, DC. He founded the CapArea.NET User Group Silverlight Special Interest Group and has been recognized by Microsoft as a Tablet PC MVP. He blogs regularly at www.FranksWorld.com.

     

    Browse publications by this author
  • Vibor Cipan

    Vibor Cipan is currently serving as the CEO and Partner of FatDUX Zagreb – a full service interactive UX and service design agency with offices around the world. Before joining FatDUX, Vibor worked at Microsoft Development Center in Copenhagen and before that, at Microsoft, Croatia. One thing, however, has stayed constant—his focus on user experience, service design, usability and information architecture. He has been awarded the prestigious title of 'Microsoft Most Valuable Professional' for three years in a row (and is still currently holding that title). He was the youngest awardee and the first one in the CEE, Europe to receive the award while being a full-time student.

    Browse publications by this author
Book Title
Access this book, plus 7,500 other titles for FREE
Access now