Blog: Archive for January, 2008

Birthday Party! Celebrate the 2nd Birthday of the YUI Library and Yahoo Pattern Library February 26 at Yahoo

Visit the event registration page on Upcoming to sign up for the YUI and Yahoo Pattern Libraries 2nd annual birthday event.

In February 2008, the YUI Library and the Yahoo Pattern Library turn two years old.

In those short two years, YUI has grown into a richly featured library that embodies some of the best of what HTML, CSS and JavaScript make possible in the browser. With a light, fast core, YUI empowers you to build your own solutions that support all A-Grade Browsers. And when you want to pull additional functionality off the shelf, YUI is there for you with more than 30 a la carte components that range in complexity from a simple JSON Utility to the powerful DataTable, Menu and Rich Text Editor. When big established brands like CBS Marketwatch, Southwest Airlines, Northwest Airlines, IndyCar.com, and others join Yahoo in implementing YUI, you know you’ve got a library with traction, momentum, and critical mass. And when you see young companies like Gaia Online, Mint, and OurStory building the future of their business with YUI at the foundation, you know what motivates us to keep improving the library every day.

The Yahoo Pattern Library is the outgrowth of a long history of work at Yahoo and elsewhere. Bill Scott, now at NetFlix, took the Pattern Library “open” alongside YUI back in 2005, and it’s now under the stewardship of Christian Crumlish. But the library really draws from the creativity, inspiration, and effort of the full community of user-experience specialists at Yahoo, as well as from those of you in the community who work with Christian to improve upon and iterate the patterns. Christian is hard at work burnishing the existing patterns and creating new ones, and 2008 looks like another great year for this resource.

Celebrate!

We’d like to invite the Yahoo Pattern Library and YUI Library communities to Yahoo for a modest birthday celebration on February 26, 2008, beginning at 5 p.m. on the main Yahoo campus in Sunnyvale. We’ve opened up registration for 150 guests on Upcoming, and signups will be on a first-come first-served basis. Registration is required due to limited space in our venue, so please sign up right away if you want to reserve yourself a spot.

Christian will give a short talk on the YPattern Library at 5:30 and the YUI Team will be updating you on plans for the coming year after that. Beer and some food will be served, and we’re looking forward to a mellow evening with lots of opportunities to mingle, share ideas, and hear what you all are up to.

By Eric MiragliaJanuary 24th, 2008

Empty Links and Screen Readers

About the Author: Mike Davies is a web developer for Yahoo! Europe focusing on web accessibility. He was the Technical Lead Developer of a website redesign which became a PAS 78 case study into the business benefits of accessible websites. Mike writes about web accessibility, Atom and web standards on his personal blog at isolani.co.uk. (Photograph courtesy of Neil Crosby)

With the help of other members of the Yahoo! Accessibility Stakeholders group, I ran a screen reader test to establish whether links that contain no link text were an accessibility barrier. We tested a number of approaches to hiding links across a typical range of screen reader and browsers.

The conclusion is that the most accessible link is one that contains link text. Different techniques of hiding links, from no link text, through to hiding by CSS can cause an accessibility barrier to screen reader users. Each screen reader presented its user with a different set of problems and barriers.

What follows is a detail description of the test, tabulated results, summary of techniques that passed, failed or came close, and a list of web development recommendations.

The Microformats include pattern

The Microformats group have created an include pattern which is a mechanism for including a portion of data from one area of a page into another area on the same page. Essentially, it’s a means of preventing the duplication of data.

A good example of this is a page that lists all the reviews done by one person. Instead of every review having to duplicate the reviewer details, we can use the include pattern to define the reviewer once, and include it into each review. No needless duplication.

The main technique being advocated as an include is the humble link, but in an effort to minimise duplication of content, the example is an empty link; a link with no link text:


<a class="include" href="#author" title="James Levine"></a>

The current accessibility understanding is that empty links can present a barrier to screen reader users. The Microformats group have attempted to solve this problem by using the title attribute to offer something a screen reader can use to announce a link.

The issue here is to find a way of marking up a microformat include pattern that’s accessible to screen reader users.

Test cases

I produced 18 test cases covering a wide range of techniques to hide a link from being displayed. These tests covered:

  • Normal links with proper link text
  • Links with no link text or title attribute
  • Links with a title, but no link text
  • Links containing just whitespace for text

