OakHazelnut.com is a working portfolio site of Amber Case: an amazing independent journalist, search engine and social media consultant. Her site is one that is a resource to the community, and thus is seen by thousands of readers every month.
However, because it contains ample amount of informations (a typical post weighs in at about 750 words) the site has to be easy to read. So easy that only the text that is absolutely necessary to the content shines, while other materials regress. Add the fact that she publishes an article every two days to this.
Readability and legibility is of further concern because, while the OakHazelnut.com’s ultimate goal is to get more subscribers, most readers still interact with its web interface, or at least use it prior to subscribing.
Objective and Challenge
As a typographer, my aim was to make OakHazelnut as easy to digest as possible. As a publisher, Amber Case needs a vessel that will, like Beatrice Warde’s Crystal Goblet, be robust enough to hold any content that she throws at it.
Right off the bat, I was presented with the challenge that the visual language of the site must stay as similar to the old as possible. This makes sense. After all, OakHazelnut.com has been known to use the same theme throughout its inception, GreenWave, and thus must remain consistent.
This means that tweaking navigation scheme is okay (and even encouraged if it can mimic those of other sites to encourage familiarity) but switching images, color scheme or number of columns around must be avoided, or done very subtly at best.
In addition to this, because the author installed many plugins and changed many lines of code already, shifting the structure of the CSS (ie. reorganizing classes) was not to be done, to avoid breaking the theme.
With these constraints in mind, I got ready to work.
The Four Step Process
1. Standardize Typography
The very first thing that I set out to do was standardize the font family used in the site. Many themes rely on using different families to distinguish content. This is fine, but only if done well Blogs have many layers of information that need to be distinguished from each other. For instance, a typical blog page may have:
- Blog title
- Blog description
- Navigation
- Secondary navigation
- Blog post title
- Post heading (h2 through h6)
- Meta information
- Body text
And in most cases, using one font family is enough to get the job done.
But if one would choose to use two, this is how one might group them. One font per group.
Group 1
Primary Information, one where you want the eye to go look at first. Ideally, you would be able to simply hover from item from item in this group and get the gist of the blog.
- Blog title
- Blog post title
- Post heading (h2 through h6)
Group 2: Secondary
- Blog description
- Body text
- Navigation
Group 3: Tertiary
Informations to be “read later” (in most cases, one would group them with Group 2)
- Secondary navigation
- Meta information
On Choosing Typefaces
Some fonts are better suited for one purpose than another. For example:
- While Lucida Grande/Sans and Verdana looks and reads well at smaller sizes, it quickly loses subtlety and elegance when set as headlines (Lucida is more resilient.)
- Helvetica, Arial, Times New Roman, and now Georgia, work equally well at relatively wide range of sizes, thanks to our habit of reading and therefore getting used to it over a long period of time.
- Trebuchet MS, tend to be used prominently at large sizes but hadn’t found many uses in body text (even though it’s just as readable, this I don’t know exactly why.)
- Others, like Hoefler Text, Baskerville and Didot, may be unsuitable to be set small thanks to the monitor’s low resolution
- Others still, like Futura and Gill Sans, comes by default on Mac but never ended up getting used very much (the reason is obvious, for using a font that isn’t installed on 85% of the Windows-platformed systems does not make sense.)
- Finally, Tahoma is face that comes with almost every computer, and one that I find to be of a fitting use in subheadline situations (the spacing is too tight on smaller sizes, yet the construction does no display subtlety at large sizes.)
Getting Into The Code
View GreenWave’s original CSS file.
View OakHazelnut.com’s CSS file.
Of course, then, even though I was forbidden to reorganize the CSS class and ID structures, I must in some ways put some order in its structure. Right off the bat, I noticed (code shortened to highlight important points):
body {
font-family:Trebuchet MS, Arial, Helvetica, sans-serif;
}
#menu_search_box {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#header_center_text #header_center_body {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#header_title span {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#menu {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_right #sidebar h2 {
font-family:Arial, Helvetica, sans-serif;
}
#blog_right #sidebar ul li {
font-family:Arial, Helvetica, sans-serif;
}
#blog_right #sidebar li a {
font-family:Arial, Helvetica, sans-serif;
}
#blog_right #sidebar ul li ul li {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_right #sidebar ul li ul li ul li {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_right #sidebar ul li ul li ul li a {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left #blog_comm .comm_panel {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left #blog_comm .comm_text {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left #blog_comm #comm_post_form td {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left .item_class .item_class_title_text .date_month {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left .item_class .item_class_title_text .end_title {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left .item_class .item_class_text {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left .item_class .item_class_panel a {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left .item_class .item_class_panel a:hover {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
div#footer #footer_text {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
Notwithstanding the fact that Helvetica and Helvetica Neue should be specified in front of Arial whenever possible, and that mixing two sans serifs is generally not a sound principle to follow, specifying the same font-family set over and over again for very small levels of CSS class is simply redundant.
To remedy this, I did a Find-and-Replace run, deleted all occurrence of “font-family:…” and replace them with:
body {
font-family: "Lucida Sans Unicode", "Lucida Grande", "Helvetica Neue", Helvetica, Arial, sans-serif;
}
strong, em, b, i {
font-family: "Lucida Sans", "Lucida Sans Unicode", "Lucida Grande", "Helvetica Neue", Helvetica, Arial, sans-serif;
}
h1, h2, h3, h4, h5, h6, address {
font-family: "Lucida Sans", "Lucida Sans Unicode", "Lucida Grande", "Helvetica Neue", Helvetica, Arial, sans-serif;
}
These lines of code does much of the same thing that the redundant blocks above do with only the lines that are actually needed to do the job, and nothing more. Much better.
On Choosing Lucida
Note how I specified a different set of typeface to replace the default set that the WordPress theme had. Why did I chose an odd combination of Lucida Sans Unicode, Grande and Sans? And why did fall back on Helvetica Neue, Helvetica and Arial?
Technically, I used a solution from SixThings called “Lucida Hybrid.” Put simply, Lucida Hybrid aims to combine the best of:
- Lucida Grande – only available on Mac, no italic, renders beautifully
- Lucida Sans Unicode – available on Windows, no italic, renders beautifully
- Lucida Sans – available on both platforms, has italic, but the normal weight renders poorly at certain sizes
Typographically, I used the Lucida family because it’s the same face that Mac OS X uses to set the UI texts—bringing familiarity, therefore allowing the typography to disappear and content to shine. On the case that a Window user don’t have this family, the CSS will roll back to Helvetica Neue first, then Helvetica, and, if nothing else is possible to use, Arial. Again, Helvetica and Arial are two faces that computer users are used to seeing.
2. Enhancing Body Text Readability
My next objective is to soup the body text up. GreenWave’s default CSS specified:
#blog_left .item_class .item_class_text {
color:#8a8a8a;
font-family:Verdana, Arial, Helvetica, sans-serif;
font-size:11px;
line-height:20px;
}
This is the right idea. Any small type on low resolution display must be generously leaded to avoid clumping, and Verdana reads well at 11 pixel. However putting an #8a8a8a (roughly 50% grayscale) color on a white background provides too little of a contrast for such ample amount of texts to read well.
My solution:
#blog_left .item_class .item_class_text {
color:#262626;
font-size:12px;
line-height:20px;
}
On a lit display like a monitor, specifying black (#000) on white (#fff) is too jarring for the eye. I avoided it by using a dark shade of gray. The same solution is used in most books that are printed in slightly tinted, “egg white” paper, because reading a bright white, glossy paper is not easy.
Note how I kept the line-height generous, but increased the font-size by one pixel.
3. Standardizing Behavior
Next, I looked at how the links behave. Notice how, by default, the theme behavior specified light grey for body texts and dark grey for link colors. This is very helpful, but note how hovering at the link does not actually change it in any way. It remains dark grey. No highlight. No underline. Nothing. To aid comprehension, links behavior should be standardized:
- Every link color inside the body of the blog, if put on top of a white background, should be colored green. This includes regular and meta information links. Exception: Post Titles, because it’s big enough to be distinguishable from the rest of the text.
- Every link color, if put on top of a non-white background, could be colored white or grey, depending on the needs and color contrasts
- Every link put on top of a white background, when hovered, should be colored in light green, then underlined. Exception: Post Titles, because underlining a text with small leading isn’t pleasing to the eye
- Every link put on top of a non-white, when hovered, could keep its color or switch to light green, whenever appropriate and beneficial to page contrast, but they should always be underlined.
4. More Tweaks
The last step is to change more colors, increase more leading and decrease more type sizes. To regular readers, the tweaks are subtly visual at best; but remember: the more readers voraciously dive into the material itself without noticing how the type was set (except on highlighted elements), the more the typography had succeeded.
Ready To Make Your Site Or Blog Read Better?
