The fundamental problem with UI

11 May 2006

When we write a document that's going to be printed we have a plethora of design choices, the most important and fundamental one being the fonts we use. We can choose to be boring and use Arial or Helvetica (here's how to tell the difference) and Times New Roman, or we can select and licence a font (or several) that better expresses who we are and that better supports our corporate image.

The same goes with books. I was very disappointed in the fonts used to print my book, since I thought they looked staid and boring. I wanted to use a more modern font than the ones Wordware eventually used (and I'm not sure what they did use in the end).

You could say that a hobby of mine is typography. I love looking at letterforms and why they are the way they are. What decisions did the designer have to solve, what constraints was he under, and how did he solve them? I'm always interested in how businesses present themselves through the text they provide and want us to read. Have they gone to the trouble of designing their corporate look-and-feel down to the fonts they use? Are they consistent in using them? Did they make a good choice? And so on.

Unfortunately one of the biggest problems about typography, especially with regard to a corporate's look-and-feel, are the fonts used in the software that company writes. Seldom does the UI follow the company's standards, and it's not the programmers' fault. The problems are many fold:

  • you can't assume your customer has your corporate fonts; in fact, all you can assume for Windows is that the customer has the standard fonts that come with the OS, although even then different OSes have different standard fonts
  • although you could ship your corporate fonts with your app and plonk them in the Windows\Fonts folder, any program could then use them gratis with the probable wholesale violation of your font license
  • it's nigh-on impossible (a.k.a. there is no OS support for this anywhere) to embed fonts in an application so that only the application can use those fonts. (However, I wonder how Adobe does it with embedded fonts in PDFs? Does Acrobat Reader have a font rendering engine?)

Sometimes it can be worse than this. I well remember at a previous job showing in a lunchtime presentation one screen from the company's product that used two very similar fonts (if I remember correctly, MS Sans Serif and Arial). And even worse, at two different font sizes (something like 10 and 11). At my previous company, whose main product's UI was a browser app, I was always complaining that on every page there were two very similar fonts (Verdana and whatever the default font for the PC was set to). To me it just looked jarring and unprofessional, but nothing was ever done about it.

One day, I hope, it will become easier to design UIs to use specific fonts and then to ship those fonts as part of the application in such a way that only that application can use them. And then one day a little time after that you'll be able to do the same with web applications, but I'm not holding my breath in the interval.

(Prompted by this article on flow|state.)

Free DevExpress Products – Get Your Copy Today

The following free DevExpress product offers remain available. Should you have any questions about the free offers below, please submit a ticket via the DevExpress Support Center at your convenience. We’ll be happy to follow-up.
Alan (DevExpress)
Alan (DevExpress)

Hmmm, I've never taken into my head that I should pay so much attention to fonts in the UI. Mostly I prefer to simply set all fonts to the same type, but never think that some fonts are better and others worse, and the unique font may represent my own style. Thank you for this idea. :-)

By the way, what font do you like best of all?

PS. If you're interested in how Acrobat Reader renders its embedded fonts, you can ask the XtraReports guys, they know a lot about exporting to PDF ;-)

12 May 2006
Dan F
I hear you. Web is particularly hard to do cross browser without resorting to hackish feeling sifr techniques. However, if you're writing winforms apps, it's relatively easy to embed true type fonts in your application - Not "click and forget" easy, but certainly doable.
14 May 2006
You actually can have fonts private to your application! Have a look at AddFontResourceEx (Win32) or PrivateFontCollection (.NET)
18 May 2006
Hi all!

The real "fundamental problem with UI" is that all of your editor controls raise *Change event only after loosing focus!

29 May 2006
I completely agree with you, I always like to present documents that look nice (Professional) I even push for the use of different/better looking fonts among my piers, but is very hard...we developers tend to think that if something does what it has to do, it's enough...presentation is a big part of the ecuation IMO... I personally like "Light" fonts and definately Sans Serif with some exceptions... I'm a big fan of Gill Sans and Futura.

29 May 2006
"it's nigh-on impossible (a.k.a. there is no OS support for this anywhere) to embed fonts in an application so that only the application can use those fonts. (However, I wonder how Adobe does it with embedded fonts in PDFs? Does Acrobat Reader have a font rendering engine?)"

Actually, Windows allows applications to install fonts temporarily, and to do so without notifying every other app that is running at the time.

(TTF's specfically:) When Acrobat Reader gets a PDF with an embedded font, it extracts it to a file with a randomized name in a system temp folder from which it will load it as an application-only font.  But before it writes it, A/R changes the font's internal naming and it reverses the charmap table, so that, for example, a normal 'A' may show up with the Unicode value for 'x'.  When the PDF's text using that font is rendered to the screen or a printer, A/R internally converts the character values in the PDF into the remapped character identifiers in the extracted TTF.

The next time the embedded font is extracted and loaded the external and internal made-up names and the character mapping will be different.
6 December 2006

Please login or register to post comments.