YUI contributor (and author of the Interval Selection Calendar example) John Peloquin of W. Hardy Interactive has released another excellent option for Calendar implementers: a layered navigation path for selecting years and months. The layered approach provides an alternative to the built-in navigator interface that ships with Calendar.

John describes the inspiration and thought process behind this implementation on his blog, where you’ll also find API documentation and source code.

(I realize this is not a scientific survey. I’m just interested in engaging the wider community in a discussion instead of trying to impose my view or Yahoo!’s view on the community as authoritative.)

Everywhere I go lately, it seems that interaction designers and web developers are talking about accordion widgets and debating about what makes an accordion an accordion. Not everyone working in this field has heard the term (some may simply refer to “stacked panels” or “collapsible panels”) but most get the gist fairly easily. Ironically, none of the UI elements described as accordions share the actual behavior of a real-world accordion (the musical instrument): namely, that stretching an accordion opens all the folds evenly.

Accordions have been an on-and-off topic of discussion on the main IxDA mailing list; we discussed them in our Pattern Library workshop in Vancouver earlier this month, and there’s been an ongoing discussion about accordions on our internal designer mailing list here at Yahoo!.

So I sat down with some folks from the YUI team (and Marco, the maker of an experimental YUI accordion widget) a little while ago to sort through a draft of an accordion pattern that might help inform the development of an official YUI component.

Broadly speaking, most people agree on what we’re talking about when we talk about an accordion interface element. Everyone agrees that accordions are used to compress content into a limited space and that they consist of panels that can collapse or expand. Beyond this, there are a number of subtle nuances that not everyone agrees on.

One trend I’ve noticed is that front-end developers tend be agnostic about how the accordion should work, viewing it as really just a variant on a tree widget. Designers tend to be more prescriptive, saying that to be an accordion it must behave in thus and such a way (but not all designers agree on what these rules are).

In the end, the YUI folks will produce code that can be made to do just about anything. We aren’t going to try to impose our own taste or preferences in design through the functionality of the code itself. However, we will use the associated pattern to make suggestions and recommendations drawn from the experience of the entire design community, and we will probably lobby for default behaviors that match what most people expect.

So, if you’ve got a few minutes and an opinion, please visit the survey and let me know what you think!

I’ll close the survey on April 30.

Version 2.7.0 introduces a new StyleSheet component, graduates three components out of “beta”, improves support for the upcoming release of IE8, includes over 180 bug fixes and enhancements, and ships with more than 300 functional examples.

Introducing StyleSheet

The YUI StyleSheet Utility, developed by YUI engineer Luke Smith, provides a means to optimize the application of a style or changes to existing styles across multiple elements without incurring the cost of a page reflow for each element. Using the benefits of dynamic CSS, the StyleSheet Utility allows the creation of new stylesheets and changes to existing stylesheets that can be applied to multiple elements without the need to loop through the elements in the DOM, thus maintaining an optimal experience for the end user of the page.

Updates to Existing Components

Charts Enhancements

The Charts Control benefits from several new additions in the 2.7.0 release made by Dwight “Tripp” Bridges. Charts can now be specified with rotated axis labels and titles. New series styles have been added which allow more control over the color and alpha settings of lines, borders, and fills for the series markers. A zeroGridline style has been added to be able to draw attention to a chart’s zero gridline when it appears beyond the origin. Several bugs have been addressed in the TimeAxis class, resulting in more accurate majorUnit and minorUnit calculations.

Additions to the Dom Collection

Matt Sweeney has been hard at work in both the 3.x and 2.x code lines of YUI. As an enhancement to 2.7.0, the work done in 3.x on getXY() and setXY() has been integrated into the Dom Collection for this release. The properties height and width are now available in Region; the get() method now supports Element instances; and several new methods have been added for this release, including getComputedStyle(), getElementBy(), setAttribute(), and getAttribute().

Container Changes

The Container family of components has received a couple notable updates from YUI’s own Satyen Desai. Dialog now supports sending post data along with any data mined from the form for “async” post requests. It also provides the Connection object as the first argument to subscribers of the “asyncSubmit” event. Overlay’s “fixedcenter” support has been enhanced with the ability to optionally disable centering on scroll when the window size is not large enough to fully contain the Overlay. The Container README file included in the release contains full details on these items and a full list of changes for 2.7.0.