Each type of link was styled in the following ways:

  • Displayed in a default manner
  • Positioned off-screen
  • Visibility of hidden
  • Display set to none

The tests were carried out by three screen reader users. Two of them are super-users of screen readers, so consequently have a great deal of experience and knowledge that can allow them to work around many difficult accessibility issues. Interestingly, neither of them had their main screen reader set up to read out both the link text and the title. Both of them have multiple screen readers installed. The third tester was a web developer with a deep understanding of using screen readers.

Ideally, we’d need more screen reader users to create a decent sample, including non-power users, but the results we saw are fairly consistent.

Success criteria

There are two screen reader behaviours that form a successful test case. The first was that a link was read out normally, as if it were an inline link within a paragraph of text. The second successful behaviour was that the screen reader does not announce the presence of a link and just skips over it.

The test results

We covered four major screen reader versions over three different browsers. The results for each combination can be seen in the following table. The result cells are colour coded to quickly highlight techniques that are safe to use:

  • Red-coloured cells indicates buggy behaviour or the output was likely to frustrate the screen reader user.
  • Amber-coloured cells indicate that the technique did work, but relies on stylesheets to hide the link from screen readers.
  • Light green-coloured cells indicate the technique did work, but relies on particular configurations of a screen reader.
  • Green-coloured cells indicate that the technique did work, and did not rely on stylesheets or a particular screen reader configuration.

All the information conveyed in colour is also available in the table footnotes and the notes below.

Tables for each browser combination

Link results for JAWS 8.0 and JAWS 7.10 with Internet Explorer 64
type of link default offscreen visibility: hidden display: none
Normal text text nothing nothing
empty href href href nothing
empty with title title title href nothing
whitespace href href href nothing
whitespace with title title title href nothing
Link results for JAWS 8.0 and Firefox 2
type of link default offscreen visibility: hidden display: none
Normal text text nothing nothing
empty absolute href absolute href absolute href nothing
empty with title title title absolute href, title nothing
whitespace href buggy1 absolute href nothing
whitespace with title title buggy1 absolute href, title nothing
Link results for JAWS 9.0 with Internet Explorer 6
type of link default offscreen visibility: hidden display: none
Normal text text nothing nothing
empty href href nothing nothing
empty with title title title nothing nothing
whitespace nothing2 nothing2 nothing nothing
whitespace with title title title nothing nothing
Link results for Window-Eyes 6.1 with Internet Explorer 6
type of link default offscreen visibility: hidden display: none
Normal text text nothing nothing
empty href href nothing href
empty with title title title nothing nothing
whitespace nothing2 href nothing nothing
whitespace with title nothing2 nothing2 nothing nothing
Link results for Window-Eyes 6.1 with Internet Explorer 7
type of link default offscreen visibility: hidden display: none
Normal text text nothing nothing
empty "empty", href3 "empty", href3 nothing "empty", href3
empty with title title title nothing nothing
whitespace nothing2 nothing2 nothing nothing
whitespace with title nothing2 nothing2 nothing nothing

Footnotes to the tables

  • 1.
    buggy

    means the screen reader reacted as if there were two separate links instead of just an empty link.

  • 2.
    nothing

    means that the screen reader announces there's a link, but there's no link text read out.

  • 3.
    "empty", href

    means the screen reader reads out the word "empty" followed by the contents of the href attribute

  • 4. In JAWS 8.0 with Internet Explorer when a list of links was displayed, the links could not be reordered alphabetically. We tried both a different page, and with JAWS 7.10, and that worked fine. Empty links breaks JAWS 8.10 ability to sort links when listed.

Test case failures (code red)

The following is a list of failures and buggy behaviour:

  • An empty linked styled with display none caused the href attribute of the link to be read out in Window Eyes 6.1
  • An empty link styled to visibility: hidden caused the href attribute to be read out in JAWS 7.10 and JAWS 8.0 in Internet Explorer and Firefox 2. With Firefox, JAWS 8.0 read out the absolute URL of the link.
  • An empty link regardless of styling (apart from display: none) caused the href attribute to be read out in JAWS 7.10 and JAWS 8.0 on both Internet Explorer and Firefox. Again, JAWS 8.0 with Firefox read out the absolute URL of the link.
  • A link containing whitespace as link text caused the href attribute to be read out in JAWS 7.10 and JAWS 8.0 in Internet Explorer and Firefox.
  • With JAWS 8.0 and Firefox we saw a buggy behaviour where a link containing just whitespace as link text was actually read out as two separate links.
  • With Window Eyes 6.1 and Internet Explorer 6 we saw buggy behaviour where a link containing just whitespace and a title attribute, but styled to appear offscreen, the href attribute was read out even though there was a title attribute present.

