Yahoo! User Interface Blog (YUIBlog)

YUI Theater — Ryan Cannon: “There is no off-season: NFL.com’s move to YUI” (42 min.)

January 17, 2012 at 10:57 am by Ryan Grove | In Development, YUI Implementations, YUI Theater | No Comments

NFL.com’s Ryan Cannon (@rcanine) joined us at YUIConf 2011 to share the story of why NFL.com chose YUI over jQuery, how they migrated a large codebase from Prototype to YUI 3 on a tight schedule, and how they use YUI to create websites and mobile apps for one of the world’s most popular sports leagues.

Links

• View in HD on YouTube
• Slides
• Full YUIConf 2011 Playlist on YouTube

Find conversations: bloglines | technorati

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

YUI Stories

November 10, 2011 at 1:07 pm by Ryan Grove | In YUI Implementations, YUI Theater | 1 Comment

At YUIConf 2011 last week, we set up a video camera and invited attendees to tell us how they use YUI and why they chose it for their projects. We were thrilled to hear their stories, and we’d love to hear yours as well! After checking out the video, leave a comment and tell us how you use YUI.

Find conversations: bloglines | technorati

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

Loader Usage at Quorus

March 24, 2011 at 9:49 am by Peter Abrahamsen | In Development, YUI Implementations | 2 Comments

Today, I’d like to talk about YUI Loader and how we at Quorus, Inc., use it to provide third-party websites with new features on demand.

The code we write powers features on other peoples’ pages, meaning we’re in the unenviable position of having not only no control over the browser environment, but heavy restrictions in how we use the document itself. Our customers put a Quorus bootstrap script on their pages; everything else needed for our functionality is loaded dynamically and on demand. We go to heroic lengths to make sure that our elements, styles, and scripts do not alter the behavior of anything we’re not responsible for.

We started our present code base two years ago, when YUI 3 was just taking shape. It was a risky decision at the time to commit to a codebase that wouldn’t hit beta for several months. In retrospect I can’t imagine how we would have accomplished what we have without it. I haven’t seen any other framework that has components approaching the power of Loader, Attribute, and CustomEvent.

The Quorus bootstrap script we provide to our customers does almost nothing. Its job is just to load the core of our platform without blocking the rest of page load, and to queue any API calls until we’ve done so. This core script file, called stage2, inlines yui, loader, and oop, as well as enough smarts to load additional libraries to respond to API calls, user clicks, and other conditions in the operating environment. Most other resources are served by a custom combo server that serves custom Quorus and stock YUI modules.

Bootstrap queues up API calls made in the host site’s code between when it loads and when we’re ready to go in an array on our global object, QUORUS:

QUORUS._callbacks = [];
QUORUS.use = function () {
  // turn the arguments object into a regular array,
  // so that it can be stored safely
  var args = Array.prototype.slice.call(arguments, 0);
  QUORUS._callbacks.push(args);
};

Once we’re ready to process API calls, stage2 runs them one by one in timeouts. This ensures we yield control regularly back to the browser, which makes the user experience more responsive. The behavior is a lot like Y.AsyncQueue, but simpler and doesn’t require YUI to be loaded:

// Put the real 'use' function in place for any subsequent calls:
QUORUS.use = function (feature, callback) {
  YUI.use('module-that-provides-the-feature', function (Y) {
    // find the API for the requested feature, and pass it to the callback
    callback(Y.APIs[feature]);
    // process another pending API call, if any:
    setTimeout(processAPICall, 0);
  });
};

// Play catch-up, running each callback in sequence:
function processAPICall () {
  var callback = QUORUS._callbacks.shift();
  if (callback) {
    QUORUS.use.apply(QUORUS, callback);
  }
}

// Start processing the queue:
processAPICall();

The bootstrap file is, by this point, mostly immutable: it’s something we hand off to a customer, who might require a month or more to deploy any new version we gave them—an impossibly long time for an agile startup company. The stage2 file, meanwhile, is small, loads from our own servers, and has a short cache lifetime. This ensures that no end user will have an old version for more than a few minutes. Nearly all the other resources we need are in permanently cacheable JavaScript libraries and CSS files.

