Yahoo! User Interface Blog (YUIBlog)

iPhone Design Stencils in the Pattern Library

December 17, 2009 at 2:11 pm by Christian Crumlish | In Design | 1 Comment

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Results of the Accordion Pattern survey

October 26, 2009 at 2:44 pm by Christian Crumlish | In Design, Development | No Comments

A few months back we shared our current thinking on the “accordion” navigation component, and asked the community of web developers and designers who read this blog to take a survey to help us determine defaults, current practices, and other guidelines to incorporate into an Accordion pattern and provide input into an Accordion YUI component.

I’ve had some time now to review and study the results and I wanted to share them with the community as we write up a “beta” version of the pattern and get ready to share it, so without further adieu, here are the results (note that this survey should not be considered strictly scientific).

Who Responded

Respondents identified themselves the following ways:

• Designer 21.4%
• Developer 32.1%
• Hybrid (Both designer and developer) 42.3%
• None of the Above 4.2%

Terminology Distinctions

Overwhelming majorities across all respondents agreed that

• Accordion and Accordion Menu mean the same thing (73%)
• Accordions and Tree Controls are two different things (89%)

Many commenters described the difference between accordions and trees along these lines: “Tree Control generally implies a depth of hierarchy that is not generally present with an accordion.”

A smaller majority said that Accordion and Collapsible Panels refer to the same thing (60%).

These majorities were consistent across roles.

Presentation of Accordions

A solid majority (68%), said that accordions can be laid out horizontally as well as vertically (and in fact the pattern is well attested on the web). People suggested that the labels on a horizontal accordion should be written vertically and/or rotated.

An even larger majority (72%) said that accordions can have only two levels (this aligns with the distinction between accordions and trees):

A slight majority (53%) said that accordions may be nested within other accordions. The written comments suggested that the wording of the question led some to answer that it’s certainly possible but not necessarily desirable, making suggestions such as, “If you adequately gutter them, this would be possible, but generally a terrible idea – kind of like using too many tabs and having them wrap into multiple rows.”

This was one of the questions where self-described designers and developers took opposing sides. 57% of Developers and Hybrids agreed that accordions may be nested, whereas 64% of Designers said they may not be. (None of the Aboves split 50/50!)

If I had to guess, I’d say that developers (and hybrids), more intimately connected with the how than the why may have been expressing more of a “you could do it…” perspective, whereas designers may have been expressing more of a “…but you shouldn’t” point of view.

How Accordions Should Behave

A small majority (54%) believes that accordions should allow for more than one panel to be open at a time. Both behaviors can be found online, so our impression is that this behavior may depend more on the constraints of the design space and the purpose of the accordion than on a blanket rule one way or the other.

This question also split along identity lines, but in an ambiguous way. Hybrids preferred the one panel-at-a-time rule by a tiny majority, while Designers and Developers and None of the Aboves agreed that multiple panels are okay by slightly larger majorities.

A much larger majority (73%) believes that an accordion can have a completely closed state (that is, that it’s not necessary that there always be one panel open). The only outlier is that the None of the Aboves broke 60% for the position that there must always be one panel open.

Several commenters suggested that it is a good practice to have one panel open by default, and for that panel to be either the first one, the one most recently used.

Another large majority (76%) believes an accordion’s overall size can change as needed, rather than being constrained to a consistent size. (Of course, there are contexts, such as the screen of a mobile device, in which it may be a valid choice or even a design constraint that an accordion maintain a consistent size.)

A very slight majority (51%) suggested that accordions should open on click (as opposed to on hover) and a nearly as large minority (45%) said that it depends. Interestingly, fewer than 4% were willing to state the accordions should open on hover as a rule.

Written comments on this question offered plenty of good food for thought, such as:

Opening a panel should require explicit action. If an accordion has multiple panels, opening on hover could be a jarring experience. Rather, use a tooltip to convey summary details of what is in the panel, and have the user explicitly “click” to open that panel.

Depends on the configuration of each accordion.

I put these examples together [multiple, rollover], so the developer can actually use the “best fit” for each use case.

Also, there should be the option to use rollover with different rules: (one most be open) or (elements should be opened on mouseover only).

For advanced usages, an accordion should open on hover during drag and drop operations. In any other circumstance, you can’t trust that the hover is intentional.

Accessibility

Finally, we asked an open-ended question fishing for any known accessibility issues with accordions and got a lot of great answers. (For our example issue, most people agreed that making the entire label clickable and not just a small icon is important.)

