Over the past year, I've had the honor of teaching the CSS Basics classes to dozens of AOL designers and programmers. The class takes students from the basics of what makes a Web page through to the fundamentals of the CSS Language and finishing with best practices.

After the class, I get a lot of good feedback and questions from the students, but the most frequently asked question is "What's next?"

Objectively measuring design is critical to a product's success. Usability testing and tracking are powerful tools to evaluate your design with data from real users, and now AOL Designers have another tool at our disposal. With the help of Forrester Research we have created the AOL User Experience Checklist. Building upon the great work of Forrester's original Web Site Review Scorecard, we've added evaluation criteria specific to AOL and our design standards .

Best practices evaluated in the list include messaging to users, navigation and way-finding, visual and architectural hierarchy, and task efficiency.

I am recommending that every product be evaluated once a year at a minimum for a baseline. Then teams may revisit their report and score as improvements are launched.

Please note that a perfect score is exceedingly rare and the goal should be to always be improving the score. If the score is always moving in the right direction then we know our experiences are always improving as well.

AOL folks can find the checklist on our design guide here:
AOL UX Checklist

If you are struggling with CSS in your projects, help is near!

The AOL Design Guide is now your go to place for CSS information, including:

• Recommended Software: a list of software and add-ons with free or have a free trial period.
• CSS Resources: the latest AOL CSS template file to start your project, CSS reference guides, the list of browser safe fonts, and other tools for working with CSS.
• Best Practices: If you have a question about how to get the best code and designs with CSS, check out the Best practices list. This list will answer questions such as when to use inline styles (never) and which is the best color value notation (RGB).

But the page is still growing! We will be adding CSS training materials, the AOL Dev/Design Process for working with CSS, and expanding the best practices list. Stay tuned!

If you have any questions about the best practices, want to suggest software and resources, or have any questions about designing with CSS at AOL, please email me at j.cranfordteague@corp.aol.com

Visit the CSS Best Practices page:
http://designguide.office.aol.com/BestPractices/CSS

Over at InfoQ, they are debating whether it's worth while to support Internet Explorer 6 anymore. The article details several online serivices, vendors, and developmental frameworks that are pulling support, arguing that the browser that once made up 95% of the market share is no longer an online player now that Internet Explorer is on the scene.

On the one hand, deciding not to support IE6 and embracing Web standards can make it easier to create Web sites, expand your design possibilities, and generally allow for a better experience. On the down side, if you do go with a Web standards compliant site and ignore IE6, these sites do not tend to degrade gracefully and many users on the older browser can get frustrated. Any thoughts about what we should do?

This week I'll be at the Voices That matter Conference in Nashville, TN speaking on the topic of Web typography, but I wanted to give everybody at AOL a little preview of the center-piece of my presentation: Web Safe Fonts.

Web typography is pretty much synonymous with limitations. Limited controls, limited styles, but, most importantly, limited font-family choices. The first of these limitations will require changes in the browsers, however, there are a surprisingly large number of fonts to choose from, but only if you are willing to work with a more fluid typography. Most designers are familiar with the 11 "Core Web Fonts" that are industry standards. Primarily, we will use Arial (or Helvetica), Times New Roman (or just Times), and Georgia has become popular in the last few years. You will occasionally see Verdana and Trebuchet MS tried, but these are not the most elegant looking of fonts. We use these fonts because we know that they are pre-installed on most computers. Yet most computers will also have many other fonts pre-installed on them, either by the operating system or by specific applications.

I have created a list of "Web Safe Fonts" showing fonts pre-installed on Windows and Mac as well as fonts installed by iLife on the Mac (which is standard on all Macs) and Microsoft Office for both Mac and PC. Although not all of these fonts will be of general use, it does balloon the list of reliable fonts from 11 to around 200. To make selection easier, I have also indicated which OS the font is pre-installed for, ranked each font on a scale from 1 to 5 (with 1 for fonts almost certain to be installed and 5 for fonts unlikely to be installed), and the source of the font.

Let me know what you think of the list, and if you spot any fonts that should be or should not be in it. The site is in "Beta" while I work on vetting the list and adding functionality (like the ability to sort the list), so any constructive criticism would be most appreciated.

View the Web Safe Fonts >>

I'm going to be setting the new standards for typography on the Web, and I want your help.

A few weeks back, while at the W3C CSS Work Group Face-To-Face meeting in San Diego, I volunteered, to be the advocate for several of the CSS 3 Modules. A while back, the Work Group decided that, rather than trying to release one big document, they would release the CSS 3 specification in smaller modular chunks. As an advocate for parts of the overall CSS 3 specifications, I work to push my chosen modules through from a working draft to a full blown recommendation. It's kind of like taking a bill through the US Congress, only with more transparency. I decided to take on the four issues which I believe will have the most effect on the work we do here at AOL: CSS Basic UI, CSS Hyperlink Presentation, CSS Fonts, and CSS Web Fonts. It's a lot of work, so I'll be concentrating on the Font Modules first.

