Austin Chau and I are here on the Yahoo campus for the Yahoo BrowserPlus release party. I'm going to blog the event as it happens here (Disclosure: I work for Google with the Open Web Advocacy and Gears teams).
First, Ernest Delgado, Canvas whiz here at Yahoo, sent me a cool demo showing a prototype he and Michael Johnston made of Yahoo Maps and Flickr integrating with Yahoo BrowserPlus using the native gyroscope on Macs. You just hit the side of the laptop, for example, in order to jump to the next Flickr picture, or tip your laptop to zoom around a Yahoo Map:
* Starts with some really nice demos of things you can create in the browser using YUI.
* Underlying technologies driving browsers are very complicated.
* About 7 knowledge areas needed for web development -- each is different than the standard, with bugs and specialized expert knowledge. You get about 672 different permutations of things needed for you to know and test on.
* YUI focused on "A-grade browser support".
* Good to target toolkits like YUI, since it helps you be future-compatible when new browsers appear like iPhone and Google Chrome
* Goal of YUI: Have a sophisticated widget like a rich text editor work cross-browser using just a snippet small snippet of code.
* Also want things to be automatically accessible.
* Progressive enhancement should be easy and possible, showing a cool demo of hierarchical menus still being readable on Lynx, a version of Firefox with no JavaScript, and then a full IE with CSS and JavaScript on.
* YUI is ala carte, file sizes are small, between 15 and 30K for any given component (including gziped)
* Deployed at Yahoo for three years, on every major property, 400 million users/browsers consuming YUI every month. In properties like Flickr and on the front page, well tested.
* YUI in lots of places: iGoogle, Wall Street Journal, Mozilla, LinkedIn, Southwest.com, Obama website, more
* ~1,000,000 external downloads
Now Lloyd Hilaiel is getting up to present on Yahoo BrowserPlus, the focus of today's event:
* The teams motivations: people get browsers -- browsers could be so much more -- plugins aren't working! Takes too long for new innovations to propagate (5-7 years)!
* Non-goals: no fixing web UI, no web outside the web (like AIR or Mozilla Prism), no improving JavaScript (that's the domain of YUI, JQuery, Dojo, etc.)
* YES to new web features with low overhead. Low overhead: low intellectual overhead, low overhead to implement and get it into widespread production
* Plugins have strengths (scriptable, cross-browser), but they have problems... installing them sucks, writing them is hard, sharing doesn't happen, updating is clumsy, securing them is hard
* BrowserPlus enables in-browser desktop applications
* Abstraction layer over web plugins. Implements all the stuff common to web plugs, decreasing cost of development and helping end users with management and installation
* User install core platform just once
* Page requests distinct services it wants to use, if not installed user is prompted to accept services and they are installed on the fly
* Demo of Flickr uploader working in browser using Yahoo BrowserPlus - drag and drop into browser of images, even folders for recursive uploading, 100% leveraging client-side functionality, multiple file selection.
* Demo of a BrowserPlus marble maze game using the Mac's motion sensor that exposes a single function that gives the laptop's x and y position and acceleration. Idea is that you can expose simple functions for custom hardware -- rest of app can just use web technologies.
* Demo where you can drop a file into a page and then work with the files contents, service coming out soon. Took just one day for them to create. Imagine dragging and dropping vCards or iCal files for example for a web-based calendering system.
* Demo showing desktop notifications
* Services installed on demand, no more monolithic plugins -- instead smaller services, installation seemless, no browser restarts
* Authoring of new services currently restricted to Yahoo and partners
* BrowserPlus will be Open Source! Goal is to have Service API and services open source by end of year, everything else by mid next year.
* Need to figure out how to protect end-users while removing Yahoo from the loop of handling serving up the services
* Yahoo roles: consumer of the platform and the project maintainer (bug fixes, feature requested, service adoption)
After a short break the team (Lloyd Hilaiel, Steve Spencer, David Grigsby, and Gordon Durand) did a deep dive on the Yahoo BrowserPlus architecture, security model, user-facing interaction, how web developers interact with it, and how to create your own services. There is some really impressive engineering in here; they've tackled some hard problems. There's lots of great material they went over, too much to summarize here. You can download the presentations from here in Keynote format.
Here's a snippet of using BrowserPlus from some JavaScript:
Services are either binary shared libraries (.so or .dll) or Ruby script! The Ruby interpreter itself is a Yahoo BrowserPlus service that other services can use (services can be composed together and can work with each other, similar to how Unix utilities work with piping).
Nicholas C. Zakas has posted about a new Yahoo! home page that uses YUI 3.x. They are currently testing the new home page out, but having it use the latest and greatest dogfood on a web page as trafficked as the Y! home page is a big deal. Save a few bytes here or there and you are talking serious benefits. Anyway, Nicholas talks us through some of the benefits that he saw:
I felt that building on YUI 3 would make implementing our design much easier based on several goals that we had for the framework:
Eliminate global dependencies. We wanted each part of the page to operate separately from all of the others. Each part should have no knowledge of what else is on the page and therefore can’t depend on objects to be globally available. The 2.x library is based on the global YAHOO object, which we would have had to abstract away; the 3.x concept of YUI instances that could be individually manipulated worked perfectly to achieve this goal.
Make it small, make it fast. The Front Page can’t afford to be slow, so we needed to have as little code as possible to get everything up and running. YUI 3 impressed us with its organization into small, atomic units that allowed us to specifically include parts of the library that we wanted while eliminating parts that were unnecessary. Further, one of the goals of YUI 3 was to optimize for runtime execution and make it faster than the 2.x version. Once again, YUI 3’s approach was directly in line with the Front Page’s goals.
Create version independence. From the start, we didn’t want to have dependencies on specific versions of YUI components as this can lead to maintenance issues. What we really wanted was for each part of the page to be able to use whatever version of the components that they wanted. The sandboxing feature of YUI 3 opened up the possibility of having two (or more) YUI instances each loading different versions of various components while not interfering with each other.
Allow code portability. Having worked at Yahoo! for a combined five years, Steve and I knew that anything we put on a Yahoo! property could be a candidate for porting to someplace else. We knew that this possibility meant the code had to stand on its own and not make assumptions about the environment in which it was placed. We thought about the most difficult environment possible: a locked-down browser environment where the JavaScript code has no direct access to the DOM. Since YUI 3 can abstract away the DOM through its Node interface, we had the entrypoint necessary to make this requirement a reality.
Be forward compatible. The project to create a new Front Page is an incredibly long one and we wanted to be as forward-looking as possible. We knew that if we created the framework on YUI 2.x that we’d be hard pressed to get time to upgrade later on. By building on YUI 3 from the start, we eliminated the need for developing an upgrade path later on.
BOSS - Build Your Own Search Service (the your is silent for reasons I cannot tell you as it would endanger the lives of our agents in the field) is a Yahoo! API to access their search index and get the data back either as XML or JSON. Whilst there is ample documentation available it can still be a bit daunting to use the API purely in JavaScript - especially when you want to have several asynchronous calls - for example when you want to search the images, news and web sites for a certain query.
I've had several complaints of Hackers at the Open Hack Day in Brazil about this and wanted to make their lives easier by writing a wrapper for the API.
This wrapper is yboss and it was a big success at the Hack Day with the winning hack in the BOSS category actually being based on it.
To use the wrapper all you need to do is to embed it in your document
Then you have access to the get method of the wrapper which searches all the defined search options with the query you provided. You can define a callback method that will be called when all searches have been successfully performed.
The data is provided either as a JSON object with all the mandatory properties for a BOSS result display or - as shown here - as HTML lists that can be written out via innerHTML.
Yahoo! has had a big day with a lot of Open platform releases (OpenSocial, YAP, etc) and to add to that they have released Yahoo! BrowserPlus version 2.1.6, which is important as it opens up the BrowserPlus platform for anyone to use.
It features:
Google Chrome and IE 6 support
Smaller 2mb installation
End user configuration panel for managing permissions on a per site basis
three new services
a fun game using the macbook's motion sensor!
full API documentation, code samples, and a new forum for developers
The services now available out of the box are:
DragAndDrop: Support drag and drop of files from desktop to web browser.
FileBrowse: Present the user with a file browser dialog.
FileChecksum: Allows client side MD5 of user selected files.
FlickrUploader: Provides an interface to the Flickr Authorization and Upload API.
ImageAlter: A service based on ImageMagick to alter images locally and and serve them over HTTP.
InactiveServices: A built-in corelet which allows for the exploration of available inactive services, which may be downloaded and activated.
IRCClient: A service that allows you to connect to IRC chat servers.
JSONRequest: Allows secure cross-domain JSON requests, inspired by http://www.json.org/JSONRequest.html.
Log: Access plugin logging facilities. The available levels in order of severity are Fatal, Error, Warn, Info, Debug.
Motion: Use the hardware based motion sensor or mouse position to attain the (virtual) orientation of the computing device. Mouse position allows a resonable fallback for machines that don't contain an accesible motion sensor.
Notify: Post notifications to the desktop. Supports Growl on Mac OS X, if installed.
PStore: Provides a persistent store.
RubyInterpreter: A service which allows other services to be written in Ruby.
TextToSpeech: A corelet that interfaces the OS provided text to speech facilities.
Uploader: This service lets you upload files faster and easier than before.
A lot of cool stuff there, and motion? nice!
I chatted with Lloyd Hilaiel of the YBP team, and he kindly answered some questions:
What are you most excited about with the release?
Most exciting to me personally is widening our audience. Throughout
the development of BrowserPlus we've been romping around Yahoo!
talking to people. Getting criticized, encouraged, and sharing ideas
about how the platform should work. This feedback has been critical
to our development, and has fueled some of the better decisions we've
made. During our sneak release we've gotten an order of magnitude
more feedback. Patches, hacks, and challenges from people all over.
Ultimately the kind of discussion that's needed to make good software.
So opening the platform for the world to use is the most exciting part
about this, and getting to hear more what people think.
Where do you see Y!BP fitting in with the Open Web?
Well, the problem we're most focused on is the difficulty in
authoring web plug-ins, both in terms of making them safe
(having robust features like revocation and versioning), and the
complexity of writing them (many platforms, many browsers, many
distribution and update mechanisms).
So possible contributions to the open web? Well eventually,
a decentralized means of supporting emerging standards by making
reference implementations safe and easy. We'll see how far we get!
Can you elaborate on the model of creating your own corelets? Can
you do so easily and sign them? Or just Y! for now?
From the beginning, even before we were thinking about opening the
platform, we felt that a centralized model for extending the web
inside Yahoo wouldn't scale well. We wanted to empower *other* people
to build the 'services', the things that actually deliver features
people can understand. So from the beginning we've tried to make it
as easy as possible for services to be prototyped, built, signed,
published, and consumed.
But the flip side, is being able to author code that can run
unsandboxed on end user devices can be extremely dangerous if there
isn't anyone there to commit to and stand behind end user security and
privacy. So we are going to be taking steps to responsibly balance
end user security with developer freedom in terms of authoring
new BrowserPlus services. This is obviously a hard problem that we don't take
lightly, but we've got a couple ideas of different approaches. We'd
love to hear what other people think might work.
So concretely, today, *distributing* new services is
restricted to Yahoo! and its partners. Stay tuned.
Anything else fun that you think the Ajaxian audience would want to know?
Sure! Write a level for the marble maze game! A level is just a bit of
JSON. Pop it on our forums and we'll get the top 5 on our site
with your name up in lights! (you gotta pick your own nickname though).
2.6.0 introduces a new Carousel Control, offers the Paginator Control for general use (it was previously bundled with DataTable), includes more than 450 total fixes, enhancements and optimizations, graduates eight components out of “beta,” and now ships with more than 290 functional examples.
To go along with the carousel and paginator controls, you will also find details on updates too: TreeView, Calendar, Rich Text Editor, Drag & Drop, Uploader, DataTable, AutoComplete, and Container.
With Christian around, you can be sure that accessibility is taken seriously, and we see improvements there:
We’ve continued to work hard to make YUI accessible. The Carousel, Button, Menu, TabView, and Container all have enhanced accessibility support in addition to what’s otherwise noted in this blog post. We continue to count accessibility amongst our highest priorities; stay tuned for a few more blog posts on the topic in the coming days and weeks.
Blogging from @media Ajax. Christian Heilman is talking about the interaction of Ajax/Javascript and accessibility.
BTW Christian's arranging an accessibility event, including a hack day, this Friday/Saturday in London - Scrpting Enabled. Tickets are free, but booking is required.
Legislation is not the (only) answer. Smart developers can find ways to work with the technology to improve experiences. He's covering various examples of using the technology to improve accessibility. For example, Flash is evil for accessibility, right? But not if you're building a chatroom where deaf users can see and sign to each other using video. Pragmatism!
Okay I'd like to know how many of the Ajaxian readers are actually old enough to remember real arcade games which required endless amounts of quarters to become good. Yeah, those were the days when calluses on your thumbs were the norm and being able to "hold it" (ie: not go to the bathroom for long periods of time) was a HUGE advantage.
Warning! Ghosts are very smart, they are spending most of the time trying to find where are you hiding and when they finally finds you, they run away :)
(one of the A.I. bug!)
Smart is an understatement! Either my fingers are super slow or these ghosts are just too darn good!
lighter (less K-weight on the wire and on the page for most uses)
faster (fewer http requests, less code to write and compile, more efficient code)
more consistent (common naming, event signatures, and widget APIs throughout the library)
more powerful (do more with less implementation code)
more securable (safer and easier to expose to multiple developers working in the same environment; easier to run under systems like Caja or ADsafe)
What's New
Sandboxing: Each YUI instance on the page can be self-contained, protected and limited (YUI().use()). This segregates it from other YUI instances, tailors the functionality to your specific needs, and lets different versions of YUI play nicely together.
Modularity: YUI 3 is architected to use smaller modular pieces, giving you fine-grained control over what functionality you put on the page. If you simply want to make something draggable, you can include the dd-drag submodule, which is a small subset of the Drag & Drop Utility.
Self-completing: As long as the basic YUI seed file is in place, you can make use of any functionality in the library. Tell YUI what modules you want to use, tie that to your implementation code, and YUI will bring in all necessary dependencies in a single HTTP request before executing your code.
Selectors: Elements are targeted using intuitive CSS selector idioms, making it easy to grab an element or a group of elements whenever you’re performing an operation.
Custom Events++:Custom Events are even more powerful in YUI 3.0, with support for bubbling, stopping propagation, assigning/preventing default behaviors, and more. In fact, the Custom Event engine provides a common interface for DOM and API events in YUI 3.0, creating a consistent idiom for all kinds of event-driven work.
Nodes and NodeLists: Element references in YUI 3.0 are mediated by Node and NodeList facades. Not only does this make implementation code more expressive (Y.Node.get("#main ul li").addClass("foo");), it makes it easier to normalize differences in browser behavior (Y.Node.get("#promo").setStyle("opacity", .5);).
Chaining: We’ve paid attention throughout the new architecture to the return values of methods and constructors, allowing for a more compressed chaining syntax in implementation code.
// Adds the Drag plugin to the element with the id "demo", and enables all of its h2 children drag as handles.
Y.get('#demo').plug(Y.Plugin.Drag, {
handles: 'h2'
});
// Attaches a DOM event listener to all anchor elements that are children of the element with the id "demo". The event handler prevents the anchor from navigating and then sets a value for the innerHTML of the first em element of the clicked anchor.
Y.on('click', function(e){
e.preventDefault();
e.target.query('em').set('innerHTML', 'clicked');
}, '#demo a');
Very exciting stuff to the team. I look forward to seeing a full up code repository too!
Have you ever wanted to be able to easily grab a thumbnail image that represents a website?
Eric Ferraiuolo has created Ajax-Alexa-Thumbnails on Google Code, a library that builds on YUI to do just that.
The project consists of a server-side component written in PHP which makes the cross-domain request to Amazon's Alexa Site Thumbnail web service, and a JavaScript component which makes Ajax requests to configured server-side component and caches the results.
Safari and IE8 are already changing the way scripts are getting loaded. Their idea is to download the scripts in parallel, but execute them in the sequence they’re found on the page. It’s likely that one day this blocking problem will become negligible, because only a few users will be using IE7 or lower and FF3 or lower. Until then, a dynamic script tag is an easy way around the problem.
Danny Thorpe wrote some comments and the issue with Safari:
This works great for Firefox and IE, but fails completely in the Safari browser. Safari doesn’t implement onLoad notifications for script tags. This forces you to abandon the onLoad technique and instead use the technique of embedding something at the end of each script file to signal when the file has been loaded.
The script libraries for the Windows Live sites use this technique - every source file contains a function call at the bottom that tells a central notifier that it has been loaded. Other code can ask the notifier to signal them when a file or set of files have been loaded. This works in all browsers without relying on diverging browser idiosyncrasies.
, Plugins
