Yahoo! User Interface Blog

Periodically, we touch base with developers in the community who are implementing YUI for projects outside of Yahoo. Kris Cieslak caught our eye with some YUI-powered games that he posted to the Yahoo! Gallery. Kris is the author of the digitalinsane blog which focuses on web development and JavaScript programming. He writes Ajax and DHTML applications mostly powered by JavaScript libraries like YUI and supported by other web services.

What is your background in frontend engineering?

I started programming when I was 10, writing a few games in BASIC on my Commodore 64k. When I bought my first PC I started learning Pascal, C/C++ and assembly language. I was on the Polish demo scene, as a very newbie coder, and I learned a lot from the professional coders. In college I worked on Windows XP Registry and wrote an advanced Registry Manager in Delphi. Recently I started programming in JavaScript and started my blog.

When did you first learn about YUI? What was the first application you wrote with it?

About six months ago. I’ve really the Yahoo APIs; this is why I decided to spend more time working with them and with YUI. My first application based on Yahoo services was Image-Search! and the first project I created with YUI was Yetris!.

What games have you written using YUI?

I’ve written four games based on YUI. The first was Yetris! — a JavaScript version of the classic game which probably everyone knows. This was my first project based on YUI and I spent four days working on it. I spent most of that time reading the YUI’s documentation and trying to adjust my ideas to the YUI environment. I started writing Yetris on 31 December 2006 about four hours before midnight; many people spend that time at New Year’s parties but I was learning YUI.

The second and my favorite game is Puzzle. This application is based on YUI and the Flickr API. The hardest part was to figure out how to divide photos into small pieces using only JavaScript. If you have one or two images you can use graphics applications to do that, but what if you have to manipulate millions of photos? As you can see, I found a solution.

When I had finished the Puzzle, I remembered a version of Space Invaders written in assembly language which I found on programmersheaven.com, and that inspired me to write a JavaScript clone of that classic game. I had a real problem with performance in Firefox and I had to spend lot of time optimizing the code especially for that browser.

Solitaire is my most recent project. I spent one week, six hours per day working on it. I hadn’t used drag and drop techniques before, and there was a lot to learn. When you look
at the code you will see that it is complex but it is also very compact. Without YUI the problem would be very hard to resolve. I wrote four different versions of that game using four different techniques. And the last technique proved the best and works very well on three popular browsers.

In using YUI for these projects, what aspects of the library have been particularly pleasing to work with and powerful in solving problems?

YUI does a great job keeping balance between functionality, the size of the library and performance of the functions. Generally I’m using YUI because it’s solving the problems with cross-browser compatibility, because I can easy manipulate each element/layer, because I can get or change the position, color, transparency of each object, because I can use the Drag and Drop Utility, and of course because of the Animation Utility — very effective and simple in use.

For me, the most important parts of the YUI are Dom and Event. These libraries resolve most of my problems with browser compatibility.

What pain points have you noticed in using YUI? What would you like the YUI team to focus on next?

At the beginning, I had the problems with documentation. Each of the functions is clearly described. However, I didn’t know how to use them. I would like to see more simple examples; these are more important than any description, especially for complex functions.

As for what to add to the library, maybe advanced mathematical libraries (numbers conversion, vectors, complex, angles, statistics, calculator widget etc…) would be nice to see in YUI.

What’s next on your plate? Any exciting projects coming down the pike?

Doom3.js! I’m joking. However, creating 3d shooter in JavaScript is not impossible. I think it is possible to make a game similar to the early version of Wolfenstein 3d but without textures and animated sprites (enemies), with very, very simple levels.

Do you have a YUI implementation that would be of interest to the YUI community? If so, please share your link and post a message to the community forum at YDN-JavaScript, or leave us a message in the comments section below.

Most Ajax Applications Break Standard Browser Functionality