Updated Treeview

Prolific YUI community member and developer Satyam has contributed a long list of enhancements and bug fixes to YUI’s TreeView Control for this release. Node highlighting and selection has been added, including single and multi-node selection support as well as upward and downward propagation. There have been significant improvements to focus and event handling. The parsing in buildTreeFromMarkup() has been updated to read an HTML attribute called “yuiConfig” which can override any property read from the markup. It assembles an object literal that is then passed to buildTreeFromObject(). Several class names have been added to TreeView in order to make it easier to identify elements in the generated HTML. This is only a small sample of the changes to this component for 2.7.0. Refer to the TreeView README file for the full summary of changes in this release.

Internet Explorer 8 Support

The YUI team has put a great deal of effort into testing the library components with the pre-release versions of the new IE8 browser. There have been several changes made in the library to provide better compatibility with the new browser. Please note, at the time of the 2.7.0 release, IE8 is still a release candidate. Should any significant issues be found when IE8 is officially launched, we will work to post a timely YUI update.

Promotion from Beta Status

The following components have been promoted out of “beta” status in the YUI 2.7.0 release:

• Element
• ProfilerViewer
• Selector

Over 180 Enhancements and Bug Fixes

The information included above describes just a few of the updates in 2.7.0. Refer to the README digest or the individual README files for full details on changes in this release. YUI 2.7.0 also addresses over 180 defect reports and enhancement requests that have been submitted by the development community. A comprehensive change log has been provided for your reference.

Thanks!

The YUI Library has grown in functionality as well as quality as a result of the feedback and suggestions we get from all of you in the community. We hope you will enjoy using the 2.7.0 release of YUI, and we look forward to your continued feedback on the YUI mailing list and forum. Please continue to log any enhancement requests you have for the library as well as defects you run into in your development at our new ticket repositories on YUILibrary.com.

For all of your feedback and support, I extend a big thank you to everyone in the YUI community on behalf of the entire development team: Adam Moore, Dav Glass, Eric Miraglia, Jenny Han Donnelly, Luke Smith, Matt Sweeney, Nate Koechley, Satyen Desai, Thomas Sha, and Todd Kloots; and contributors: Allen Rabinovich, Caridy Patiño, Dwight “Tripp” Bridges, Gopal Venkatesan, Julien Lecomte, Matt Mlinac, Nicholas C. Zakas, Philip Tellis, and Satyam.

This is part 4 in an ongoing series. You can read the other parts here:

• Image Optimization Part 1: The Importance of Images
• Image Optimization Part 2: Selecting the Right File Format
• Image Optimization Part 3: Four Steps to File Size Reduction

In the previous article, the progressive JPEGs were briefly mentioned as a possible option when optimizing JPEGs. This post now diggs into this option a little deeper with the results of an optimization experiment involving over 10,000 images.

Baseline vs. progressive JPEGs

Baseline are the “normal” JPEGs, the type of JPEG that all image programs write by default. The browsers load them top-to-bottom as more of the image information comes down the wire.

Loading a baseline JPEG, click to enlarge

Progressive JPEGs are another type of JPEGs, they are rendered, as the name suggests, progressively. First you see a low quality version of the whole image. Then, as more of the image information arrives over the network, the quality gradually improves.

Loading a progressive JPEG, click to enlarge

From usability perspective, progressive is usually good, because the user gets feedback that something is going on. Also if you’re on a slow connection, progressive JPEG is preferable because you don’t need to wait for the whole image to arrive in order to get an idea if it is what you wanted. If not, you can click away from the page or hit the back button, without waiting for the (potentially large) high quality image.

A reason against progressive JPEGs I’ve heard is that they look a bit old school and that users might be underimpressed, if not irritated, by the progressive rendering. I am not aware of a user study that focuses on this issue, please comment if you have heard or conducted such a experiment.

There is controversial information in blogs and books whether progressive JPEGs are bigger or smaller than the baseline JPEGs in terms of file size. So, as part of the never-ending quest for smaler file sizes and lossless optimization, here is an experiment that attempts to answer this question.

The experiment

