Methods to load iconographic assets in apps have improved over the years. A great advantage to those who do not have the support of graphical designers on their teams. Icons for apps have evolved from old day clip-art galleries all the way to icons stored inside font files. This latest method besides being handy provides the ability to render vectorized icons. Vectors adapt themselves to different display resolutions where our app might be available. Most of the XAML visual elements are vectors and so should be icons.

Microsoft offers many fonts that ship with Windows containing illustration assets. From the traditional Wingdings fonts to the new ones designed for modern apps, the Segoe family of fonts. In the latest version of Windows 10, we can find Segoe MDL2 Assets and Segoe UI Emoji. They come preinstalled in the system and can be consumed by controls that render text simply by changing the FontFamily property of the control. Although, there are a series of controls created to display icon assets.

The UWP development platform provides a series of classes that extend the IconElement class, but only two of them support fonts as their source. FontIcon and SymbolIcon, these classes differ in the way we indicate what icon to use. SymbolIcon is created exclusively to consume icons from Segoe MDL2 Assets, and its source can’t be changed. It allows the class to expose a Symbol property that accepts an easy to memorize icon friendly name, as oppose to FontIcon where we can assign a different FontFamily value and indicate the icon to use through its Glyph property using the internal Unicode value representing the glyph location inside the font file.

The value we can assign to the Symbol property in a SymbolIcon does not include the valid glyphs that the font provides. For those cases, the recommended method is to use the FontIcon class instead. We can freely indicate the Unicode value based on what the font contains. The two font icons that come with Windows usually get additional icons as new versions of Windows ship. For this reason, we need to be careful in assuming that a Unicode value will render a valid icon in the previous version of Windows where our app could be running as well. Check on MSDN or use the Character Map accessory application that comes with Windows to verify a Unicode value and if it is valid in the versions of Windows the app targets.

When using a Unicode value identified in the Character Map we use one of two formats based on where we make the assignment. In XAML code we use "" where E787 is the hexadecimal value for the selected glyph in Character Map in image 1. To use it in code-behind the format is "\uE787".

The icons found in Segoe UI Emoji font come with color information for its glyphs. This color is shown if the platform or the application they are rendered in supports multicolor layers coming from fonts, UWP apps support it as well as Windows 10. In cases where there is no support for color, a monochromatic version of the emoji is displayed. Some text controls (TextBlock and TextBox) provide a property IsColorFontEnabled to indicate when to use color or the fallback monochromatic version. FontIcon does not have this option. The glyphs found on Segoe MDL2 Assets are only monochromatic. There is no color information coming from the font itself, but that does not prevent us from setting the control’s Foreground property to some color and get the font’s glyphs colorized. If we look closely at all the glyphs provided by this font we will notice that certain icons come in two versions: outline and filled. Having a FontIcon instance rendering the fill glyph and assigning a color to its Foreground property, and overlapping another instance of FontIcon rendering the outline version of the icon creates the effect of multiple layers with different colors.

As seen in the previous section, there are instances where the icon we are looking for is not provided by any of the system fonts or that an icon does not have its corresponding outline/fill version we wish. To solve this, we could look for other fonts available online, free or commercial, and embed them into our project. Some projects might even have the budget to get professional font designer services where we could have fonts created with icons from trademarked visual assets, like logos or other visual assets that help our app set a differentiating element.

With a font file (usually TTF) that contains our custom icons embedded into the application project, we can proceed and use it in the different controls that we discussed earlier that support FontFamily changes. The same way as we add image files to the project we can add a font file. Verify that the file is added to the project with Build Action set to Content.

Once we have the file in the project is a matter of reference it in the FontFamily property of the control using this format:

FontFamily="[PathToTTF]#[NameOfFontFamily]"

A font file could define more than one font family, for this reason, we need to indicate its name after the file name. On code-behind you can set this property as well, FontFamily is a class that its constructor takes a string value indicating a Uri pointing to a resource. We can take this mechanism to refer to a custom font in our project this way.

Notice that the Uri uses the application Uri schema to refer to resources in a project. This provides the possibility to have font files embedded in satellite assemblies (Class Libraries).

Before closing this post, let’s talk about the user licenses that govern the use of fonts. The contents of fonts, being them letters or symbols, are bound to license that indicates if it is possible or not for us to redistribute the file with our application. It also indicates other permissions or restrictions regarding the modifications of the glyphs it contains.

A graphical designer or a company might have trademarked those designs an explicit permission should exist. In the case of the Segoe fonts or other fonts that are part of Windows 10, when we refer to their glyphs in our app without embedding the file in our project is part of the expected usage of it allowed by its license. We are not distributing the font and when the application is launched in a customer’s Windows 10 machine it will load the font information from that machine.

