Fluid Grids

One of the first things that has to be addressed when designing a site is the layout. Historically, because of the limitations in browsers, most sites have been built in some variation of what I’m calling “poster format”. One width, variable height, and you have the following problems:

  • On large monitors, content appears tiny and hard to read, and you always come away feeling like there was a lot of wasted space on the screen.
  • On small monitors (or if you have a site snapped to the side of your screen) the content doesn’t scale down, and your left with scrolling back and fourth to be able to read everything.

Over the years one of the principle solution to address this, if someone addressed it at all, was just to never center your content and just let it fill your entire screen. Although this almost works for lots of content, it’s difficult to read as paragraphs will stretch across the screen and you constantly lose your place as your eyes try to find the beginning of the next line. The other problem that arises is that if your designer has a large screen, theres a tendency to continue to add content to ‘fill in’ the space so the main content area isn’t as large. All in all, the only solutions were hacks on a broken system.

With the mobile smart phone market exploding over the last several years, and the browser wars providing an exponential increase in speed and standards complacence, we have a unique opportunity to re-evaluate how we build our sites. A beautiful example of this is this site:


No matter what browser you visit it on, or what size your browser is at, the content will be sized appropriately, the typography is readable, and everything will feel right. No insane urges to re-size your browser window.

This, to a limited degree, is how I want the Comatose Theme to look and behave. Fluid layouts are hard, and getting everything to work correctly while still maintaining a standard html5 layout hierarchy is going to be tricky.

Here’s a link to the demo: http://www.paulrohde.com/demo/html/layout-demo.html

And a video of the layout in action:

Since I currently don’t have access to a scanner, I will be scanning in and posting up images of the layout brainstormings with commentary soon.

Until next time.

Blogging: Comatose

After many revisions, starts, restarts, remakes, redesigns, tweaks, updates and misc changes to this site, I’ve finally decided to take and overhaul this entire site starting with the theme. I’ve had a daunting Todo list that grows every time I look at my site. The web has changed drastically. The browsers we use each day have improved exponentially and hardly resemble the ones we used a few short years ago. Sites have to be designed for media from a small screen to a huge widescreen monitor. Content is more dynamic. Layout is becoming organic.

I’ve decided to rebuild this site, starting with the theme. But just rebuilding it isn’t enough. I’m going to open source the theme on GitHub, as well as blog the development and decision making process that has (and is) driving the design and development of this theme.

Web, meet Comatose. Comatose, meet web.

Fonts and the Web

Here at InterKnowlogy, we get time each week to tinker and dive into technologies that interest and inspire us. We call it RECESS, which stands for Research and Experimental Coding to Enhance Software Skills. This week I’ve been noticing sites ‘sprucing it up’ by using custom font embedding with services such as TypeKit (Or similarly related projects such as Google Web Fonts) that allow you to license and use custom fonts in a site.

There’s a problem though. 90% of the time it annoys me.

Let me explain. First impressions are everything, and right after first impressions is readability. If I come to your site looking for information, to read something, I don’t want to get a headache doing so. The problem isn’t the design or the font itself usually, it’s the way the browser deals with and renders the font. Using a custom or weird font for the body text of the page WILL bother people. Its why standard fonts exist and are as popular as they are: readability. Now, that being said, there are really good design reasons to want to use custom fonts in a dynamic content driven site to augment the design. Especially in the title and headers since it will catch someones eye and because people spend a minimal amount of time reading them anyways. Whatever the reason, if your going to go down the custom font path its going to be important to refine and choose a solution that is going to be consistent and usable for the people that visit your site.

Coming back to RECESS, I spent some time examining the different offerings and essentially broke them into two categories: Browser/OS rendered text, and Image rendered text. Let me explain: For the Browser/OS rendered text (which TypeKit and Google Web Fonts use) the text is set using normal CSS rules, and then an actual font file is loaded by the browser and used to display the text. Almost exactly how text is displayed for application on your computer except that the font is never ‘installed’. The advantage is that it behaves exactly like normal fonts, you can type, select, copy, and do all the normal things you do with text. The second way is imaged rendered text, taking some chunk of text and turning it into an image that gets displayed in place of the text. Designers sometimes do this for logos and main headers that almost never change because it doesn’t require the use of a more modern browser and they KNOW that it will display the same way. Also in this category is a tool called Cufón. It’s a bit of JavaScript and a bit of a generator. It basically takes a font file, turns it into a bunch of shapes, and then on the users computer it uses JavaScript to load, render, and replace text in the page with those images. The disadvantage being you can’t select and copy the text in the same way, but the advantage is that it looks consistent and renders well.