Test cases relying on stylesheets (code amber)

All of the test cases that relied either on the display or visibility styles to hide the link from the screen reader did succeed (except for the failures noted above, for example the handling of visibility is exceptionally buggy in JAWS).

When CSS is not enabled, or the styles are ignored by the screen reader, the behaviour falls back to the default case.

Test cases relying on screen reader configuration (code light green)

Test cases using the title attribute worked when the screen reader was configured to read out title attributes. Both our experienced screen reader users had changed their screen reader configuration to read out titles on links when there was no actual link text. Unfortunately, this is not sufficient to conclude that this is a majority preference.

Thus, techniques using the title attribute are reliant on a specific screen reader configuration to work as expected. This configuration cannot be assured, and cannot be relied on.

Test cases designed to hide the link from a screen reader by not supplying any link text fail when the screen reader configuration is set to announce links. Announcing links gets the screen reader to preface all link text with the word 'Link'. Empty links that successfully dodge screen reader heuristics and produce no link text still run into the frustrating problem of a link being announced, but no text associated with that link.

Passed test cases (code green)

Only two of the eighteen test cases resulted in an unqualified pass:

  • A normal text link with default styling
  • A normal text link displayed offscreen. (Links displayed offscreen are still announced by the screen reader)

Conclusion

Not using proper link text forces the browser and screen reader to fallback to heuristics in an attempt to determine what the link text should be. Internet Explorer decides to offer the title attribute, and failing that, it tries to extract something readable from the href attribute. JAWS 8 with Firefox 2 on the other hand reads out the absolute URL of the page, followed by, if available, the title attribute; or if the title attribute is not available, it extracts something readable from the href attribute.

There are breakages in JAWS 8.0/IE6 and Windows Eyes with IE6, when the link text is empty. We observed that a screen reader user could not alphabetically sort a list of links in JAWS 8.0, and so this creates a barrier to quickly finding a link, a barrier that wasn't there before, and it's the markup that provokes/uncovers this bug.

Windows Eyes also has problems with empty text links, falling back to reading out the href attribute, and uniquely reads out the link href when the link is styled with display: none.

An empty link with a title attribute, styled with display: none looks to be a feasible option, but flounders because of two ungrounded assumptions:

  • CSS will always be enabled on browsers communicating with screen readers
  • The title attribute is configured to be read out by screen readers.

Neither of these assumptions realistically hold, nor can be relied on.

Web Developer Recommendations

  • Always have proper link text for a link, and assure that the link text makes sense in context. At that point the link can then be hidden by positioning it offscreen. If the link is styled with display set to none, ensure that the content makes sense with and without the link text in place.
  • Never have an anchor with jusst an href attribute. The screen reader fallback is to read out the entire URL or try to extrapolate something readable from it, or a combination of both. This can lead to unpredictable results. How a browser or screen reader translates a URL into text that is read out requires more extensive testing.
  • Never use visibility: hidden to hide an empty link from view. This leads to the title attribute being ignored in both JAWS/IE6 set-ups, and the absolute URL of the link being read out with Firefox. It also introduces a dependency on CSS to prevent an accessibility barrier.
  • Never use just white space as the link text, the choice of link text between the setups tested differ significantly, with all combinations creating an accessibility barrier - either of reading an entire absolute URL, or guessing the link text based on URL extrapolation, or as in Window Eyes announcing a link, but with no link text read out.
  • Never use display: none as a means of hiding this link. This creates a dependency on CSS, since the rendering of the page in screen readers is degraded.
  • Never rely on the title attribute as the sole means of providing a form of link text since it's inconclusive whether title attributes are enabled for all screen reader users.

Resources

  • Test cases: The 18 test cases that we used for this experiment. This will allow interested parties to re-run these tests and confirm the findings.

Thank you to Artur Ortega and Victor Tsaran (both of the Yahoo! Accessibility Stakeholders Group) for volunteering time to run these test cases and talk through the issues they encountered - that process was enlightening and informative. Thanks to Ben Hawkes Lewis for his insight and guidance on screen reader usage, also for volunteering to run these tests through his screen readers, and his support of running this experiment. Finally, thanks to Ben Ward for taking the initiative to understand and resolve the accessibility implications of certain markup techniques, and for providing me with an interesting problem to tackle.

