What are font metrics?

We’ll start with a font. A font is a digital representation of a typeface that consists of a series of glyphs (commonly called letters or characters). Computers read a font file in order to render glyphs on your screen as pixels. To describe how all those individual glyphs should be assembled together into words, sentences, and paragraphs, typeface designers encode the font with metrics.

Font metrics help the computer determine things like the default spacing between lines, how high or low sub and super scripts should go, and how to align two differently sized pieces of text next to each other.

Visualizing a font’s metrics, it looks a lot like guidelines in Sketch or Photoshop.

Your computer is constantly using font metrics, but as a designer or developer, you probably don’t think about them in your day to day. Maybe this is the first time you’ve heard of font metrics.

Similarly, while design and development tools use font metrics under the hood, they don’t often expose them to their users. But they could—and it could change the way you design. To understand how, we first need to talk about the anatomy of type.

A look inside type

There’s an anatomy behind the letters that makes up this sentence. As the example below shows, the curve of an “s” is called the spine—or the white space inside an “a” or “o” is the counter. Then there’s that imaginary line that all letters “sit” on (baseline), the tops of capital letters (cap height), and the tops of lowercase letters (x-height).

When we practice typography by arranging type on a page or screen, we’re often leveraging different bits of anatomy to create readability and beauty. For example, the search suggestions in Google Maps contain both a place’s name and address.

To help you focus on the most important information (a place’s name), the typographer has set the address in a smaller type size and a lighter color. But to help with readability, both the place’s name and address share a baseline.

The baseline is also helpful for creating vertical rhythm, which may make it easier for readers to jump from line to line, paragraph to paragraph, and section to section.

Another bit of frequently used anatomy is cap height, the top of capital letters. It often helps align your type with the top edge of pictures.

Or baseline and cap height can be combined to create a playful container for smaller type.

When we vertically center icons with type, we’re usually centering based on the cap height (if the first letter is uppercase) or the x-height (if the first letter is lowercase).

Typographic anatomy plays a big part in our designs. Pieces of that anatomy are encoded in font metrics, which open the door for our tools to help in new ways.

How do our tools use font metrics today?

Font metrics metadata is used by tools like Sketch to power features like smart guides, which can help you snap the baseline to a layout grid.

Similarly, CSS’s vertical-align relies entirely on font metrics.

Unfortunately, most of the time, our tools obscure type’s anatomy behind the bounding box.

In Sketch, the bounding box is represented by selection handles. In CSS, you can see it by setting a background-color. All type positioning is in relation to the bounding box, so if you wanted 100px from the top of the screen to a paragraph, our tools yield 100px to the top of the box, not to the top of an “L” (cap height) or the bottom (baseline).

While our tools are generally pretty good at helping with baseline alignment, that’s not always true. Multi-column layouts in Sketch can be tricky. If two differently sized headlines are aligned to the bottom of the bounding box, the smaller inevitably looks too low. Care must be taken to create a layout grid for smart guides to snap to or they must be aligned by hand.

Similarly, top aligning text to an icon doesn’t always work out either. On the left, Sketch’s align top tool. On the right, I aligned with the top of the “L” with the icon by hand. There isn’t any help from smart guides this time.

Finally, vertically centering text to an icon is a pain. Using Sketch’s align tool, the text always looks too low. The same is true with CSS flexbox’s align-items: center.

This is because even though the space above and below the text’s bounding box is equal, the space above and below the “M” is not.

In all of these examples, you could “eyeball” it, squinting your eyes or zooming in until things look right. Eyeballing comes with some notable downsides however:

• Translation - eyeballing leads to a lot of seemingly random values for spacing/margins. Say, margin: 27px 0 18px. If you’re not building the designs yourself, it’s easy for a developer to make a mistake when copying values from Sketch. And if you work on a team with other designers, sticking to a spacing convention (like an 8pt grid) becomes next to impossible.
• Maintenance - even if all the spacing values make it into code successfully, it’s easy to accidentally break them with future code changes.
• Flexibility - if the size, line height, or typeface ever changes, you have to carefully eyeball everything again.

With today’s tools, font metrics are usually hidden behind the scenes. But they don’t have to be.

How could our tools use font metrics?

Font metrics enable us to build smarter tools. They are the key to opening the bounding box, exposing the beautiful typographic anatomy inside.

