Brian Walker

These here internet tubes are known for two things; Bringing a whole world of people together to gain and share knowledge and experience, and Times New Roman. Yes, Times New Roman, that default of web fonts, is practically inescapable online. So too are a few others; Arial, Helvetica (if you have a Mac), Verdana, Georgia, Courier, Tahoma, Comic Sans. Oh how I shudder to think of Comic Sans.

But you notice something? This blog post isn’t written in any those. It’s written in a fine little font called Aller, developed by Dalton Maag. It’s long been too difficult, cumbersome, or both to reliably use custom fonts on the web. But we stand on the brink of a new era, one that gives us designers more freedom, and may make the web a little better for everyone.

The earliest solutions for using custom fonts were to just save your text as an image and upload it on to your site. Obviously, this presented several problems. In the early days of the web this resulted in long delays in page loading since modem speeds were much lower. People relying on screen readers (such as the visually impaired) couldn’t get the text in the image. Additionally, search engines couldn’t see the text and ignored it (and with it, your website).

Eventually, this led the way to image/text replacement. The idea behind this was simple: Since download speeds were improving, the delays could be mostly eliminated. By coding the site with web safe text, then using CSS to hide the text (either in a hidden overflow, or beyond the borders of the screen), we could replace it with an image. Since screen readers and search engines ignore CSS, the site would still be useable. Unfortunately, this method had it’s own set of problems. Text couldn’t be copied or pasted from the site, and search engines began to ignore ‘hidden’ text.

Flash and JavaScript based techniques, such as cufon and sIFR, were then developed to solve the issue. Unfortunately, by relying on extraneous technology, they couldn’t be relied upon in many situations. The iPhone and iPad don’t support Flash, and most mobile devices that do have such abysmal support that users avoid any contact with sites using it. Additionally, many mobile phones still do not support JavaScript, and many users simply turn it off for security concerns.

So where now do we stand?

The @font-face solution seems ideal on paper, and has existed since the days of IE6. Most web designers know of it, but few use it, even though most can’t articulate why they don’t. The most common answers in my experience, are that they heard that it doesn’t quite work right. Many of those who have put in the effort to learn to use it get frustrated when it refuses to work and give up.

The problem with @font-face was that although all major browsers support it, they all required their own specific type of font. Safari, Firefox, and Opera all support True-Type and OpenType Fonts, while mobile platforms such as the iPhone only supported SVG. Worst of all, Internet Explorer only supports Embedded OpenType Fonts; Where does one procure these mythical .eot files?

Today, we have two major solutions to this problem. The first is Google Font API, a collection of roughly 20 fonts, and a code generator to make them work on your site. Initially relying on JavaScript, it now relies solely on CSS. The downside to this is the limited number of fonts and the dependancy on Google’s own servers. If someone were to access your site while Google’s font servers were down, your site would revert to it’s default fonts. To be fair, this is Google we’re talking about. Rarely do their servers go down, but it has been known to happen from time to time.

Thankfully, our second solution is FontSquirrel, which addresses both these issues. What is FontSquirrel? Well, mainly it’s a repository of high quality, commercially licensed free fonts for use on the web. These fonts are hand picked by font designer Ethan Dunham, who also runs the site, so you can be assured that they passed his test of quality. The other great part of FontSquirrel is the @font-face Generator. Using the Generator, you can select a number of fonts from the site, or fonts you yourself are licensed to use on the web, and create a quick package of proper font types with the required CSS. The Generator will take whatever font file you give it, and spit out an .eot file, as well as an .svg, .ttf, and .oft, doing all the hard work for you! Designers no longer have an excuse as to why they don’t use @font-face.

It works, but my fonts look bad! (Hint, hint)

In the physical world, fonts are just shapes, but in the digital world they must be made up of the pixels on the screen. Hinting is used in digital fonts to give the software an idea of how the font should be displayed onscreen. What hinting does is adjust (some might say pervert) the font so that it stays inside the pixel grid.

For the most part, Macs generally ignore hinting, instead using transparencies and other techniques to replicate the font as accurately as possible. This is why at very small sizes, most fonts on the Mac become somewhat blurry. Windows, on the hand, take the stance that maintaining the pixel grid is more important than the integrity of the font. This is why, at very small sizes, all Windows fonts begin to look the same. The fonts can only be simplified until they reach a minimal number of blocks to be made up of.

Hinting is something that most free fonts don’t have, and even many commercial fonts don’t do very well. It’s a very difficult job, trying to keep the fine line between maintaining the integrity of the font, and maintaining the integrity of the pixel grid. When generating your .eot fonts, FontSquirrel tries to automate this process. Early on, it was mostly a disaster. Now they seem to have discovered an algorithm that works most of the time. Or at least, some of the time. Your mileage may vary, but in my experience it’s pretty good. With ClearType enabled on your Windows machine, it’s very often above-average.

What about commercial fonts?

