#btconf Berlin, Germany 07 - 09 Nov 2016

Frank Rausch

Frank Rausch, a user interface designer and app developer, specialises in digital typography. He is co-founder and managing partner at Raureif, an award-winning interaction design consultancy based in Berlin.

In his work, Frank Rausch utilises technology and algorithms to shape digital reading experiences. He teaches user interface design and typography at design schools in Potsdam, Copenhagen, and St. Gallen.

Want to watch this video on Vimeo directly? This way, please.

Typography is Code

Text is everywhere. We read more than ever, probably consuming more written content from glass than from paper. Designing a quality reading experience for dynamic text requires a mindset and workflow different from traditional print typography.

All digital text is processed by algorithms, so every aspect of how words and sentences are displayed can be shaped with code. This makes programming an essential and powerful skill for designers and typographers. It’s time to explore and embrace methods that will make digital reading interfaces better than printed paper.

In his talk, Frank will show details from his work and speculate about the typographic workflows of the future.


Frank Rausch: How are you doing? Yeah, I know. Okay.

Audience: [Laughter]

Frank Rausch: I make apps for a living. My job is making apps. Whenever I meet new people and they ask me, “What do you do?” I tell them I make apps. It makes it easy for my parents to explain what their son does: He makes apps. Right?

Then the people think I make these little squares here, and I really like the simplicity in this. It’s really more convenient than explaining what I actually do because I’m a user interface typographer. Actually, I’m a user interface typographer/developer, but I’ll get to that in a minute.

User interface typographer: what is that? Does anyone know? You can’t know it because I made it up for myself.

What I do for a living is I specialize in putting words on buttons. Now a lot of you probably also do that. A lot of people put words on buttons. The difference that I take this process very seriously.

Audience: [Laughter]

Frank Rausch: Typography, as you may know, means arranging text, giving text an appropriate shape for whatever you’re trying to achieve with that. That’s the shortest definition I could come up with.

Why is typography relevant for user interfaces? Typography is relevant because text is everywhere. In user interfaces, text is just all over the place. It’s not just another ingredient. It actually is the interface. Text is what makes all this stuff understandable. If I took the words away, there wouldn’t be much of a user interface left, right?

Look at this iPhone setting screen here. It’s all text. It doesn’t make sense any more, right?

You thought Word 95 was hard to use. When I remove the text, it’s even more like a picture puzzle.

Text is essential for almost all the things we do with our digital devices. We read more than ever and, you know, just watch people on the subway or watch people in this perfect stock image. What do they do? They probably read something. They read Twitter. They read WhatsApp. They read Facebook, email, the news, blogs.

If they don’t read, they write. But when you write, you also read. That’s why the quality of text deserves attention, the legibility and the voice of the typefaces you use deserves attention, and how you lay out all the text in your user interfaces deserves attention.

Typography is user interface design for text. Let me just walk you through an example. Let’s design a reading interface here. It only takes a few minutes and a few years of practice, but let’s get started. We jump right into Xcode because it’s not that hard, right?

Open Xcode, put in a UI text view, make it full screen, and that’s how easy it is. Then you’re done. Not really, so now let’s tweak this a little bit. Maybe we can improve it by using a different typeface. Several typefaces are comfortable for reading.

Now the font choice always comes first because all the other text settings depend on it. Let’s make that text a little bigger. That iOS default font size is really small, so let’s make that bigger, you know, line length. Text columns shouldn’t be wider than 60 characters. That’s about what you want at most.

Anything else? Maybe scoot it down a bit. I don’t know. Make the line height bigger first and scoot it down a bit. Anything else? You can also adjust the tracking, but that’s an advanced thing. You shouldn’t be doing this when you don’t know what you’re doing.

Typography is not picking typefaces. Typography is more than that, and picking a typeface is like picking the color for a painting. Just because you pick a color doesn’t give you painting skills. What matters is what you do with the typeface you’ve picked.

With these four parameters, you can do all of what we’ve just seen and make text perfectly legible. That’s just typografisches handwerk. That’s just typographic craftsmanship. It’s not rocket science. Typographers have been doing this stuff for centuries. User interfaces then, on the other hand, is just a few decades old and typography has seen centuries of evolution, iteration, experience, and knowledge about how to design the best reading experiences.

