Development

Separating legibility fact from myth

An interesting aspect of the annual ATypI conference is that it provides a forum for researchers working on text legibility and related problems to present their findings. The 2015 conference in São Paulo, Brazil was no exception; various sessions addressed font display in automotive navigation systems, the effectiveness of text markup, and how factors like spatial frequency impact users' ability to read text. There was also an entire session dedicated to debunking oft-repeated myths about how fonts can affect readability for users with dyslexia.

Fonts and combating dyslexia

Bruno Maag and Alessia Nicotra tackled the persistent myth that someone can create a font that counteracts the symptoms of dyslexia. Attempts to do so are a surprisingly common occurrence, they noted, with Chrisian Boer's Dyslexie, Robert Hillier's Sylexiad, and Abelardo Gonzalez's OpenDyslexic being just a few of the recent examples. But these projects invariably misunderstand the symptoms of dyslexia, attributing them (and, usually, limiting them) to visual confusion—such as having trouble distinguishing between "b" and "d" due to their similar-but-mirrored shapes. In fact, the research is clear that dyslexia impacts language processing in a different part of the brain altogether from where images are processed.

Nicotra listed the clinically recognized symptoms of dyslexia, only a few of which are observable in a visual context. Rather than manifesting in the temporal lobe, where visual input is processed (and where letters are recognized, followed by syllables and words), dyslexia symptoms affect the language-processing center in the brain's phonological area. Consequently, the real symptoms of the condition also are observed in hearing (such as the inability to recognize alliteration or rhyme) and the semantic processing of language. Some say dyslexia is over-diagnosed, particularly by non-physicians, but it is fairly well defined in the medical community. Nevertheless, the myth persists that by using fonts with altered letterforms (as in the Dyslexie and OpenDyslexic fonts, in particular), patients can overcome the condition and improve their reading proficiency.

The research does not bear this out, however, Maag said. He then discussed several recent papers and doctoral dissertations that reported finding improved reading comprehension or comfort when certain changes were made to the way text on screen or paper is displayed. But the findings tend to underscore well-known principles of good, legible typography—such as increasing contrast, increasing stroke weight, and using a sufficiently large x-height. Thus, the changes that result in better legibility for readers with dyslexia also improve legibility for readers without dyslexia. He also pointed to a paper by Thomas Phinney that found there was no statistically significant difference found in readability tests of Dyslexie versus Arial. Finally, Maag noted that tests show that increasing the spacing between letters and between lines of text increase reading speed—again, both for readers with dyslexia and those without.

The takeaway, he said, is that there is not a magic bullet, especially not at the level of font design. Rather, improving the viewing conditions for the reader benefits legibility, comprehension, speed, and comfort—regardless of medical issues like dyslexia. The good news, he reminded the audience, is that reading is a learned skill for everyone, and everyone requires practice. While scientific research shows that font choices do not have a greater impact on people with dyslexia, research also shows that, with a degree of additional practice, the majority of children with dyslexia are able to achieve reading proficiency equal to their classmates.

Reading, legibility, and comfort

While Maag and Nicotra took on a long-held misconception, several other speakers presented work that looked at new ways of assessing or improving text readability. Kevin Larson from Microsoft's Advanced Reading Technologies (ART) group presented his work on how spatial frequency relates to text legibility. The central notion is that, as with all visual stimuli, the human eye's ability to distinguish important features in a line of text hinges on the size of those features when they strike the retina—which, in SI units, is measured in cycles per degree (cpd). A high spatial frequency corresponds to more details crammed into the same space, therefore it means a higher cpd.

Measuring text in cpd makes intuitive sense, since it normalizes measurements to the eye's frame of reference, but it is rarely what is done in practice. In research, reading tests often note the font size used, which does not indicate the physical size of strokes or of important features like the crossbar on "e" (which is the feature that distinguishes it from "c"), nor take into account the reader's distance from the display. Larson led ART studies that tested how accurately participants could read text as a function of spatial frequency. The results included some real-world numbers, like the fact that test subjects could read text with a spatial frequency of up to 50 cpd.

That 50 cpd number is averaged across all of the subjects and is the upper bound that readers may be able to see; the actual legibility threshold for any given reader varies continuously, since it is dependent on a number of other factors. The team found that high-contrast text was necessary to reach that 50 cpd upper bound, and that contrast proved to be more important than screen resolution—which is often cited as improving legibility. But the team also noted that real-world conditions can make achieving the required contrast impossible. Screen backlights, ambient lighting, and age-related loss of visual acuity can limit how much contrast is possible. Larson concluded that, ideally, text interfaces should be adjusted continuously to provide optimal contrast and optimal spatial frequency for the user.

Continuously adjusting text displays may sound far-fetched but, interestingly enough, the underlying idea was backed up by the findings of another speaker. Keitaro Sakamoto from Morisawa Type reported on that company's tests with changing the font weight of display text in automotive navigation systems, based on the ambient lighting conditions. The issue, he said, is that road tunnels in Japan are substantially brighter than in many other regions, and the brightness change causes problems for drivers at night.

The researchers tested a system where font weight was increased from light to medium to bold depending on whether the car was in daylight, a tunnel, or outside at night. They measured both the reaction time of the driver and the correctness of the driver's response (e.g., "change to the left lane now"). As expected, the responses were improved by adjusting the font weight, which would seem to align with the ART team's research. Interestingly, though, the team found significant differences between the effects when used on kanji and on kana text. It is not clear if the distinction has to do with the relative densities of the two scripts, or with the different semantic ways they are used in normal Japanese writing.