Same goes for any other font from the internet. We need to check what permissions or restrictions we must follow to make use of it.

In summary, we visited the icon controls that the platform offers as well as how to consume the system provided icons in those controls and a mechanism to include custom-made fonts embedded in our project or a class library.

The light effect that appeared on nearby tab’s borders while hovering a tab was possible using a technique called Reveal from the Fluent Design System, one of the new features of Windows 10 Fall Creators Update, which is about using light to guide user interaction into target areas of the app.

Some controls have this functionality baked into them but disabled by default as these visual effects are GPU intensive tasks that if used improperly or in too many controls could compromise the performance of your app altogether.

As many visual aspects this is achieved using styles paired with visual state changes. Another technique introduced by Fluent Design is Acrylic which define a new Brush named AcrylicBrush which allows different levels of transparency for app elements within the app and with other apps or objects behind its window.

The visual effects for Reveal combine a set of Brushes for Background, Foreground, and Border applied to the target element.

To be able to consume this feature we change the target values of the project to Fall Creators Update build in both values for build targets, this will make all the new types available to our code. There are ways to set up the code so that it checks for different build versions so that users in older builds can still run the app without the extra juice, but that is a topic for another post, so bear in mind that for this to work in your machine you need to have the Fall Creators Update and its SDK installed.

We begin defining two AcrylicBrush instances around the colors used in the TitleBar and the PivotHeaderItem. Then we create StaticResource references to replace the values that were already used by the app.

If you read the previous article you might remember that we overrode a series of StaticResource references inside the ThemeDictionary to impact or affect those values inside the styles for Pivot, PivotItem and PivotHeaderItem. Pay closer attention to the later ones, they have combinations of states and actions to support the different VisualStates observed in the control’s behavior. To suit our new needs, we are going to rearchitect those references for PivotHeaderItem which is the area where we will be applying the Reveal effect.

The new changes organize the states and actions into three groups: Background, Foreground, and BorderBrush with the corresponding states of Selected and Unselected. Although the “unselected” is not part of the name for the resources anymore.

You can refer to the source code on GitHub to observe these changes as they represent a big chunk of code to include it in here.

Once all the colors and brushes are in place with the corresponding reference names for StaticResources we proceed to make modification inside the styles defined for the controls. Most of the changes were to the style for PivotHeaderItem, but a few improvements were given to the other styles as well that are worth mentioning. For the Pivot style, the Background property of the elements named LeftHeaderPresenter and RightHeaderPresenter is now pointing to a ThemeResource instead of a StaticResource, although the result is visually the same. Why this change? It is better for styles to have dependencies on values defined at a Theme-level, so they can adapt properly making the apps theme-aware. Another changed is around the ItemsPresenter named PivotItemPresenter, this element has been wrapped in a Grid, so we can apply the properties of Background, BorderBrush and BortherThickness to the whole row. And the same values were removed from the root Grid on the PivotItem’s style ControlTemplate.

In the PivotHeaderItem style the changes made were on three areas as shown in the following code fragments, first to the Style setter properties some were modified, and others added.

Then some additional properties set on the Grid root for the ControlTemplate.

And as the core for the Reveal effect, the changes happened inside the VisualState elements for most of states in the controls behavior. As this code change is too big to post in here, I present one of them to illustrate the changes while the others are significantly similar with its corresponding resource value reference.

With these changes the goal of applying Fluent Design to the app is completed. Remember to review the complete project source code on GitHub as some small details were not mentioned in this post. And in case things don’t work as expected let me know in the comments.

While starting a project I wanted to have a similar visual style as the one found in modern versions of Office, specially the Ribbon control, but then I couldn’t find a Ribbon control in the toolkit that ships with the Windows SDK, and while the Ribbon control behaves very similar to a Tabs control there wasn’t one either for UWP apps. After searching for a while I found that in UWP it is the Pivot control the one that offers a generalized functionality like Tabs or Ribbon.

The Pivot control offers a series of sections identified with a header and as the user selects one of those headers the content of the section is presented. The way the Pivot control made its way into Windows Phone and after that to Windows 8.1 and 10 was to change Page views. For that reason, it didn’t occur to me that it could be used as a Ribbon.

Now, the task is to change the styles and visual resources of the Pivot control to match as much as possible the experience of the Ribbon control found in Office.

For this post, Visual Studio 2017 (with the latest updates applied) and Windows 10 Fall Creators Update will be used with its corresponding Software Development Kit.

The starting point for any change to the style of a control is usually looking at the controls Style property where we can easily right-click the control in the Designer area or through the Document Outline in Visual Studio. But after trying some changes and looking at the style contents I couldn’t figure out how to totally modify the PivotHeaderItem to mimic those tabs found in the Ribbon control.