There’s a long tradition and so much knowledge on how to make text easy to process for human eyes and brains. Why not apply this to user interfaces. And not just talking about the readability of long form text. Especially in user interfaces, we often see small bits of data. Also in the analog world, like on my bank account statement there.

Let’s talk about numbers for a minute. There are so many apps and services around numbers, but most of the apps I’ve seen, the numbers are hard to read, and that’s kind of insane because, when you’re making a financial app for example, you’re actually making a number viewing app.

This is what my German bank’s Web banking looks like. It’s not really – you know, there’s no love in this design. There’s no design in this design, actually. Only German bookkeepers know why there’s an S on the end instead of minus to say that it’s a negative number. Even worse, just look at this three pixel misalignment on the left. Anyway–

A few years ago I worked on a banking application for the Mac called MoneyMoney. It’s only for the German market, but in Germany if you want to sell a product then you have to give it an English name. That’s another small piece of advice here.

This is the original design from 2011. The UI fashion has moved on, obviously, and textures and shadows are not en vogue any more. But the good typography is timeless. Let me just show you how much effort we put into this formatting these numbers.

This is what it looks like when a number gets pulled from the database, more or less. This is what the programmer sees. You could, of course, display it like this. But even the worst programmer at the German bank will run an algorithm to do a little formatting. Something like this, yeah. It’s not really great. It’s localized for German here with the comma for the decimal separator. But, overall, pretty uninspired, right?

That’s the first thing I want to fix here is just removing the S and adding a minus. But now the typographers in the audience, are there any typographers here? Shout if you are a typographer.

Audience member: Hey!

Frank Rausch: What’s wrong with this? It’s not a minus.

Audience member: [Indiscernible]

Frank Rausch: It’s a hyphen. Thank you. This is a minus. This is a typographer’s minus. It’s like the en dash. It’s a little longer than a hyphen. Yeah, if you’re programming, of course, then this is not the right minus. But if you do typography or anything else but programming, this is the correct one. It even has a Unicode, by the way.

Let’s add a thousand separator here. By the way, this the German way. This is the American way. Of course, if you display a number in any app, it should be localized to the user’s preference.

Switching back to the German version here, maybe let’s make this a little smaller. I know that it’s euros. I don’t have to see it all the time. Maybe use a typeface that’s easy to read with more open shapes. Those serifs are a little too fragile here, so let’s add the sans serif version of Novel for this. Make the currency a little bolder. Maybe make the important part of the number a little bolder. Make the unimportant part a little less in your face. Yeah, shift the minus to the optical middle, of course.

Now you’re saying that’s a lot of formatting, and I’m not done yet. Maybe add a little tracking. There we go.

I think it was worth the effort, especially if you compare it to the original version. Easy to read, right? Yeah.

This is how we color coded the numbers in our app: negative red, positive black. This is what I see in many financial apps. It looks like a good idea to add the plus to say it is a positive number. There’s a plus. But it’s not really a good idea because leaving out the plus actually emphasizes the difference between these two types of numbers. Also, for red/green color blindness, it’s a really bad idea to use red and green.

Again, nothing spectacular. It’s typografisches handwerk.

Why is there so much shitty typography in our digital products? I mostly blame old school typographers. They ignored digital for too long. They probably thought books and paper were never going to go away.

And they thought you could only make really ugly shit on the Internet. Look at this. This is Microsoft, Microsoft’s 1994 website, the original first version. It looks like graphic design hadn’t even been invented. But of course then typographers looked at this, and they said, “No, of course we don’t want to have anything to do with this.”

They thought, yeah, if I sit down in front of one of these, of course I can’t read on this. I can’t read Harry Potter on this. Then of course the book was a way better reading interface back then. But now if we talk about readability, legibility, and screen reading on screen, we should actually be comparing these two.

I think the biggest problem is that typographers hate giving up control. I know this myself. Let’s look at a traditional typography workflow. The typographer gets a piece of content, and a text. Then this is the typographer. Takes this content and formats it, puts it in a layout. That means the outcome, the size, the material, the printed thing in the end is the design.

