Wyatt Says...

This will be the quickest tip you’ll ever read. But first, some background. If run your .NET app on Windows Vista or Windows 7 unaltered you might notice the fonts look a little funky. Especially when compared to Microsoft’s own apps. See the ugly font in the window on the right:

On the left I’m using the default system font in Windows Vista & 7: Segoe UI. On the right I’m using the default font that every Windows Forms app uses: Microsoft Sans Serif. It’s quite obvious that the Segoe UI font is slightly larger and more legible. Not only that, but if you use the font on the right instead – the Microsoft Sans Serif – your app will be out of place in Windows Vista & 7, since every other app in Vista & 7 uses the Segoe UI font.

Problem: Segoe UI isn’t in Pre-Vista systems

The problem is that Segoe UI is only shipped with Vista & 7 versions of Windows. So you can’t just hard-code the Font property of the form to be Segoe UI (or your app will look like utter crap in Windows 2000 & Windows XP).

And thus this simple snippet of code to use Segoe UI on Windows Vista & 7 while still using the default system font in Windows 98, 2000 & XP.

public Form1()
{
    // use Segoe UI in Vista & 7
    Font = SystemFonts.MessageBoxFont;

    InitializeComponent();
}

Or, in VB.NET:

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    ' use Segoe UI in Vista & 7
    Font = SystemFonts.MessageBoxFont
End Sub

That’s all you have to do to use Segoe UI font in your app. And if you set the AutoScaleMode of the form to “Font” then all of the controls on the form will scale to fit the larger font:

Bold font problem

What if you want to bold a title? Simple, right? Just click the Font property of the label you want to bold:

However, the problem with doing this is now every control on the form except the label you want to bold will be Segoe UI font. Why is this? Every control on your form will have the same font as the parent unless specified otherwise.

In our case the parent is the Form and we’re explicitly setting the font to be bold for our label to be “Bold Microsoft Sans Serif”.

“Ok, ok – but how do I make a bold label use Segoe UI?”

We just learned you won’t be able to do it in the designer, so instead you’ll have to do it in code:

public Form1()
{
    // use Segoe UI in Vista & 7
    Font = SystemFonts.MessageBoxFont;

    InitializeComponent();

    // set the title to be bold
    lblTitle.Font = new Font(Font, FontStyle.Bold);
}

Or in VB.NET

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    ' use Segoe UI in Vista & 7
    Font = SystemFonts.MessageBoxFont

    ' set the title to be bold
    lblTitle.Font = New Font(Font, FontStyle.Bold)
End Sub

7 Days of Windows 7

Join me tomorrow when I talk about adding professional looking menus to your app. See the full list of articles in the series.

For the next 7 Days I’ll be giving 7 C# & .NET tips to make your Windows application look like it was built for Vista and Windows 7. All of these tips are used in our products (wyBuild, wyUpdate, and LimeLM) and they range from the simple one-liner, free open source controls, and to the advanced tip.

And since wyBuild, wyUpdate, and LimeLM are all compatible with Windows 2000 through Windows 7 all of these tips will be backward compatible.

7 days of Windows 7

Day 1: Windows Vista & 7 Font, Segoe UI, in C# and VB.NET
Day 2: Making the menus in your .NET app look professional
Day 3: Windows 7 Progress Bar in .NET
Day 4: Drag & drop icons in .NET – Windows 2000, XP, Vista, and 7
Day 5: Shield icons, UAC, and process elevation in .NET on Windows 2000, XP, Vista, and 7
Day 6: Windows Vista and Windows 7 .NET Controls – Every possible one you could ever want
Day 7: Finishing touches: Make your .NET app shine with professionalism

This week I was doing work on LimeLM that involved virtual machines. In particular preventing piracy in an environment where the whole PC can be duplicated bit-for-bit. As you can imagine this meant installing and using many virtual machines; VMware, Virtual PC, Virtual Box, Hyper-V, Parallels, and every other obscure VM.

When I ran Parallels the first time it reminded me of a split test I ran on wyBuild a couple of years ago. Here’s the first run of Parallels:

You’re seeing this right – 4 windows stacked on top of one another. They’re even polite enough to welcome me twice.

No one reads dialogs.

The worst part is that I still haven’t read what the dialogs say – and this is even after I cropped & arranged the dialogs in Photoshop, proof-read this article 3 times, and written this very sentence. They could say some pretty vulgar things and I wouldn’t even know.

If a dialog has more than 3 words I just look at the buttons and guess what the dialog says. Here’s what I read:

I clicked OK on the last dialog, and a new dialog popped up:

Oh God, they’re breeding. I’m sure “Copyright Notice” is real page-turner, but I have better things to do.

What can you learn from Parallels’ Mistakes?

By this point I’ve forgotten what Parallels Workstation is. I think it’s a dialog generating machine.

What can we learn from Parallels’ horrific design?

• Their developers haven’t read The Elements of Style. Rule 17: Omit needless words.
• The Parallels developers don’t do clean installs of their programs.
• They haven’t sat a user down and had them use Parallels from start to finish (from setup to the first virtual machine).

“Ok, but what can I apply to my own work?”

Parallels’ first-run faults seem easy to apply for web & desktop developers alike. But if you clear the front door – let users actually use your program – will you convert more trial users to paying users? What if you clutter the first run – do users care?

Yes, they do.

In wyBuild’s early betas (back when it was still called InstantUpdate Designer) I ran a split test comparing how long a person used wyBuild. Group A had a version of wyBuild with crap similar to Parallels Workstation; the user had to dismiss a couple of “useful” dialogs before they could use wyBuild. Group B had an experience similar to what we use today; a dead-simple first screen:

I foolishly thought the first-run dialog boxes would give users a better understanding of our product.

In retrospect the results aren’t surprising. Group B, the group that wasn’t interrupted, used wyBuild more than twice as long as Group A. More than that, the people in Group B were around 2 times as likely to save their project and build their first update.

So, the group that was bothered by a bunch of pointless dialogs often quit before they’d created their first update. (And this was back when wyBuild was free. The only measure of success was if the user actually used the product).

Because this data was collected remotely (it was opt-in, of course; I’m not a sleaze), we couldn’t ask the people in Group A why they gave up. If I were to guess I’d say their thoughts ranged from “It’s too confusing” to “I’ll do it later, when I have some free time” (i.e. never).

Anticlimactic lesson: Don’t waste your users’ time.

You almost certainly have a competitor that is faster, cheaper, better, or all of the above. So, the next time you add just one more dialog or just one more field to your order webpage, think about how many potential customers you’re losing.

Scratch that. Test to see how many users you’re losing.