Member Sign In
Not a member?

A Wired.com user account lets you create, edit and comment on Webmonkey articles. You will also be able to contribute to the Wired How-To Wiki and comment on news stories at Wired.com.


It's fast and free.

Sign in with OpenID
Sign In
Webmonkey is a property of Wired Digital.
processing...
Join Webmonkey
Please send me occasional e-mail updates about new features and special offers from Wired/Webmonkey.
Yes No
Please send occasional e-mail offers from Wired/Webmonkey affiliated web sites and publications, and carefully selected companies.
Yes No
I understand and agree that registration on or use of this site constitutes agreement to Webmonkey's User Agreement and Privacy Policy.
Webmonkey is a property of Wired Digital.
processing...

Retrieve Sign In

Please enter your e-mail address or username below. Your username and password will be sent to the e-mail address you provided us.

or
Webmonkey is a property of Wired Digital.
processing...

Welcome to Webmonkey

A private profile page has been created for you.
As a member of Webmonkey, you can now:
  • edit articles
  • add to the code library
  • design and write a tutorial
  • comment on any Webmonkey article
Close
Webmonkey is a property of Wired Digital.

Sign In Information Sent

An e-mail has been sent to the e-mail address registered in this account.
If you cannot find it in your in-box, please check your bulk or junk folders.
Sign In
Webmonkey is a property of Wired Digital.

Typotheque’s Web Fonts Rock, But Old Machines Can’t Learn New Type Tricks

By Scott Gilbertson October 21st, 2009 Categories: Visual Design, Web Basics

Font foundry Typotheque has introduced a new web font system that gives web authors a new set of font embedding options for their website designs. However, as cool as Typotheque’s new tools are, they can’t overcome some larger problems with the @font-face rule in CSS and the state of type on the web in general.

Typotheque, a Netherlands-based font foundry, recently unveiled a set of web licenses and an easy cut-and-paste solution for web developers looking to take advantage of the CSS3 @font-face support in modern web browsers. The solution is particular nice because it doesn’t require the overhead of loading JavaScript libraries like some other proposed solutions we’ve covered, such as TypeKit. Typotheque’s system requires only a CSS file and a simple @font-face stylesheet rule.

Also working in Typotheque’s favor is a web-only license, which is issued and controlled by the company, that’s considerably cheaper than licensing the actual font files.

Unfortunately, in the real world, @font-face’s results aren’t always what you expect. As BoingBoing recently discovered when it tried a redesign using @font-face to embed custom fonts, CSS3’s @font-face rule doesn’t always render correctly on older PCs.

While it’s nice to see font foundries like Typotheque embracing both web licenses and simple embedding tools, the results are decidedly mixed. So long as your site’s users are running a modern OS like Mac OS X, Windows Vista or most Linux distros; and they have modern browsers like Firefox or most of WebKit-based browsers, the @font-face and Typotheque’s new embedding system work wonderfully. The only minor issue is a quick flash of unstyled text appearing when the page loads in Firefox, but that can be addressed with a simple JavaScript workaround.

However, for those users still using Windows XP, embedded fonts are not, by default, anti-aliased and results in jagged, ugly fonts that aren’t going to make you or your visitors happy.

To see how things looked in various browsers, we loaded Typotheque’s Fedra Sans font up in a test page at 72 pixels and then looked at it in various browser/OS combos:

Fedra Sans in various browsers. Click the image for a larger view.

As the image above demonstrates, the results are just fine in Firefox on Mac OS X and Linux, acceptable in IE7 in Windows XP and downright ugly in IE6 on XP. Given the considerable percentage of web users still browsing with IE6 in Windows XP, @font-face clearly isn’t going to work for every site.

Still, for those that just want to experiment with @font-face, Typotheque’s new system is the simplest, cheapest system we’ve tested. There’s even a free month-long trial available for testing purposes. For more details, head over to the Typotheque website.

See Also:


Post Comment | Comments | Permalink

Mozilla Throws Its Weight Behind Improving Web Type, Adopts WOFF for Firefox

By Michael Calore October 20th, 2009 Categories: Software & Tools, Visual Design

