Yahoo! User Interface Blog (YUIBlog)

Ask Satyam — and Be Eligible for a Free Copy of the New YUI 2.8 Book from Packt

Satyam (Daniel Barreiro) wrote last week about his experience writing YUI 2.8: Learning the Library, the new YUI 2 volume now available from Packt.

Packt has generously offered a few free electronic copies to YUIBlog readers. Suggest a question or tutorial you’d like to see from Satyam on a YUI 2.8-related topic as a comment on this post, and if Satyam picks your suggested topic for one of his three “Ask Satyam” blog posts Packt will make an electronic copy of Satyam’s book available for you to download.

Satyam will be posting answers to his three favorite questions here on the blog over the next month or so.

Find conversations: bloglines | technorati

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

YUI 3.2.0 Preview Release 1: Touch Event Support, Gestures, Transitions, CSS Grids, ScrollView, Uploader, and More

The YUI contributor’s team is pleased to announce the first developer preview of the upcoming YUI 3.2.0 release. This preview provides an opportunity for developers and implementers to help test the release for potential regressions and to provide feedback on new features and components. If you have an existing YUI implementation, please exercise YUI 3.2.0pr1 in your development environment and let us know what you find.

There are three ways to get started with the preview release:

• Use from the CDN: YUI 3.2.0pr1 is available on the CDN via the 3.2.0pr1 version tag — so you can reference preview-release files like http://yui.yahooapis.com/combo?3.2.0pr1/build/yui/yui-min.js. If you switch to this seed file for the preview release, all subsequent use() statements will continue to load YUI 3.2.0pr1.
• Download the release: Download YUI 3.2.0pr1 from YUILibrary.com, including source code and examples for all components — including those new to this release.
• Explore the examples: As a convenience, we’ve posted the preview (along with the functioning examples roster) to YUIBlog. Feel free to explore the release there as a prelude to switching your CDN version reference (or downloading the preview) and testing it out in your own environment.

Noteworthy Changes Coming in YUI 3.2.0

As with all YUI development work, you can track our current plans and progress on our YUI 3 tasklist, including a comprehensive list of YUI 3.2.0 (and some upcoming 3.3.0) changes; you can also check in on our progress addressing issues in the bug database. Here are some of the new and updated components featured in the 3.2.0 developer preview:

• Intrinsic support for touch events has been added (mynode.on("touchstart", function(e) {});). We’ve also added a Gestures module with two bundled gestures — gesture-flick and gesture-move — that work with both touch- and mouse-driven devices. Check out the API docs or the bundled sample page for ideas about how to start using Gestures.
• YUI’s intrinsic Loader now supports capability-based loading. This allows us to segregate, for example, IE-specific code into separate submodules and allow the Loader to bundle that code only for browsers that require it. We’re leveraging this new feature to avoid shipping IE-specific code in the Dom module to non-IE browsers, a performance/k-weight boost that will benefit all users of modern browsers with no code change required.
• YUI 3’s animation portfolio now supports transitions via the Transition module, providing browser normalization for this powerful, hardware-accelerated (where available) technique for handling transitions; check out the example for sample code. Animation, in its most basic form, has a streamlined dependency tree for modern browsers, significantly reducing the k-weight for simple animation in better browsers.
• YUI 3.2.0 will bring with it a new beta version of YUI’s CSS Grids component, and you can begin exploring this new approach to Grids in the preview release. The examples are the best place to start.
• We worked with Michael Johnston of the Yahoo! Mobile Engineering team to bring a new (beta) ScrollView widget to YUI 3.2.0. ScrollView provides a scrolling pane implementation familiar to users of native Apple iOS applications, emulating the elasticity of the element when scrolled to the beginning or ending limit. You’ll see in the 3.2.0pr1 examples for ScrollView that this component is device neutral, working well with a mouse as well as with touch events on your Android or iOS device.
  
• The Uploader component from YUI 2 is now part of the YUI 3 family as well, debuting as a beta in 3.2.0.
• The History module that debuted with YUI 3.0.0, which was a port of the YUI 2 version, has been deprecated (it remains available in YUI 3.2.0 as history-deprecated). A new beta History utility debuts in 3.2.0, based on Ryan Grove’s History Lite module from the YUI 3 Gallery. A preview-release example from the new component is a good starting reference.
• The JSONP and YQL Query modules from the YUI 3 Gallery have become canonical components, debuting as beta in this release.

Feedback