For example, if Lato is the current font, Sketch can read lato.ttf’s font metrics, calculate the distance from the baseline to the cap height, then change the bounding box to snap to that new height. Vertically aligning center now works perfectly.

Once your intent of centering based on cap height is communicated, tools can preserve it. If the icon needs to increase in size or the text decreases in size (like if your users have adjusted the CSS base font size in their browser), nothing breaks.

The same benefit applies if the font changes (maybe your web font failed to load, or you’re using a system fonts strategy).

Writing code becomes easier too—no more align-self: flex-start; margin-top: 13px; to perfectly center the text. If CSS exposed font metrics via a property, like leading-trim, flexbox could take care of everything for you.

.icon-label {
    /*
    trim off the bits of the bounding box
    above the cap height and below the
    ideographic baseline
    */
    leading-trim: cap ideographic;
    /*
    then center using the trimmed height
    */
    align-self: center;
}

Our tools could also use font metrics to look at x-height and suggest a readable typeface for body text, quickly find a suitable fallback font to avoid FOUC, or in some distant future algorithmically suggesting typeface pairings.

Conclusion

Good typography is hard, but it can be easier with good tools. Embracing the raw anatomical features of type could enable us to create designs that are precise, resilient, readable, and maybe even original.

But it can be hard to get excited over Sketch features that don’t exist and CSS properties that aren’t implemented. Luckily, we can build some of this ourselves! In the next article, I’ll explore how exactly to extract and read the font metrics for your fonts. Once you have the raw data, I’ll explain the math behind using them in layout, and how they can be useful in today’s in HTML and CSS.

Further reading

Font metrics are a low-level implementation detail, but they’re far from boring. If you’re interesting in learning more, check out some of these fantastic resources. And if leading-trim sounds like a compelling CSS feature, check out CSSWG #3240.

• Deep dive CSS: font metrics, line-height and vertical-align by Vincent De Oliveira
• Get Down to the Nitty-Gritty of Text Rendering in Sketch by Yakim van Zuijlen
• Understanding the First Baseline Position of Text by Mike Rankin
  • It’s worth noting how our design tools of old (InDesign, Illustrator) expose richer font metrics control than today’s modern tools

Here are 6 quick tips to get you started with VoiceOver and Safari.

1. Turn it on

Head to System Preferences > Accessibility > VoiceOver and check the box. A dialog will show offering an optional tutorial (took me about 20 minutes), but you don’t need that, you have this guide! Click Use VoiceOver.

As soon as VoiceOver is on, your computer will start talking to you. You’ll also see a floating black bubble containing closed captions with a written version of the VoiceOver text, as well as a black rectangle indicating what UI elements have been focused on.

You can still use your mouse when VoiceOver is on, which is a helpful crutch while you’re still learning the keyboard shortcuts.

2. Be an explorer

While you can use your mouse, VoiceOver was designed to be used with your keyboard. You may have used familiar keyboard shortcuts like TAB and SHIFT + TAB to navigate in the past, but some types of UI aren’t tab-able.

To solve this, VoiceOver introduces new keyboard shortcuts. All of these shortcuts ask you to start by holding down CTRL + OPTION (referred to in the documentation as VO for Voice Over).

Start by trying CTRL + OPTION + →.

Try all the arrow keys! Notice how VoiceOver sometimes has tips for interacting with certain UI.

3. Silence!

As you navigate, all the talking can be repetitive if you aren’t used to it. Simply tap CTRL to instantly stop VoiceOver from reading. If you have music playing, OSX will smoothly lower the volume when VoiceOver is speaking, then ramp it back up when VoiceOver is done.

4. Stepping in and out

For certain pieces of UI, VoiceOver will focus on the container. To access the UI within the container, use SHIFT + CTRL + OPTION + ↓.

Try it out by switching to Safari, entering a URL in the address bar, and using the shortcut to start navigating.

Similarly, to get out of the container use the up arrow.

5. Click click click

Previously, I’ve used ENTER as the keyboard equivalent of clicking with the mouse, but a much more reliable option with VoiceOver is CTRL + OPTION + SPACE, which will do exactly what a click would.

6. Navigating

Play around with exploring via the arrow keys for long enough and you’ll soon become tired. There’s so much UI! Do we really have to CTRL + OPTION + → hundreds of times to get to the bottom of the page?

Luckily, no. VoiceOver has a cool feature called Rotor that lets you jump between things like sections, headings, links, and more. Activate it while on a webpage with CTRL + OPTION + U.