Firefox users will soon gain the ability to see an even greater diversity of fonts on web pages.

Mozilla announced Tuesday that version 3.6 of Firefox, due by the end of the year, will support the new Web Open Font Format, or WOFF. Web authors will be able to include WOFF fonts in their page designs by linking to the font files in their code the same way they link to images and other downloadable files.

WOFF becomes the third downloadable font format supported by Firefox — version 3.5 included support for TrueType and OpenType font downloads.

But WOFF has two key advantages over TrueType and OpenType: WOFF fonts are compressed, so they download faster, and they include support for tags and other unencrypted metadata.

This is a significant step forward not only for the emerging open format, but also for type on the web in general, which is still stuck in a state of mild turmoil.

For years, designers have been limited to using only a set of five or six common fonts on the web. But thanks to new font rendering tools within the emerging HTML5 and CSS3 standards, web designers now have the ability to use newer, more visually interesting typefaces — and make that type appear more consistently across browsers, operating systems and screen resolutions.

Even with these new abilities, intervening forces like DRM, licensing restrictions and varying levels of support from the browser makers have stalled progress, forcing the modern designer to resort to a variety of workarounds and hacks if they want to use these new fonts. Some possible solutions have shown up, including the OpenType standard and a “middleman” licensing model proposed by the startup Typekit, but haven’t yet gained traction. Earlier this month, popular website Boing Boing launched a redesign using CSS3’s @font-face rule, but ran into problems when things didn’t render correctly on older machines.

WOFF doesn’t promise to totally solve the problem of browser compatibility — it still uses the same paradigm within CSS3’s @font-face rule where users are served a preferred font choice first, but are then offered backup choices if their browser doesn’t support the first one. And there are still special considerations for IE 8 users, as Microsoft’s browser supports @font-face, but only if you use the .eot font format.

What it does do is improve workflows for those using downloadable fonts in their designs.

Mozilla contributor John Dagget outlines the compression and tagging advantages on the Mozilla Hacks blog:

First, compression is part of the WOFF format so web authors can optimize the size of fonts used on their pages. The compression format is lossless, the uncompressed font data will match that of the original OpenType or TrueType font, so the way the font renders will be the same as the original. Similar compression can be achieved using general HTTP compression but because compression is part of the WOFF format, it’s simpler for authors to use, especially in situations where access to server configuration is not possible.

Second, the format includes optional metadata so that a font vendor can tag their fonts with information related to font usage. This metadata doesn’t affect how fonts are loaded but tools can use this information to identify the source of a given font, so that those interested in the design of a given page can track down the fonts used on that page.

Dagget also notes that WOFF fonts aren’t “secure,” so the format shouldn’t be used by foundries wanting to regulate the use of their work. However, over 30 major type foundries — including House Industries, Hoefler & Frere-Jones and ITC — are already endorsing the format, and Mozilla’s support should help foster its popularity.

You can read more about how WOFF is used, plus see examples on the Mozilla Hacks blog. You can also check out WOFF support yourself by downloading the latest nightly builds of Firefox and giving it a whirl.

See Also:


Post Comment | Comments | Permalink

Debunking the Myth of the Page Fold in Web Design

By Scott Gilbertson October 16th, 2009 Categories: Visual Design, Web Basics

Web standards give developers a way to build websites so that anyone can access them. Unfortunately web standards don’t cover more difficult problems, like how to make sure people can find what they want on your site.

For that developers need to turn to common design patterns, but unfortunately many design patterns are outdated. For example it was long held as a common belief that most users would not scroll down the page, so your content needed to be “above the fold” if it was to be noticed — a term leftover from newspapers where the primarily headlines are above the fold, so those walking by a newsstand would see the important stuff even though the paper was folded in half. The web equivalent of above the fold is the area you can see without scrolling.

However, that conventional wisdom is not nearly as true today as it was back when Jakob Nielsen encouraged developers to keep everything above the fold. Of course Nielsen’s own site has plenty of content below the fold — after all, the web isn’t a newspaper.

CXPartners, a U.K.-based design agency, recently posted the results of a study involving some 800 user testing sessions, and on only 3 occasions did the page fold stymie users.