One of the many free APIs that Yahoo! provides is the image search API. I used it to find images that match a number of queries, such as “kittens”, “puppies”, “monkeys”, “baby”, “flower”, “sunset”.. 12 queries in total. Once having the image URLs, I downloaded all the images and cleaned up 4xx and 5xx error responses and non-jpegs (turned out sometimes sites host PNGs or even BMPs renamed as .jpg). After the cleanup there were 10360 images to work with, images of all different dimensions and quality, and best of all, real life images from live web sites.

Having the source images, I ran them through jpegtran twice with the following commands:

> jpegtran -copy none -optimize source.jpg result.jpg

and

> jpegtran -copy none -progressive source.jpg result.jpg

The first one optimizes the Huffman tables in the baseline JPEGs (details discussed in the previous article). The second command converts the source JPEGs into progressive ones.

Let’s see what the result file sizes turn out to be.

Results

The Census report, like most such surveys, had cost an awful lot of money and didn’t tell anybody anything they didn’t already know — except that every single person in the Galaxy had 2.4 legs and owned a hyena. Since this was clearly not true the whole thing had eventually to be scrapped.

Douglas Adams — “So Long, and Thanks for All the Fish”

The median JPEG returned in this experiment was 52.07 Kb, which is probably not the most useful statistic. The important thing is that the median saving when using jpegtran to optimize the image losslessly as a baseline JPEG is 9.04% of the original (the median image becomes 47.36 Kb) and when using a progressive JPEG, it’s 11.45% (46.11 Kb median).

So it looks like progressive JPEGs are smaller on average. But that’s only the average, it’s not a hard rule. In fact in more than 15% of the cases (1611 out of the 10360 images) the progressive JPEG versions were bigger. Since it’s difficult to predict when an image will be smaller as progressive by just looking at it (or for automated processing without even looking at it), an idea of how the image will perform based on its dimensions or file size would be really helpful.

Looking for a relationship, I plotted all the results on a graph where:

• Y is the difference in the savings “baseline minus progressive”, so negative numbers will mean cases when baseline is smaller

• X is the file size of the original image

The graph shows how the results are all over the place, but there seems to be a trend — the bigger the image, the better it is to save it as a progressive JPEG.

“Zooming” into the area of smaller file sizes to see where progressive JPEGs get less effective, let’s only consider the images that are 30K and under. Then using the trendline feature of Excel, we can see where the line is drawn (for a clearer trendline mouse over or focus or click the image).

src="http://yuiblog.com/assets/2-progressive-jpeg.png"
id="progressive-jpeg-chart"
alt="Progressive vs baseline JPEG for smaller images"
/>

Summary

The take-home messages after looking at the graphs above:

• when your JPEG image is under 10K, it’s better to be saved as baseline JPEG (estimated 75% chance it will be smaller)
• for files over 10K the progressive JPEG will give you a better compression (in 94% of the cases)

So if your aim is to squeeze every byte (and consitency is not an issue), the best thing to do is to try both baseline and progressive and pick the smaller one.

The other option is have all images smaller than 10K as baseline and the rest as progressive. Or simply use baseline for thumbs, progressive for everything else.

IE and progressive JPEGs

“Oh, not IE again!” is probably what you’re thinking, but it’s not so bad actually. It’s just that IE doesn’t render progresive JPEGs progressively. It displays the image just fine, but only when it arrives completely. So in IE, the baseline JPEGs display more progressively (top-to-bottom is still progress) than the progressive JPEGs.

A word on ImageMagick

ImageMagick is a an impressive set of command-line image tools, which you can also use to optimize files. Unlike most other image software, by default ImageMagick writes optimized baseline JPEGs (as if using the -optimize switch in jpegtran).

ImageMagick can also strip meta data and write progressive JPEGs, so I repeated the experiment outlined above but using ImageMagick instead of jpegtran. The commands used were:

>convert -strip source.jpg result.jpg // baseline JPG
>convert -strip -interlace Plane source.jpg result.jpg // progressive JPEG

Observations from the ImageMagick experiment:

• The baseline vs. progressive trendline is the same: images 10K or bigger are better optimized when using progressive encoding
• The overall compression is better: the median is 10.85% optimization for baseline JPEGs (jpegtran saved 9.04%) and 13.25% for progressive JPEGs (11.45% with jpegtran)
• There is some quality loss. ImageMagick doesn’t perform fully lossless operations. Inspecting random images visually I couldn’t tell any difference but using an image diff utility shows that pixel information in the images has been modified.

And the last set of stats gleaned from the experiment has to do with the speed of writing JPEGs. Here’s how jpegtran and ImageMagick performed while optimizing the 10k+ images on my laptop (Windows XP, 2GHz dual CPU, 500Mb RAM). From fastest to slowest:

1. jpegtran baseline (11 images per second),
2. jpegtran progressive (9 images/s),
3. ImageMagick baseline (7 images/s),
4. ImageMagick progressive (5.5 images/s)

This is part 2 in an ongoing series. You can read the other parts here:

• Image Optimization Part 1: The Importance of Images
• Image Optimization Part 3: Four Steps to File Size Reduction
• Image Optimization Part 4: Progressive JPEG…Hot or Not?

This second installment of the image optimization series talks about file formats and how to chose the right one for the job. We’ll briefly discuss the popular GIF and JPEG formats and then move on to highlighting the rock star, PNG, hopefully helping correct some misconceptions about it.

GIF

GIF is a palette (also called “indexed”) type of image. It contains a palette of indexed colors, up to 256, and for every pixel of the image there is a corresponding color index. The format is no longer subject to patent issues, so you can create GIFs without the risk of going to jail. (For more on the history of the GIF format, click here.)

GIF is a non-lossy format, which means that when you modify the image and save it, you don’t lose quality.

GIF also support animations, which, in the dark Web 1.0 ages, resulted in a plethora of blinking “new” images, rotating @ signs, birds dropping … an email, and other annoyances. In the much more civilized Web 2.0 era, we still have “loading…” animations while we wait for the results of the next Ajax request to update the page, but there are also things like the good old shiny sparkles that people like to put in their social network profiles. Nevertheless, animation support is here if you need it.

GIF also supports transparency, which is a sort of boolean type of transparency. A pixel in a GIF image is either fully transparent or it’s fully opaque.

JPEG

JPEG doesn’t have the 256 colors restriction associated with GIFs; it can contain millions of colors and it has great compression. This makes it suitable for photos and, in fact, most cameras store photos in JPEG format. It’s a lossy format, meaning you lose quality with every edit, so it’s best to store the intermediate results in a different format if you plan to have many edits. There are, however, some operations that can be performed losslessly, such as cropping a part of the image, rotating it or modifying meta information, such as comments stored in the image file.

JPEG doesn’t support transparency.

PNG

PNGs is a non-lossy format that comes in several kinds, but for practical purposes, we can think of PNGs as being of two kinds:

1. PNG8, and
2. truecolor PNGs.

PNG8 is a palette image format, just like GIF, and 8 stands for 8 bits, or 2⁸, or 256, the number of palette entries. The terms “PNG8″, “palette PNG” and “indexed PNG” are used interchangeably.

How does PNG8 compare to GIF?

• Pros:
  • it usually yields a smaller file size
  • it supports alpha (variable) transparency
• Cons:
  • no animation support

The second type of PNGs, truecolor PNGs, can have millions of colors, like JPEG. You can also sometimes come across the names PNG24 or PNG32.

And how does truecolor PNG compare to JPEG? On the pros side, it’s non-lossy and supports alpha transparency, but on the cons side, the file size is bigger. This makes truecolor PNG an ideal format as an intermediate between several edits of a JPEG and also in cases where every pixel matters and the file size doesn’t matter much, such as taking screeenshots for a help manual or some printed material.

Internet Explorer and PNG transparency

We said that both PNG types support alpha transparency, but there are some browser eccentricities that affect both types and about which you should be aware.

With PNG8, whenever you have semi-transparent pixels they appear as fully transparent in IE (version 6 and lower). This is not ideal but it’s still useful and is the same behavior that you get from a GIF. So by using a PNG8, in the worst case (IE < 7) you get the same user experience as with a GIF, while for other browsers (Firefox, Safari, Opera) you get a better experience. Below is an example that illustrates this, note how in IE6 the semi-transparent light around the bulb is missing (source: SitePoint):