By Mike DaviesJanuary 23rd, 2008

In the Wild for January 18

Here are some of the stories and happenings that have caught our eye since the last “In the Wild” post:

  • YUI’s Nate Koechley on the TWiT Podcast: Over on the TWiT network’s “Free and Libre Open Source Software” (FLOSS) podcast, Randal Schwartz and Leo Laporte had YUI’s Nate Koechley on as a guest to talk about YUI. It’s a great interview — astute questions and observations from the hosts, and of course Nate has been on the front lines talking about YUI since its inception.
    Nate Koechley with Randal Schwartz and Leo Laporte on the FLOSS podcast
  • Final version of YUI-Based Lightbox on The Code Central: Cuong Tham’s Lightbox goes final; according to Cuong, “The most significant change in this version of the lightbox is that image thumbnails are no longer required for creating lightbox instance. That implies that you can create an image gallery without the presence of image thumbnails. The more exciting aspect of this new feature is that you can virtually grab any image from the internet and include it in your gallery.” Lots of positive feedback on his blog, where you’ll find download links and demo pages.
  • YUI-based Loading Panel Widget: Cuong pours it on with another YUI adaptation, in this case a Loading Panel Widget. As always, he has it fully documented with all the code you need to get started.
    Cuong Tham's Loading Panel Widget on the Code Central Blog.
  • vBulletin 3.7 adds further YUI integration: If you’re a vBulletin user, the 3.7 release from late last year brings in fuller YUI integration and adds the ability to switch between local and Yahoo-hosted YUI files. Letting Yahoo host your YUI files can save you bandwidth and improve performance, so it’s great to see the vBulletin team exposing that as a simple configuration.
  • The MIT Timeline Mashup.MIT Timelines Mashup: Yahoo engineer Wally Punsapy put together this exploration of a rich timeline mashup and it’s currently an Editor’s Pick in the YUI section of Yahoo! Gallery. It’s more of a concept piece than a finished app, but it’s suggestive of the new breed of interactives that are maturing around APIs from companies like Flickr, Blogger, Youtube, Yahoo, Google and others.
  • YUI CSS on Rails: John Munsch makes the case that Rails’ tight integration with Prototype is no reason not to use YUI CSS on your Rails app.
  • Review of AutoComplete Widgets: I’ve long argued that AutoComplete is one of the most important client-side interactions to support in a JavaScript CSS library, so I was excited to see this article on Developer.com covering the implementation of AutoComplete in several libraries (including YUI). To ramp up on the YUI implementation, check out Jenny Han Donnelly’s User’s Guide and examples for YUI AutoComplete.
  • Simple “show/hide” toggle with YUI: Lustr.nl has a nice codesnippet for a YUI-based show/hide toggle. From their post, “Within applications / websites you want to show and hide elements based on mouse clicks. Instead of defining each ‘toggle’ seperately you can use this toggle function. By adding a ‘rel’ attribute to a link you can define a toggle action. This toggle function also offers animation as an extra.”
  • Qollage.com beta released: Online collage-creation site Qollage.com opened up a beta recently and there are numerous sample collages to explore. Qollage takes an aggressive approach to using rich interactions, with a dozen different YUI components included on the page.
    The Qollage.com login screen, using YUI Dialog.
  • Notes on using onDOMReady: Michael James offers some useful notes about the use of onDOMReady (implemented in YUI and elsewhere) — and especially about some things to think about when use of onDOMReady fails at first blush to protect you from the dreaded “operation aborted” error in IE. (If you’re not familiar with onDOMReady, the tutorial text on this onDOMReady example might be of interest.)
By Eric MiragliaJanuary 18th, 2008

Automatic conversion from simple, accessible data tables to YUI Charts

About the Author: Christian Heilmann is the author of Beginning JavaScript with DOM Scripting and Ajax. He has worked in web development for almost 9 years for several agencies and .coms and is currently a lead developer at Yahoo! in England. Christian is a frequent speaker on the conference circuit in the UK and Europe; you can find some of his writing here on YUIBlog as well as on his personal blog at http://wait-till-i.com.