Our industry has made significant progress in the past few years. Web pages have become vastly more sophisticated in terms of appearance and responsiveness. Some companies have pushed the envelope so far that their web page could easily be mistaken for a native application (check out Scalix Web Access or the new Yahoo! Mail, to name just two examples). In the meantime, that same rush to produce the most stunning web experience has led us to forget some of the most basic principles of the web. Our pages run inside a web browser, and even if modern web browsers can now be used to support very complex applications they are mostly used for what they were originally intended to do: browsing the web.

This dual purpose creates a lot of confusion among users. Some of the basic features of browsing, such as the use of back and forward buttons, or the ability to bookmark a page, rarely achieve the desired result in a dynamic web application because dynamic changes to a page do not naturally register themselves with the browser’s native history engine. Moreover, there is a difference between "backing out changes" in an application — the undo command, ctrl-z — and retracing one’s steps in a navigation context. Many web-application developers find themselves puzzling over what role the back button should play when they make the transition from writing web sites to writing web applications.

Ignorance Is Bliss…

Only recently did I find myself impacted in my own work by the absence of a good solution for managing navigation history and session state in a rich application. At the time, I was working on a very simple web site for my father’s new venture. After “ajaxifying” the site, the navigation became a lot faster. However, a coworker of mine pointed out to me that the back and forward buttons were not working anymore, and that individual sections of the web site could not be bookmarked. In my case, this problem was a deal-breaker; I absolutely had to find a solution. After a bit of time digging around on Yahoo! Search, I discovered a long and impressive library of articles from developers attempting to solve this problem.

Currently Available Solutions

One of the most important articles in this collection is Brad Neuberg’s piece on how to handle bookmarks and the back button in Ajax applications. Neuberg’s Really Simple History (RSH) framework works well on most browsers, but unfortunately it does not work on Safari — considered an A-Grade browser in Yahoo!’s Graded Browser Support approach. Another disadvantage of the RSH framework is the need for a server round-trip every time a new entry is added to the browser history on Internet Explorer. Nevertheless, Neuberg’s work, which pushed back the frontier on this difficult issue, made me believe that my quest was not hopeless.

I then read Mark Schiefelbein’s article on developing Ajax applications that preserve standard browser functionality. His article mainly looks at the Backbase Ajax engine and how it provides support for the back/forward buttons. The Backbase solution works well, but I was once again confronted by the issue of browser support; their demos do not appear to work on Opera and Safari. Moreover, Backbase is a commercial product, and I wanted a solution that would play well with the open-source tools I was already using, and in particular one that could be included as part of YUI.

Creating a Browser History Manager for YUI

Given that background, I decided to tackle the problem on my own. After a little bit of tinkering, I was able to put together a demo that worked on Firefox and Opera using the URL fragment identifier. The idea is very simple: Change the URL fragment identifier, using the window.location.hash property, to add a new entry to the browser history and periodically check the value of the hash to detect history changes. In addition to solving the issue with the back/forward buttons, this also allows the application to be bookmarked in a specific state. This approach provides support for Firefox (and other Gecko-derived browsers), Opera, and for recent nightly builds of WebKit (the open-source rendering engine underlying Apple’s Safari browser). Unfortunately, the window.location.hash approach does not work fully on current versions of Safari — and, more importantly, it does not work at all on Internet Explorer. It might serve as part of the solution, but it obviously couldn’t constitute a unified approach across browsers.

One of my colleagues at Yahoo!, Dav Glass, is an accomplished Mac geek who has a great deal of experience solving hard problems on Safari; Dav volunteered to help tackle browser history in the current versions of Safari. With Safari, there were two main issues to overcome:

1. We needed to identify when back forward interactions occurred;
2. When those interactions occurred, we needed to identify where we were in our stack of saved states.

