Dragos Manolescu from Microsoft Live Labs and Joe Yoder from The Refactory are organizing a pattern-mining workshop at TOOLS 2008 Europe, July 5-6 (dates still to be confirmed) in Zurich, Switzerland. I’ve agreed to be on the program committee to help review proposals and advice.

In their own words:

Web 2.0 features are now commonplace — blogs, wikis, RSS feeds, social bookmarking and the like are almost everywhere you look online. Now that these technologies are maturing, what are their common problems and challenges? How are these problems being solved? What similar challenges do Web 2.0 developers face, and how can they leverage the most common solutions? Here’s your chance to gather with other professionals facing the same issues and work together to identify solutions.

We are looking for system experts, domain experts, and pattern experts to come together, bring examples, detect commonalities, and write patterns. Proposals are due May 5.

See the call for proposals for more details.

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.

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

When Erin Malone and Matt Leacock and others first launched the internal pattern library, they presented a talk at the IA Summit, called Implementing a Pattern Library in the Real World: A Case Study (and subsequently the linked article on the same topic at Boxes and Arrows). Then Erin and Bill Scott took the library to the public on the Yahoo! Developer Network website and Bill Scott “enriched“ the library with tons of Ajax-y goodness, closely tied to the YUI Library.

Since that time, I came on board and I’ve worked on reorganizing the library, updating the patterns, and shepherding a new generation of patterns through our internal refinement and review process, with an eye toward identifying useful social and openness patterns that we can share with the whole Web. So when people come up to me at conferences or find me on mailing lists for information architects and interaction designers frequently they are curious about how the library has evolved in the years since it was founded, what our internal process looks like these days for writing, reviewing, approving, and rating patterns, and how we decide which ones to publish in the open library.

Recently, I gave a talk here at Yahoo! as part of our UED brown-bag series, called The Pattern Library Wants YOU!, intended to update oldtimers on changes and improvements to our process and infrastructure and to orient new designers about the library, and of course to encourage people to get involved. Ricky Montalvo, our ace videographer for YUI Theater and YDN Theater, recorded my talk and edited it together with my slides, and we just spent a week or so removing any too-sensitive information and getting our friendly legal folks to sign off on releasing the talk to the public.

So, without further ado, here is the public version of my talk, which should answer a lot of those questions I’m hearing these days.

Context of Use

Mobile devices are excellent at connecting users to information; and while consumption of information is likely the largest segment of mobile device usage, interacting with a mobile device to perform important tasks is a usage segment that deserves significant attention. This is because generative work conducted on mobile devices tends to be tactical in nature and demands a sense of immediacy. Users have a very specific need and desire to accomplish their goal in the easiest and fastest way possible. This fact alone helps explain why mobile interfaces are designed the way they are:

• Feature sets are optimized to streamline common use cases
• Use typography to show hierarchy and importance
• Features are progressively displayed
• Large buttons are used to make interactions actionable

Let’s explore a mobile email client as an example of how these attributes are manifested.

Streamline Common Use Cases

Whether you’re lounging at the beach, riding the subway, or at a client meeting, the need to access email on your mobile device is likely predicated by a sense immediacy. If at this point you thought “What about boredom?”, I’d like to remind you of the beach scenario. A complex interaction involving zooming, tiny check boxes, and the like is the last thing one needs. Several mobile email applications address this challenge by displaying an optimized interface that allows users to select an inbox or folder, view a list of messages, and then act on a specific message. Though this model may not be best when dealing with bulk actions, it simplifies the interaction to a primary use case and allows users to get the information they need. Once the user has access to the information being sought, additional options are contextually presented.

Show hierarchy and importance

Instead of using a data table layout with dedicated columns for each piece of email meta data, the iPhone email interface groups sender, date, subject, and message status information into repeating units that make identifying a message a simple task. By varying font size, weight, color, and style, one is able to discretely communicate each morsel of information without having to label it. This not only reduces interface clutter but allows the data to speak for itself.

Features are progressively displayed

While performing bulk actions like flagging several messages is an extremely useful feature, it is probably not a primary activity performed on a mobile device. In the case of the iPhone, options to delete a message, reply, and move to a different folder are are only displayed when viewing a message. Taking this concept one step further, tapping the reply icon allows the user to specify if they wish to reply, reply all, or forward the message. By simplifying the mechanism for how one selects a message to a single click, and removing the ability select multiple messages, all features that deal with acting on a message are progressively disclosed in context of that message.