That’s all for now. Go ahead and give VoiceOver a try, maybe even try it out on that swanky-new-feature you’ve been working on. Some things to watch out for:

• Does VoiceOver announce that your clickable areas are clickable?
• Do your headings show up in Rotor?
• Do images have a description?
• Is copy in all caps read as an acronym?

Bonus tip: for those of us with touchpads, it is possible to lose your mouse if you accidentally are holding down CTRL + OPTION and rotate 2 fingers clockwise (my palm did this once). To fix it, simply hold down the keys and rotate 2 fingers counter-clockwise.

Unfortunately, these tools are mostly unavailable on Windows. My teammates at Microsoft largely prefer to work in Adobe Illustrator because it’s cross-platform. Not wanting to be left out, I started researching potential solutions. I ended up creating an Illustrator extension called Bloks which takes a new approach to layout.

Bloks uses stack-based layout. When art is placed in a BlokGroup with an orientation (vertical or horizontal), the BlokGroup keeps them stacked in that direction, edge to edge, no matter what you do.

Basic, but combined with a few extra features you can create just about any layout. Perhaps the most powerful feature is the ability to place symbols in BlokGroups. Resize a symbol once and all the BlokGroups it’s used in move to make room for it.

Access to such a primitive layout mechanism has the benefit of allowing designs that other tools do not.

You can also give objects flexibility, which allows them to fluidly resize.

These features come together to enable powerfully complex layouts, all within Illustrator.

I’ve been able to try Bloks out with several designers for a few months. It turns out that stack-based layout is extremely easy to learn, easier than the constraints Figma uses or the box model used by Antetype.

Stack-based layout is also extremely powerful. However, certain scenarios (like pinning an object 12px from the artboard’s right edge) are not intuitive (constraints make more sense in that case). Using symbols within stack-based layout is a huge time saver. You can change 20 margins in a few clicks. It would be even better with support for dynamic symbols (similar to symbol overrides in Sketch) as entire components could be turned into symbols.

Conclusion

I’m convinced that layout is a growing pillar of design, alongside giants like typography, color, and motion. As our industry’s tools evolve, I hope they add options for stack-based layout, maybe in conjunction with constraints so that everyone can explore this space.

You can try Bloks if you have Illustrator. Let me know if you have a problem by creating a new issue. Share your experience, frustration, or delight with me in the comments or on Twitter.

Under the hood, it’s all powered by flexbox (thanks for the tip Matej) and lot of long nights.

• “Well you should try X framework!”
• “Bah, all these libraries are to save you 20 keystrokes. Just use raw JS!”

While neither of those comments are completely disagreeable, they forget the big picture. Using raw JS may end your paralysis, but is it always the best choice?

Most sucessful frameworks and tools exist and prosper not because they saved you keystrokes or they just wanted to do something different for the hell of it. They exist because the vanilla technologies used for webdev (HTML/CSS/JS) make it hard to follow some very important principals:

1. DRY
2. Avoid globals
3. Encapsulate

HTML and CSS sometimes can’t accomplish being DRY. CSS and JS are both bad at avoiding globals. CSS is particularly horrid at encapsulation.

Ignoring these principals is fool hearted. They’re hard learned lessons from decades of programming experience. For example, encapsulation eliminates an entire class of bugs! Those bugs will bite you regardless of your project’s size, and they’ll only become more aggressive as it grows.

Successful frameworks and tools often got there by making it easier to follow your principals. To name a few: Sass and Handlebars keep it DRY, Webpack and Browserify keep it non-global, React and Web Components help encapsulate.

To conclude, I encourage you to make an honest list of the principals that you value. Ask yourself how important each is and what’s the easiest way to adhere? Sometimes the easiest answer might be to use a tool. Other times, it might just be to learn how prototypical inheritance works in Javascript. The important thing is to put your principals first, tools second.

Great minds discuss principals. Average minds discuss technologies. Small minds discuss tools. – Brad Frost

1. Create an Azure Web App. It’s free, but you have to hand over your credit card number
2. Follow the FramerAzureBoilerplate instructions to enable simple username/password authentication, as shown below:

Of course there are obvious security issues with sharing the username and password to everyone you want to share the prototype with, so keep that in mind. It’s also possible that your company has an internal Azure instance, which is even more secure.

