After you completes the first steps in creating your reliable theme, it is now time to move forward and consider another aspect in this task. When the palette is ready the next step in to plan for the typefaces. Fonts are a crucial aspect tha shares with colors the scene almost with the same weight.

Choosing the wrong typeface means make your application difficult to read so the user can be tired after a short usage, but this is only one aspect of the problem. Togheter with colors, fonts contribute to the general feel about the reliability and effectiveness of the user interface. It is really important to carefully choose a wide set of options about fonts

aspect of the typeface: it exists a huge number of typefaces and every one of them can be used in specific context. Carefully evaluate your font, preferring sans-serif on serif because the first one are more readable in different sizes when used in user interfaces.

size of the font: size matters, and it is not a joke. Size is not only a problem of readability but also a problem of space. you have to choose the right size balancing the readability and the space available for your content. Also you have to consider that big does not means automatically easy to read. Using an huge typeface can significantly reduce the number of words you can write in a row and force the user to move from left to right too much times.

significance and uniformity of the size: the size is also a problem of meaning. Using a big font makes the content really preminent over another part where you use a smaller typeface. An also you have to use an omogeneous size across different parts of the application. As an example if you decide to use a given size for the grid header you have to use the same size on all the grids of the application.

careful use font weight: font weight and italic can give an additional gear to your interface but as usual, abusing in bold and italics can make the interface confused and not readable. For this topic it is valid the same rule of the previous point. Choose a weight and style for each meaning and the use it omogeneously across all the elements.

contrast of font on background: color of the typeface can affect readability more than size. Always use an high contrast between the foreground and background but not the maximum. Using too high contrast can create flickering effect and reduce readability.

After choosing typeface, size, weight and the other parameters I discussed in the previous paragraphs, it is time to embed them in your theme. Here is a short set of easy rules:

#1 - Plan the fonts matrix

Given that you only use a unique typeface for your application, or that you plan for a single typeface at a time, the font used in your theme can be easily organized using a matrix. Your fonts matrix have the weight in the rows and the sizes in the columns. Here is a simple matrix:

The font matrix really can help to better understand fonts across the parts of your application. You know that the upper left corner identifies parts that are less important than the lower bottom cell. You do not have to fill every cell in the matrix, but on the contrary the better is leaving the most of the cells empty.

#2 - Name your weights and sizes

Then, as we have done with colors, it is important to abstract names for weights and sizes. Primarily for sizes but also for weights you have to use a naming convention that remove the need of knowing the number or the real weight of the typeface. For weights you can user terms like "Light", "SemiLight", "Normal", "SemiBold", "Bold". You can alternatively use FontWeight or FontFace to determine weight. Lot of fonts are created in various flavors with a face for every weight. Segoe UI is an example.

   1: <FontFamily x:Key="FontFamilyLight">Segoe UI Light</FontFamily>

   2: <FontFamily x:Key="FontFamilySemiLight">Segoe UI SemiLight</FontFamily>

   3: <FontFamily x:Key="FontFamilyNormal">Segoe UI</FontFamily>

   4: <FontFamily x:Key="FontFamilySemiBold">Segoe UI SemiBold</FontFamily>

   5: <FontFamily x:Key="FontFamilyBold">Segoe UI Bold</FontFamily>

For sizes I usually use "ExtraSmall", "Small", "Normal", "Medium", "Large", "ExtraLarge", etc... This naming helps to separate the real size from the meaning of the size. You can assign to Normal a size of 12 or 18 and then recalculate all the other sizes on the base of the middle value. It is not important the regularity of the distribution but most of the times the distance between the intervals increase on the growing of the size.

   1: <mscor:Double x:Key="FontSizeTiny">9.33</mscor:Double>

   2: <mscor:Double x:Key="FontSizeExtraExtraSmall">10.667</mscor:Double>

   3: <mscor:Double x:Key="FontSizeExtraSmall">12</mscor:Double>

   4: <mscor:Double x:Key="FontSizeSmall">13.333</mscor:Double>

   5: <mscor:Double x:Key="FontSizeNormal">14.667</mscor:Double>

   6: <mscor:Double x:Key="FontSizeMedium">18.667</mscor:Double>

   7: <mscor:Double x:Key="FontSizeMediumLarge">21.333</mscor:Double>

   8: <mscor:Double x:Key="FontSizeLarge">24</mscor:Double>

   9: <mscor:Double x:Key="FontSizeExtraLarge">29.333</mscor:Double>

  10: <mscor:Double x:Key="FontSizeExtraExtraLarge">37.333</mscor:Double>

  11: <mscor:Double x:Key="FontSizeHuge">42.667</mscor:Double>

