Text Visualization and Code Editors

Long before I started investigating typographic attributes for data visualization, Aaron Marcus and Ron Baecker were doing the same thing for software code. Back in the mid 1980s there weren’t integrated development environments, no integrated debugging tools and so on. My first coding environment in the mid 80s consisted of green text on a black background: 24 x 80 characters at maybe 72 dpi (*).


Old school: low resolution green-screen display.

If you wanted to better understand what was happening in a few blocks of code, there was no windowing system: you had to rely on flipping back and forth between code sections and carrying a lot of detail in short term memory – which is difficult.

So, instead, we printed it out. High speed line printers printed out large amounts of text on fan fold paper. You can cross reference between a few hundred of lines of code on paper much more easily than 24 lines on screen. And, on paper, you can use a highlighter to indicate variable declarations, underline conditionals, add squiggles or boxes around code and so on.

Baecker and Marcus realized that the then new Apple Laserwriter offered great resolution (300dpi) and excellent typographic capabilities. It could automate the tasks of differentiating types of statements using typographic attributes, instead of manually marking up the print out after the fact. They itemized the typographic attributes available, wrote routines to format and print code, did numerous studies and created recommendations through the 1980’s (e.g. CHI paper) – all before the academic research field of data visualization got started. Here’s some code from their book Human Factors and Typography for More Readable Programs formatted following their recommendations.

Baecker Marcus Code Formatting

1980’s laser printer-based code formatting using font weight, size, italics, shading, even smallcaps.

It’s a great example of visualization using typography. Italics, bold, background shading, slightly larger size for the function name, even smallcaps on the constant.

Over time, the display resolutions got better, code writing software got better, typography on desktops got better. Leading code editors nowadays do syntax highlighting reminiscent of Baecker and Marcus’s work – notice the many typographic attributes at work:


Snapshot of WebStorm – syntax highlighting varies underline, italics, bold, colors aid understanding. 

While the rich typographic formatting of in-line contextual highlights is the norm in software editors; typographic formatting to convey data is not normal in data visualization. Two years ago I went through all the text visualizations then listed at the Text Visualization Browser and cataloged which visual attributes were used to add data to text. Out of 249 visualizations then listed:

  • 40 didn’t have any text in the main visualization at all – they were visualizations such as point clouds, graphs, etc.
  • 103 used plain text without indicating any additional information, not even color coding – essentially plain labels.
  • Only 106 out of 249 (40%) used any kind of additional formatting(!) And what kinds of formatting did they use? Almost entirely size and color were used (often both). Only very rarely were typographic attributes – such as bold, italics, caps or underlines  – used, as indicated in this table:


Notice, for example, that varying font intensity is more common (occurred 9 times) than varying font weight (occurred 6 times). This is a bad design choice, because fonts come in a wide variety of weights which are more legible than varying font intensity:


Changing brightness reduces text legibility…


while, changing weight maintains text legibility.

What makes this particularly interesting is that the researchers designing and coding these visualizations were spending long hours staring at code editors full of typographic cues like the WebStorm snapshot — but then didn’t use any typographic cues in their visualizations! Possibly they had become accustomed to the typographic manipulation and no longer consciously aware of it, or, perhaps because it was situated in a different (non-visualization) context, the mental connection to visualization was never made (because visualization research rarely talks about typography).

This is just one example of a kind of “design blindness” (like change blindness, but without the change – i.e. missing something that is clearly visible). What other cues are UI designers seeing but completely missing?

About richardbrath

Richard is a long time visualization designer and researcher. Professionally, I am one of the partners of Uncharted Software Inc. I have recently completed a PhD in data visualization at LSBU. The opinions on this blog are related to my personal interests in data visualization, particularly around research interests related to my PhD work- this blog is about exploratory aspects of data visualization not proven principles.
This entry was posted in Data Visualization, Font Visualization, Legibility, Text Visualization. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s