Charts are a great idea to make rows and rows of boring numbers easier to understand and to take in — for people that can see them. However, not all of your site’s visitors can see and you’ll also want to keep information you offer available for search engines. There are a lot of libraries on the web that allow you to create charts, but not many take this use case into consideration.

In praise of data tables

This is where data tables come into play. (Note: For the purposes of this article, I’m referring to pure HTML tables — not to rich UI controls like Jenny Han Donnelly’s YUI DataTable Control.) They are the perfect data construct in HTML as they are available both for people that can see and those who can’t. Assistive technologies like screen readers offer a way to navigate tables and to read their information row-by-row and cell-by-cell. All you need to do to please everyone is to use the correct markup (including a few attributes you might not have used yet):

<table summary="Results of a survey of which animals people would like to see more on YDN">
  <caption>What animals would you like to see more?</caption>
  <thead>
    <tr>
      <th scope="col">Animal</th>
      <th scope="col">Requests</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Kittens</td>
      <td>45331</td>
    </tr>
    <tr>
      <td>Puppies</td>
      <td>32323</td>
    </tr>
    <tr>
      <td>Elephants</td>
      <td>12345</td>
    </tr>
    <tr>
      <td>Badgers</td>
      <td>6546</td>
    </tr>
    <tr>
      <td>Sharks (without lasers)</td>
      <td>223</td>
    </tr>
    <tr>
      <td>Sharks (with lasers)</td>
      <td>2323</td>
    </tr>
  </tbody>
</table>

The summary attribute tells assistive technology what this table is about and the caption shows up for all users. The th elements define what cells are headers and the scope attribute applies them to all the data cells they are connected to. In this case it means that “animal” gets read out before each animal and “requests” before each number. This means that even a visitor who cannot see will still know in row five what the information is about. All in all the table renders as:

What animals would you like to see more?
Animal Requests
Kittens 45331
Puppies 32323
Elephants 12345
Badgers 6546
Sharks (without lasers) 223
Sharks (with lasers) 2323

Easy to understand, but not too pretty. And it can get boring. How about we use this information and create a tasty pie chart like the following (click on the image below to see the working example in action)?

The accessible table enhanced with a pie chart (image; click through to see working example)

Using table data to automatically generate charts

In order to have the table be preceeded by a pie chart like this all you need is to add two scripts at the end of the document body and a class called yui-table to the table itself. For example:

<table class="yui-table" summary="Results of a survey of what browser people love">
  <caption>What browser do you love?</caption>
  <thead>
    <tr>
      <th scope="col">Browser</th>
      <th scope="col">Lovers</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>MSIE</td>
      <td>221</td>
    </tr>
    <tr>
      <td>Firefox</td>
      <td>516</td>
    </tr>
    <tr>
      <td>Opera</td>
      <td>312</td>
    </tr>
    <tr>
      <td>Safari</td>
      <td>100</td>
    </tr>
    <tr>
      <td>Omniweb</td>
      <td>30</td>
    </tr>
    <tr>
      <td>Lynx</td>
      <td>4</td>
    </tr>
  </tbody>
</table>
<script src="http://yui.yahooapis.com/2.4.1/build/yuiloader/yuiloader-beta-min.js"></script>
<script src="tablestoyuicharts.js"></script>

This will show in a browser with the latest Flash plugin like this:

The accessible table enhanced with a pie chart (image; click through to see working example)

You can define the size of the chart in CSS by defining a width and height for each div element with a class of yuichartfromtable:

div.yuichartfromtable{
  width:300px;
  height:300px;
  margin:0 auto;
}

As for the scripts: the first script is the YUI Loader Utility which allows you to pull in YUI components on-demand. This is great, as you don’t need to add lots and lots of script elements but let the YUI Loader figure out what it needs. You can download the second script here; if you care to know what is going on with it, check the following section. If you just want to use the script, then you’re done :-).

How does this work?

The script to turn all tables with the class yui-table into charts is quite short, as it uses the newer YUI components that take a lot of the heavy lifting off you, especially the table-to-dataset conversion which is done by the YUI DataSource Utility. The full script is this:


var tablestoYUIchartsplease = new YAHOO.util.YUILoader({
  require: ['charts'],
  onSuccess: function(){
    var tables = YAHOO.util.Dom.getElementsByClassName('yui-table','table');
    YAHOO.util.Dom.batch(tables,function(o){
      var chartcontainer = document.createElement('div');
      YAHOO.util.Dom.addClass(chartcontainer,'yuichartfromtable');
      YAHOO.util.Dom.insertBefore(chartcontainer,o);
      var data = new YAHOO.util.DataSource(o);
      data.responseType = YAHOO.util.DataSource.TYPE_HTMLTABLE;
      data.responseSchema = {fields:['response','count']};
      YAHOO.widget.Chart.SWFURL = 'http://developer.yahoo.com/yui/build/charts/assets/charts.swf?_yuiversion=2.4.1';
      var chart = new YAHOO.widget.PieChart(chartcontainer,data,{
        categoryField:'response',
        dataField:'count',
        expressInstall:'http://developer.yahoo.com/yui/build/charts/assets/expressinstall.swf'
      });
    });
  }
});
if(document.location.toString().indexOf('http')!==-1){
  tablestoYUIchartsplease.insert();
}

Let’s chunk it up and see what each section does:

var tablestoYUIchartsplease = new YAHOO.util.YUILoader({
  require: ['charts'],
  onSuccess: function(){

First up, we let the YUI Loader do its magic: We instantiate a new loader, tell it we need the YUI Charts Control and wait for the different script nodes to be generated and the components to be loaded before we continue. The loader tells us all is OK by firing the onSuccess event, which we use to execute an anonymous function that does all the other work.

    var tables = YAHOO.util.Dom.getElementsByClassName('yui-table','table');
    YAHOO.util.Dom.batch(tables,function(o){

We use the YUI Dom Collection to get all tables with the correct class and apply a function to each of these tables using the batch method. The method sends the current table as the parameter o to this function.

      var chartcontainer = document.createElement('div');
      YAHOO.util.Dom.addClass(chartcontainer,'yuichartfromtable');
      YAHOO.util.Dom.insertBefore(chartcontainer,o);

We create a new div element, give it a class of yuichartfromtable (to allow for styling) and insert the new element into the document before the table.

      var data = new YAHOO.util.DataSource(o);
      data.responseType = YAHOO.util.DataSource.TYPE_HTMLTABLE;
      data.responseSchema = {fields:['response','count']};

Then we allow the rather new YUI DataSource Utility to flex its binary muscles. While this is meant to wade through external data sources and JavaScript arrays for you, it also allows for a responseType of HTML table, which means it converts a table to a JavaScript object you can work with. As we’re dealing here with a really simple table, all we need to do in terms of responseSchema is to define two fields: a response (what) and a count (how many). These three lines are all you need to convert the table to a dataset that both the YUI Charts Control and the YUI DataTable Control can use.

      YAHOO.widget.Chart.SWFURL = 'http://developer.yahoo.com/yui/build/charts/assets/charts.swf?_yuiversion=2.4.1';
      var chart = new YAHOO.widget.PieChart(chartcontainer,data,{
        categoryField:'response',
        dataField:'count',
        expressInstall:'http://developer.yahoo.com/yui/build/charts/assets/expressinstall.swf'
      });

Time for pie: we define the URL of the Flash movie that draws the pie and instantiate a new pie chart. We send the div we created earlier as the container, the data we retrieved from the table as the data to display and define a configuration object. This object has the response field as the categories and the count field as the data. The expressinstall defines what Flash movie to show if the visitor doesn’t have the right Flash version.

    });
  }
});
if(document.location.toString().indexOf('http')!==-1){
  tablestoYUIchartsplease.insert();
}

Almost done. All the script now needs to do is to call the insert() method of the YUI Loader — that gets the ball rolling. I’ve enclosed the method in an if statement that checks if the HTML is called up via HTTP or not as the Charts Control needs HTTP to work.

Summary

That’s all you need to do to progressively enhance an accessible data table to turn them into a pie chart using the YUI Charts Control. We can extend this example to allow for several types of charts and to turn the tables into sortable data tables quite easily. If there is interest, drop us a comment.

By Christian HeilmannJanuary 17th, 2008

Carousel Design Pattern

3-D carousel wireframe imageAs the end of last year was winding up I spent some time tinkering with the open pattern library, in order to clear the way for our latest pattern release, Carousel. One reason why I needed to do this tinkering is that the Carousel pattern contains a few new fields in its data model. These are primarily elements that we have been including lately in our internal patterns that I wanted to find a way to promote to the public library.