After reading David Bloom’s post on using document.body.scrollTop, we started thinking about what other properties might change during back/forward navigation. So we wrote a script to dump all the window.* variables and found out that, in Safari, window.history.length changed each time the browser history changed — not that it should change, but it clearly did. Armed with this knowledge, we began by setting up our own “history” array to track the changes keyed off of the window.history.length change. This approach gave us the two pieces of information we needed: We could tell when the user hit "back" or "forward", and we could tell where they were when they did so. (Note: The fact that window.history.length changes when the user hits the back button is a bug that has been fixed in WebKit. Therefore, this approach requires “forward compatible code” for Safari by using the URL fragment identifier as the preferred, long-term method of detecting history changes; we only fall back to relying on the history object itself when it’s necessary to do so. Over time, the window.history.length hack will become less and less important.)

All of that still left us in need of a solution for Internet Explorer. On IE, we had to adopt a radically different approach. We create a hidden IFrame that we initially point to an existing document on the web server. Writing to the IFrame using document.write adds a new entry to the browser history. The HTML we write looks like this (”current_state” is replaced by the actual state of the application):

We then periodically (every 50ms) look at the content of the IFrame — especially the text inside the inner <div> element — to detect history changes. Once we detect a change to the history, we change the URL fragment identifier using top.location.replace(...); this technique allows the application to be bookmarked in a specific state without impacting IE’s history stack.

In sum, the YUI Browser History Manager uses three different techniques to provide support across the A-Grade browsers:

The Problem Of The Initial State

Another concern in creating the Browser History Manager was to provide a mechanism for identifying the initial state of the application when the page/application loads via the back button (eg, the user has navigated away from the application to another site, then returns to our application using the back button). Indeed, from a programmatic standpoint, returning to a page using the back button or the forward button, or simply loading the page for the first time, are identical scenarios. However, the state of the application may need to be different depending on the situation. For example, if you return to a page using the back button, the state of the application should be the last state visited by the application before you left the page; this will likely be different from the initial state when the page first loaded during this browser session.

We approach this problem by storing state information in a hidden form field because the value of form fields persists across pages during the entire browser session. If we set the value of our form field to the current state of the application every time the application changes state, we can then initialize our page appropriately when the user returns to our application after having interacted with it beyond its initial state.

Intended Use: "Back" vs. "Undo"

The main role of the YUI Browser History Manager is to persist the history of states visited by a web application within a single browser session; in this week’s initial (and experimental) release we believe that it handles this problem well. However, there are limits to what these techniques allow you to do. The simple fact that URLs have a maximum length limits the amount of state data that can be stored (that limit is browser dependent — it is 2083 bytes on Internet Explorer, a bit more on other browsers). Imagine for example a TreeView Control containing thousands of nodes located at several levels of depth. If you wanted to represent the collapsed/expanded state of each node as a string, you would quickly run out of room; the information space provided by the URL doesn’t have the capacity to support that level of detail. More complex web applications can have a theoretically infinite number of states.

Given these limitations, and given the user’s expectation of what a "back button does" as compared to an "undo" command, we recommend thinking about the Browser History Manager as a tool for managing high-level navigational states: what screen is displayed, what tab is selected, what month is being displayed in a dynamically-generated calendar, etc. Because we cannot encode an infinite number of states, the back button cannot act as an “undo” command that takes snapshots of session states at high resolution throughout an interaction — and it shouldn’t try to do so. This sometimes subtle difference should drive the way you plan to make use of the YUI Browser History Manager.

Feedback

Due to the complexity of this problem space as it applies to the A-Grade browser family, we’re releasing the YUI Browser History Manager as an experimental utility at this point. We look forward to your feedback (here, or in our forums), and we hope to improve this implementation over the coming months to make it a genuinely robust, reliable, and cross-browser utility that solves one of the most vexing and problematic challenges involved in building rich internet applications.

We released version 2.2.0 of the Yahoo User Interface Library (YUI) today. This release is one of the most substantial revisions we’ve done to the library since its inception. Leading the change manifest is a new versioning track and three brand-new YUI components:

New versioning, 0.12.2 —> 2.2.0:

YUI was released internally at Yahoo! about six months before it was released for public use under a BSD license in February 2006. Although the internal and external versions of the library were identical, the way we built and distributed them was different and we managed those differences with separate versioning tracks. Today we’re merging the internal and external project versioning and reaffirming that the YUI you can download here is exactly the same YUI Library used all across Yahoo!. Hence, we’re retiring the old public version series (which had reached 0.12.2) and we’re unifying the versioning of this release at v2.2.0.

Browser History Manager

Building desktop-style applications within web browsers — which were designed to read hyperlinked pages, not to run apps — has created many challenges. Not the least of these challenges involves handling "back/forward" navigation buttons and bookmarking. First, there’s the tough question about just what the back button or bookmark should do in your app to be consistent with your user’s intuition/expectation. Then there’s the question of how to make your desired implementation work across all the A-Grade Browsers. No one, as far as we know, has resolved the technical issues in a satisfactory way across the A-Grade. Today we’re releasing the YUI Browser History Manager, an experimental component that supports all A-Grade browsers in managing the back/forward button navigation and bookmarking for dynamic web pages. Stay tuned to YUIBlog for a deep-dive on Browser History Manager from its author, Julien Lecomte, later this week.

DataTable Control

YUI engineer Jenny Han Donnelly, who brought you the Logger and AutoComplete Controls, rolls out her third component today with the DataTable Control (beta). Tabular data is one of the most common UI presentation tasks. DataTable allows you to present tabular data and allow your user to engage that presentation by modifying/enhancing the data, sorting and searching through it, and adjusting the presentation itself (by, for example, changing column widths). DataTable’s debut featureset includes:

• Progressive enhancement: DataTable is built on the foundation of HTML table element markup, providing a solid progressive-enhancement path.
• Nested column headers
• Custom sort functions
• XHR data sources: Integration with Connection Manager offers robust support for pulling in off-page data.
• Inline editing: Contents of cells can be editable, allowing users to update the information they’re reviewing.

This is just our first release of the DataTable control, and we know that there are many possibilities for pushing this implementation further; we look forward to hearing your feedback in the YUI Forums about this release and what you’d like to see next.

Button Control

Todd Kloots, author of the Menu Control, today brings you the new Button Control (beta). Buttons are essential parts of most graphical interfaces, but the visual constraints of buttons in their various form-control implementations (submit buttons, radio buttons, check boxes, etc.) diminish their effectiveness in some applications. The Button Control provides a platform for implementing visually impactful buttons that range from standard click-to-navigate buttons to radio buttons and checkboxes to advanced split-buttons that can operate as both a button and a menu.

Other Noteworthy Changes

In addition to the three new components and the new versioning scheme, YUI in 2.2.0 incorporates a number of other significant changes to the library generally and to components specifically. Some noteworthy changes include the following:

• Reorganization of utility classes: Several utility classes (including Element and KeyListener) were originally introduced as part of the component for which they were written — Element, for example, was part of the TabView distribution. We have begun a reorganization of these utility classes, allowing them to serve a wider range of YUI components and to be more logically accessible within your own implementations. Today, KeyListener becomes part of Event and Element breaks out of TabView to become its own (beta) component…and hence a new dependency for TabView.
• The YAHOO Global Object:
  • YAHOO.lang: The YAHOO Global Object now ships with a lang member; extend and augment are moved under YAHOO.lang, as are a variety of new utility methods for determining object types. Among YAHOO.lang’s members is a hasOwnProperty method normalizing the behavior of that test for Safari 1.3 and older. We have implemented YAHOO.lang.hasOwnProperty for all of YUI’s hasOwnProperty invocations; although Safari 1.3 is not an A-Grade browser, this should allow YUI-based applications to degrade more generously on older versions of Safari.
  • YAHOO.env: YAHOO.env is another new YAHOO-object member introduced with v2.2.0; it contains version and build information for all YUI components that have been loaded in the current window. Using YAHOO.env’s methods and data, you can determine which of your required components are already on a page and, if present, which version has been loaded. (Note that versioning information will only be available for implementations of YUI from v2.2.0 onward.) This facilitates, for example, the work of engineers creating YUI-based badges and modules that appear in diverse contexts, some of which already include YUI implementations.