The PivotHeaderItem is the element that renders the contents assigned to the Header property for each PivotItem. But the style that defines those elements is not exposed through any “style” property in the Pivot control, instead we only get a HeaderTemplate property which generates an empty DataTemplate to start from scratch. Not very helpful for what we want to do.

I took another approach based on something I read on MSDN on the many searches for a solution, modifying the controls ThemeResources.

We start by creating a New Project in Visual Studio using the Blank App template for Windows Universal, on this I made modifications to the MainPage.xaml and its code behind to extend the contents of the window to cover the window’s TitleBar and mimic a similar style as with the target application.

Following by adding a ResourceDictionary (AppStyles.xaml) to the project where all style definitions and modifications of existing ones will be stored and added a reference to this resource in the Page section of MainPage.xaml. A series of numerical and color and brushes definitions were added to be applied to the TitleBar look.

In the XAML code for MainPage.xaml, there is a series of Grid elements to layout the different pieces that made up the TitleBar, there is a reserved area to the left where some apps have the Back navigation button, an area for the document title, another area where Word in this case shows the current logged in user, a panel separator for aesthetics, and the window control buttons to minimize, maximize and close the program window. After that a Pivot control with a series of PivotItem elements following the sections found in the Word application.

And the code behind added to MainPage constructor to change the color of the TitleBar, specially the reserved buttons area and some instructions to extend the window contents into the area reserved for the TitleBar.

We copy into our own ResourceDictionary the elements to override into a ThemeResources section and assign the new values. This will cause that the controls that have references to this resources will take our changes first, and if we didn’t modify them, they use the default values.

As we change some of the values for the Theme resources we might notice that certain changes get reflected immediately on the Designer in Visual Studio, but other changes will require to Build the project, so changes get compiled and the Designer refreshes its cache values for those resources.

After all the possible modifications to themes, there is still some changes to get closer to have a Pivot that resembles the Ribbon in Word, for that we need to modify some values on elements of the Pivot, PivotItem and PivotHeaderItem styles.

To avoid getting lost in the contents of the styles and not making this post even longer, I will only point to the particular changes to the styles but you can have access to the complete sample code for this post at GitHub.

The ThemeResources in the previous code excerpt made some references to a series of Brushes that were not previously presented. Those are the colors for the Pivot control copied from the values used for the TitleBar but I wanted to have separate identifiers for them in case we wanted to quickly made changes that affect only one control.

The style for the Pivot control, look in the source code for “style for Windows.UI.Xaml.Controls.Pivot”, contains five minimal changes, 3 of them are numeric values and the other 2 add properties to a pair of ControlPresenters. The numeric values affect the following elements, the Grid “PivotLayoutElement” which defines two rows had its first row's Height value changed from Auto to 32. This is the height of the tabs area for the Ribbon. The other two numerical changes were in the Height property of the Buttons “PreviousButton” and “NextButton” from 36 to 32 as they need to fit in the row defined for the Ribbon’s tabs. The remaining two changes on the ControlPresenters are highlighted in the below code fragments.

For the PivotItem style, search for “style for Windows.UI.Xaml.Controls.PivotItem” in the source code of AppStyle.xaml there are two changes. The value for the Setter property VerticalContentAlignment changed from Stretch to Center. And the Grid serving as container for the ControlTemplate got two additional properties, BorderBrush and BorderThickness.

The last set of changes are in the PivotHeaderItem style, search for “style for Windows.UI.Xaml.Controls.Primitives.PivotHeaderItem” in the source code. Changes to this style are two, the first is to change the value of the Height property on the style Setter from 48 to 32 as seen in previous changes this represents the height of the tabs row in the Ribbon. The other change is in the ControlTemplate container adding to the Grid a CornerRadius property with value "2,2,0,0" to set the rounded corners of the tabs. As we can see in image 3, that’s the most noticeable missing change to achieve our goal.

After all these changes are in place, we can build and run the solution to observe the effect. Notice that while our changes makes the experience quite similar, we didn’t copy the entire behavior of the Ribbon control. If we look closer into the Ribbon in Word we will see that as we move the mouse over the unselected tabs, their background change into a color that is not quite solid, as in our code, it feels more like a gradient brush. Also the tabs at each side of the one being hovered get a small glowing background effect creating a more vivid illusion of light, it is a nice touch, but was not part of what I planned to do. I kept thinking on how that could be implemented, might it be possible that such effect is part of the new Fluent Design? Certainly, I will revisit this in a future post.

You can find the complete source code for this article on GitHub and use it as a starting point for your project.