TypeKit is a great resource for those who want to use professionally and commercially licensed fonts. TypeKit works as an intermediary between font foundries and designers, allowing commercial fonts to be used while protecting them from illegal download and misuse. My only complaint about TypeKit, and really it’s not their fault, is that it seems font foundries have been very slow on the uptake of new technology, and so their library isn’t as vast as it should be. At the time of this writing, it includes 514 fonts, but someone’s favourite is bound to be missing.

The upside to TypeKit, however, is that with professionally developed fonts you are likely to see much higher quality hinting on your Windows machines.

We all hate coding for IE6.  To be fair, there are those among us who enjoy charging extra for it, but I think we can all agree that it would be nice if IE6 just went away.

Unfortunately, that’s not likely to happen.  With the flop that was Windows Vista, and slow adoption of Windows 7, IE6 is here to stay in the home market for quite some time.  Compounding that are the IT departments that refuse to allow employees to upgrade, due to internal web solutions that were coded (short-sightedly) specifically to work on IE6 and only IE6.

In any case, it’s impossible to know the exact market share of any browser.  The statistics are out there, and you’ll probably see colleagues cite them, but really, they only show the part of the web that was measured.  For example, Net Applications has reported that IE6 has a 22% market share as of August 2010, while website Ars Technica claims it accounts for less that 10% of their visitors.

So how do we deal with IE6?  Code to standards, then ‘fix’ for IE6?  Ignore it completely?

Personally, my approach in the past was to code to standards, and then create a separate IE6 stylesheet which I would use to fix a wide range of bugs, both large and small.  There are those who disagree with this approach, thinking that if we ignore IE6 it will go away.  Actually, the idea is more akin to thinking “If most websites don’t work in IE6, then it’s users will have to upgrade”.  While normally this would be true with technology, you’ll find few companies eager to alienate a sizeable portion of their users, and so they insist that IE6 must work.

My current approach is that of graceful degradation.  I code my HTML and CSS to standards, and I test in Firefox, Chrome, Safari, Opera, and Internet Explorer 8.  Once the code renders well in those browsers, I take a look at IE6, and to a lesser extent, IE7.  I then begin to tweak the code in subtle ways, to make it more palatable for IE6 users.  The goal here is not pixel-perfect accuracy, but rather, a simplified version of the final site.

A few months ago, frustrated with a client site that wouldn’t render properly in IE6, I angrily tweeted that “If IE6 users cared about rounded corners, Microsoft would have implemented them!“  This is wrong for a number of reasons, but the main one is that the average user simply does not know that IE6 is full of bugs.  Frankly, they are using IE6 because that is the browser that came pre-installed on their computer.  They don’t know that other browsers are out there, and even if they do, they are comfortable with this one.

What isn’t wrong with my angry statement, however, is the idea that rounded corners are unnecessary.  Rounded corners are usually superfluous in web design, no matter how badly the client thinks they’re necessary.  They occasionally look nice, but usually look awful, and certainly we have moved past the point where they are considered trendy.  Incredibly rarely do they *make* a design (though occasionally they break it).  If I can render them entirely in CSS, without making scores of different corner images for each different coloured box, then that is best practice.  That way, they will render rounded in most browsers, while IE6 will show them with square corners.

This is a good thing, for you, for your clients, and for the web in general.  You get saved the frustration of coding specifically for IE6.  Your clients save time and money, not having you code for IE6.  Finally, the web as a whole benefits, because most users aren’t using the latest version of Firefox and then switching to IE6 just for kicks.  People overwhelmingly prefer one browser.  As a web designer, I am forced to use no less than than seven (SEVEN!) different browsers on a daily basis, but when I’m surfing on my own time, it’s Firefox all the way.  That’s my personal choice, just as those users who stick with IE6 have made theirs.  But when they do upgrade, or see the same site on a friend or co-worker’s machine, they will see what they have been missing.  This is how the web benefits.  They will be encouraged to upgrade, and possibly encourage others.  The faster the rate of adoption of new technology, the sooner we as designers can reliably implement it, and the sooner everyone reaps the benefits of that technology.

One last thing to note: I don’t advocate refusing to code specifically to IE6.  In fact, I still do it when requested by the client (and yes, I do bill them for the extra time required).  I do however, explain to them the difficulties with IE6 at the start of the project, and possibilities for graceful degradation that won’t affect the overall usability of the website.  The reason I am able to do this is because I know IE6 in and out, and that knowledge is invaluable.

As a designer, I come across Flash a lot. A significant portion of my career thus far has been spent working in Flash, and for a while, it was my bread and butter. Now, I avoid it when I can. I’ve talked to a number of other designers who feel the same way, but how did we get to this point? What changed from those early days of Flash love?

To answer that, let’s take a quick look back at the history of Flash. Originally released as FutureSplash, and acquired by Macromedia and re-released as Flash in 1996, it’s original goal was to help users build websites without having to learn to code. Between 1996 and 2010 Flash became an entire development environment. Basic scripting supported was included in the 1997 release of Flash 2, with Flash 5′s release in 2000 included ActionScript 1.0. ActionScript 2.0 was included with Flash 7 in 2003, this being the first truly modern and ‘complete’ version of ActionScript.

MacOS X

When Apple decided to make the switch to a UNIX based operating system in 2001, Adobe decided to focus their development efforts entirely on Windows, assuming that the UNIX effort would be a failure. When Mac OS X debuted and proved to be a startling success for Apple, Adobe was caught off guard. Their subsequent efforts on the platform have been criticized as "rushed" and inferior to their Windows counterparts. Since much of the creative industry responsible for Adobe’s success prefers the Mac platform, this became one of the ways that Adobe first began to alienate this creative base. To this day, Adobe Flash is cited as one of the number one problem applications for Mac OS X. It is known for bringing the entire system to a grinding halt when invoked on a website.

ActionScript 3.0

In 2006, Adobe released Flash 9 with support for ActionScript 3, which was a complete restructuring of the language. Although a vast improvement, AS3 was not backwards compatible, and so users had to learn an almost entirely new syntax to use the new features, abandoning six years of learned code, and further alienating the creative base that Adobe relied upon. By this time, new and more open techniques had been developed for accomplishing much of what Flash had been used for previously.

iPhone and iPad

With the release of the iPhone in 2007, Apple refused to allow Flash technology to run on it until Adobe could release a "stable" and "reliable" version. Since Adobe has not been able to do this on the Mac, it is not surprising that as of 2010, Adobe has been unable to meet Apple’s requirements on the iPhone. After selling over 100 Million iPhones, Apple released the iPad to great acclaim in 2010, again refusing to allow what it considered a poor implementation of Flash on the platform. At this point, most users have agreed that Flash is unnecessary on the device.

Android Phone Support

Google’s Android mobile OS was released in 2009 in an attempt to compete with Apple’s iPhone. One of the key promises in Android was Flash support. Unable to develop a stable version, Flash was delayed multiple times for Android, before finally being released in "beta" form on a number of shipping phones. It has since cleared the beta stage, though many phones still ship with the beta version installed. Results across different hardware have been mixed, from running seemingly fine on some systems, to unusably bad on others. This has alienated many early adopters as they have now come to expect that the experience with Flash will be less than ideal. In addition to the unstable and unreliable implementation have been problems with phones being pushed so hard by the software that they can become quite hot, as well as extremely shortened battery life.

Can Flash be saved?

Perhaps more appropriate is the question "Should Flash be saved?". Although popular, Flash has never been much more than a browser plugin. It became so ubiquitous with the web for a while that the plugin now comes pre-installed on many computers, but this doesn’t change the fact that it is unavailable on most mobile platforms, and performs quite poorly on all platforms outside of Windows.

As a designer I asked myself these four questions about whether Flash can be saved, or is indeed worth saving:

1. Can the advantages of Flash be recreated using open web standards?

   Between CSS3, JQuery, and HTML5, I can now avoid using Flash in 90% of the situations I used to rely on it. HTML5 definitely has a long way to go, but it is an open standards up-and-comer. Flash is 14 year old piece of closed technology with a poor-to-non-existent implementation on all non-Windows platforms.

2. Is it likely that Adobe will suddenly "get Flash right" on non-Windows platforms?

   Although strides have been made recently in improving the Mac-based Flash implementation, including hardware acceleration, it is still buggy and insecure. Additionally there are significant issues with 64-bit operating systems (even in Windows), and hardware acceleration is unsupported in Linux environments.

3. When will we see Flash on the 100,000,000+ iPhones and iPads?

   Arguably never. As time marches on, Flash support seems less and less necessary, and therefore less and less likely on the platform. Apple has gone from acting mildly upset about Adobe’s inability to produce a suitable Flash port, to downright publicly hostile towards the company’s efforts in recent months. Major content providers such as YouTube and Hulu already provided dedicate apps to support the iOS platform, and those few that don’t are surely hard at work on it.

4. What about competing phones? Adobe has promised that Flash will soon be available and working on most mobile platforms.

   Flash regularly stalls and crashes on modern hardware. Top-of-the-line desktop computers with multiple multi-core processors, dedicated graphics cards, and up to 32GB of RAM choke on Flash video. What hope then, do we have that Adobe can deliver a version of Flash that can run the same content on mobile hardware, which has only a fraction of the power?

   Not to mention the fact that different handsets run on completely different hardware, further complicating the implementation of hardware acceleration. Given the fact that the average handset only last six months on the market, it would be impossible for Adobe to optimize Flash for each different piece of hardware before they became obsolete.

Perhaps the simple fact then, is that Flash has run it’s course.

This is not to say that Flash is dead, but it is almost certainly dying. It will be a long, protracted death, and Adobe will do it’s best to keep this cash cow running for as long as it can, but in the end it’s unlikely that they will be able to keep it up.

As designers, we must continue to move forward in order to offer the best value and solutions to our clients. Increasingly, Flash is being replaced by newer, more stable, more reliable, and more open technologies. Our efforts are better spent learning these new technologies, than trying to teach an old dog like Flash new tricks.