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

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!

AOL's content has gotten very cloudy over the past year. And I'm not talking about the outlook of our pundits. I'm talking about the increased usage of "clouds" to represent data on our content pages. Commonly referred to as 'tag clouds', they are the data pattern that allows for data to be viewed in different ways, typically by order and magnitude. Wikipedia has a more detailed explanation of the pattern in case you care.

Unfortunately our implementations lack consistency in the way that we convey both order and magnitude, sometimes resulting in hard to comprehend displays and inefficient reuse of implementations. Let's take a look at some real examples to convey the absence of best practices in our designs and then we can talk about the three design principles needed in any cloud.

In case you didn't know, The World Wide Web Consortium (W3C) is the organization responsible for coming up with the standards that guide how Web browsers display your designs. Generally, this means creating and maintaining some kind of computer language such as HTML, XML, and (my personal favorite) CSS. CSS, is of course, the language we use to describe what are designs should look like in a Web browser. As with all endeavors where people from a variety of disciplines, backgrounds, jobs, and positions come together to agree on something, coming up with these standards is not always pretty process.

As a member of the W3C CSS Work Group, I am privileged to be able to see the inner workings of how the sausage of Cascading Style Sheets is being made. However, while the rest of the work group are all committed and knowledgeable individuals, only a few of them have design backgrounds and so often do not know what issues a work-a-day web designer runs into. So, I'm asking you to help me identify some of the deficiencies, inadequacies, and missing pieces of CSS.

In a few weeks, I'll be heading to Boston for the Annual W3C Technical Plenary Meeting, where I'll meet face-to-face with other members of the CSS Work Group to talk about the future of Web design.

In the comments section of this post, I'd like you to give me some of your best ideas. Tell me what you would like to be able to do with your Web designs in the future, that you can't do now because of the limits of the medium. What do you need? What is too hard? What frustrates you? What have you had to find a kludge for to get the desired results? Let me know. Don't worry about using the right technical language or trying to make it look like CSS. Just tell me what you need. And if someone else posts something you like (or dislike), feel free to second it, add to it or argue with it.

I'll take the best of these ideas to Boston with me, and bring the voices of working designers to guide the technologies that shape our craft.

Let me get things started: