GITCAFÉ TYPOGRAPHY

VISUAL SYSTEM & UI DESIGN • SHANGHAI • JUNSEP 2015

GITCAFÉ TYPOGRAPHY

VISUAL SYSTEMS, UI DESIGN

GitCafé is the first Git-Based code hosting and collaboration service in China. In a 3-month internship, I have considerably improved the process and result of visual design.

THE CHALLENGE While GitCafé was the first in China to offer a substituting service for GitHub, its design process and results were problematic. The whole visual design lacked proportional relationships. Moreover, the design guidelines was too vague and brief, causing inconsistency amongst different pages. Most importantly, due to personnel shortage, the company did not have enough awareness of design’s importance.

My challenge then, was to establish, refine and enforce, firstly within the design team, a set of design guidelines robust and flexible enough for my colleagues to follow. I also needed to advocate for design’s position in the organization, through small lunch talks and big lectures. I began with analyzing the existing design with fellow designers. Below shows the original tickets (the equivalent to GitHub’s issues), the most frequently visited page by programmers:


The branding color, green, suffered overuse. This specific hue also hurts to look at on some monitors.

Negative spaces are not considered at all. The page look busy; everything does not have clear hierarchy.

Colored dots correspond to the tickets’ properties, but are too far away in the left sidebar.

SOLUTION GitCafé’s interface is completely text-based and graphics only played a supplementary role in outward-facing pages. Consequently, it is crucial that the typography is carefully attended to. Yet at the start of the project, I discovered to my dismay that the design team had been primarily designing a Chinese-predominant interface with Latin placeholder text. I immediately insisted that we instead use Chinese placeholders, the reason for which I will soon mention.

TYPE

HIRAGINO SANS GB

SOURCE HAN SANS

As none of the seriffed Chinese typefaces pre-shipped with OS X or Windows have decent-enough quality, we had to resort to sans-serif ones. Webfonts were not feasible given their large download sizes, due to a large character set; for a programmer-facing service, low latency was a significant factor. In such harsh constraints, only two typefaces met both aesthetic and technical requirements: Hiragino Sans GB, modified from Dainippon Screen’s famous Hiragino Kaku Gothic; and Source Han Sans, an open source superfamily based on Kozuka Gothic, co-developed by Google and Adobe.

While we could only offer the users to download and install Source Han Sans, Latin webfonts are completely within reach. At the same time, I advocated for a stronger consciousness in mixing Latin and Chinese scripts. A preliminary analysis of the two scripts’ use of Cartesian space gives some insight:


HIRAGINO SANS GB


SOURCE HAN SANS

Blue and red rectangles correspond to the two scripts’ apparent sizes. Both texts are at the same size of 96 px.

The Latin is set in Nobel (this site’s sans-serif), and the Chinese in Source Han Sans.

It should be quickly obvious that when mixing Chinese and Latin text in the browser, the Chinese always looks bigger. This problem gets worse especially when the Latin typeface has a small x-height, and the nominal size has to be increased to compensate for legibility loss. In fact, it stems from the two’s inherent difference in morphology. The Latin alphabet divides the vertical space into three parts: ascent, x-height area, and descent, amonst which only the x-height area is responsible for conjuring the apparent size. The Chinese characters, on the other hand, only has one vertical component, that is, the ICF (Ideographic Character Face), and occupies the Em much fuller. It is for this reason that I advocated against using Latin placeholder to do Chinese design—the text would look too big, crammed and dense.

To alleviate this problem, the Latin counterpart typeface should have a large x-height to mitigate the apparent size difference. Respectively the descenders and ascenders would have to be very short. It would be better if it has small-ish capitals. This is because the small caps, which are often used in desktop typesetting for abbreviations, is an OpenType feature that has inconsistent browser support. On the web normal capitals occur more frequently, and it would disrupt reading less if they are less big and jarring. We arrived at Alright Sans (by Okay Type), a sans-serif that meets every requirement.


ALRIGHT SANS & SOURCE HAN SANS

typo­graphy

While I believe that typography should be expressive of its content, a set of simple rules is better in inducing consistency in the corporate environment when working with multiple sensitivities and tastes. A common grid, I believe, would be most helpful. But what grid? There already existed a column grid. Do I need to reinvent the wheel?

A baseline grid, whose definition is intimately tied with the scale of type sizes, would help clearing up the existing muddled relationship of negative spaces and instill vertical rhythm. To be exact, I would define an array of type sizes according to a modular scale, and then derive a baseline increment that is also mathematically related to them. My passion for fine book typography made me decide that the starting point would be long-form reading, a use case where even the most minute mistake accumulates considerable discomfort. A set of typography capable of handling long-form reading would naturally be robust enough for web type. So I picked a Chinese article online with as many semantic levels as possible, and then set it in InDesign. I would choose a comfortable body size, set leading as the baseline increment, and use modularscale.com to generate workable sets of type sizes.

Because what matters at the end is the apparent size in the human eye, I decided that I would use Points—an absolute unit inherited from print—instead of px or em, which varies according to browser settings and screen densities, as the starting point. I also tried to avoid two kinds of settings: those that frequently produce infinite decimals after pixel conversion, and those that produce point sizes nonexistent in metal types. The former effects unpredictability as some browsers round off decimals; I eschewed the latter mainly to reproduce print aesthetic and land at good font hinting.

My colleagues and I would painstakingly (re-) design the Help pages using the current typographic guide, and found impracticalities to improve on. The first version was most suitable to set a book, but the type sizes increased so quickly that it was almost impossible to create proper contrast in the smaller size range. The second version uses a different scale ratio to solve this problem, but further tests showed that the baseline increment is too tight, making icons and buttons’ alignment difficult. In the third version, then, I loosened the baseline increment and chose a whole new set of sizes using a different ratio … We spent weeks sweating over the details, struggling to predict the visual system’s performance in actual scenarios, iterating and iterating.