• New YAHOO_config global: With this release we are introducing a new global variable, YAHOO_config, that allows you to define certain configuration characteristics of YUI prior to loading the YAHOO Global Object. The significant and immediate win here is that you can use YAHOO_config to define a listener that will be invoked any time a YUI component is loaded on the page. For scenarios where you’re adding components dynamically, this will prove valuable in ensuring that dependencies are loaded in the correct sequence.

There’s much more we could say about this release, and there’s more to come on YUIBlog soon — plus a nice bit we’re looking forward to sharing with you at the party on Thursday. For now we encourage you to download the new distribution, explore the updated documentation on the YUI website, and begin exploring it for yourself. Release notes for each component can be accessed from that component’s main documentation page; it’s in those release notes that you’ll find detailed change manifests for each component.

Periodically, we sit down with developers in the community who are implementing YUI for projects outside of Yahoo. Yesterday I sat down with engineers from OurStory.com, including VP of Engineering and co-founder Chris Lunt, Chief Architect (and former Yahoo!) Tim Correia, and Senior Engineer Jerome Poichet.

OurStory.com is a company that’s gotten a lot of good press in the past year and enjoyed another recent boost with its participation in Demo ‘07. In the video below you’ll get a good sense of what the OurStory product is about — if you imagine a web-based storyboard for aggregating multimedia clips and blog-style text entries about the events of your life, you’ll be on the right track.

I got together with the OurStory team to learn more about how they’ve embraced the interleaving and interconnectedness of today’s web by using APIs from Flickr, Yahoo! Image Search, and del.icio.us, while simultaneously harnessing the energy of the open-source community by building on top of resources like YUI (they’re using Event, Dom, Connection Manager [including file upload], Animation, Drag & Drop, Container, Calendar, AutoComplete, TabView, and some of Jack Slocum’s utilities). If you want to get a sense of what a fully realized Web 2.0 product looks like — one that goes far beyond the ad hoc nature of most mashups — OurStory.com will be of interest to you. (The highlight for me is the use of the Yahoo! Term Extraction API to extract key terms from story entries and to then to suggest images from Flickr or Yahoo! Image Search based on the extracted terms; watch for the waffle demo at about the 7-minute mark….) And if you’re interested in how YUI components can work together to build a rich, coherent, attractive and performant interface, Tim’s exploration of OurStory’s YUI integration is a must-see.

At the end of the ~10-minute video, I asked Chris, Tim, and Jerome to talk about both the good and bad aspects of building on top of third-party APIs and to discuss some of the pain points they’ve experienced using YUI. I think you’ll find their answers illuminating, particularly Chris’s discussion of how the vastness of Yahoo! Image Search — what he calls its “access to esoterica” — can be a double-edged sword.

Do you have a YUI implementation that would be of interest to the YUI community? If so, please share your link and post a message to the community forum at YDN-JavaScript, or leave us a message in the comments section below.

Periodically, we sit down with developers in the community who are implementing YUI for projects outside of Yahoo. Yesterday we met with a team from the marketing firm Genius.com, a company that specializes in helping sales professionals monitor (in real time) the impact of emails sent to qualified sales leads. Genius.com allows salespeople to track who has read an email message, which recipients have gone on to visit related web content, and which recipients are looking at that content at any given moment — all of which allows for a highly personalized followup response. Ryan Ausanka-Crues, Nader Farahani, and Chris Krueger from Genius.com met with us to talk about how they are using YUI to create their rich interface and that crucial sense of interactive immediacy necessary in a product that communicates real-time feedback to its users.

At what point did you begin evolving your application to use a rich interface? What were the original tools/libraries you used?