When we release a new version of our code, stage2 automatically directs browsers to start downloading from a new location, ensuring that they use only the newest code. This setup allows us to deploy changes quickly without serving up assets more often than necessary. Not only does this keep our bandwidth costs low, but it provides a better user experience: the cached resources load very quickly while the page is loading.

If we were starting our codebase today, with the benefit of the YUI Gallery, there are a number of components we might use to make our lives easier. One of them is Eric Ferraiuolo’s Base Component Manager, which assists with wiring up components (typically Widgets) on demand. Another might be Storage Lite, to help us retain application state across page loads.

Many thanks to the YUI team for their great work, and to the community for their contributions. If you would like to read about our approaches to sandboxing or to coordinating asynchronously loaded components, please let me know in the comments!

About the author: Peter Abrahamsen writes Ruby and JavaScript, manages server infrastructure, and studies user-centered design in Seattle, Washington, USA. He can be found on IRC as Rainhead.

Find conversations: bloglines | technorati

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

Bringing YUI Theater to Internet TVs

December 6, 2010 at 10:14 am by Chad Auld | In Development, YUI Implementations | 4 Comments

I wanted to post a quick update on a few YUI related projects I’ve been working on with a friend of mine, Ozgur Cem Sen (@ozgurcemsen). Eric posted a few months ago about our efforts to bring YUI Theater to Boxee. We just finished reworking the UI for Boxee and added some new features such as browsing by tags and search. We are currently working with the Boxee team to get the app added into the new Boxee Box repository. That is in addition to the standard repository they have for the desktop version. The Boxee Box repository has some stricter requirements around performance and video quality. The new versions should hopefully be out within the next week or so.

While finishing up the Boxee app we stumbled on the Samsung TV platform and the timing was perfect because they are actually running a “Free the TV” challenge. We came across the contest pretty late in the game and nearly missed the submission deadline, but we pushed hard and successfully recreated the same experience for Samsung in short order. If you have a few minutes please vote/help spread the word about our YUI Theater submission for Samsung – http://www.freethetvchallenge.com/submissions/249. We’ve got 50+ other entries to beat.

Last, but not least — we also just recently completed work on a YUI Theater app for Plex. It isn’t in the official application repository yet, but the request is in. In the meantime you can download it from here if you’d like — http://wiki.plexapp.com/index.php/YahooYUITheater.

Here are a few videos of the applications in action:

• Samsung TV app – http://www.youtube.com/watch?v=e1kRicivfDU
• Plex app – http://www.youtube.com/watch?v=oxBPqVQqdnY
• Boxee app – http://www.youtube.com/watch?v=IK4i1DksuhU

You should expect to see similar efforts for Google TV and Yahoo! Connected TV in the not so distant future as well.

Hopefully these apps prove to be valuable resources for those that can’t typically attend the meetups and/or didn’t make the latest YUIConf. We’ll continue to add new videos as they are released.

Find conversations: bloglines | technorati

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

jQuery and YUI 3: A Tale of Two JavaScript Libraries

October 27, 2010 at 2:08 pm by Mark Rall | In Development, YUI Implementations | 5 Comments

Recently I had the opportunity to build my first JavaScript front end application. What follows is a short story of the discovery and evolution that comes about when trying to use tools that aren’t suited for the job at hand. It is an account of the learning acquired through developing the same front end application using two very different libraries, jQuery and YUI 3. Details of the client and the project have been intentionally omitted.

Overview

The project involved the refactoring of several disparate Flash tools into a single interactive application based on open standards for a large content publisher. Of high importance, the application had to be highly optimised with a small initial foot print due the large number of daily page impressions the client receives. Several phases were involved, with the first being an initial proof of concept.

The concept involved the development of one view of what would be the completed application. It consisted of:

• An initial seed file (< 1KB) responsible for the dynamic loading of any frameworks (e.g., jQuery or YUI 3) and the initial application file.
• The development and inclusion of jQuery plugins to support form element styling and validation, and dynamic chart visualisations.
• The generation and population of UI, based on user inputs, configuration defaults and the application’s location within the publisher’s site.
• The calculation and presentation of information based on the user’s input.