1. Download Node.js and install
2. From Start, open the Node.js command prompt and enter npm install -g framer-cli
3. cd C:\Users\yourname\Desktop\, or to some other folder
4. framer new MyProto.framer
5. framer preview MyProto.framer

If you now take your browser to http://localhost:3000/, you’ll see your work! To make changes:

1. Navigate to C:\Users\yourname\Desktop\MyProto.framer\
2. Rename index.js to index.coffee
3. Open index.coffee and make changes

If you make edits while framer preview is still running, you’ll see your browser automatically perform a live refresh whenever you save. Step 2 is optional (working on it), you could write in JavaScript if you wanted. That’s the basics, but here are a few more tips:

• Emulate Framer Studio’s Mirror feature by typing ipconfig in the command prompt. You should see an IPV4 Address line with a set of four digits separated by periods. For example: 192.168.0.214. This is your IP address. If you have a device or phone on the same local network, type that number, plus :3000 into your browser. For example 192.168.0.214:3000. Now you can test your work on a phone or tablet. We’re working to make this easier.
• You can change the mouse cursor to a touch point by integrating this outstanding pull request.
• If you’re including code from a Framer Studio project and it doesn’t immediately work, you may want to integrate this pull request.
• If the preview isn’t showing anymore, check the command window where you ran framer preview. Compilation errors are displayed here.

The two major features that I miss most from Framer Studio are PSD and Sketch import as well as the editor’s intelligent autocomplete. You can play around with plugins for editors like Sublime Text to get better autocompletion (framer-cli is working on support for Tern), but it still won’t be great. And of course designs can be manually imported, but that’s fairly painful.

Today, the developer created a list UI component.

She sought to consolidate and unify lists in her many apps, while removing duplicate code. Her users would rejoice at the level of polish and consistency she’d achieved.

Being a responsible developer, she wants to ensure that lists display just as fast as ever. Unfortunately, she only has high-end devices to test on. Everything seems to be fine with her changes. But, she suspects that may not be the case on low-end devices. So she writes some code to measure how long it takes for the list to render and runs some tests, effectively benchmarking. Here are some of her results:

Unfortunately, it appears that on average, she made things a bit slower. Sure, it’s only a few ms, but what will a few ms become on a low-end device? Worse still, the 94ms result appears to be an outlier. Hmm. Maybe another process got some extra CPU time on that run. As she runs more tests, the level of variance is frustrating. ±10ms, sometimes worse!

Discouraged, she thought for a bit and came up with an idea. What if she wrote a stress test? Perhaps it tries to render 1,000 list items instead of the usual 40-50. That should take whole seconds to run and the mere ±10ms variance will be insignificant. Here’s her next round of results:

Oh dear. Not only did that attempt fail to clamp down on the variance, her changes seem to have made things even worse!

This is a dismal hole.

You can stay in it. Run more tests. Sometimes the variance will be less and you’ll think you have concrete results. But you’ll run more tests the next day and things are thrown back into chaos. To get yourself out, you must learn three things:

• Test real-world scenarios
• Test on slow, cheap devices
• Use a performance analyzer

Test real-world scenarios

Measuring performance is frustrating because each time you measure, you might get a different result. This is at odds with the repeatable nature of computing. While it’s tempting to write a stress test to minimize variance, unless you need to perform at the scale you’re testing there’s simply no value in optimizing for it. Test real-world scenarios.

Test on slow, cheap devices

This one sucks, because you have to buy something. Good thing it’s cheap, right? Alternatively, there are more than a few services out there that let you virtually “rent” a device for testing. While it’s tempting to try and slow your machine down or use an emulator, use a real device that you want to support.

Use a performance analyzer

These tools are often hard to use and come with a steep learning curve, but trust me they’re worth it. Instead of guessing at which part of your code is at fault, it will tell you. Even better, it stops you from measuring time from your app code, which may result in Heisenbugs.

Having absorbed these learnings, the developer was enlightened. After testing on a low-end device, she found that there wasn’t even a performance issue! Equipped with this newfound wisdom, she set out to prevent others from the same fate.

Doxygen turns out to be the de facto solution for this. It was super easy to hook up, I could document both in code and in separate files and I could document in markdown! I’ve found markdown to be the absolutely quickest way to write well structured comments. C# style Document XML is great, but not if you have to type it by hand. I might be swayed back to DocXML if Intellisense supported it for C++ and I could get a good comment generator going.