Larson also presented a shorter session that outlined some recent ART work exploring text mark-up. The research team explored comprehension, both with new readers (e.g., children) and with experienced readers when confronted with hard-to-parse text. It found three mark-up techniques that seem to improve reading comprehension. First, marking the syllable boundaries in a word (such as with a small or light-colored dot or tick mark) significantly improves readers' ability to recognize and decipher unfamiliar words.

Second, it found two techniques that helped readers parse garden-path sentences—semantically tricky constructions like "She knew the answer was not correct." On a first-time read-through, such sentences are often parsed incorrectly—for instance, "She knew the answer" is likely to be the reader's analysis of the first part of the sentence, only to be reversed when the second part is read. Interestingly enough, rendering all verbs in a different color and encasing subordinate clauses [in brackets] both improved comprehension without impacting reading speed. While these techniques might not appeal to publishers or software makers for general display usage, Larson felt that they could prove useful as accessibility aids.

Scientific research is, naturally, a continuous process. It is interesting to note, for example, that legibility researcher Ann Bessemans presented her own findings from a reading-comfort study that found a negative correlation between comfort and regular visual rhythms in a line of text. That is, a strong, regular pattern of light and dark—as one usually sees between the vertical strokes and the white spaces in text—seems to increase reader discomfort and fatigue. That would seem to conflict with established conventional wisdom, which teaches that irregular rhythm is bad for reader comfort. But, Bessemans noted, the historical research on reading comfort is frustratingly vague in its definitions, and measuring comfort is difficult to do in an artificial, laboratory-like setting. Her primary takeaway is that more rigorous research is called for, as is a more formal approach to defining and assessing reader comfort.

In the software industry, legibility issues often fall to online publishers and UI designers to deal with. But it is interesting to note how deeply some of the findings could affect software development. Better mark-up options for accessibility might not be difficult to implement, but continuously adjusting the text contrast in response to lighting conditions is another matter altogether. Yet there are few software interfaces that can afford to dispense with all concerns about text readability.

Comments (2 posted)

Quote of the week

— Bryan O'Sullivan has a little more trouble getting to the fire escape than did Igal Tabachnik.

Comments (5 posted)

GNU Guix 0.9.0 released

Version 0.9 of the Guix package-management system for GNU software has been released. Changes include the ability to graph package dependencies, support for Texinfo markup in package metadata, the ability to install packages from local files, and improvements to Guix's Emacs interface.

Full Story (comments: none)

MicroPython 1.5 available

Version 1.5 of MicroPython, the Python implementation for microcontrollers, is now available. Updates include advanced read-eval-print loop (REPL) support with auto-indent and auto-completion, support for SSL client connections, and a new machine module to access microcontroller hardware features.

Full Story (comments: 4)

Enlightenment Foundation Libraries 1.16 released

Version 1.16 of the EFL libraries and related programs have been released. The primary focus of this release was improving Wayland support, but there are other changes, too, such as improved finger-scrolling support and OpenGL support in the Evas canvas element.

Full Story (comments: none)

Xorg-server 1.18.0 available

Version 1.18 of xorg-server has been released. New features include support for XRandR 1.5 and improvements to support for NVIDIA's Optimus hardware.

Full Story (comments: none)

TensorFlow released

Google has released its TensorFlow machine-learning library under the Apache 2.0 license. "TensorFlow is an open source software library for numerical computation using data flow graphs. Nodes in the graph represent mathematical operations, while the graph edges represent the multidimensional data arrays (tensors) communicated between them." For those who are unfamiliar with this type of programming, this basic MNIST tutorial gives a feel for how it works with TensorFlow.

Comments (5 posted)

Development newsletters from the past week

• What's cooking in git.git (November 5)
• What's cooking in git.git (November 6)
• LLVM Weekly (November 9)
• OCaml Weekly News (November 10)
• Perl Weekly (November 9)
• PostgreSQL Weekly News (November 8)
• Python Weekly (November 5)
• Ruby Weekly (November 5)
• This Week in Rust (November 9)
• Tahoe-LAFS Weekly News (November 11)
• Wikimedia Tech News (November 9)

Comments (none posted)

Native file choosers in GTK+

At his blog, Alexander Larsson announces that a new feature has landed in GTK+3 that enables applications to use the native file-selection widget from the underlying platform. The work arose as Larsson sought to add a file-selection portal for the xdg-app sandboxing system. "What we need is a Gtk+ API for the file chooser that hides the details of how the dialog works. At this point I realized that this is something that has been requested a lot in a different context. Such an API would allow us to plug in platform-native file chooser dialogs." Support for OS X is said to be under exploration.

Comments (none posted)

Wingo: embracing Conway's Law

At his blog, Andy Wingo writes about how Melvin Conway's observation that "the structure of things that people build reflects the social structure of the people that build them". Notes Wingo: "This division goes down to the inner life of programs, too; inside it's all just code, but when a program starts to interface with the outside world we start to see contracts, guarantees, types, documentation, fixed programming or binary interfaces, and indeed faults as well: how many bug reports end up in an accusation that team A was not using team B's API properly?" The subsequent discussion explores how forks, not-invented-here syndrome, and bundling may help development projects reshape other people's code to fit their own needs. "You can't be responsible for everything. One way out of the mess is just to give up, cross your fingers, and hope for the best. Sure. Fine. But know that there is no magical first-person-plural; Conway's law will apply to you and the things you build. Know what you're actually getting when you depend on other peoples' work, and know what you are paying for it. One way or another, pay for it you must."

Comments (none posted)