The company from day one started as a Web 2.0-focused project, but we didn’t have the engineering resources to create everything ourselves — we knew that from the beginning. So we looked at a lot of UI libraries back when we were getting started on the product. We looked at Dojo, and we looked at Google’s web toolkit and some of the commercial libraries. We had a big decision to make about whether to spend money on a commercial product or use one of the open source packages. Ultimately, we found that what we could get from the open source community was more than enough for us.

Why did you choose YUI as part of your JavaScript foundation?

What attracted us to YUI specifically was the documentation, first and foremost. It was surprising, at the time we were doing this research, how many good tools were out there that simply didn’t have enough documentation to make us feel confident about doing complex implementations. YUI’s documentation makes it easier for us to hire people, too, because with YUI we don’t need to hire someone with YUI-specific skills. A good programmer can come to YUI and learn it based on the documentation. That’s been important to us lately as we’ve grown the company.

The YUI examples were another factor that drew us to YUI; you could see immediately how each component was meant to be used and whether it solved our core problems.

The final key draw to YUI for us was the quality of the APIs throughout the library. It was compelling to see how much thought was given to writing the APIs and designing them in such a way that it would make sense to use and to build on. The APIs resonated for us, made sense immediately in many cases, and that made it much easier for us to feel comfortable building on YUI.

There’s a sense, too, that with Yahoo! behind this it will be around for a long time and will continue to receive real development commitment.

How are you using YUI in your site today?

Today we’re using the Animation Utility, the Dialog Control, the Calendar Control, and Jack Slocum’s YUI-ext Grid, among other things. We’re beginning to implement Connection Manager for XHR transactions, and we do a lot of that. We have a lot of work under development that extends this even further. We’re in the process of converting wholly to YUI from some in-house components and from some other third-party pieces. We’re now in the process of converting every XHR call to Connection Manager; in one place, we’ve ripped out about 700 lines of XHR code and replace it with 130 lines based on Connection Manager.

We’re also in the process of converting every table from an old hand-rolled solution to Jack’s Grid or the upcoming YUI DataTable.

You’ve mentioned that you’re using Jack Slocum’s YUI-ext library, an extension of YUI. What holes has Jack’s work filled for you?

Jack’s work was one of the things that put us over the top for using YUI . Some of the components we really needed, like the Grid, weren’t in YUI, but Jack had them; Jack’s Grid really made it possible for us to use YUI. And we could see how Jack was extending YUI and the patterns he used to do that; that showed us that there was a solid foundation for building our own implementations and going beyond just what YUI did out of the box. Another thing that we really liked about Jack’s work is the richness of his examples visually; he goes beyond the base YUI in terms of styling his examples, which is really important to us as we try to style our own components. We’ve also gotten accustomed to Jack’s implementation of the API documentation, which is based upon but styled differently than the documentation on the YUI site.

How has the YUI implementation process gone for you so far?

Our CTO really pushed us in this direction. We knew we needed to get ourselves onto a coherent platform, whether it was Dojo or YUI or something else. And when we went down this path, the experience really validated the decision to migrate to a platform. Things we’d been struggling with for a long time we were able to mock up in a couple of days once we moved to YUI. Jack’s Grid was a good example of that.

Compared to where we were, it’s been a huge step forward.

What are some of the pain points you’ve experienced while using YUI?

It would be better for us if there was more attention given to the graphical or visual aspect of the examples. It would be easier for our visual designers to work with the examples if they had more of the visual richness that will ultimately be part of the product.

Getting started was tough back in the early days for us — there’s so much information on the YUI website, it can be hard to know where to start. There were challenges early on, too, in just tracking what includes were needed — that information was available in the documentation, but not in the API docs, and so we spent some time learning how to track dependencies (Editor’s note: dependencies are now included in API docs as well as in user guides). Back in the early days, we would have benefitted from a "Getting Started with YUI" guide or tutorial.

Do you have a YUI implementation that would be of interest to the YUI community? If so, please share your link and post a message to the community forum at YDN-JavaScript, or leave us a message in the comments section below.