Part of the reason for the shift can be seen in CXPartners’ hotspot study, which used eye tracking software to reveal that users nearly always spend some time glancing at the scrollbar to judge page size. Now, that doesn’t mean you bury your best content below the fold, but it does mean that you shouldn’t worry too much about things that simply don’t fit above the fold.

But one surprising thing thing comes out of the study is that having less above the fold actually encouraged exploration below the fold. According to CXPartners’s study, the judicious use of white space and visual clues that lead the eye down the page significantly increase the chances a user will scroll.

The key is to make sure there are no barriers that would make your users think there is no “below the fold” content. One example cited in the study had a large horizontal bar running across the page, which acted as a barrier — it looked like the bottom of the page even though it wasn’t. Eliminating the horizontal bar encourage users to scroll the page.

Although it might run against your aesthetics as a designer, clipped text and cut off images are also high on the list of things that encourage scrolling.

Here’s CXPartners’ suggestions based on their user testing research:

  1. Less is more — don’t be tempted to cram everything above the fold. Good use of whitespace and imagery encourages exploration.
  2. Stark, horizontal lines discourage scrolling — this doesn’t mean stop using horizontal full width elements. Have a small amount of content just visible, poking up above the fold to encourage scrolling.
  3. Avoid the use of in-page scroll bars — the browser scrollbar is an indicator of the amount of content on the page. iFrames and other elements with scroll bars in the page can break this convention and may lead to content not being seen.

So what would Jakob Nielsen think? Well, actually he seems to have weighed in in the comments, suggesting that what CXPartners discovered is old news. That may be true for Nielsen, but the CXPartners’ write up is much more readable than the technical, jargon-filled document Nielsen points to, and even if “below the fold” is a myth, it’s a well established one and there’s no harm in debunking it again.

Be sure to check out the comments on the CXPartners site for some helpful design tips and techniques from readers, as well as some thoughtful criticisms of the study.

Photo: Matthew Bradley/Flickr, CC

See Also:


Post Comment | Comments | Permalink

Boing Boing’s Redesign Uncovers the Dark Side of Web Fonts

By Scott Gilbertson October 8th, 2009 Categories: Platforms & APIs, Visual Design

Culture news site Boing Boing recently tried a daring experiment — redesign its immensely popular website using some largely untested tools of the open web.

Unfortunately for Boing Boing, its ambitious plan resulted in a small disaster.

The team decided to use CSS3’s @font-face rule in its recent site redesign, which would enable it to use a custom font to display its text. However, far from delivering the look BoingBoing was going for, @font-face fell flat on its face; when the changes went live Tuesday, not only were the fonts Boing Boing wanted to use not legally available for the web, the font it settled on — specifically BPreplay — ended up looking terrible for most users.

The result was hordes of angry Boing Boing fans complaining that the new headline font was “ugly,” “an abomination” and “plain nasty.” Of course, the culprit wasn’t really the font, but rather how different it looked depending on which browser and operating system the viewer was using.

Web designers have long been pining for open source tools that would afford them more control over site designs, including the ability to create animations, complex layouts and — probably the biggest wish-list item — the ability to use original typefaces and proprietary fonts in their designs. Many of these things are currently being written into into HTML5 and CSS3, two next-generation open standards for building well-formed web pages. We’ve even praised CSS3’s font-face rule and talked about how you can legally use it today.

The problem is that while modern browsers, like the latest versions of Safari, Firefox, Opera and Google Chrome, all support @font-face, the Windows XP operating system often doesn’t have anti-aliasing turned on by default. The rule, which is still part of CSS3’s draft specification, is also not supported by any version of Internet Explorer. So, as cool as your font might look when properly anti-aliased, on Windows XP it looks, as Rob Beschizza, head of Boing Boing’s redesign puts it, “like ass.”

Beschizza, who like many Boing Boing contributors used to work for Wired.com, spoke to Webmonkey over e-mail shortly after the redesign launched and after the feedback started pouring in.