In the interest of full disclosure, my own experience up to this point had been in developing small, standalone solutions, the type of which you could typically describe as plugins. These included dynamic UI components such as image carousels, interactive maps and Twitter / Flickr widgets. At the time of first dabbling with JavaScript, jQuery was popular, easy to learn and allowed me to quickly pick up the basics needed for the projects I was working on. However these were all standalone units and had no need to interact with other code or as part of a larger application.

First Attempt

On completing the first phase of the project, it became painfully obvious that I was dealing with a very different beast than what I was used to. Having had little experience in code organisation, my code quickly became disorganised, inefficient and repetitive. As a result, the first part of what would become a much larger application was slow to load. In fact it took eight seconds to generate that single proof of concept. A big change was needed and while I had considered using a small library like Dean Edward’s Base or John Resig’s Simple JavaScript Inheritance pattern to add class-based inheritance to jQuery, I decided to go one step further.

What I wanted was a complete, mature framework within which to develop my first OO application. Something that would effectively guide me through the process. In reviewing the available libraries I decided to adopt YUI 3 for the following reasons:

• Integrated, inheritance-based application development support including attribute and class management.
• Long term solution:
  • Support for standards and accessibility.
  • Funded by a large well known organisation, Yahoo!
  • Associated with respected names like Douglas Crockford, Nicholas Zakas, and Stoyan Stefanov.
• Performance optimisation:
  • Initial seed file of only 7KB.
  • Lazy-loaded modules on demand.
  • CDN delivery.
• Varied and comprehensive documentation:
  • Yahoo! Developer Network
  • YUI 3 API Documentation
  • YUI Theater
  • YUI Library
  • YUI Blog
• Mature, consistent evolution between releases.
• Integrated tools in YUI Compressor, YUIDoc, YUI Builder, and Console.
• Not just JavaScript, a CSS framework too.

Take Two

Integrating YUI 3 brought several direct and indirect benefits to the project:

• Inheritance-based architecture and class management through the Attribute interface, and Base and Widget classes producing performant, reusable and organised code.
• Separation of presentation from model and data using the Widget class to render alternate views (inline or overlay) based on the application’s location within the site.
• Sandboxing and dynamic module inclusion through YUI.use().
• Cross-browser console debugging using YUI Console.
• On save, performance optimisation using YUI Compressor in Eclipse.
• Easy inclusion and integration of pre-existing jQuery plugins.
• On save, automated code documentation using YUIDoc.

The final result was a happy client and a finished product with sub-second load times (remembering it took 8 seconds to load the initial proof of concept).

Lessons Learned

Select the right tool for the job

In reading this post I’m sure some readers will view this as anti-jQuery. Not at all. jQuery is a fantastic project responsible for many innovations. But, as with any tool, it has its strengths and an intended purpose. Its strength lies in normalising browser inconsistencies, lowering the barrier to entry for the novice and improving the efficiency of experienced programmers. The primary learning that came out of the project was that you can’t rely on one tool for every job. YUI builds on what jQuery can provide by also offering a well architected application framework. But it’s fair to say that it comes at a cost, see the next point.

Steep learning curve

You need patience, especially when writing your very first application with an unfamiliar library as I did. However the payoff is immense. By learning another library, not only will your core JavaScript skills improve, you’ll also develop a deeper understanding of how libraries work and the benefits they bring. I try to learn something new about YUI everyday and the more I learn, the more I’m in awe of the thought and sheer talent that’s gone into building YUI.

Only load content when you need it

While it’s certainly programmatically easier to just to load everything you may need upfront, the performance improvements gained as a direct result of lazy loading content only when you need it is huge. This was one of the key contributing factors for drastically improving the performance of the application.

Interact with the DOM as little as possible

This point doesn’t relate to the specific library used. By caching the required DOM elements and utilising HTML templates more, UI rendering time fell considerably. Nodes can be cached using Y.one() while node lists can be captured using Y.all(). Also Y.Node.create() was very useful in efficiently converting large text strings of HTML to DOM elements prior to insertion.

Learn by example, use a CDN

In using YUI’s CDN delivered library we decided to deliver all the project’s assets via CDN. This was probably the next largest contributing factor to the performance improvement.