In any case, the website Doxygen creates is wonderful, but ugly:

Luckily I found doxygen-bootstrapped which applies the goodness of Bootstrap. The original repo was a bit sparse on documentation, but I managed to figure things out and contributed an example site to get your project up and going quickly.

Very pleased with the result. It’s even fairly responsive to screen width changes!

Side note

For anybody else needing to document C++ projects, you might have noticed that VS has a compiler option to generate DocXML. You could plug the XML output into Sandcastle and get a very nice looking site. The problem is that the DocXML compiler for C++ treats links in comments like code. What you’re linking to must be forward declared! This is incredibly impractical for comments where you want to link between different classes in your code base. Doxygen does not have this restriction.

High contrast is a source of confusion for many. This is a practical guide that extends the MSDN guidance and sample for developers who would rather not think about it.

When do I need to think about it?

As soon as you need to apply color to any UI (change it from its system default) or need to add images as decoration (ex: image background).

What do I need to do?

Start by creating the proper plumbing, if it doesn’t already exist.

• In App.xaml, create a ThemeDictionaries collection
  • Note that App.xaml may not be the most performant choice
  • HighContrast is not the only available key name. There’s also HighContrastBlack, HighContrastWhite, and HighContrastCustom
    • In almost all cases, HighContrast is all you need. Forget about the others - read on to see why
• In Default, create the type of Brush you need (usually a SolidColorBrush). Give it a Key name specific to what it’s being used for:
  • <SolidColorBrush x:Key="BrandedPageBackground" />
• Assign the Color you want for it
  • <SolidColorBrush x:Key="BrandedPageBackground" Color="Red" />
• Copy that Brush into HighContrast
• Determine what color your Brush should be in HighContrast

<Application.Resources>
    <ResourceDictionary>
        <ResourceDictionary.ThemeDictionaries>
            <!-- Default is a fallback if a more precise theme isn't called out below -->
            <ResourceDictionary x:Key="Default">
                <SolidColorBrush x:Key="BrandedPageBackground" Color="Red" />
            </ResourceDictionary>
            <!-- HighContrast is used in any high contrast theme -->
            <ResourceDictionary x:Key="HighContrast">
                <SolidColorBrush x:Key="BrandedPageBackground" Color="Red" />
            </ResourceDictionary>
        </ResourceDictionary.ThemeDictionaries>
    </ResourceDictionary>
</Application.Resources>

High Contrast Colors

Determining a color for high contrast requires a bit of learning. If you don’t have time, stop now. The plumbing you’ve created above will make this a simple bug to fix later.

The user can switch to high contrast using the above settings page. They have 4 high contrast themes by default. Once they select an option, the page shows a preview of how apps will likely look. Every square on the preview can be clicked to change its value. Every square also directly maps to a XAML system resource.

Prefix the names called out above with SystemColor and postfix them with Color (ex: SystemColorWindowTextColor). These will dynamically update to match what the user specified! The documentation for this is poor, but we can learn a bit from how they worked in the WPF days.

This frees you from having to pick a specific color for high contrast. Instead, pick a system resource that corresponds to what the color is being used for. In the above example, we named our SolidColorBrush BrandedPageBackground. Since this will be used for a background, we can map this to the SystemColorWindowColor in high contrast:

<Application.Resources>
    <ResourceDictionary>
        <ResourceDictionary.ThemeDictionaries>
            <!-- Default is a fallback if a more precise theme isn't called out below -->
            <ResourceDictionary x:Key="Default">
                <SolidColorBrush x:Key="BrandedPageBackground" Color="Red" />
            </ResourceDictionary>
            <!-- HighContrast is used in any high contrast theme -->
            <ResourceDictionary x:Key="HighContrast">
                <SolidColorBrush x:Key="BrandedPageBackground" Color="{ThemeResource SystemColorWindowColor}" />
            </ResourceDictionary>
        </ResourceDictionary.ThemeDictionaries>
    </ResourceDictionary>
</Application.Resources>

If you stick to this palette of 8 high contrast colors, you don’t have to create any additional high contrast ResourceDictionaries. This limited palette can often present difficult challenges in representing complex visual states. My advice is to look at other areas of Windows (like Start) and see how they solved a similar issue. Often, adding a border to an area only in high contrast can help bail you out of a situation.

DOs & DON’Ts