For truecolor PNGs, the situation is a much less attractive compromise. All the semi transparent pixels appear grey in IE prior to version 7 (source: W3C).

IE7 introduces proper native support for alpha transparency in both PNG8 and truecolor PNGs. For earlier IE versions you need to fix the truecolor PNG transparency issue using CSS and an AlphaImageLoader filter, which we’ll discuss in more details in a follow-up article. (Spoiler alert: avoid AlphaImageLoader.)

“All we are saying is: Give PiNG a chance!”

Although PNG8 should be the preferred of the PNGs, because it’s smaller in filesize and degrades well in early IEs without special CSS filters, there are still some use cases for truecolor PNGs:

• When the 256 colors of the PNG8 are not enough, you may need a truecolor PNG. This is a case you should try to avoid. On one hand, if you have thousands and thousands of colors, this starts to look like a case where JPEG will be better suited and will give better compression. On the other hand, if the colors are around a thousand or so, you may try to convert this image to a PNG8 and see if it looks acceptable. Very often, the human eye is not sensitive enough to tell the difference between 200 and 1000 colors. That depends on the image, of course; often you can safely remove 1000 colors, but sometimes removing even 2 colors results in an unacceptable image. In any event, try your potential truecolor PNG candidate as PNG8 and as JPEG and see if you like the result in terms of quality and file size.
• When most of the image is semi-transparent. If only a small part of the image is semi-transparent, like around rounded corners, the GIF-like degradation of PNG8 is often OK. But if most of the image is translucent (think a PLAY button over a video thumbnail), you might not have a choice but to use the AlphaImageLoader hack.

At the end, let’s summarize what was discussed in this article highlighting that:

• JPEG is the format for photos.
• GIF is the format for animations.
• PNG8 is the format for everything else — icons, buttons, backgrounds, graphs…you name it.

2.6.0 introduces a new Carousel Control, offers the Paginator Control for general use (it was previously bundled with DataTable), includes more than 450 total fixes, enhancements and optimizations, graduates eight components out of “beta,” and now ships with more than 290 functional examples.

New YUI Controls

The Carousel Control

The YUI Carousel Control, contributed by Gopal Venkatesan (and based on the Carousel originally created by former Yahoo Bill Scott), provides a widget for browsing among a set of like objects arrayed vertically or horizontally in an overloaded page region. Like most YUI controls, Carousel can consume content from page markup using progressive enhancement techniques or be created, configured, and populated entirely via script. It has built-in support for the lazy-loading of content via XMLHttpRequest (aka Ajax) using YUI’s Connection Manager. And be sure to notice that Carousel’s ARIA Plugin example makes it easy to use the WAI-ARIA Roles and States with the Carousel control.

The Paginator Control

The YUI Paginator Control addresses the navigation aspect of chunked content, offering a set of controls that it can render into your UI to allow users to navigate through logical sections of local or remote data. It’s a great tool for managing page load times by reducing the amount of markup or data needed per page. In combination with Connection Manager or DataSource, paging through large sets of server side data is easy and can avoid the need for full page loads.

The simplicity of the getting started example risks hiding Paginator’s power, so be sure to explore the choices for configuring the Paginator. Plus, it’s built on a UI component architecture that allows implementers to easily create custom Paginator controls that will work automatically.

The Paginator Control was introduced with DataTable in version 2.5.0, but it has been broken out as an optional dependency for general use as of version 2.6.0.

Over 450 Improvements

You can view 2.6.0’s comprehensive change log of fixed bugs and concatenated release notes for the entire library, or keep reading for highlights.

TreeView

Prolific YUI contributor (and YUI Community Awards winner) Satyam has given TreeView a significant overhaul with support for progressive enhancement, state retrieval, JSON-base construction, focus, keyboard navigation, and node editing. 2.6.0 should be fully backward-compatible with 2.5.2 and earlier implementations. More details in the upgrade notes for TreeView.

Calendar

Thanks to Satyen Desai, the Calendar Control received significant accessibility improvements in 2.6.0 including the addition of text to the previous-month, next-month, and close icons for improved screen-reader interaction.

Rich Text Editor