Here is a sampling of other insight about accessibility with accordions:

I think it’s safe to assume that an Accordion interaction is an advanced interaction. Lots of accessibility problems can arise.

1. Content is hidden behind panels so people may not find it.
2. Depending on the size of the clickable area or the trigger to open/close the panels there could be issues with the manual dexterity needed.

Accordions should open all panels if javascript is unavailable (though that may produce a “flicker” for those with javascript).

It depends on whether content in the hidden panels is present in the DOM or is retrieved upon opening the panel. If it is being retrieved, focus needs to be placed on the newly opened panel.

Well, I really believe the title should be clickable, specially if the content of the element will be loaded using AJAX (just like a tabview approach), but the reality is that sometimes the developer (should have)/(want) the control to customize that behavior. Here is the list of examples that I created for an accordion widget implementation based on YUI 2.x, it’s probably one of the most used components from the bubbling YUI extension.

We’ve had a case where the ‘label’ of the accordion was a link to a full blog post, and so could not be accordion-clickable. In that case, we wrote an icon into the source with js to do the job. Provided the icon is sufficiently large and/or comes with an accesskey, I don’t see a major difficulty…

Accordion controls server the purpose of fitting lots of content into less space. Since this is a visual concern, it would be fine for a screen reader to simply read all of the content and ignore the fact that it is displayed as an accordion visually. It is sufficient for an icon to be clickable to expand a panel. There could be a configuration option to allow the entire label to expand a panel, or it can be left up to the implementing developer to attach a listener to the label that calls a public “open” or “expand” function to add that functionality.

Just think of an accordion as a tabbed view. The entire panel label area should be clickable, but if it contains other controls (e.g. a “dismiss” or “close” button) I suggest only the label (text) be clickable, or at least the clikable area only expand up to the interactive controls (i.e. for a caption containing a button, the area above, below and “after” the button should be clickable).

Releasing the Draft Pattern

One commenter questioned the artificial constraints of the survey (a fair cop, if you ask me):

I didn’t like this survey. The questions were not flexible enough. As a designer/developer, I believe all interface elements need to be tailored to particular site or web application. Asking black and white questions does not leave room for the obvious differences between projects. Some projects need a hard and fast rule, while the same rule might be totally inappropriate for another application. For the most part, I could of answered every question with a “it depends” result.

Rest assured that the pattern will only gently recommend and the YUI code will be flexible and powerful. The survey wasn’t designed to limit people’s choices but rather to gather opinions and preferences, so even feedback about not having hard-and-fast rules is useful.

We’ve published a beta version of the Accordion pattern in the Yahoo! Design Pattern Library. If you’d like to give further feedback on the pattern, in a free-form manner, please drop by or visit the related forum discussion.

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

John Peloquin’s Multi-layer Calendar

April 3, 2009 at 2:41 pm by Eric Miraglia | In Design, Development | 6 Comments

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.

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Survey: When is an Accordion not an Accordion?

March 23, 2009 at 9:20 pm by Christian Crumlish | In Design, Development | 6 Comments

I’m looking for feedback from people who have designed or built an interface using an “accordion” module (or are considering doing so). You see, I’ve been working on a design pattern for accordion modules, and I’d like to throw out a handful of open questions to the community via this brief survey. I’ll be listening elsewhere as well, on twitter (@mediajunkie) and on mailing lists where web designers and developers hang out.

(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.

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

YUI Turns Three!

February 18, 2009 at 7:38 pm by Jenny Han Donnelly | In Design, Development | 6 Comments

The YUI Library turned three years old this month and we’d like to invite you — our community of developers and implementers — to come out and celebrate! To celebrate our third birthday (and our 2.7.0 release), we’ll be hosting a recession-chic happy hour at the Blue Chalk Cafe in downtown Palo Alto, Thursday, February 26 from 6:00 to 8:00 pm. Nothing too fancy, but we’ll have fun goodies to give away and the first few rounds of drinks are on us (until the tab runs out). Details and signups are at Upcoming. Hope to see you there!

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

YUI 2.7.0 Released

February 18, 2009 at 3:52 pm by George Puckett | In Design, Development | 21 Comments

The YUI development team is pleased to release version 2.7.0 of the YUI Library. You can download YUI 2.7.0 from YUILibrary.com or configure your implementation using the YUI Configurator.

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.

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Image Optimization, Part 4: Progressive JPEG…Hot or Not?

December 5, 2008 at 8:23 am by Stoyan Stefanov | In Design, Development | 9 Comments

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).

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)

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!