Now in a digital workflow, a typographer has to work differently. The typographer creates some kind of engine, like HTML, CSS, algorithms, you know, some kind of digital thing that takes content, all kinds of content, maybe content that wasn’t even written when the engine was written, and takes this content and puts it on all kinds of different devices. That’s a completely different workflow. That means the direct control is no longer possible, so typographers had to give up control over the instance, and they would gain control over the whole system, which is way cooler if you ask me.

I don’t just mean HTML or CSS when I talk about engines that do something with text because actually HTML and CSS is not an engine, as you probably know. I mean algorithms that analyze and reformat text to a content.

Do you guys read Wikipedia? I read Wikipedia every day. It’s great, except for the – how much is that? Five meters of line length here. It’s really hard to read. Really hard to read. Exhausting for the eye. You end up here, and then you have to go all the way back over there. It’s very tiring.

I mostly read Wikipedia on my iPhone and iPad anyway. But I didn’t really like the website, Wikipedia’s website on my phone. I didn’t really like the official app. And that means I had to build the Wikipedia app of my dreams. I call the app VIKI. Exactly how you pronounce Vikipedia auf Deutsch. We say Vikipedia in German, you know, VIKI.

My goal was to create a Wikipedia reader app that has the best possible reading experience on all these devices. Yes, also on this one. A showcase of good typography with no excuses for bad typography. I’m not really there yet, but 98%, I think.

This is what it looks like. You see what other people are reading when you open the app. You can search for articles, of course. The table of contents. But my favorite feature is actually that I can read the content.

Good typography starts with a good type face, especially when you make a long form reading app, of course. VIKI ships with 12 quality fonts, four styles of Diogenes, four styles of Komet, four styles of CamingoCode because there are some articles with source code in them and I don’t really want to see it in Korea.

Now you’re saying, well, that’s great. You picked some fonts.

Audience: [Applause]

Frank Rausch: Yeah, I picked fonts, but that’s not typography, as I told you before. Let’s look at how VIKI layouts search results. Instead of doing something like this and repeating the title in the excerpt, my code checks if the article excerpt contains the title. If it does, then it’s merged. This avoids unnecessary redundancy and also saves a lot of space, which is crucial on small devices.

This is a nice, subtle way to increase information density, especially on the small devices. This is a comparison with the official Wikipedia app. They show a lot more results, but in my experience when you search for something on Wikipedia it’s actually one of the three first things is the right one you were looking for. Also, my design has higher information resolution and a more comfortable reading size.

Another thing about Wikipedia is that it allows everyone to use all the styles in the world. You can use HTML, you know, almost in an unlimited way. Of course people love it. They add inline styles and background colors and rounded corners, and most of this I didn’t really want in my app.

Let me show you an example. This is a disambiguation box. You probably know this, only not the German version. Yes, there is a German version. It can’t be that hard to restyle. Here’s why it’s a German version. It’s a table. It’s localized in every language. It has an ID. It has cell padding settings. It has some uncemented classes, and it has an inline style. I don’t know why. How do I remove all these styles now without breaking anything?

This is the one that breaks everything. This is what we tried in the previous project. It’s a regular expression that goes through the HTML and just kills all the inline styles, all the comments, everything that’s not necessary. But it’s a little too harsh, and also you should never regex HTML or XML - never.

We need a more selective method, so what’s more selective? CSS. I can probably hear some cringes here. People running out of the audience because of this. Yeah, you should never do this and you should never do that. It’s highly selective, exactly what I wanted to achieve, but then I benchmarked this and I found out that it takes, like, on iOS on the Web view it takes like 300%, 400% more rendering time because it embedded this layer all the time. I’m sure Harry Roberts can tell you about all this stuff later on why you should never undo CSS with more CSS.

What’s the solution here? I use a simplified version of this. It’s JavaScript in the Web view. It loops through all the elements up there. Then it removes all the styles from the inline styled elements. But first it saves all the stuff I want to keep, like maybe I want to keep the background color or position in some cases. Then I reapply the inline styles that I had saved temporarily. Yeah, this is still not very elegant, but it works really well, and it’s incredibly fast, way faster than doing this with CSS.