Large buttons are used to make interactions actionable

When you use a laptop or desktop computer, chances are that you’re in a very controlled environment; lighting is good, you sit a comfortable distance from the monitor, and using a mouse or trackpad to control a screen cursor is a simple task. In contrast, mobile devices may be used in unpredictable situations; outdoors in very bright light, in the course of another activity (like driving), or while in constant motion—which makes coordinated movements difficult to perform. By making the clickable area of an action large, many of these issues are resolved. When highlighted by a contrasting background color, important actions are more easily seen and targeted even when overall screen contrast is poor. Most important of all, a large click area requires less precision and effort to activate; an excellent manifestation of Fitts’s law.

Context of the medium

Interfaces designed for a desktop internet browser experience are usually not optimized for a mobile internet browser. Aside from the issues arising out of the context of use, the mobile device itself may present you with challenges and opportunities not present in the desktop realm:

• Dealing with phone numbers and other mobile friendly data
• Displaying information on a smaller screen
• Not using a cursor
• Device speed and network latency

Dealing with phone numbers and other mobile-friendly data

If your mobile web application displays phone numbers, making it easy for a user to dial that phone number should be a top priority. By using the tel: URI scheme and linking a phone number, many mobile internet browsers will dial the linked phone number.

Some mobile devices may redirect certain URLs to native applications. This is the case with the iPhone redirecting YouTube and Google Maps URLs to the onboard application, but can also be observed with phones that automatically open the built-in calendar when an iCal file is downloaded, or open the built-in address book when a vCard file is downloaded. To design an experience that can gracefully coexist with others tools, one needs to understand what kind of media can be processed by specific mobile internet browsers, and when onboard applications are launched.

Displaying information on a smaller screen

While most desktop web applications are designed for 800×600 or 1024×768 resolutions, mobile devices employ significantly smaller displays. Some mobile browsers scale graphics to fit their screen width and some mobile browsers allow the user to scale and magnify a portion of the interface. Using traditional web development techniques of creating fluid designs that scale horizontally is the fastest way to deploy a single design to many different mobile devices.

Older mobile devices may have a horizontal resolution of as few as 96 pixels while newer models have horizontal resolutions of 240 or 320 pixels. If you are bothered by the wide range of horizontal resolutions and feel that your design options are discretely different for different resolutions, think about creating resolution-specific CSS files. Common horizontal resolutions are 96, 128, 176, 240, and 320 pixels.

If you have the luxury of targeting specific devices, don’t overlook the option of serving device-specific CSS files. Doing this allows you to fine-tune object dimensions for a specific device as well as customizing your application’s skin to provide an onboard application feel, if so desired.

Not using a cursor

Mice, joysticks, scroll-wheels, keypads, fingers, and styli—oh my! Different mobile devices require different tools to interact with their interfaces. While each of these input tools accomplishes the essential task of selecting an object, each also presents us with limitations.

Joysticks, scroll-wheels, and keypads typically use up/down commands to scroll content and automatically focus on fields, links, and buttons. In essence, this limits a designer and developer to listening for focus, blur, and click events. Advanced devices that use fingers and/or styli as the input tool may provide access to more events, but here too a wide range of device specific behavior may restrict event listening to a small set. Blazer and PocketIE browsers, depending on device configurations, may allow a user to scroll a page by using a stylus to interact with scroll bars; the same browser on a different device may be limited to a joystick input tool. The Safari browser on the iPhone offers page scrolling by allowing the user to push the page in the direction of the scroll. Whereas Blazer and PocketIE browsers could allow for the opportunity for direct object manipulation (like drag and drop), such an action is not natively available on the iPhone because the act of dragging is reserved for a system-level interactions.

All is not lost, however. Just because a device does not support dragging or double clicking does not mean it has a poor event model. The act of dragging an object to a drop area may seem trivial—but when this action needs to be performed in a moving subway while clinching a hand strap, the mechanics involved can range from being frustrating (using one’s thumb to drag and other fingers to hold device) to outright masochistic (trying to control a stylus from moving around a slippery surface).

Device speed and network latency

Until the day that WiFi and WiMAX technologies are built into every mobile device, planning on data transfers via GPRS and EDGE networks is a reality—which means data is transfered as slow as 60 kbits/sec. Even if one is able to overcome the speed and latency of a slow data network, there’s still the mobile device’s processor and RAM to contend with. As expected, a desktop or laptop computer is several times more powerful than a typical mobile device. Complex code execution on a mobile device may therefore be several times slower than the same code run on a desktop computer. More importantly, mobile devices are all about the consumption of information; lightweight interfaces (both in terms of features and bytes) deliver information faster.