The goal of a preview release is to make it as easy as possible for all of us in the community to evaluate progress of the upcoming release and provide feedback. Please take some time to test 3.2.0pr1 and let us know what you find by filing tickets in the YUI 3 bug database marked as “Observed in version” 3.2.0pr1. We’ll do our best to address preview-release questions on the YUI 3 Forums, too.

Find conversations: bloglines | technorati

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

YUI Theater Comes to Boxee, Courtesy of Chad Auld and the Brilaps Team

YUI contributor and former Yahoo Chad Auld emailed us to tell us about his latest project with his Brilaps group — a project that has brought YUI Theater to the TV screen via Boxee. In Chad’s words:

Boxee is an up-and-coming cross platform application that aims to help bring web content to the TV. It is based on the open source XBMC project and allows users to write new plugins to bring in additional content. We launched a new project about three weeks ago to build our first Boxee plugin, and we selected the YUI Theater as the content we wanted to bring from the web to the TV. There are so many great videos archived there (and growing), we think it is a terrific source of content for developers to have access to from their couch (especially since most of the videos are a bit longer than someone might have time to watch comfortably from their laptop). It took us about a week to build the plugin, another week to polish it up and sort out a few bugs, and about a week to get the application approved by the Boxee QA team and pushed into the public repository. I just got word that it hit the public repository this morning and so I wanted to reach out and let you know.

This is fantastic news for anyone who has been enjoying YUI Theater content and would like to catch up on the latest from Douglas Crockford, Brendan Eich and all the other great YUI Theater speakers from the comfort of his/her couch. Check out the video above for a tour of the UI, and then go grab Boxee and get started.

Find conversations: bloglines | technorati

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

Frontend Engineering Positions Available with the Yahoo! Flex Force Team

The Yahoo! Flex Force is currently looking to expand our team with a few talented frontend Engineers. As part of the Flex Force team, you will have the opportunity to work on multiple strategic projects of high profile and high visibility. These positions involve being an ambassador of best practices and sharing knowledge across the organization. We work closely with the different platform teams, including the YUI team, to ensure we’re using the latest strategies, techniques, and tools.

As a recent example, the Flex Force team was behind the implementation of the new Yahoo! Updates widget which is built entirely using YUI 3.

To be successful at this role, you’ll need to be a self-starter and fast learner with a positive mindset who can quickly ramp up and take on different challenges. A true passion for frontend technologies and best practices is also required.

If working with me and my colleagues on the Yahoo! Flex Force sounds interesting to you, head to the Yahoo careers site and check out the following positions:

• Frontend engineer position #1
• Frontend engineer position #2
• Frontend engineer position #3 — this is a more senior role, with more experience and additional skills required

Find conversations: bloglines | technorati

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

YUI: Open Hours Wed, July 21st

For those of you that don’t subscribe to the YUI calendar or YUILibrary.com forum, the next installment of YUI: Open Hours will be tomorrow, July 21st.

This time we’re going to focus on a recurring theme for YUI community contributors that are just getting started building their own modules: How to build a Widget and how to build a Plugin in a YUI 3 way.

Anthony Pipkin, aka apipkin of #yui IRC channel fame, will be the guest, guiding us through his learnings over the last year and showing how to move from copying and pasting the YUI 3 documentation examples to feeling confident that you’re making the right choices for how to approach a problem in a “YUI 3 way of thinking”.

We’ll take a look at two of his simpler Gallery modules, the Button Widget and the Node IO Plugin. He’ll discuss what they looked like originally, versus today, and why they changed.

Then we’ll play around a while, maybe build something from scratch based on what the folks on the call want to cover.

Matt Sweeney (Node, Selector, TabView, Grids, etc) and Satyen “the Guru” Desai (Widget, Plugin, Base, Attribute, etc) from the YUI team will also be on the call. So there will be best practices in the house.

For YUI 3 consumers that aren’t (yet?) contributors, this call should still be valuable for understanding the thinking behind how YUI 3 widgets and plugins are built and what sort of patterns to expect from new YUI components. And no doubt there will be other great takeaways as always.

We’ll be online from 10am to 12pm PDT. The connection details are the same as usual.

1. Dial in to 1-888-371-8922 (non-US participants, email me for a local number)
2. Enter the attendee code 47188953#
3. Join the screen sharing session (this will prompt you to install the Adobe Connect plugin if this is your first time using it)

Here’s the forum thread for this Open Hours. I’ll post some of the interesting takeaways after the call.

Follow @yuilibrary on Twitter for the latest.

Hope to see you there!

Find conversations: bloglines | technorati

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

Author Notes: Writing YUI 2.8: Learning the Library, the New YUI 2 Book from Packt