For those using Windows Vista or Mac OS X, Boing Boing’s redesigned headline fonts looked just fine. Indeed much of the experimentation so far with @font-face is happening on designers’ blogs and portfolios — sites where the audience is likely to be using a modern browser and a modern OS.

If your audience is limited to people who live on the web’s cutting edge, then @font-face works pretty well.

However, for sites like Boing Boing, which has much broader audience, Windows XP and older browsers are still a significant portion of daily traffic. And while browsers that don’t understand @font-face (such as Internet Explorer) were fed a typical web font, in this case Verdana, the combination of modern browser and older OS proved disastrous.

But even practical issues like improper font rendering weren’t the only problem Boing Boing faced trying to use @font-face.

The font BoingBoing ended up using, BPreplay by the design group backpacker, wasn’t its first choice, but rather, because of licensing issues, its only legal choice.

“Our first pick for that headline font was VAG Rounded, which Mark (Frauenfelder, co-founder of Boing Boing) had used in his first mock-ups for the design,” says Beschizza, but the foundry didn’t offer a license for web display.

In fact the design team went through a whole list of font choices before they found one that was legal and fit their design.

Given the outcome, it isn’t hard to see why some foundries don’t want to license their fonts. Forget about @font-face making the actual font files available for download — if the fonts look terrible, no one will want them anyway. In fact, the foundry that makes one font Boing Boing tried to license cited appearance as the main reason they were declining to license the font.

So does that mean there isn’t going to be a way to use @font-face until Windows XP is a dim memory? Well you could always use JavaScript to detect the operating system and selectively applying @font-face to an OS that can render it. That (among other things, like licensing complexities) is one of the potential problems startups like the TypeKit project are hoping to solve.

Of course there’s always another option — just ignore Windows XP users. For smaller sites that may be a viable option, but for sites the size of Boing Boing the only real alternative is to do what Boing Boing did — revert to good old Helvetica and call it day.

Eventually web fonts will work, but for now they remain well out on the cutting edge. So, if you’re working on a large site, tread with care.

Photo: healthserviceglasses/Flickr

See Also:


Post Comment | Comments | Permalink

Design Patterns Solve Common Problems for Web’s Color Blind Users

By Scott Gilbertson September 29th, 2009 Categories: Visual Design, Web Basics

Every website owner wants to reach as large of an audience as possible. That’s why good web developers go to pains to ensure their sites are standards compliant, work across all browsers and provide solid accessibility for devices like screen readers.

Unfortunately, while those are all steps in the right direction, none of them address a quite large subset of problematic users — the color blind.

Color blindness affects between five and ten percent of the general population. Most color blind humans are male, and the most common form of color blindness makes it difficult for the person to distinguish between reds and greens.

We’ll admit that we hadn’t fully considered the impact of color blindness on website design until Andy Biao of Waxy.org pointed us to We Are Color Blind. The site hosts a collection of design patterns for making your website more accessible to people with common forms of color blindness.

If you’re thinking this is simply another thing you need to worry about when picking color palettes and page designs, relax. The patterns on We Are Color Blind, aren’t complicated and the site is full of very easy, subtle solutions.

For example, consider Apple’s iPhone availability chart — a simple list with store locations alongside red and green dots to show which stores have iPhones and which don’t. The problem is that if you don’t see color, distinguishing between the red and green dots is very difficult. The solution, however, is very simple and elegant — change the red dots to red squares. The basic design of the site, and the color scheme, is maintained, but the difference in shapes allows color blind users to easily get the same information.

Other potentially problematic designs include pie charts, heat maps and color pickers. But as is the case with the iPhone chart, there are easy solutions. For example, with charts, heat maps and other color maps, simply adding a tooltip when the mouse hovers over a selection helps eliminate the color dependency.

Our favorite part about We Are Color Blind is that not only does it make you aware of a problem you might have previously overlooked, but it has thoughtful solutions all ready to go. We wish there were more collections of common design patterns and solutions out there; if you know of others be sure to let us know.

Note: The image at the top is a plate from the famous test developed by Shinobu Ishihara. Individuals will normal vision will see the number 74. Color blind individuals will see different numbers or no numbers at all depending on what type of color blindness they have. Learn more at Archimedes-lab.org and Wikipedia.