Remember that if you decide to use FontWeight for name the weight of the your application you have then to name your face:

   1: <!-- WEIGHTS -->

   2: <FontWeight x:Key="FontWeightLight">Thin</FontWeight>

   3: <FontWeight x:Key="FontWeightSemiLight">Light</FontWeight>

   4: <FontWeight x:Key="FontWeightNormal">Normal</FontWeight>

   5: <FontWeight x:Key="FontWeightSemiBold">Bold</FontWeight>

   6: <FontWeight x:Key="FontWeightBold">Black</FontWeight>

   7:  

   8: <!-- FACE -->

   9: <FontFamily x:Key="FontFamilyDefault">Segoe UI</FontFamily>

#3 - Name your styles

As you should never use your colors directly in the markup, you should never use font family, weight and size in the same way. For fonts the problem is slightly more complicated because there is not a "Brush" instance to define to wrap the typeface. You have then to define a style for every control that have to use the typeface.

This may seems difficult but you have to keep in mind that, soon or later you will have to create a style for each element you have to put in the markup. So it is normal to assign the right typeface, weight and size combination to each one.

The most obvious element you have to create a style is TextBlock. And for textblocks you can use a conventional naming that identifies the parts where you have to put the text. To be more clear, the style you apply to textblock is the one you wrote in the cell of the font matrix.

<Style x:Key="TextInputLabelStyle" TargetType="TextBlock">
    <Setter Property="FontFamily" Value="{StaticResource FontFamilyBold}" />
    <Setter Property="FontSize" Value="{StaticResource FontSizeNormal}" />
</Style>

Also remember to determine the default aspect of the TextBlock using implicit styles

<Style TargetType="TextBlock" BasedOn="{StaticResource TextInputLabelStyle}" />

After this your fonts have been strongly organized in your theme and you can start using blend to edit styles and templates. Blend UI is able to show your planned fonts easily and you can take advantage of naming to make the look & feel more effective.

Working on applications built with Silverlight, it is really common you have to deal with styles, templates, and often this means you have to build a theme pervading an entire application. Building a theme is not so simple as you may believe at the first sight. It requires instead a careful planning, from the conceptual side first and in the technical implementation then. There are lot of topics regarding the creation of a theme from the designer point of view but here I want to discuss about the implementation details that are often underestimated.

Styles are a great thing. But if you ever tried to use them without a careful planning you are aware that, more than often, they become a nightmare. We all are conscious about the reasons that move us to adopt styles in an application, but when the time comes we all tent to forget these reasons. And this is the mother of all the mistakes - ok, not only about styles - that usually makes our "stylesheet" more similar to a disordered trashcan instead of an useful thing. You start coding UI, then you understand that some properties have the same values, so you extract them and put it into a style. This may seems good but soon (or perhaps too late) you start to be unable to reuse the same style on more than two or three controls before you need to duplicate it.

Planning for styles is a difficult game, but it may change your life to the better if you know where to start from. And in my humble opinion the real start point - just after the end of the designer's work - is to create a palette. Colors and Brushes are usually the most obvious properties you move to a style, but having your colors spread over a 5 thousand rows stylesheet is almost not useful as if it was spread along all the pages. So, before you start, write down this sentence and put it on top of your monitor: "I will never write a color manually more than once".

#1 - Name your colors

It may seems silly but this rule automatically imply we have to name our colors. Ok guy, please stop writing now. Do not name Red as Red. Instead you have to use a more meaningful naming that adhere to the matter of your application. I usually make large use of adjectives like "Light" and "Dark". The reason to not name Red as Red (this is about to become another sentence to put on your monitor) it that easily, what it is Red now may become Green tomorrow and you for sure do not want to name as Red all your Green :) If a theme make its work fine it allows you to easily change lot of your UI without changing anything in the pages. So, here is a simple example of a named palette:

   1: <Color x:Key="ExtraDarkColor">#FF333333</Color>

   2: <Color x:Key="DarkColor">#FF666666</Color>

   3: <Color x:Key="BasicColor">#FF888888</Color>

   4: <Color x:Key="LightColor">#FFdddddd</Color>

   5: <Color x:Key="ExtraLightColor">#FFeeeeee</Color>