In December 2009, editors at Packt Publishing asked me if I’d like to write the second edition of their book on the YUI Library. The original author, Dan Wellman, was engaged in other business at the time, and they needed an author who was broadly familiar with YUI 2. The first thing I thought was: aren’t you a little bit late? Much of YUI 3 was already out in GA and more was coming with every release. But the Packt team wanted to proceed, and I agreed to take on the challenge.

On July 16^th, the new volume came out, YUI 2.8: Learning the Library, not as a second edition but as a new title. In the end, it wasn’t such a bad decision. While the book was going through the editing process, YUI 3 gained the ability to load YUI 2 components from the use() statement. This extends the usefulness of the extensive YUI 2 catalog while taking the pressure off developers to produce YUI 3 versions of all YUI 2 components.

• Sample Chapter: Packt has released a sample chapter from the new volume, covering YUI 2.8 Rich Text Editor, on their website, giving you a flavor of what the new book contains.

The goal with this new volume was to cover all non-beta YUI 2 components. This broad vision forced me to take a deeper look at components I had barely used in their most basic forms as well as others I’d not used at all. However, in contrast to the first edition, a project that began not long after the library had been made public, I had a few years of cumulative experience with YUI — my own experience paired with that of the many users who share their experiences and advice on the forums and the blog. I was also spared from many blunders by an excellent team of reviewers, two of whom, Caridy Patiño and Iliyan Peichev, are also well known YUI contributors.

To keep the book to a manageable length, I eliminated some images, long examples, and reference material that could be found at the YUI website. While the first edition had at most two components per chapter, the new one has up to four and has a couple of new chapters. Even so, some components didn’t make the cut.

The Evolution of YUI 2

I learned a lot about the YUI Library while writing this book, and the changes I made to Dan’s text were instructive about the library’s evolution since its release in 2006.

The programming style for example code has changed in these years. Instead of creating a namespace (or using YAHOO.example, which is always available as a placeholder), we now tend to fit everything within an anonymous function created when the DOM becomes available. (This style is closer to what we see in YUI 3.) We now use namespaces when we absolutely need to create globally accessible variables (including objects) such as when we create a custom library component. Sandboxing saves us some typing, since we can define functionally-scoped aliases for the objects we use more often from YUI (Dom, Event, Lang are common shortcuts) or variables of our own. This approach also lets YUI Compressor do a far better job.

Having a panoramic view of the whole of the library allowed me to notice how it developed over time. The architecture of the components changed and it is clear how everything has converged into what is now YUI 3.

Early components, like TreeView, had few dependencies. As certain patterns started to become obvious, some basic component infrastructure started to develop. The Container family had a Config object which allowed for getter and setter methods, and so have all the components that inherit from it. It also uses the Custom Event object, which is one of the two ways to work with custom events we have available in YUI 2.

With the release of TabView came the YUI 2 Element Utility, which provided improved getters and setters (via AttributeProvider) as well as better custom events (via EventProvider). Seventeen other YUI 2 components inherit from Element. Looking at the evolution the library, it’s easy to see how the ideas behind Element, as a DOM element wrapper, came to inform YUI 3’s Node. Element’s role as a basis for other components was broken out in YUI 3’s Base and Widget, though the new components are all far more powerful and complete, each in its own area. For example, Node’s all and one methods return Node instances while Element’s getXxxx methods return plain DOM element references, not completely abstracting the DOM.

The two models, Config and CustomEvents on the one hand and AttributeProvider and EventProvider on the other are not totally incompatible. In Menu and Split Buttons both models coexist, as Button inherits from Element and it hosts a regular Menu that inherits from Container.

Undoubtedly, YUI 3 benefited from all of this experience; but YUI 2 also benefitted from YUI3. Cool stuff came from YUI 3 to enrich YUI 2, such as event-delegate and element-delegate and other new events we can listen to (focusin and focusout, mouseenter and mouseleave). This also became possible because of the way we load components, which changed during YUI 2’s lifespan — most importantly with the introduction of the YUI 2 Loader — and became formalized as intrinsic support for client-side loading in YUI 3.

Loading affected how the components got designed and how the final component files are built. In YUI 2, to minimize the number of outstanding server requests, the components had to have as much of what they needed packed together. Thus, some components got loosely related objects in them just to have them handy when and if needed, others got a bunch of objects with a whole range of features packed in one file because loading the separate parts was too costly. Then came aggregates such as yahoo-dom-events.js or reset-fonts-grids.css since they are almost invariably used together or utilities.js which gathers all the often used components in the YAHOO.util branch. But the real change came with combo-handled requests, which allowed us to pull any number of script and css files each in just one http request. That makes it less necessary to optimize the packaging of the objects in the library into component files and those into aggregates based on a hypothetical ‘average user’.