I’m obsessed with microtypography. Do you know what that is? Using the correct characters in the right way and spacing them correctly. The problem is that the modern laptop we use is basically a typewriter with a very powerful calculator. That’s a tragedy for typography because nobody bothers how to type or knows how to type correct punctuation characters any more because they’re not on the keyboard. The typewriter didn’t have all the typographic characters, so they’re all missing from our keyboards we use nowadays.

They’re really hard to find on the Mac. You can use some key combinations. This is wrong. I’m pretty sure most of you do this. These are typewriter quotes. They only exist because 150 years ago there was not enough space on the typewriter keyboards to accommodate the opening and closing shapes that are correct for English. For German, you use these or these. So every language has different, slightly different rules. But I don’t know a single language that uses these except for programming languages.

If you take away one thing today from this talk then don’t use these quotes. Use the correct ones. It’s not that hard to find them on the Mac keyboard. I will be monitoring the Twitter feed later on.

This is a dumb apostrophe. That’s what it’s called. It’s the same thing. This is the correct one. I don’t know a single language where this is the correct apostrophe.

Now look at the official Wikipedia app and look at VIKI. In the Wikipedia app or in Wikipedia, in the English Wikipedia, they use these quotes for everything everywhere, the dumb typewriter quotes and apostrophes.

Now in my VIKI app it looks correct. How did I do this? Did I go into each single article and change them manually? Of course not. It’s fixed on the fly. When you load the article in VIKI, it runs a piece of software on it and then fixes all the microtypographic problems.

I use SmartyPants. I don’t know if you know that. I really like the name of that library. It’s part of Markdown, so almost all of the Markdown libraries have it. I use something called Hoedown, C version, and this is all the code that was necessary to implement it in VIKI. I can just pass in an HTML string and I get a microtypographically correct HTML string back.

There’s really no excuse to have this on your website. I mean I don’t read that website anyway, but on this single headline they have two wrong apostrophes, one hyphen instead of an en dash, and four wrong single quotation marks while double quotes would work better. Just look at this. That’s a usability problem, right?

Fixing other people’s mistakes, of course, is fun, but there are things that are more fun like designing with code. For example, this is what the article title header in VIKI articles looks like, or this is what it would look like if I didn’t fix it. Of course, the typographer in the audience, the one single typographer over there, you don’t like that, right? I don’t either.

In all the articles I parse for colons in titles and then add a line break after them. And I also changed the formatting to italic after the colon. This is all done by an algorithm.

Then I do this. I don’t know if you can see this. I’m going to zoom in now. That’s why it’s called microtypography. I had a hair space because that’s just what you do if you can. The beautiful thing is once you’ve written a piece of typographic code, you can just automatically apply it to all the other articles in all kinds of languages.

Now, what did I do with this title? It’s just a little bit too long to look right here. The good news is that lots of Wikipedia articles follow the same scheme, so a lot of articles start with “List of” and a lot have brackets in the end, so I can use a very simple – this is a simplified version of the one I use that only works for English and Spanish. It’s a regex that splits up this title.

Typographers should love regex. It’s just the perfect tool to reformat text because this can break down this title into these three tokens, and I can do whatever I want with them and just apply the formatting that I want. Like this. Once again, if I build this once, I can apply it to all articles on Wikipedia and just use the power of algorithms to make it look good.

I’m just showing off another feature here of the app where you can see what Wikipedia articles are around your location. But what I want to point out here is that, of course, I don’t use a regular space between the number and the unit, but I use a thin space, which is the correct one, a non-breaking thin space. In typography we have lots of spaces because one space is not enough. We have even more than these. This is just a small collection of the most common ones. It’s really fass ohne boden. How do you say in English? A bottomless pit, I think. When you want to be serious about typography.

One of the biggest strengths of digital typography is that the reading interface can adapt to the user and to the user’s context. How do we personalize the reading experience? Do we add some settings? Yeah, we could add some settings, but then people would configure something like this. Why is this even possible on a Kindle to configure something like this? Nobody can or wants to read this.