This is a very simple example but it explains the point effectively. You have to choose your names basing more on where or when they are used instead of the color they represent. It is a good rule of thumb to have a scale of light fore each color you use in your palette. This makes your life easy when you need to present selections, embossed borders (really? please avoid emboss your borders) and so on. This section has to be written at the very start of a ResourceDictionary (in another post I will explain how to organize the dictionaries) and it is the sole point where a color appears in the one I call the "sharped form" (remember the "#" in front of the color? ok you got the sharp).

#2 - Name your brushes

Ok, I'm reading clear on you the doubt. What the hell I can do with a bunch of colors? You all are right, colors are a form that is not ready to be used in your markup. 9 times over 10 a property of an element does not accept an instance of Color but instead it requires a Brush. So, as you did with colors, now you have to name your brushes. Brush names are more close to the real usage, and please keep in mind that nothing prevent you from use the same color in two or more brushes. Here is a set of brushes:

   1: <SolidColorBrush x:Key="BackgroundBrush" Color="{StaticResource ExtraLightColor}" />

   2: <SolidColorBrush x:Key="HighlightBrush" Color="{StaticResource LightColor}" />

   3: <SolidColorBrush x:Key="SelectionBrush" Color="{StaticResource LightColor}" />

   4: <SolidColorBrush x:Key="AlertBrush" Color="{StaticResource DarkColor}" />

As you can see, the brushes' name suggests the use you have to do with it. In this example you have Highlights and Selections rendered with the same LightColor and the AlertBrush is a DarkColor. This one is a good example of the naming: you do not need to have the Alert as Red, you only have to use a color that stands over the BackgroundColor. An the naming here helps you to remember the meaning instead of it color.

#3 - Name your gradients

Some applications make use of gradients. As you know gradients are simply a transition between a series of colors. And with your named colors you can for sure create a set of named gradients. Thanks to the Brush concept you can avoid to put gradients in the markup but you can easily put them side by side with the palette and the solid brushes and this way you are able in the future to change a solidcolor to a gradient and a gradient to a solidcolor:

   1: <LinearGradientBrush x:Key="SoftBrush" EndPoint="0.5,1" StartPoint="0.5,0">

   2:     <GradientStop Offset="0.0" Color="{StaticResource ExtraLightColor}" />

   3:     <GradientStop Offset="1.0" Color="{StaticResource LightColor}" />

   4: </LinearGradientBrush>

   5:  

   6: <LinearGradientBrush x:Key="ToolbarBrush" EndPoint="0.5,1" StartPoint="0.5,0">

   7:     <GradientStop Offset="0.0" Color="{StaticResource DarkColor}" />

   8:     <GradientStop Offset="1.0" Color="{StaticResource BasicColor}" />

   9: </LinearGradientBrush>

In my old applications I was use to call gradients as a named followed by "Gradient" but recently I've understand that it is a bad policy like naming Red as Red. You will understand it the first time you whant to flat your embossed toolbar and you transform a gradient to a solid brush.

#4 - Take advantage of Blend (with care)

Once you have created a palette and a set of brushes you can start using them and Expression Blend is your best friend but you have to pay attention to something.

On the right side you see the color tool of Blend. Instead of it you see a tab named "Color Resources". Please always remember to never use it. This tab exposes the Color instances you named in your palette. At the first sight is may seems a good idea to select colors from here but is means you put a Brush in the markup and this brush wraps the color you have selected.

Just because Colors are not directly supported, Blend expose them to let you edit gradients easily but it wraps them into a brush before to set the property of the element you are editing. You have instead to use the last button on the very top of the window. It is named "Brush Resources" and it shows the brushes you have laboriously defined.

It is all about colors

As I've already said, your palette is the central point of the theme of your application. And planning themes carefully let you change the look & feel easily making its lifetime much more longer. XAML Resources are ten times more powerful than CSS and the content of this post is a good example of this power. As an interesting excercise, please try to reproduce the matter of this post in a CSS and you will understand that it is simply impossible.