What it boils down to

Simplifying interactions and streamlining access to information may not be as cool as crafting richer interactions, but they are the most effective techniques available at producing a design that is easy to use on a mobile platform. Simplified interfaces can also lead to leaner code, which means less data is transfered over slow connections.

Designing with awareness to context will yield a more atomic design that instead of introducing users to a proverbial blank canvas, will guide them toward accomplishing important tasks. Having to deal with slow data speeds, high network latency, smaller screens, and an unpredictable mode of use only reinforce the need to isolate an application’s essential features and offer access to them when contextually appropriate.

Next time you design an interface for a mobile device, remember to consider context of use and context of the medium as part of your design strategy.

Online Resources

The links below provide more in-depth information about several popular mobile platforms:

ACCESS / Palm OS

• ACCESS | Palm OS Application Design
• Zen of Palm (PDF)

Apple iPhone

• Apple iPhone Human Interface Guidelines

BlackBerry

• Optimizing Content for the BlackBerry Browser (PDF)

Nokia

• Nokia Web Browser Design Guide

Microsoft Mobile Internet Explorer

• Microsoft | Mobile Web Development

Motorola

• Motorola Developer Guides

Update: fixed broken Fitts’s Law link.

We’ve done away with the first-order distinction of “User needs to” and “Application needs to.” In the interests of fostering a user-centered (or, if you prefer, customer-centric) design perspective, we have reclassified all of the patterns in terms of a set of high-level user needs, because we feel that even things the application (or designer) “needs” to do must be driven ultimately by satisfying the need of an end-user.

Currently, the top-level categories in the new organizational scheme include Search, Navigate, Read, Select, Interact, Give Feedback, and Customize. A few more will probably appear as we roll out additional patterns.

Speaking of which, we are publishing a new pattern today, Vote to Promote, which is our interpretation of the best way to incorporate a scheme to allow your users to vote up content, whether content native to your application or identified elsewhere (as with Digg and Reddit).

Vote to Promote was written by Bryce Glass, a senior interaction designer on our community platform team. It’s the first in a series of “social media” patterns we’ve been working on now for much of this year, and you can expect a bunch more to appear over the next few months.

Vote to Promote is also the first pattern to include a “pattern gallery.” One bit of feedback we hear a lot - from you and from designers inside Yahoo! - is that more illustrations are better. This may sometimes show up in the form of diagrams, schematics, and templates. But each new pattern we release from now on will also feature a set of example images captured from across the Internet and displayed via Flickr. Check out the Vote to Promote pattern gallery and feel free to suggest additional examples.

Let us know what you think of the new navigation scheme and the latest addition to the library. Thanks!

With the goal of better understanding how people interact with the Web via various types of Assistive Technology (AT) — and what that might mean for developers and designers — Karo Caran takes us on a 16 minute overview of screen magnification software (in this case ZoomText) and how it is used by partially-sighted users to interact with the Web. Karo shows you the basic toolkit and then applies those tools to some typical web sites to give you some perspective on how she uses magnification software while she browses the web.

Though screen readers get most of the press, it’s good to remember that it’s not the only AT game in town.

Related URLs

• YUI Theater — Victor Tsaran: “Introduction to Screen Readers”
• YUI Theater — Doug Geoffray: “From the Mouth of a Screenreader”

Technical Notes

A downloadable and iPod-compatible MPEG version of this video is available for download. The .m4v file format we’ve used for this video (and many others in the YUI Theater) signifies that it is an MPEG-4 file with video; if you’re not downloading to view on an iPod, and/or are using a system that doesn’t recognize the .m4v extension, try renaming the file to .mp4.

This is also a good opportunity to introduce myself. My name is Christian Crumlish. I am an information architect, interaction designer, writer, and the new curator of the Pattern Library. I think of myself as a pattern detective because a big part of my job is to uncover successful patterns on the Yahoo! network and “in the wild” and capture and document them for eventual publication in the Pattern Library.

I’ve got some big shoes to fill. Matt Leacock was our first pattern librarian, launched our internal pattern library, developed many of the earliest patterns, and established a structure and process for the library. Bill Scott oversaw the public release of the pattern library as you you probably remember from his posts on this blog and the slew of fantastic Ajax patterns (among others) that he shepherded into the library. Fortunately they’re both still nearby for me to hassle when I’m not sure what to do, as is Erin Malone whose leadership has driven the development and release of the library all along.