Oh, hmm... that doesn't look right! Is that dark background #040108, per chance? This is a screenshot from CSS Edit's preview window.

Hello there, I've been invited to write on ControlShift, so I best get to it! My name's Dave Balogh, I've been working here for over 3 years and had the pleasure to work on many of the various channels here. I currently reside on AOL Body, AOL Home, and help out on many of the other AOL Living channels. As AOL has transitioned to the open web, our workflow and process has undergone many of its own transitions. Over the last year I have been taking on CSS duties for my specific channels, with the intent to make our content more solid than ever. This can be seen most prevalently on AOL Home, where I had the opportunity to work tightly with my Art Director, Web Techs, and programming team. What I want to highlight is what my process is, and how it may work for your teams. Read on!

Are you tired of the limited fonts at your disposal as a Web designer? I know I am. But, that changed yesterday when Apple released Safari 3.1 which includes the ability to download common Open Type and True Type fonts to be used in your Web designs without having to install them on the users computer first. Make no mistake, this is the beginning of a revolution in Web design. And I mean an actual revolution-not like the way the word "revolution" is used in TV commercials to make you think you are doing something new when you actually are doing the exact same thing only paying for it-since Apple is openly revolting against the status-quo established by the dominant player in the browser market.

I saw this demoed at the W3C conference last fall, so I wasn't too surprised that Apple could do it, but I am surprised that they are willing to throw down the glove to Microsoft who is opposed to allowing fonts to be used without a strict DRM system in place to not only prevent fonts from being misused either in sites they are not licensed for or stolen by the end user.

CSS has included all of the syntax needed to download fonts for years, the only thing holding typography on the Web back was that the browser makers could not agree on a common font file format to support. Microsoft recently offered to open their proprietary .eot format, but many considered it too little too late. With Safari 3.1, you can now add any True Type (.ttf) or OpenType (.otf) fonts that you have at your disposal.

Ian Hickson, who I sat next to at the W3C CSS Work Group meeting last November in Boston, has just completed work on the next generation browser test Acid3. Now ready for prime time on acidtest.org, the test includes 100 new tests of HTTP, HTML, CSS, ECMAScript (JavaScript), SVG, and XML. Hickson, who is also the primary author of the new HTML5 specification, wrote most of the tests with others coming from the Web design community.

So far, I've tested IE6, Safari 3, and Firefox 2. All of them failed the test spectacularly. I recently reported that the upcoming IE8 passes Acid2, but learned that it only works if the originating server is reconfigured and it is unlikly it will be passing Acid3 anytime soon.

As I mentioned in a previous post, great things are being expected of the next browser to come out of Redmond, Internet Explorer 8. These expectations were heightened when Microsoft reported that alpha versions of IE8 showed the Acid2 Face. Although IE7 was a welcome relief from the debacle that is IE6, it was never able to pass the Acid2 test, which only renders correctly in browsers that fully support standard HTML, CSS, and Javascript features. IE7 just has too many inconsistencies with the standards compliant browsers that require us to kludge together fixes. The Web Standards Project's rigorous Acid2 test is considered a milestone test for browsers that want to claim to be standards compliant. To pass, the browser in question must properly interpret:

• Transparent PNGs
• The object element 
• Absolute, relative and fixed positioning
• Box model
• CSS tables 
• Margins
• Generated content
• CSS parsing
• Paint order
• Line heights
• Hovering effects

If all of these have been implemented properly, then the creator is rewarded with a nice smily face and a great big "Hello World!". Let's hope that this is a portent of better Web design to come.

One of the core tenets of agile development is the formation of smaller teams to execute quickly and at a higher degree of quality. When I first began at AOL four years ago, it would not be uncommon to see meetings with 70 or more individuals (most of them checking email through a 5-hour meeting*). Though I strongly believe we have come far since then I believe there is still a way to go to strip down our teams to the core essentials of output. To be clear, this does not mean staff reduction to achieve this goal. Rather it implies that a given business can cover more ground with the current level of staffing by having more empowered "mini-squads" solving problems in real-time, not bureaucratic-time. Instead of one "uber-team" you could have seven or so sub-teams bringing in deliverables, delighting consumers, and actually more enjoying what they do.

Click "Read More" to find out what this chart is about!

The week before last (5 Nov - 7 Nov) I was fortunate enough to attend the W3C Technical Plenary Meeting and participate in helping define the future of Web design using the CSS standard and learn about the future of the Web from some of the top thinkers in the industry. The first two days I spent with representatives from Google, Adobe, and others as well as reps from the top browser manufacturers including Microsoft, Mozilla, Apple, and Opera. We discussed many different issues that will change the way you--or by the time they are actually implemented in the Web browsers--your children design for the Web.

Over the next few weeks, I'll be giving reports on what happened at the meeting and how what is being decided will affect our profession in the future.

Today, let's talk fonts.