Dav Glass added the often requested Undo and Redo capabilities to the Rich Text Editor Control.

Drag & Drop

If you’ve struggled with making Drag & Drop work well over troublesome content such as iFrames, you’ll welcome the introduction of a hidden shim that now makes such traversals effortless.

Uploader

Uploader has been updated to work with Flash Player 10, a sign of our continued commitment to emerging technologies. But because of security changes in the upcoming Flash Player 10, the UI for invoking the “Browse” dialog has to be contained within the Flash player. Because of that, this new version of the Uploader is NOT BACKWARDS COMPATIBLE with the code written to work with the previous version (it is, however, compatible with Flash Player 9). Do not upgrade to this version without carefully reading the documentation and reviewing the new examples.

DataTable

There has been significant work on DataTable in this 2.6.0 release. (See the README for the full manifest.) Amongst the changes, DataTable introduces the ScrollingDataTable and CellEditor classes, the Paginator widget is now offered as a standalone component, and significant changes have been applied to DataTable’s pagination and sorting architectures. While backward compatibility has been maintained whenever possible, the Paginator widget is now an optional dependency, and custom extensions to inline cell editing or server-side pagination and/or sorting will likely need to be updated to be compatible with the new models. Implementers who are upgrading from an earlier version are strongly advised to read the Upgrades Notes.

AutoComplete

As of the 2.6.0 release, AutoComplete has been migrated to use YAHOO.util.DataSource, which is now a new required dependency. The YAHOO.widget.DataSource class, which used to be packaged with the AutoComplete control has been removed. While backward compatibility has been maintained whenever possible, implementers who are upgrading from an earlier version are strongly advised to read the Upgrades Notes to smooth the transition.

Container

The Container family of controls have enhanced positioning, height, and modality support in 2.6.0 via new preventcontextoverlap, context, and autofillheight configuration properties.

Other Notes on 2.6.0

Yahoo! Design Pattern Library

Concurrent with the initial YUI release in February 2006, Yahoo! released the Yahoo! Design Patterns Library. Design Patterns describe an optimal solution to a common problem within a specific context. Today we’re happy to strengthen the relationship between these two sibling libraries by offering YUI code for two existing patterns: The Pagination Design Pattern and the Carousel Design Pattern.

Accessibility Improvements

We’ve continued to work hard to make YUI accessible. The Carousel, Button, Menu, TabView, and Container all have enhanced accessibility support in addition to what’s otherwise noted in this blog post. We continue to count accessibility amongst our highest priorities; stay tuned for a few more blog posts on the topic in the coming days and weeks.

Graduation Day

The following seven YUI components have graduated from beta as of 2.6.0:

• Cookie Utility – with a new removeSub() method and two parsing improvements.
• DataSource Utility – with significant backward-compatible refactoring, see the README.
• Resize Utility – with new support for a useShim config and a series of bug fixes.
• YUI Loader Utility – with better timeout and combo handler support.
• DataTable Control – significant improvements and bug fixes: check the README.
• Layout Manager – with new support for Ajax content retrieval and a series of bug fixes.
• Rich Text Editor – including lots of new custom events and the ability to customize the edit windows better, along with ~40 bug fixes.
• Profiler has been promoted out of beta unchanged.

(Note that the ProfileViewer developer tools, the Element and Selector utilities, and the Carousel and ImageCropper controls remain designated as beta.)

Thanks!

We’re proud of this 2.6.0 release and want to thank the entire community for their contributions, guidance, and continued support. We hope you enjoy all the new power and easy of use reflected in 2.6.0, and we look forward to your feedback in the comments below and on the YUI mailing list.

Thank you again on behalf of the entire development team, Adam Moore, Dav Glass, Eric Miraglia, George Puckett, Jenny Han Donnelly, Luke Smith, Matt Sweeney, Satyen Desai, Thomas Sha, and Todd Kloots; and contributors: Caridy Patiño, Dwight “Tripp” Bridges, Julien Lecomte, Matt Mlinac, Allen Rabinovich, Satyam, Gopal Venkatesan, and Nicholas C. Zakas

Just recently I published a new pattern, Sign-in Continuity, to the Yahoo! Design Pattern Library. It could be filed under “Engagement,” a category we have internally but that hasn’t appeared yet here, but I decided to put it in the “Social” category instead.