See Also:


Post Comment | Comments | Permalink

Snow Leopard Gives Designers a Dark Web

By Scott Gilbertson September 9th, 2009 Categories: Visual Design

Web developers upgrading to Apple’s new Snow Leopard operating system will see something a little different in their monitors — Apple has switched the default color settings in OS X 10.6 to gamma 2.2.

The net result for web designers is that colors will appear somewhat darker than in previous version of OS X.

Many Mac toting web designers have long changed the old Apple default of gamma 1.8 to gamma 2.2, as PCs have long been set to gamma 2.2. And thus, the majority of your audience would see colors in gamma 2.2.

However, if you’ve never used gamma 2.2, beware that colors do look significantly darker.

As for why Apple used 1.8 for the last 25 years, Adobe’s Principal Product Manager for Photoshop, John Nack has the skinny on his blog.

A long story made short: gamma 1.8 is much closer to the colors you’d get from a typical print press, making colors on a Mac match what your final printed product would look like.

Apple’s switch to gamma 2.2 reflects, at least in part, the shift away from print to web and video output. It also means that the default colors on Mac and PC monitors is now nearly identical.

If for some reason you’d prefer to keep the old 1.8 gamma look on your Mac, head to system preferences and click “displays.” Then just create a new color profile and set the gamma to gamma 1.8.

See Also:


Post Comment | Comments | Permalink

Breaking Down the Worst User Experience Myths

By Scott Gilbertson August 27th, 2009 Categories: Visual Design

The design gurus over at Think Vitamin have a great list of the Top Ten of User Experience Myths. Two in particular leaped out at us: the myth that more user preferences is always a good thing, and the myth that design solutions have to be original.

When it comes to preferences, Think Vitamin’s Keith Lang nails it: “every preference which is not really needed is a design choice that I’m offloading to all the users of my product or service.”

If there was one thing we could eradicate from the software world it would be this myth that more preferences equals power user happiness. In fact it’s offering the right preferences that makes all your users happy, regardless their skill level.

The second myth we’d like to see more designers breaking is the myth that everything has to be original. Hopefully this one is a bit more obvious, but if you haven’t figured it out by now, there is a reason that power buttons have similar icons, CMD+C/Ctrl+C always copies text and download buttons usually have an arrow pointing down.

There’s no need to re-invent the wheel to solve every interface problem. Don’t be afraid to borrow or even outright steal ideas that are so common they’ve become part of the universal language of design.

Be sure to read Lang’s whole post as there are quite a few other myths worth remembering.

Photo: Fensterbme/Flickr

See Also:


Post Comment | Comments | Permalink

New JavaScript Library Brings Vector Graphics to the Masses

By Scott Gilbertson August 25th, 2009 Categories: Software & Tools, Visual Design, Web Basics

The use of Scalable Vector Graphics, better known as SVG, has long been a great way to create dynamic graphics on the web — just feed your ever-changing values into an SVG XML file and you’ve got an always up-to-date image. It’s a great tool for displaying dynamic charts, graphics and other data visualizations on the web.

But of course, there are some issue with SVG, namely (what else?) inconsistent support across browsers. Eventually, SVG will likely enjoy native support in all the major browsers. In the mean time, there’s a possible solution on the horizon — the SVG Web JavaScript Library.

SVG Web is a JavaScript library which provides SVG support for most browsers, including Internet Explorer, Firefox, and Safari. Combining the library with the native SVG support in many browsers brings you to a solution that reaches about 95 percent of the web.

That’s pretty good by nearly anyone’s standards, and the demos on the project’s website show off some impressive tools — drag and drop photo editing, a Tetris knock off and more.

The only catch is that the SVG Web project is still in the early alpha stage and has quite a few bugs (several of the examples don’t work with Firefox’s native SVG support, though everything we tried did work with the Flash fallback option).

Still, despite the early alpha status, quite a few big names, including Wikipedia, are either currently using or working on projects that plan to use the SVG Web library. If you’ve been itching to get your SVG graphics on the web, but you’ve been hesitant due to browser compatibility issues, give SVG Web a try. And remember, if you find any bugs, be sure to add them to tracker.