To my mind, there is no more pressing issue for improving Web design than giving designers greater typographic power. Despite the justifiable concern that this great power might be misused, I have little doubt that the quality of Web design will increase once we can get away from the monotony of Times, Arial, and now Georgia as the only fonts we ever seem to see in a Web page. The actual syntax to add fonts to a page has actually been a part of the CSS standard for years. The sticking point is around what font format the browser manufacturers will support. Microsoft and Netscape developed there own formats in the late 1990's but neither supported the others, so no standard emerged. While it may seem like a no-brainer (why not just support the industry standard True Type format), some browser manufacturers are highly concerned with the possibility of the abuse of Intellectual Property (IP). Not only how do we prevent people from stealing fonts from their Web browser (very easy to encrypt) but more importantly how to prevent the use of fonts that a designers does not have the rights to use.

We spent an entire afternoon discussing these issues, with some participants questioning whether our group should even be talking about endorsing a particular format. We don't endorse JPEG or QuickTime or MPEG, so why should we put a stamp a particular font format? Others argued that we might never see Web fonts if the CSS Work Group doesn't get behind and one format that would be interoperable on all browsers. At the end of the day, it will not matter, though, what the W3C decides if the browsers do not support it. So, I turned to the rep for each browser and pointedly asked whether, if the Work Group decided to support True Type fonts, would they support that format in their browser. Mostly the answer was yes, but there was one notable exception that was less than definitive.

The final result of the day was that we voted to have the W3C advisory committee examine the issue and decide whether to endorse a format or not.

So, it sounds like nothing much got done.

BUT... back in reality as the meeting was breaking up, Hakon Wium Lie of Opera (and the most impassioned voice at the meeting for letting the browsers define the font formats they want to support) demoed the most recent beta build of the open source Web kit (which Apple Safari is based on). It had gone ahead and implemented the ability display any True Type font using Web fonts. So, we may have real typography on the Web sooner than we could have hoped for. If the Safari model takes off, and we can easily use fonts on our Web pages, then other browser manufacturers may just have to play along whether they like it or not.

When I published my little article on Boxes and Arrows back in ...June? July? (well, a long time ago anyway), I had no idea folks would still be talking about it in November. I've been interviewed twice in the past few weeks about issues around user's scrolling behaviors--it's been alot of fun!

One was recorded for a Boxes and Arrows podcast and can be heard here: http://www.boxesandarrows.com/view/blasting-the-myth-of16

And the other was for this article written by Terry Heaton of AR&D about the evolution of News as a product and how companies should integrate news into their content strategy: News is a Process, Not a Finished Product


I'm enjoying the debate, so keep those opposing thoughts coming...

I 've arrived in Boston for the W3C Technical Plenary Meeting, making it through Logan airport relatively unscathed. One of the issues that I'm working on at this meeting is trying to push forward Web fonts. Imagine a world where you were not limited to the smattering of fonts available on the Web surfers computer, you could use any font you had at your disposal. Believe it or not, CSS already allows that. So where are all the fonts? Why isn't the Web brimming over with a vast array of typographic styles? The problem isn't the CSS standard. The problem is how we protect the intellectual property of the type-foundries that create the fonts. Technically it would be quite easy to place font files on a server and have the browser's download them. However, this creates 2 problems:

How do you keep the end user from taking the font files?

How do you ensure that the designer using the font has the rights to use it?

As a part of this debate, I took on the assignment of defining what where the designer's needs (requirements), which we will be discussing at the meeting this week. Let me know if you have any further suggestions.

Within this post is a slide that I have been using in my last few presentations to represent the shift in consumer behavior and how it impacts online brand strategy. In the first section you can see the old school "death star" approach where the brand has built a big, impressive and scary website or portal that others will flock to due to its sheer gravitational pull.

The middle schematic shows where we are today: a still-there-but-reduced-in-strategic-importance branded portal surrounded by offshoot sub-brands designed to appeal to factions of the core audience. An example you can experience now is AOL.com > AOL Music > the alternative offshoot spinner.com. The clear benefit is that we can leverage technological platforms yet still have audience pitch-perfect content and voice. The final schematic shows 2-3 years from now, where the portal is an influencer in terms of platform innovation (and still "holds down the fort"), but is not where the majority of time is spent by the consumer. You'll also note that consumers have more self-chosen launch points into the slipstream. For portal design this means that more customization and total web "heat" must be exposed for the site to have value to ever more picky consumers. They have to be able to make it more their own. And, of course, those parts need to be distributable around the web like mini-traffic generators for your core sites.

As brands rush to get integrated into the next hot social networking portal (which, by the way, changes every year), they may be missing a bigger opportunity: the long-tail thousands of smaller micro-sites that permeate the web and are under the radar of larger brands. Custom targeting of distributed content and functionality from your site becomes more and more critical.

Part of the answer: create more open services and provide incentives to web developers and designers to leverage tools and access to your platforms. In other words AOL needs to help "power" the Web, not simply itself. Google and YouTube really nailed it here. So as we go gaga over Facebook (well deserved and relevant to integrate within), we have to remember there is not ONE PLACE you need to be. Brands will need to be in HUNDREDS or MILLIONS of places to succeed in the future!