I decided to tinker with these and see what I came up with (All screenshots are on Windows 7, the IE9 ‘font’ example is invalid as I would have had to convert it to a different format for it to display, but I was lazy. There is another example later that illustrates IE9 correctly showing a font this way.)

So here are some screenshots of the results on different browsers on Windows 7:

Chrome 12:

Firefox 6:

Safari 5.1 on Windows

Internet Explorer 9

I was surprised at the results. Same font, same file, but completely different results between Chrome / Firefox / Safari (IE9 excluded obviously) for the regular font rendering. Cufón came out the most consistent of all of these.

Next I went to TypeKit and found excellent illustrations of why embedding fonts is still so difficult and why I’m seriously considering using Cufón for the time being:

From top to bottom, Safari 5.1, Chrome 12, Firefox 6, IE9

The big thing to note is how jagged the letters look until you get to IE9. Readability wise, I would NOT consider using an alternate font for a large amount of text unless I had to, and for right now, Cufón seems a very viable choice for consistency.

There’s no final conclusion in this, since you will have reasons that will drive you to one option or another (Or simply throw your hands in the air and announce to the world that you are done with the web forever) So:

Nerd out.


Be careful with your font choices and how far you take this on a site that will be used on a regular basis. Cheers!

An Introduction To Web Fonts

Back in the old days of the Internet, circa 10 years ago, people were just beginning to discover all the new cool things you could do with the web. Print was still around in full force in all its forms of magazines and newspapers. We even had individuals that made a living putting together and curating text based content. Over the years as more and more content has migrated to the web, one of the major limitations designers have faced is that they only had about 3-5 fonts that they could reliably use to format their text and be sure that the particular font they had chosen would exist on the users machine. Sometimes there would be variations, but those variations could never be guaranteed to render the same way in a users browser. Print was just extremely flexible and could provide a typographical brand and experience that the web simply couldn’t match.

As the web has continued to evolve through the browser wars and the waves of ‘web 2.0’ there was still very little change in the way text was shown in the browser. Over the last few years some of these issues have begun to be addressed, and there’s a growing amount of support in more modern browsers to express this new idea of web fonts. The core issue is that everyone is running on a different browser, different operating system, platform, or device, and each unique configuration has its own typographical settings, fonts, defaults and so on. Websites initially began experimenting with solutions to solve this issue by actually embedding a link to the font that the browser can recognize, download, cache, and use to render fonts it doesn’t already possess. But this also posed a problem: Type foundries don’t simply want their fonts to be embedded and freely downloadable and usable by whoever happens to come along and visit a site that uses one of their fonts. A font foundries whole business model is based around the licensing of the fonts they create, so having something ‘freely downloadable’ would never appeal to them.

As I have been doing some exploration on the latest and greatest of web technologies related to HTML5 for RECESS here at InterKnowlogy, I wanted to share two different approaches that I’ve found of companies that are exploring this somewhat new idea of web fonts. Chances are you may have even seen sites already that use this, but didn’t realize it or how they did it.

TypeKit – http://www.typekit.com

Google Web Fonts – http://www.google.com/webfonts

Each of these take two separate approaches that may or may not be viable to you as a designer / developer / company depending on your needs. TypeKit is arguably the more powerful and flexible options of these two, but is a paid service (although very reasonably priced). It has a large portfolio of professional grade fonts from many different foundries, including some many of the main fonts that are included in Adobe products (which I’m sure is a plus for many designers). They uses an internal obfuscation and customization process to protect the individual font from being used outside of the website that the license was purchased for. This has allowed them to negotiate deals with some of these foundries to license the fonts for web use through their company (and they’ve obviously been decently successful).

Google on the other hand, has opted for the freely available open source fonts. All the fonts used in its web fonts site are free to use for anything and are supported on a purely donational basis. This provides two advantages: All the fonts are freely available, and a single browser can cache a font and use it across any sites that also use that same font without redownloading it, this means there will be less overhead and a more consistent experience across sites that use Google Web Fonts. However, arguably the biggest downside is that the selection of fonts is much more limited. Google has done a excellent job of curating the available fonts it has to ensure that they meet some internal quality standards, but likely many of the industry standard fonts will never be available in Google’s catalog because of licensing issues.

There is some very cool things you could do with this, I’ve purposely left out many technical details in order to give a more general overview of web fonts. Hopefully this has been enlightening and has sparked some creative ideas for cool new things you could do with this technology.

Happy Typing!