The two newest patterns

The Calendar Picker comes in handy when users need to select dates or date ranges. Probably the canonical scenario is travel planning. Airline reservation systems all use some variation on the calendar picker pattern and the best ones do a good job of anticipating the date vicinity, especially for the return portion of a round trip. The YUI Library has a Calendar control which this pattern complements.

Alphanumeric Filter Links sound deceptively simple: a common segmentation of large information repositories for easier navigation. (Of course this only works in alphabetic languages!) However, our internal review process uncovered a number of gotchas related to alphabetization and found a number of variations of this pattern to address distinct scenarios. Basic list filtering driven by text-links is so “Web 1.0″ so we’ll be sure to relate this context to Auto Complete and other dynamic ways of sorting and filtering long lists of data. As we build up the Pattern Library we’ll group them together under an umbrella parent pattern.

As always, we welcome discussion, feedback, and suggestions about these patterns on the ydn-patterns list. I’ll be announcing new pattern releases here on the YUI Blog, and will continue the series of exploratory posts and essays Bill Scott started. Together I expect we will contribute to the public discussion of design pattern, interaction design, information architecture, and user experience in general.

Join us Thursday, February 22nd, from 5:30 to 8:30 PM, at Yahoo! HQ in Sunnyvale, California. Visit Upcoming.org for details and to RSVP. 300 people max, so RSVP early!

Beer. Food. Music. Guitar Hero on the projectors. Some other goodies and a few announcements we think you’ll like. (No, not Beck.)

At 6:30 there will be a brief presentation by the YUI team. After that we’ll have “built-with-YUI mini-demos”, where some of you can take the stage for 5 minutes to show off how you’ve been using the YUI Library. There’s only time for a handful of these quick talks before resuming the music and party around 7:15, so leave a note in the comments or send me an email directly (natek at yahoo-inc dot com) to get your proposal in.

That’s it: RSVP on Upcoming.org, send in demo proposals, and get ready to party with us on Thursday, Feb 22nd, from 5:30pm.

Thanks,
Nate

Update: The tag for this event is yuiparty07

Q: What’s the best way to communicate a pattern?

James Reffell
UI Design Manager, eBay Inc.
Curator, eBay Pattern Engine

I’m constantly amazed at the power of design patterns to communicate. I’ve found that a well-described pattern can both convey both a specific solution (which can help me solve a difficult design problem) and the core interaction principles that underly all good patterns (which can help make me a better designer).

While designers will probably always be the primary authors of and audience for design patterns, I’m finding more and more that they’re useful in communicating with all sorts of folks. These include not only the developers who are responsible for building our designs but also the business folks, product managers, and other non-designers. There’s also a big difference between talking to other designers inside an organization (as with eBay or Yahoo’s internal pattern libraries) and talking to a more general design audience (as with books or the public libraries).

The core pieces of information – What, Use When, Why, How, and Examples – are necessary to tell the story of each pattern for all audiences, and Who becomes a big deal in an internal library. Users of an internal library might also find links to internal design standards and specifications useful, as well as a list of places where the pattern appears. Additionally, as Bill points out, if the pattern will be used by a specific developer audience, the How and Examples might add sample code and implementation details. Since patterns aren’t exactly built in stone, it’s also helpful to add things like ratings, discussions, links to similar patterns, and the like.

Once you’ve added all these additional pieces of information you have something that’s grown well beyond just a design library – and that’s OK as long as it works for the intended audience, and as long as those first core pieces are in place!

So much for the parts of the whole. I think it’s also important to look at the pattern description as a whole and coherent story, however. Narrative is an important tool for communication, and I think we might not take advantage of it enough – some pattern descriptions can get a little clinical. I prefer to see the examples rounded out with some history—and maye some drama and a few laughs! There’s no harm in telling how we came to realize a given pattern was a good solve, the bumps along the road, the other things that we’ve tried and have failed entertainingly. Why can’t a design pattern also be a ripping good yarn?

Finally, the designer in me thinks we should maybe take a little of our own medicine here. Design patterns are primarily tools for designers, and we should design them accordingly. One of the things that impressed me with the Yahoo pattern group’s work is that they worked in some good design methodlogies when building the library—I’d love to see more work along those lines. Does anyone know of other examples of user testing for our pattern libraries?

- James