Pub, sub hubbub

For those experienced programmers out there, try not to laugh at this one. Having been used to writing little more than plugins in the past, I had no idea how applications should communicate internally. Even after reading “Custom Events allow you to publish the interesting moments or events in your own code so that other components on the page can subscribe to those events and respond to them,” I still missed it.

As it turns out, YUI’s custom event publish-and-subscribe model works beautifully for inter-class and inter-object communication. You can even subscribe pre and post to events and include dynamic logic to suppress bubbling based on certain conditions.

Integrate best practice into your workflow

Using Eclipse we were able to integrate JSLint and YUI Compressor into the build process. Put simply, every time you hit Ctrl / Cmd + S your JavaScript code is validated and optimised. That means you’re testing against optimised, production grade code from the very first line of code. It also means that you won’t forget to optimise in the frantic final race to the delivery deadline.

Learning YUI on the Job

Although everyone has a different learning style, I thought I’d share what resources I used to learn YUI with a specific objective in mind.

• Watch the relevant YUI Theater episodes to get a general overview of the library or learn a specific module. I can highly recommend starting with:
  • Eric Miraglia’s Welcome to YUI 3
  • Todd Kloots on YUI 3 Sugar
  • Matt Sweeney’s YUI 3 Performance
  • Luke Smith’s Debugging in YUI 3
  • Isaac Schlueter on Solving Problems with YUI 3
  • Eric Ferraiuolo on Web App Development with YUI 3
  • Luke Smith’s Events Evolved
• Read up on YUI on the Yahoo! Developer Network. I try to read a little bit every week and learn more each time I re-read it.
• Read the API documentation. If you can’t find it on YUI Theater or on the Developer Network, dig into the API. It even pays to read the code directly.
• Read and post questions to the forum on YUILibrary.com.
• Play a lot and have fun!

Conclusion

YUI 3 is a full-featured, mature and constantly evolving library suitable for small to large projects. As front end web applications become more complex, the need for libraries like YUI will grow. While for the uninitiated it can be a daunting experience at first, if you stick with it you will be rewarded.

Find conversations: bloglines | technorati

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

Building TipTheWeb with YUI 3

October 5, 2010 at 9:35 pm by Eric Ferraiuolo | In Development, In the Wild, YUI Implementations | Comments Off

About the Author: Eric Ferraiuolo is a Director of TipTheWeb and Co-Founder of Oddnut Software. He writes on his blog: 925 HTML, and can be found on Twitter: @ericf. Eric was a featured presenter at YUIConf 2009.

TipTheWeb is a new service that lets people directly support their favorite web content by tipping it. For instance, if you find a great blog post, you could tip it 25 cents.

TipTheWeb is a non-profit organization promoting freely-accessible, high-quality web content by awarding publishers that receive tips. If you publish online, you can use your TipTheWeb account to claim the places you publish to receive tips and be eligible to receive awards from TipTheWeb.

TipTheWeb’s Use of YUI 3

The user interface of TipTheWeb is completely built on top of YUI 3 (we drank the Kool-Aid.) The approach we took was to use YUI 3 as the foundation and structure for our JavaScript code. We’ve built 33 custom YUI 3 modules (56 if you include submodules, plugins, and roll-ups), several of which we contributed the YUI 3 Gallery: Component Manager, Markout, Overlay Extras, and REST Resource.

Page-Level Classes

The core features of TipTheWeb are implemented on a few highly-functional web pages which communicate with the server over Ajax. For each of these pages we created a custom YUI 3 module that exposes a page-level class used to coordinate actions between the functional parts of the page.

In one of our application’s main pages, the Tips page, you can see how this approach is applied with the page-level class TipsWindow. The main functional parts of the page are the widgets: CreateTip used for creating tips, and the TipList widgets for editing, canceling, and funding existing tips.

A Lot of Overlays

We use Y.Overlays extensively throughout our application’s UI to implement user-interactions; this allows us to keep the interface clutter-free while still having the functionality for advanced features available on the page. We needed features that were not built into Y.Overlay, so we developed Overlay Extras, which is in the YUI 3 Gallery and being used by a lot of other YUI 3 powered sites. Here are some place where we use Overlays on TipTheWeb:

Current State of TipTheWeb

We’d love for you to try out TipTheWeb; right now we are in invite-only beta, so request an invite on our site and we’ll send you an invite code.

Be sure to catch our talk at YUIConf 2010 where we will be presenting (more in depth) on how we use YUI 3 and YQL at TipTheWeb.

Find conversations: bloglines | technorati

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

Implementation Focus: Car Rental Express

September 28, 2010 at 6:01 am by Stefan Klopp | In In the Wild, YUI Implementations | 2 Comments

Car Rental Express is the leading independent car rental comparison website on the Internet. It lets users rent cars online in more than 1000 cities and airports around the world.

Our user base is largely non-technical, which means they want to compare prices and rent cars as easily as possible. With the relaunch of our website in June of 2010 we have implemented many components of YUI 2 to help provide our customers with an intuitive experience.

Which YUI components are we using?

The components that we’ve been using include Connection Manager, AutoComplete, DataSource, Calendar, Animation, JSON, and Container.

Why we chose YUI

When reviewing the different JavaScript libraries that we could potentially use on Car Rental Express, we found that the YUI was the most complete for our needs. The biggest selling features for us was the very modular approach the YUI took to implement different design patterns, as well as the robust documentation and examples they provided. From a development standpoint this led to rapid development of our application without having to struggle with a library.

How we use YUI

We utilize the YUI in a number of ways. Our 4 most used components are AutoComplete, Calendar, Container, and Connection Manager. Here are some of the ways we use each of these components.

AutoComplete

The AutoComplete component is used extensively on our site to help users find a city or airport in which to rent a car. We really liked how easy it was to implement this component, and how quickly it responds. We cache search results server-side to help improve search results; however, having the client-side caching also helped tremendously in speeding up the response of the component. Another feature that we really took to was how easy the results were to style. When displaying the locations to the user this was crucial as we needed to identify which locations where found in cities and which were found at airports.

Calendar

The Calendar component is also used throughout the site when a renter is filling in dates to conduct a search. We are using a customized version of John Peloquin’s Interval Selection Calendar and displaying it in a YUI Dialog. Essentially what we wanted to do was give the renter a two-month view when choosing their dates, as well as visually show them what date range they currently have selected. Again, this was extremely straightforward to implement using YUI 2 Calendar, and it basically came down to creating a YUI Dialog, setting the body to contain a div for the Calendar, then attaching a YUI Interval Calendar to that div.

Containers

We utilize YUI Containers throughout our website in a number of different ways. In the example above we were using a Dialog to help us display the Interval Calendar when a user was selecting a date. On our rate search results page we make heavy use of Containers to give the renter more information on different aspects of the car rental agency and the vehicle they might potentially rent. Most of the containers on this page are Panels that we re-use for each different listing. For example, the vehicle display features Panel:

Things got a little more fun with the Renter Rated agency ratings. When displaying the ratings, we really wanted to focus the user’s attention to the scores an agency received and to display this information in a clean, easy-to-view way. By utilizing the Dialog Control we were able to constrain the viewport and center the dialog easily to help us achieve this goal. By setting a blank header and footer it made styling simple by just adding the appropriate styles to our CSS. The end result was a clean ratings container that provides the renter with the information they want.

Connection Manager

Connection Manager is used throughout the site whenever we need to pull data via a XHR request. In some of the examples above we utilize this component for requesting cities and airports for the AutoComplete implementaitons and pulling the rating information for the Renter Rated Dialog.

One interesting way we utilize Connection Manager is with our rental center block that sits on most pages. To help with performance we do a lot of full-page caching on many of our content pages. However, we still wanted to display the dynamic rental center block on these pages. This presented us with a problem we were able to solve with Connection Manager. Rather than having to break up our fully cached page and cache only aspects of the page we found it was easier to just include the rental center block via a simple asynchronous request. We found that this allowed us to retain the performance from having a fully cached page, yet still display dynamic content in our rental center box.

Final Thoughts

Overall we have been extremely happy with our choice to use YUI. It provides us with a modular library that is well documented, easy to use and implement.

Find conversations: bloglines | technorati

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