To see what all SVG Web has to offer, check out the short demo video below.


[Hat tip to Simon Willison]

See Also:


Post Comment | Comments | Permalink

Use @font-face Today With Free, Legal Fonts

By Scott Gilbertson August 25th, 2009 Categories: Software & Tools, Visual Design, Web Basics

With the latest versions of Safari, Firefox, Opera and Google Chrome all supporting CSS’s new @font-face rule, you might think web designers everywhere would be rushing to add fancy fonts to their websites. But of course, most aren’t. So why, if designers have been bemoaning the state of typography in the browser since the dawn of the web, hasn’t the recent growth of @font-face support turned things around?

There’s actually another, much more complicated problem with @font-face that stops it from being the panacea for your font woes: licensing.

Unfortunately, the font foundries which create, sell and license fonts have thus far been reluctant to embrace licensing terms that would allow designers to serve fonts via @font-face legally. The foundries fear pirates would be able to steal fonts much more easily if the files were published in the wild on the web.

There are some possible solutions to this, such as third-party middlemen like Typekit. However, involving yet another layer of complexity (and potential failure) to your web stack isn’t anyone’s idea of fun. So what’s a designer to do?

It turns out there are actually some fonts that you use with @font-face today. Font Squirrel, one of our favorite places to find free fonts has an entire section devoted to @font-face compatible fonts.

Two things to keep in mind with Font Squirrel’s list: First, as the site says, “Font Squirrel makes no guarantee that our interpretation of each license is correct,” which means make sure you read it yourself and possibly contact the creator to clarify. And second, some of these fonts are downright ugly.

But not all of them. Designer Francesco Mugnai recently posted a nice roundup of some of the best @font-face candidates from the Font Squirrel collection, including two of our favorites, Museo Sans and Anivers.

Of course, even with legal fonts and decent browser support, @font-face isn’t for every project. However, if you’re sick of Flash solutions like sIFR tired of being limited to only the six fonts found on nearly every PC, Font Squirrel’s list of @font-face compatible free fonts could be the solution you’ve been searching for.

Photo: healthserviceglasses/Flickr

See Also:


Post Comment | Comments | Permalink

Complex Web Layouts Made Easy With New CSS3 ‘Flexible Box Model’

By Scott Gilbertson August 24th, 2009 Categories: Platforms & APIs, Visual Design, Web Basics

While HTML5 has been getting most of the attention lately, CSS 3, the other half of the web developer’s toolkit for next-generation web pages has been progressing as well.

Although the CSS Working Group has taken a fair amount of flack from the development community over the years, despite the Working Group’s lack of transparency and refusal to engage the community, the actual implementers — Apple, Mozilla, Opera and Google — continue to push CSS 3 toward the mainstream.

One of the more interesting aspects of CSS 3 is the new Flexible Box model spec which essentially allows you to define how unused portions of block level elements are handled. Sound confusing? Well, initially it can be. Fortunately, Alex Russell of Dojo fame has put up a nice guide to using the new flexible box model.

Essentially, two new CSS 3 selectors, hbox and vbox, allow you to easily center an element within its parent element. Then, as the spec says, “unused space can be assigned to a particular child or distributed among the children by assignment of ‘flex’ to the children that should expand.” In other words, you can make some child elements flexible and others fixed, which makes for considerably more complex layouts using only a fraction of the code you’d need to do that using pure CSS 2.

One thing to keep in mind: selectors like hbox and vbox are not universally supported yet, so if you need everything to work in IE, this method is off limits. However, hbox and vbox do work in Gecko and Webkit, which means these tricks will work just fine for Safari, Firefox and Chrome. Opera is only progressive browser missing from the list.

As Russell points out in his write-up, while universal support is still a ways away, these techniques could be used in mobile interfaces where Safari and Chrome are prevalent.

See Also:


Post Comment | Comments | Permalink
 
Subscribe now

Special Offer For Webmonkey Users

WIRED magazine:
The first word on how technology is changing our world.

Subscribe for just $10 a year