The pattern is about making sure that a user’s momentum isn’t robbed when they want to participate in a community and have to be challenged for their login credentials in order to sign their contribution. The crux of the pattern is to preserve context and make sure the user is inconvenienced as minimally as possible so that the continuity of the experience is preserved.

This raises a legitimate question: What’s “social” about sign-in? I have two reasons for classifying this pattern that way.

One is that signing-in is an act of claiming one’s identity in a shared space. Identity is an important social pattern “parent” and we have a number of patterns related to identity in the works.

The other is that social sites have evolved some new engagement patterns (some positive, some negative) having to do with invitation, sharing, organic growth, and levels of involvement, and in this context signing in to participate plays a role.

This was, by the way, what we like to call a “peeve-driven” pattern. I was trying to comment on a social object at Yahoo! site. (I won’t say which one because the problem has since been fixed.) I was challenged to sign in, which was fine, but once I presented my credentials, I was returned to the site’s home page instead of to the comment box I had been working on. Oh noes!

Sometimes, a poor user experience can help us identify an antipattern (in this case, sign-in discontinuity or in the original Latin, participatio interruptus) — and then the antipattern points the way to the positive solution.

I’d also like to mention that my summer intern, Chris Hanrath, completed this pattern and prepared it for publication. Chris also spent a lot of the summer working on the pattern library site redesign that I can’t wait to unveil. Stay tuned!

Background

Although the capabilities of the browser have evolved significantly in recent years, the user’s perception of the browser hasn’t necessarily evolved with it. After the launch of Yahoo! Photos 3.0, I remember a friend of mine emailing me because she was having trouble viewing the large version of her photos. She was repeatedly clicking on each thumbnail without success. Eventually she figured out that she needed to double click on the thumbnails to view the full size image. Double clicking to open a folder or a file is, of course, a natural interaction on the desktop, but for years users were trained not to expect this interaction in the context of web applications.

Some users still don’t expect desktop-like interaction from web applications. I remember logging into my Yahoo! Mail not long ago and seeing checkboxes next to each message. I paused. What were these checkboxes, these artifacts of Web 1.0, doing in my Web 2.0 application? I had been using the new DHTML, Outlook-like version of Yahoo! Mail since its early beta and had become used to dragging and dropping in order to move and delete messages. But the reappearance of these checkboxes was another sign that not every user’s expectations had evolved with the capabilities of the browser.

As the browser has matured it has evolved it into a platform for rich application development, making it possible to deliver applications with a level of interactivity and visual fidelity of those found on the desktop. And while the browser is now a platform, it also continues to play its original Web 1.0 role of an application, a content viewer that enables users to surf all of the news sites, blogs, etc. scattered across the eclectic Web. But as the browser now plays these dual roles of being an application and an application development and delivery platform, how does this duality impact the user in terms of usability and accessibility? And what user-centric features and functionality can consumers expect of a browser, especially one battling with duality? I suspect that Opera’s answer to these questions is that not all users understand the modern browser’s dual role, and that is it necessary to render some fundamental things consistently across experiences within the browser.

Context Menus

Consider context menu functionality. By not implementing the contextmenu event, Opera does not allow frontend engineers to override the
default context menu provided by the browser; all other A-Grade browsers support this feature. What benefit could there be to not implementing the contextmenu event?

If some users perceive everything inside the scope of the browser as a web page, that influences the user’s expectation of what functionality will be surfaced in a context menu. Over the years many users have come to expect that raising a context menu in the scope of a browser will surface browser-centric functionality relative to HTML content (i.e. “Open Link in New Window”), rather than functionality of the web application running within the browser. Therefore, providing a custom context menu for a web application might not be expected or seen as helpful for users who have come to rely on functionality in the browser’s context menu.

The downside is that, by not allowing the developer to provide custom context menu implementations (such as those provided by the YUI Menu Control), Opera is in a small way preventing the user from understanding the browser as a platform for rich application development.

Focus