But first, a little bit about the pattern. Folks inside and outside of Yahoo! have been asking us for a carousel patterns since before I got here (and you all want carousel code from YUI too — we hear you). It’s been possible to make a carousel using the Slide Transition pattern and associated YUI code, as Bill Scott demonstrated quite some time ago, but the detailed do’s and don’ts of effective carousels were still left up to the individual developers.

The Carousel Pattern page on the Pattern Library siteInternally here at Yahoo! we had a several partial carousel guidelines (carousels are used extensively across the network, especially in the Media Group sites) but no consistent standard. This past summer a large number of user experience designers carried on a week-long discussion — sharing experience and insights — and hashed out the major issues involved with carousel design. After that I gathered a group of interested designers and developers and started shaping those comments into a sketchy pattern draft.

Lucas Pettinati, a designer on the YDN team who also works closely with YUI, devoted a lot of time to sorting out the subtle details and possible variations on the basic carousel theme with me, and also cooked up some basic wireframe diagrams to help illustrate the possibilities. The draft pattern made its way through several review cycles and finally emerged ready to publish near the end of last year.

Why so much effort? It’s a good question. It’s certainly possible to describe a carousel in pattern format in a lot fewer words than we did. Both Patterns in Interaction Design and UI-patterns.com manage to describe carousels in fairly simple terms (the latter even uses a Yahoo! carousel as its sensitizing example).

We felt that there were more subtle issues at work here than simply queuing up a bunch of images and allowing them to scroll into a viewport. You’ll be the judge of whether we were right, and as always we welcome feedback on the pattern.

One last note about the pattern format: I’ve added a new field, Special Cases, to the pattern format. We’ve used it internally for some time and I’m not sure why we haven’t used it in the open library. In the past that material sometimes made it into the solution or rationale or was left out. As with Vote to Promote I’ve also included a Pattern Gallery and have now made that a standard element in the pattern model.

Finally, I’ve added a few new headings to the links along the gutter of the pattern description: Other Examples, Wireframe Templates, and Similar Patterns in Other Libraries. Other Examples are examples from around the Web, outside of the Yahoo! network. Wireframe templates are downloadable stencils (currently in Omnigraffle and Visio XML format) that designers can use to create and position their carousels. Similar Patterns in Other Libraries are, well… need I explain?

Inside Yahoo! our designers always want stencils to work with just as our developers always want code. We are working on producing wireframe templates for all of our patterns, starting with the new ones. You’ll notice that we don’t yet have YUI code for the carousel pattern but as soon as we do I will of course add a link to it from the pattern entry.

So I spent the holidays tinkering with the JSON and PHP files that build the library and adding in the new fields without breaking all the old patterns. (OK, I broke them but then I fixed them but that’s what staging servers are for, right?) Now that the new year has rolled around I realized I had stealth-released the carousel pattern when I should really be shouting about the newest pattern to the rafters. A lot of people have worked hard on this and I’m proud of the result. I hope you find it useful. Let us know what you think.

By Christian CrumlishJanuary 15th, 2008

Hosting YUI Files for Implementations in Mainland China

Announcing support for hosting YUI in China on YUIBlog.cnBack in February 2007, we opened up hosting of YUI files on Yahoo’s content delivery network to all users, and we maintain a page describing how you can implement YUI while drawing all of its resources from our network. What we’ve heard from the YUI community is that having this choice is a big deal — and more than a billion YUI files were served from our yui.yahooapis.com last week, a number that has grown steadily since we opened up that service.

The yui.yahooapis.com domain is an edge-hosted CDN, and it automatically draws files from data centers as close as possible to the source of the request, optimizing performance. While that works well in most locations, one area where we were seeing poor response times was in China, where a growing community of YUI users is located. To help improve performance for implementers serving the China market, we’re announcing today the availability of cn.yui.yahooapis.com, a CDN specifically for that region.

As of today, the following two paths will both work for retrieving the minified Yahoo Global Object:

For most implementations, you’ll want to continue using the standard yui.yahooapis.com, but if your project serves China primarily the new domain will improve your response times and deliver a better experience. For users in mainland China, we’ve seen as much as a 5x improvement in response times based on initial tests.

A bit more about this (in Chinese) on YUIBlog.cn, a blog created recently by the user experience team at Yahoo! China (a company in the Alibaba group). A big thanks to Hongwei Zeng, an engineer at Yahoo! China, for helping to make this arrangement possible.

By Eric MiragliaJanuary 15th, 2008