In YUI 3 we no longer need to load the ‘container family’ all at once. We can load the separate widget-xxxx files on top of the basic widget according to the features we need. That approach is the standard in YUI 3, but it came as one of the steps in the evolution of YUI 2. Hence, more recent YUI 2 components like event-delegate and element-delegate are packaged separately from from their base components and so is Event’s mouseenter and mouseleave. We might see further splits in library components in future releases, allowing you to choose more specifically the feature set you want and leave unneeded code off the page.

This is a story of progress, a process that necessarily went though some failed efforts. Why doesn’t TreeView inherit from Element or why hasn’t Container, and thus Menu, switched to Element or, at least, to AttributeProvider and EventProvider? Technically, the answer is ‘backward compatibility’, but in more general terms it is ‘respect’. There are thousands of websites (and tens of thousands of developers) using the the published public interface of the YUI 2 components. Making those changes would break many applications or would cut them off the upgrade path, should they want to benefit from a code fix or a new feature. Being so respectful of the installed code base is a library feature in itself. Being respectful to us, who create that code, is a feature of the people in the YUI team, and I’m very grateful it is so.

Find conversations: bloglines | technorati

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

Mobile Browser Cache Limits, Revisited

In Mobile Browser Cache Limits: Android, iOS, and webOS, I shared the results of my attempts to determine browser cache limits on Android, iOS, and webOS devices. At the end of the article, I wrote:

Use these results as a starting point, but verify them yourself before you make major decisions based on assumptions about mobile cache limitations. The mobile browser world changes at a lightning pace, so this research will have a very short shelf life.

As it turns out, that was good advice: the day after the article was posted, Steve Souders commented that he had run tests using a different methodology that was more representative of a real-world web workflow and had gotten different results.

New Methodology

My original methodology involved navigating directly to a randomly generated page of a certain size, served with a text/html content type. The results using this methodology were reliably reproducible (except on webOS), but as Steve pointed out, users don’t navigate directly to CSS and JavaScript files. My assumption that the limits for direct navigation to an HTML resource were the same as the limits for external CSS and JavaScript was incorrect, so even though the results of my tests were valid, they weren’t widely applicable.

Over the course of many IM sessions, several emails, and a couple of phone calls, Steve and I worked out a new testing methodology. I implemented a version of it on top of my cache testing framework, then Steve implemented a version capable of publishing results to Browserscope.

In the new tests, we load an HTML page that refers to a randomly-generated CSS or JavaScript component of a certain size. Then we navigate to a second HTML page that loads the same component and checks whether or not it was loaded from the cache. To determine whether a component was loaded from the cache, we store a timestamp in a cookie on each request; if the timestamp is updated the second time we load the component, we know the request hit the server, which means the component was not loaded from the cache.

New Results

We found that all the mobile browsers we tested had significantly higher cache limits for external resources loaded by a page than they did for an HTML page itself. This is excellent news for mobile web developers.

The table below illustrates our findings:

Note that 4MB was the largest size we tested, and all the iOS devices cached 4MB components. The actual cache limit for those devices may be larger than 4MB. Also, webOS on the Palm Pre Plus gave consistent results in this test, whereas it had some problems in the previous test.

It’s possible that the much lower limits my previous test showed for HTML components on iOS may indicate the use of a RAM cache for those components, while the much higher limits for CSS/JS components in this test may indicate the use of a disk cache, but this is just conjecture. Android, at least, does appear to use a disk cache in both cases, since its cache survives power cycles.

New Recommendations

Based on these new results, coupled with the results from my previous tests, I offer the following updated set of recommendations:

• Use far-future cache expiration headers. This will prevent the browser from having to send a conditional GET request.
• Try to limit HTML pages to 25.6KB or less if you want them to be cached, since the previous tests showed that this limit—imposed by iOS 3.2 on the iPad—was the lowest HTML resource limit of the devices tested.
• Keep CSS and JS components under 1MB. Of course, 1MB is enormous and your components should be much smaller than this, but don’t bother splitting a component into separate requests for the sake of cacheability unless its size approaches 1MB.
• Consider using the HTML5 application cache if it’s important that your components persist in the cache for a long time, or across power cycles.
• Do your own testing. I stressed the importance of this in my previous article and I’ll stress it again here. Use these results as a starting point, but verify them yourself before you make important decisions based on them.

Find conversations: bloglines | technorati

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