Focus could be considered as sacred as the context menu. Knowing what element has focus is fundamental to keyboard accessibility. And while most modern browsers support customization of the rendering of focus, is it a good idea to do so? The presentation and behavior is of HTML is now so completely customizable via CSS and JavaScript that the user experience can differ drastically across sites and applications on the web. Keeping something as fundamental as focus consistent means one less thing the user has to re-learn when navigating the across the web. Consider the following example:

Example 1: Anchor Elements (The Good)

	Focused anchor in Opera 9.5 (Mac)
	Focused anchor styled as a button in Opera 9.5 (Mac)

This example illustrates how the focused state of an anchor element is rendered consistently in Opera regardless of how it is styled. This consistency can be considered helpful to the user in that the familiarity of the focus outline conveys the element’s role. Therefore, the user knows what to expect when the element is clicked regardless of how it is styled. However, as illustrated in the following example, this benefit breaks down a little as the focus model for buttons isn’t the same as it is for anchor elements.

Example 2: Buttons (The Bad)

	Focused, unstyled button in Opera 9.5 (Mac)
	Focused, styled button in Opera 9.5 (Mac)

This example illustrates a potential flaw in Opera’s rendering of focus in version 9.5: unlike anchor elements, unstyled and styled buttons get two different renderings of focus, both of which are completely different, and different from the focus style applied to anchor elements. So, in Opera 9.5 there are three different focus implementations for the user to learn: the system default, the Wii-style focus and the dotted border. Compare Opera’s focus implementation to that of Safari or Internet Explorer, where by default focus is rendered consistently across elements of various types.

Opera	Safari	Description
		Focused, unstyled acnhor
		Focused anchor styled as a button
		Focused, unstyled button
		Focused, styled button

Since the default implementation of focus can be customized in other browsers, perhaps Opera users still fair better since learning Opera’s three, fixed focus models is ultimately better than having to learn potentially infinitely more. That said, if Opera is going to prevent customization of focus in the interest of usability and accessibility, they could further improve the user experience by providing a consistent implementation of focus across elements. As it stands in Opera 9.5, the following mixed styles can appear together, presenting a confusing set of visual cues:

Example 3: Mixed types together (The Ugly)

	Focused anchor styled as a button in Opera 9.5 (Mac)
	Focused, styled button in Opera 9.5 (Mac)

As illustrated by the first and second examples, Opera has three different, yet fixed implementations of focus. While Opera’s implementation of focus can be considered good insofar as the user only has a limited number of focus models to learn, it might also be considered bad in that it makes it harder to provide a consistent user experience within a single site or web application. For example, if you wanted to place an anchor and button next to each other in a toolbar, but style them consistently so that they both look like buttons, each would still render focus differently in Opera, leaving the user to wonder how the difference is significant.

Conclusion

In Opera designers and developers lose a degree of customization, but the user gains a slightly more consistent browsing experience. In some ways this consistency benefits the user in that fundamental interactions like focus and context menus remain the same regardless of the site or web application in use. However, by limiting certain types of customization designers and developers will find it just a bit harder to provide a consistent user experience within their site or application and to train the user to expect more from Web 2.0.

Recently, we released a family of related Reputation patterns to the Yahoo Design Pattern Library, the first of several collections of social-design related patterns that we’re working on. These patterns are somewhat different from the typical UI or rich-interaction type of pattern. They don’t tell you how to lay out a page or where to put an interactive widget. Instead, they address how to design a reputation system for your social software.

A key element in the Reputation family of patterns is one we call The Competitive Spectrum:

The Competitive Spectrum is the first pattern you should look at because it asks you to consider the degree of competitiveness in the community you are trying to build or foster. Are you aiming for a highly cooperative community, an arena for death-matches, or something in between? The answer to that question will inform which of the remaining Reputation patterns best apply to the design of your site or application.

The primary author of these patterns (and the creator of the sensitizing images) is Bryce Glass, a senior interaction designer on the Y! OS social team. Product manager Yvonne French deserves some of the credit as well. The patterns were developed for an internal reputation platform here at Yahoo! that was inspired and guided by online community guru Randy Farmer. We’re very pleased to be able to share them with the wider web community now and as always we welcome feedback and suggestions for improvement.

UPDATE: I forgot to mention that Bryce gave a great talk about reputation design at the IA Summit this year: Designing Your Reputation System (in 10 Easy Steps).