• DON’T put any Brushes that you create outside a ThemeDictionaries collection

• DON’T ever use StaticResource to reference a resource in a ThemeDictionaries collection. This will appear to work until the user changes themes while your app is running. Use ThemeResource instead

• DO put primitives like Color, Brush, and Thickness inside of ThemeDictionaries. Avoid putting more complex resources like Styles in them. The following situation works fine:

<Application.Resources>
    <ResourceDictionary>
        <ResourceDictionary.ThemeDictionaries>
            <ResourceDictionary x:Key="Default">
                <SolidColorBrush x:Key="BrandedPageBackground" Color="Red" />
            </ResourceDictionary>
        </ResourceDictionary.ThemeDictionaries>

        <Style x:Key="MyButtonStyle" TargetType="Button">
            <Setter Property="Foreground" Value="{ThemeResource BrandedPageBackground" />
        </Style>
    </ResourceDictionary>
</Application.Resources>

...

<Button Style="{StaticResource MyButtonStyle}" />

• DO test high contrast early and often

I’ve been thinking a lot about the elements of good typography lately. Specifically, I’ve thought about aligning type to a grid and how to technically achieve a grid-based design.

In the above example, the type’s baseline is snapped to a horizontal grid line. That’s not the only way to align type, but it’s very common. To learn about more, read about font metrics. To illustrate the value in aligning type to the grid, see the below example. Which looks better - the top or the bottom image?

The top example is aligned by descender (the bottom of the p). While the descenders do form a horizontal line, the baseline is visually stronger in this situation. In most cases, designers choose the bottom option. The intent is that the bottom edge of the rectangle is on the same horizontal grid line as the type’s baseline.

The problem

Once you start building, positioning your type by baseline is hard. Your UI framework doesn’t think like you. It puts type in a box that you position with positive (and sometimes negative) margins. You didn’t want to position type by box, you wanted to position type by baseline!

That 25px can really only be determined by guess work. Smashing Magazine explains that in CSS:

…the CSS line-height property doesn’t have an inherent concept of baseline, and each line of text is placed roughly in the middle of the element’s total height.

“Roughly in the middle.” Yuck.

Some frameworks try to remedy the issue. Android has baseAligned. CSS has vertical-align. Both of these cause a good deal of confusion. Try as you might, you’ll find yourself tediously nudging your type into place using margins. You know what you want, why can’t the UI framework think like you do?!

Enter TextLine

Let’s stop putting type in a box! Let’s think of type as curves that grow from a horizontal line that you get to position. Before, there was a box that imprisoned your type. Now, there’s a line that grows your type. Let’s call this paradigm TextLine.

Now positioning makes sense:

This paradigm extends to multi-line scenarios as well. The top margin simply applies to the first line, while the bottom margin applies to the last:

The baseline just one font metric. There’s no need to limit yourself to it. Can type grow out of the cap height line? Yes it can! Center of the em-square? Sure!

With greater power comes greater responsibility. It’s up to you to give your type enough room to grow, else it could clip and be unreadable. But don’t worry it’s not that hard. Use pseudolocalization to see how much space the riskiest glyphs need, then set a top and bottom margin that is at least that much. I’ve found that I barely have to think about it in most cases.

Further benefits of TextLine

This approach has added benefits when it comes time to localize your app. Localization can sometimes make things really ugly. Why? There aren’t very many font families that include the glyphs used in all of the most popular languages. To name a few:

• English
• Chinese
• Japanese
• Spanish
• French
• German
• Russian

Even if your font family does support all of those, what if you ever want to support something more rare like Hindi, Thai, or Sanscrit?

If you have plans of going world-wide, odds are that you’ll need to substitute fonts based on the locale. If your type is in a box, the baseline will move. Why? Different fonts have different font metrics.

Type in a box makes this a headache. You’d have to have different margins for different fonts. Localizing margins? Yuck! Now, it’s simple. You didn’t position a box, you positioned a baseline. Both fonts will render with the baseline in a visually pleasing location.

Prototype implementation

Bending our UI frameworks to treat type this way isn’t exactly easy. CSS doesn’t expose much about font metrics and unless you’re in a Canvas, JavaScript doesn’t either (although here’s a neat hack that can find the baseline, approximately).

XAML exposes baseline and cap height through the TextLineBounds API. It’s a bit hacky, but you can get a simple implementation stood up quickly using XAML’s attached properties. Here’s a screenshot:

The “Page Title” and “Subtitle” are baseline-aligned. This annoying task has been made dead simple:

<TextBlock
    Text="Page Title"
    FontSize="48"
    ...
    local:TextLine.Mode="Baseline"
    local:TextLine.Margin="120,96,0,0" />
<TextBlock
    Text="Subtitle"
    FontSize="24"
    ...
    local:TextLine.Mode="Baseline"
    local:TextLine.Margin="15,96,0,0" />

Note how both have a top TextLine.Margin of 96, even though they’re different font sizes.

Earlier, I mentioned that baseline doesn’t have to be the origin that type grows from. Cap height is another interesting metric because we frequently have to top-align type with images. This situation is illustrated by the red square next to the “This Horrible Herald’s Article” headline:

<Rectangle Width="200" Height="200" Fill="Red" />
<TextBlock
    Text="This Horrible Herald's Article"
    ...
    local:TextLine.Mode="CapHeight" />

No need for a top margin on either. It just works the way you expect.

Check out the prototype on GitHub. Unfortunately, there are some major issues with this simple implementation:

• Doesn’t work with multi-line TextBlocks
• Grid’s Auto positioning system will clip the TextBlock unnecessarily because we’re changing the Margin late
• Only supports the Baseline and CapHeight modes

A full implementation is certainly possible if you stop using TextBlock and start using DWrite. Perhaps I’ll write one someday.

That’s it. Let me know what you think in the comments!

Before now, I’ve tended to write in many different locations. From now on, this will be the one-stop-shop for everything. It’s new! It’s fun! It was created using Jekyll! You can find my previous writings here:

• Cryclops Wordpress
• Cryclops Quora

Why the move?

I was tired of feeling out of control. Wordpress made me fret over how the database was backed up. Quora doesn’t allow me to customize the look. Jekyll was the answer to both of these problems. I got started using Poole via this guide and only had to do a handful of tweaks to the poole master to get up and running.

Perhaps the only neat trick is a simple batch file that renames all of the *.html files to *.php to allow for PHP execution. This means it isn’t a truely static site, but it was the fastest way to pull in the existing header.php and footer.php look.

Working on a small team lead by Ruth kikin-Gil, we designed experiences for text selection, insertion, and the on-screen keyboard optimized for tablets.

Research

I started by reading up on market research from our awesome usability team to get a sense of who buys tablets, who uses them, who might use them in the future, and how they’re used. Tablets are a fascinating device category with a large potential for growth.

Customers buy tablets with hopes that they’ll get more done. Unfortunately, they often find the device falls short.

To find out why there’s this mismatch between productivity expectations and reality, we turned to usability studies. We discovered a huge amount of pain working with text. Even the most basic document editing tasks are worlds more complex than tapping out a text message on your phone. Users were caught in an uncanny valley, attempting to use text interactions they learned on desktop computers, with a mouse and keyboard, with their fingers on a tablet. It rarely worked.

At the time, Word wasn’t available on iPads or Android tablets, so I also looked at what the popular alternatives were on those platforms and took them for a test drive.

• iA Writer
• iOS Notes app
• QuickOffice
• Google Docs

Ideation

We did a lot of sketching, talking, and organizing to help identify the biggest areas that we could work on in several group brainstorming sessions.

The two largest problems that we agreed on were text selection and how annoying the on-screen keyboard was to invoke and dismiss.

Prototyping

I was able to quickly take sketches to high-fidelity interactive prototypes by coding a native Windows app that was a “smoke and mirrors” replica of the real Word (the Ribbon was mostly images, only enabled specific flows).

This allowed us to test the prototype with coworkers and run usability studies where the participants to completed realistic tasks. It took dozens of iterations before we were confident enough in a solution to build it.

Telemetry

While usability studies are a great tool, you haven’t succeeded until the numbers reflect that. In addition to looking at our engagement data, I wrote custom telemetry to determine whether our text selection model was frustrating.

The algorithm detected when a users finger was “wiggling” on a word while selecting (ex: they select forwards 3 characters, then backwards 2, then forwards 1 character, then backwards 1). We’d see this type of wiggling in the usability lab frustrating users. While we found a solution that worked in the lab, we weren’t as sure that would hold true for millions of users.

Conclusion

We succeeded at increasing engagement in this iteration. We received positive feedback about the new features – they’re still there today when you try the Word app for tablets.