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.