The user is not a typographer, so why burden the user with all these typographic choices? I can choose between eight font sizes on my Kindle, six typefaces. Most of them shouldn’t even be on there because they’re hard to read. It’s three different line spacings, three different margin settings, and all of that independently. Why not offer just three sizes: a normal, large, and extra large, and maybe an accessibility view that also optimizes the typeface and all the other parameters to be easier to read for people with impaired vision?

I have a pretty strong opinion on settings. One of my main goals is not to have settings at all. I gave into all the user feedback for the app and I added some settings. You can override the system font size, which I used before. Previously it only showed the font size you set in your iPhone settings. But now I have this little menu where you can override the system font size. But still it’s not possible to misconfigure it and get bad readability.

Yes, a few settings are fine, I think, but maybe there’s a smarter way. Instead of asking the user to adjust text parameters, why don’t we just use the sensors and the data instead of user settings?

A smart phone has all kinds of sensors. For example: camera, proximity sensor, ambient light sensor, accelerometer, gyroscope, magnetometer, GPS, microphone. All of this is built into all of the devices we have or most of the devices we have. That’s a lot of life data about the user’s context, right? Also, we have the cloud. A smart person once said–I don’t know who–there is no cloud. It’s just someone else’s computer. But still, maybe it has data about the user that we can use to personalize the reading experience.

These sensors and data could tell the reading app:

  • What’s the current reading distance?
  • Am I currently moving?
  • Am I standing up or lying down?
  • Is the room bright or dark?
  • Is the room quiet or busy?
  • Where am I?
  • Is the environment changing?
  • How is my health?

All this could, you know, be used to tweak the typographic settings in an app - maybe. Some apps already do this. For example, the night mode is pretty popular in iOS apps. And maybe you could use the same sensor, the brightness sensor, to also do the opposite when you’re outside and just have a high contrast mode when the sunlight shines on your display because normally for normal reading conditions you don’t want the brightest contrast indoors. It’s just too harsh. That’s why a little off-white is better than pure white.

The app could also recognize when I’m walking and then maybe increase the text size because, you know, when you’re walking the phone is shaking and needs a little bigger font size. And when you’re running faster, then it could give you even bigger text, maybe bolder text.

It could use the weather data and location data to tell when it’s raining and when there are raindrops on my phone. Then maybe the typeface needs to change because raindrops on the phone, the … are not really great for these conditions.

The app could also know when I’m not wearing my glasses. It could also know from the health data on my device how bad my vision is and adjust the font size accordingly. Or maybe if I’m in a bad mood or if I have low blood pressure, maybe it could just cheer me up a little bit like this.

Audience: [Laughter]

Frank Rausch: Maybe. Maybe not. Maybe.

These are just a few ideas of how we could maybe use data and sensors to replace user settings because settings are always a compromise, and you couldn’t really make up your mind, so you ask the user something. Maybe you can also analyze the context in the future.

A lot of my students ask me, do I really have to learn how to code to do beautiful typography, to do beautiful digital design? I just want to make beautiful things. Let’s say you’ve designed this beautiful button here. And then the developer comes back and says, it’s done. I’m going home.

Audience: [Laughter]

Frank Rausch: It’s blue. It has a shadow like you requested. It was hard work adding the shadow here. It also is Arial, as you spec’d it. So here you go.

Now you could argue with the developer. I know not all developers are like this, but every designer knows what I’m talking about. You could discuss this with a developer, but this is pretty unproductive normally, so you better learn how to code a little bit and just fix it.

When I started in UI design like 15 years ago, designers used to just make mockups and specs and hand them off to the developers. Today, fortunately, prototyping is pretty common. But I think in the future our designers are also going to have to code and be front-end developers to a certain extent because that makes them way more productive and realistic, and also because design and typography happen in all of these steps.

Now don’t expect your users to write you emails about how great your app’s typography is. If there’s no friction, then people don’t notice. I get more comments about this feature in my app than about the perfect legibility, you know, beautiful particle animation. It took me like two hours and tweaking the typography took me eight or nine months. Okay.

But that's good, actually. Text is transparent, and it’s meant to be transparent. It’s a transparent interface, transparent user interface. Most people only notice it when it’s really, really bad or if they have the feeling that something is wrong and they can’t quite put their finger on it. That makes it even more important that you, as designers and developers, care about typography. Thank you.

Audience: [Applause]