When we proceeded to the fourth version, we thought the system was good enough to show the results in front of the engineers, who were also heavy GitCafé users, though we still felt that something was not right. Anyway, the experimental help page (we were toying with the idea of switching from green to blue):

The engineers looked at the result of this typographic system, and complained that everything looked “bigger and looser” and that they couldn’t see as much information above the fold as before. This came as a surprise to me—some people don’t care that deeply about aesthetics; as long as the page does not hurt to look too much, they are willing to bear the ugliness for function. This also prompted me to reflect on where my approach was wrong.

The long-form approach was wrong because text in GitCafé appeared mostly in small chunks.

My colleagues also pointed out to me that the system at this point seemed to be focusing on vertical rhythm “too much.” An idea flew by my head. Yes, it was wrong of me at the very beginning to even use a long-form approach. There isn’t that many long-form readings in GitCafé, until the user is in the Help page. Yet the long-form mindset dictated that I must use a leading no more than 1.5× the type size, or the paragraph would fall apart—but no! Paragraphs occur in this environment much less than small, separate chunks of short text. Moreover, my prior experience with long-form reading services such as Instapaper and Medium prompted me to use a body size as big as 16px. But they are both Latin-predominant! For Chinese to achieve the same apparent size, the original 14px is enough.

JASKNI WONG

The director of design, Jaskni Wong, also proposed that we unify the vertical and horizontal grids by making the baseline increment (2× body size) the same as the smallest column unit. This way, we were no longer dealing with two separate systems, but truly only one—one that uses the smallest unit, the single Chinese character, as the start of reference in defining both horizontal and vertical, positive and negative, text and non-text relationships. Finally I could achieve my objective of enforcing consistency and ensuring quality across the team. By meaningfully breaking down the page into smaller spatial units, this system makes obvious and even forces the designer to consider proportions and dimensions. Without further adue, ladies and gentlemen, I present to you, some results of our fifth, and final, typographic guideline:


JASKNI WONG


Tickets Page; we also added tag description and improved search interactions.


Landing page, redesigned with the new guide (by Jaskni Wong).


GitCafé Campus, targeting college students (by Marco Yu).

EPILOGUE After the major work had been done, I also worked on a mobile version, trying to capture the same typographic spirit of the desktop.

The methodology of starting with the desktop is unconventional and even backwards nowadays, given the “mobile-first” trend in design and development. Yet it is reasonable for us to start this way, as majority of programmer users wouldn’t do major Git operations on mobile devices. Nonetheless, we still felt a need to attend to typography on mobile devices, at least for the outward-facing pages.

To develop a companion mobile scale, I used Typecast on my phone and iPad as real-time previews. While I managed to keep baseline increment the same—otherwise it would be an enormous hassle—the biggest change was a much more compressed size range (shown below):


Desktop (wider than iPad mini portrait): 12—67 px


Mobile (narrower than iPad mini portrait): 13—48 px

The reason to define the breakpoint at iPad mini portrait (768 px) is because there might still be desktop users on 1024×768 screens that occasionally are the case for netbooks. The desktop column grid (994 px at 1×) is still satisfactory, even for viewing with an iPad mini at landscape mode.

What matters at the end is the contrast created by size variance, not the absolute size itself.

The core factor for the compressed size range is ergonomic: the viewing distance is much shorter, as mobile devices are generally held in a more intimate fashion. However, it will be premature to simply scale down every type size. What matters at the end is the contrast created by size variance, not the absolute size itself. Not only is the boldness reduced in large titles, but the new scale ratio also offers an even finer gradation at the smaller size range. Like print design, it is as common to use 16-Point body type for a large folio as to use 6-Point for an octavo. It concerns not only the page proportion, but also (perhaps even more saliently) the distance at which the object is held from the person.

Now we had a system that is robust, flexible and detailed enough to provide design guidance in most situations. It also stimulates the designer to consider spatial proportions by conspicuously modularizing space. But most importantly, this is a typography that had truly taken Chinese—the dominant script in most scenarios—into consideration from ground up, while also paying great attention to the mixing of Latin and Chinese characters. The whole design team was doing a huge visual overhaul at the time, including branding identity and an interaction pattern library. Being part of this effort, I wrote and designed a style guide, covering also the principles behind and some other minutiae (download a pdf here if you read Chinese). It was no longer a mere collection of type styles; it also informed the entirety of visual design practice at GitCafé, and I am proud of it.

My fellow designer, Nico Hsueh, once revealed to me:

“This system is so good and convenient, I intentionally did not use it in my side projects, for I am afraid I would lose my design ability once without it.”

Jaskni (in yellow) and Nico (in grey) staring at an iteration, across a row of engineers. Photo by me.

I take it as the highest compliment.

To further consolidate our progress and to promote the status of design within the company, I also delivered a series of small lunch talks on the importance of design, and a 1.5-hour lecture on the relationship between the word and its image for the design team (slides here).

PREVIOUS
GUIQUAN

NEXT
PEDESTRIAN LEVER

And at last, a huge thank-you to all my ex-colleagues: Jaskni Wong, Nico Hsueh, Zoey Wang, Marco Yu, and Meng Meng, without all of whose support and respect I would not have been able to carry on such an ambitious project like this.

NEXT
PEDESTRIAN LEVER

PREVIOUS
GUIQUAN

NEXT
PEDESTRIAN LEVER