Monday, September 27, 2010

Web Typography

Web typography, the use of fonts on the web. Sounds simple enough. You design your web site, choose a font, and write the HTML & CSS code for your site and it looks good. However, it is not this easy. To be able to use a font in a browser, the font has to be available to browser, either native to the browser or be imported from another site. This is where it can get tricky. CSS has a @font-face tag and a URL link to the fonts you can use to pull in fonts to be used. Sounds like a plan that will work. But as Lee Corso says, "not so fast my friend".

First, to use a font on the web it has to be licensed to be used on the web, and not too many fonts are licensed for web use. If you use a font you purchased that is not licensed for the web you may be violating your end user licensing agreement with the font foundry (this is no small consequence). Second, not all browsers support the @font-face tag for all types of fonts. I don't really understand why the decision would be made to deploy a browser with less functionality (or stated another way, a competitive advantage) than a competitor's browser but there is a major player that did just that.

Why, you might wonder, is this lack of consistency even a factor to be considered? It occurs because there are no established standards regarding the licensing of fonts to be used on the web. The font foundries are close to having a set of standards that will protect their interests while allowing web designers to use fonts that are licensed for the web. Also, the W3C is working on a web font standard.

Don't despair, there is a solution to this problem, a middleman. This middleman is really a company that does all the heavy lifting with regard to negotiating the licensing agreements and technological issues for fonts. You pay a monthly fee to the company that pays for covering the license for the font as well as hosting the fonts. The good news is these fonts will work on any browser. The bad news is that not all fonts are available even to these middleman companies. But it is a start and for that we are grateful.

Thursday, September 9, 2010

Why Use Web Standards?

Do you want your web site to look good and work well with all browsers? Of course you do. Then web standards are important to you. Back in the olden days, well the late 1990s when the web was in its toddlerhood, most every browser used a different proprietary web format. This was not a great practice but it was not frowned upon because everyone was just learning about the Internet and individuality and independence was the norm. However, as more and more people began using the web it created the need for more and more web developers. Likewise, new browsers were developed, some merged, and some disappeared all together. All these changes created a sort of rat’s nest of web formats.

Multiple web formats makes web development complicated which always increases the costs associated with the initial development because multiple versions of the same site must be developed. However, the increase in costs is not limited to the initial development because over the life time of the site multiple formats must also be supported and maintained. You might think this is crazy talk and to control costs you can support one or two web formats, but do you choose which ones to support and which ones to ignore. I don’t know if you realize this, but by choosing to ignore certain formats you are by default choosing to ignore the web users whose browser is using that format. Can you afford to ignore potential customers or users? I didn’t think so.

There is an easy way to avoid having to choose what web formats to support or not support, and it is a simple decision, use the standard web format put form by the Web Standards Project. The web standards that were developed (and continue to be developed) in the WaSP ensures going forward that by using these coding standards a web site will work with any web browser. You won’t have to make the choice of what to support or not support. You put lots of time, energy, and money into coding your web site and you want it to be attractive and user friendly and available to everyone. By using these web standards when you code you won’t have to worry about browsers, you just have to worry about almost everything else.

Wednesday, September 1, 2010

The Art (?) of Information Architecture



Information Architecture (the short definition) is: analyzing, organizing, and structuring information on websites so the average user can easily find what s/he is looking for. A simple enough idea but is it simple (read easy) to do?

The Information Architect (IA, for short) has to strike a balance between what the owner of the web site wants (requirements), the content of the site (what to keep from an existing site and what to replace), and what the user wants and/or needs. It is like someone juggling, too much of one will impact the others, it may be in a good way or maybe not so good. This is where the "Art" (the skill and creativity needed for an endeavor) part of IA comes into the mix.

A fairly common thing to find when dissecting a web site is the design of an organization's web site mimics the organizational structure of the entity. This usually happens because the Information Architect follows the existing flow or structure of the organization. However, does the site user know (or care) that the Company's financial information is gathered and managed unders the direction of the VP of Customer Service and will be located under the Customer Service tab on the web site because this is the way the reporting structure is organized? I doubt the user will care, all she wants to do is land on the web site home page and with one or two mouse clicks find what she is looking for. Here the "Art" is being used to balance the company needs with the user needs.
Thinking about our user in the above paragraph, what does the Information Architect have to do to make the user experience a good one so hopefully, she will return again and again to our web site? The IA has to be able to figure out how the end user thinks and then use this information to structure the web site so that it is intuitive for the user to move around and through the site.
Try using these 8 steps the next time you are asked to build an Information Architecture.
  1. Understand the web site (system) requirements
  2. Talk to the end users of the existing site, or if there is no existing site, conduct interviews of potential and/or targeted users
  3. Develop a draft architecture and get client feedback on the proposed architecture.
  4. Understand that this is an iterative process, you won't get it right the first time around
  5. Eventhough this won't be the final architecture design, document, document and document some more
  6. Develop persona(s) and define what tasks these persona(s) will do when using the site (storyboarding)
  7. Have the project team review the storyboards
  8. Create detailed page layouts to support the storyboards (this also provides valuable information for the web designers and developers
Bottom line, effective information architecture should provide the means for users to quickly and easily find what they are looking for on a web site.