2009 » April » Yahoo! User Interface Blog (YUIBlog)

YUI Theater — PPK (Peter-Paul Koch): “JavaScript Events”

April 27, 2009 at 9:57 am by Eric Miraglia | In YUI Theater | 1 Comment

PPK (Peter-Paul Koch) of Quirksmode has been sharing his research into browser quirks for years, and this year he’s turned his attention to mobile browsers while doing a consultancy for Vodafone. That work has got him thinking about JavaScript events once again, and, as is his habit, the results of his research are freely available to the rest of us on Quirksmode (big-screen browser compatibility tables; mobile browser compatiblity tables).

PPK was in California last week and he was kind enough to visit Yahoo and deliver a tech talk outlining some of the interesting browser-event work he’s been doing. We’re happy to share that talk with you on YUI Theater. Slides from PPK’s talk are available in PDF form here.

PPK (Peter-Paul Koch): "JavaScript Events" @ Yahoo! Video

download (m4v)

Subscribing to YUI Theater:

Transcript: PPK, “JavaScript Events”

Peter-Paul Koch: Thank you for inviting me, once again, to speak at Yahoo!. I’m PPK: Peter-Paul Koch, but everybody calls me PPK. It’s a long story. I run a site called http://quirksmode.org, where you can find information about browser incompatibilities. And I have a Twitter account, obviously — who doesn’t?

And today, here at Yahoo!, I’m going to talk about JavaScript events. And I sincerely hope I can teach you something. That’s always the question when I speak for a Yahoo! audience, because you guys already know so much, I have no idea what I can contribute to it. But anyway, we’re going to give it a try. I am going to talk about JavaScript events.

It was about a year ago that I started some serious research into JavaScript events, and I published some compatibility tables. What I basically was doing, was testing the compatibility of all the common events, in all the common browsers. And there’s several things surprised me in that research. Some of these things are what I’m going to talk about today.

If you don’t know where my compatibility table is, here at http://quirksmode.org/dom/events. Use it to look up some complicated events stuff that you want to know about.

Today, we’re going to talk about four things. First of all, I’m going to give a quick introduction to the key events, because there is some confusion, sometimes, about exactly how they work. Secondly, I’m going to talk about the change event. It’s one of my absolute favorite events in the whole of JavaScript – unfortunately, it hardly works, and I’m going to talk about that. Thirdly, I’m going to talk about delegating the focus event. Event delegation, you’ll probably know about that – I’m going to give a very short introduction later on. Event delegation usually only works with a mouse and key event, but I’ve found a way to have it work with focus, and other interface events too, and I’d like to share that with you. And finally, I’m going to present the first results of my test of mobile events – and the results are weird, I can tell you that already. I’ll show you that later on.

But first: the key events. It all seems so simple. There are three key events – keydown, keypress, and keyup. And people generally think they know exactly when they fire. I’m here to tell you that it isn’t always as clear as you think it is.

Let’s go through some quick definitions. The keydown event fires when a key is depressed by the user, and it keeps on firing as long as the user keeps it depressed. That’s simple. The keypress event, basically that’s the same, except that it fires only when a character key is depressed – in other words, a key that will lead to a character being inserted into, say, a textarea. Finally, the keyup event fires when the user releases the key. Well, that’s all pretty simple.

Just to make absolutely sure that everybody understands – if I press, say, an ‘o’ key, or an ‘i’ key, or one of these strange bracket keys, both a keydown and a keypress event will fire. On the other hand, if I press special keys such as the shift key, or the arrow keys, only a keydown event will fire.

This theory of the difference between keydown and keypress originated with Microsoft. All the Internet Explorer versions actually use this difference between keydown and keypress. And Safari has copied it, as from version 3.1, I think, which was released about a year ago, maybe slightly more. The point is, here, that this theory is the only theory about the difference between keydown and keypress in existence. In contrast, Opera and Firefox just fire lots of events at you all the time, because it is tradition that it is both a keydown and a keypress event, so we should fire both whenever we see an opportunity. Which is fine, but it doesn’t explain why there should be two events, instead of just one: the keydown event. So that’s why I kind of like this theory of the difference between keydown and keypress.

So, let’s repeat it once more. Keydown fires when a key – any key – is depressed. Keypress fires when a character key is depressed. And as we can see here, it works in IE, and in Safari. Oh, and I don’t have Google Chrome items here yet, but assume that anything that works in Safari also works in Google Chrome. They are really quite close, these two browsers.

OK, so let’s move on to some practical questions. Usually when you write a script that detects user keys, he wants to know which key the user pressed, and do some interesting interface stuff based on that.

Now, there are two properties that any key event carries – those are the keyCode, and the charCode properties. And there are also two bits of data you might want to know about – the key code, and the character code. And the difference is, the key code is the actual code of the physical key the user depresses, and the character code is the code of the resulting character. So, if I press an ‘a’ key, I get key code 65, because the ‘a’ key has the code 65. But the character code is 97, for a lower case ‘a’. If I press a shift key, I get key code 16, because that’s shift – but I do not get a character code, because the shift key, by itself, doesn’t result in any character. Well, that sounds simple.

So we have one property – we have, actually, two properties, and two bits of data. And having one property containing one bit of data, and the other property the other, would of course, be far, far too simple. It would mean that you don’t need a specialized content engineers, that anyone can just write a key script, which is obviously not the idea.

So, what exactly is going on? It’s pretty complicated, actually, and frankly, I do not understand entirely why it should work like this. But it does work like this. The keyCode property. With a keydown event, onkeydown, it contains the key code – the code of the physical key the user depresses. Onkeypress, on the other hand, contains the character code – basically, the ASCII code of the character that appears on the screen. And this works in all browsers – except that in Firefox, onkeypress shows zero for key code; don’t ask me why. Then, charCode. Onkeydown, charCode returns zero, and onkeypress, charCode returns the character code. And this, too, works only in Firefox and Safari, because these are the only browsers to support charCode.

Let’s move on to something really practical. If you need the actual key that the user depressed, the physical key, use the keydown event and ask for the keyCode. That will work in all browsers. On the other hand, if you needed the character the user has just entered in a text area, or whatever, you should use the keypress event, and ask for either keyCode or charCode – one of them will contain the information you’re looking for in the browser.

Finally, sometimes you want to prevent the default action of a key. I’m especially thinking of arrow keys. Suppose you have a keyboard accessible drag and drop menu, and then you want the user to be able to manipulate the drag element by the arrow keys, and you want to cancel the default of the arrow keys – namely, scrolling the page. Basically, you should do that onkeydown, because, as I said before, keydown fires when any key is depressed, and keypress only fires when character keys are being depressed. Unfortunately, this does not work in Opera – and I must admit I did not test it the latest Opera, so it might have changed there. And preventing arrow keys in Opera is something I’m not going to talk about today, because frankly I forgot the answer.

That concludes the key events. It is not really complicated, all those key events, but you have to be aware of the difference between keydown and keypress.

Now, the change event. In theory, the change event would be absolutely wonderful to have, because the change event fires when the value of the form field is changed. Often, you want to detect everything the user does in a form – for instance, onformsubmission, you of course want to go through all form fields and validate them. But there’s also ways of making a form – or form fields, checkboxes for instance – a kind of menu that the user can use to go through a complicated interface. And what you want to do, always, is see what, exactly, that the user changed in the form. And in theory, the change event would be absolutely wonderful for that.

But usually, we are forced to use the focus or blur events instead – or maybe the click event, in the case of detecting a checkbox changes – because the change event doesn’t work quite correctly. We’re to distinguish three different cases. First of all, the change event of text fields; second, on select boxes; and third, on checkboxes and radios.

We start with text fields. And I suppose the user focuses on a text field, in any way, either by the mouse or the keyboard, and then blurs again. In other words, he moves on to the next field. In that case, no change fires, because there’s nothing that has changed – the value of the text field has not been modified. But if we change it slightly – if we say the user focuses on the text field, and then enters something, then blurs the text field, then a change event fires at the moment the user blurs the text field. Because the value of the text field has been modified, and that obviously causes a change event. This is all good; this works perfectly in all browsers.

Continue reading YUI Theater — PPK (Peter-Paul Koch): “JavaScript Events”…

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

In the Wild for April 23, 2009

April 23, 2009 at 9:22 am by YUI Team | In In the Wild | 3 Comments

News and notes from the YUI community from the past few weeks…as always, we ask you to let us know in the comments about projects and articles that we missed.

Dan Wellman, “A Look at the New YUI Carousel Control”: Dan Wellman, who literally wrote the book on YUI, has a new article out on DevShed treating Gopal Venkatesan’s YUI Carousel Control (inspired by the work of Bill Scott). Writes Dan: “The Yahoo! User Interface library continues to grow and expand with new components being added and existing components being continually patched and updated to ensure full x-browser support and cutting-edge functionality. Version 3 of the YUI is due for full release at some point this year, but version 2 (current release 2.6) is at this point still the stable and recommended release for general use. One of the components recently added is the Carousel component, a control for automatically scrolling content in an attractive and intuitive interface. It’s still a beta release at present ,which indicates that the API is not finalized and that there are likely to be bugs that need addressing. We can still use the component, though, and although we should be wary as the existing API may change, the full release will probably bring more new functionality than changes in how it is implemented. In this tutorial we’ll be looking at a basic implementation of the control, the functionality we can use at this point in time, and the properties and methods exposed by the current API.” Check out the full article/tutorial on Carousel here.
Jeethu Rao, “A Mochikit-style Dombuilder for YUI”: Writes Jeethu: “Before moving to YUI about a year ago, I was using Mochikit as my primary JS library. As advertised, Mochikit happens to be one of the most pythonic javascript libraries ever. One of the sweetest parts of Mochikit IMO has been Mochikit.DOM. This is something which I’ve always missed with YUI. innerHTML is fast, but icky and it feels a little inelegant. So, I ended up writing something like Mochikit.DOM for YUI while writing Tagz. Thought it might be useful to others as well. So, here’s the mercurial repo with the code.” Check out the full blog post here. (Original source.)
Niceforms — Form Styling Enhancements Based on YUI: The folks at FreshCut have released v0.1 of Niceforms for YUI. According to the release, Niceforms is ”an easy to use and highly configurable YUI plugin to give most form controls a modern look that is consistent across all major browsers.” Niceforms is licensed under a Creative Commons license and full documentation and a live demo are available.
SlowGeek.com — YUI-based Nike Plus Mashup from Rasmus Lerdorf: PHP inventor Rasmus Lerdorf has a site called SlowGeek.com that taps into Nike Plus data to present a graphical and interactive look at your running history. Check out Rasmus’s own stats to get a sense of the interface — and you’ll quickly learn that, far from being a “slow geek,” Rasmus is actually a speedy and dedicated mid-distance runner. YUI components including DataTable, TabView and more are on display. If you have a Nike Plus account, you can start using app yourself — just go to http://slowgeek.com/pr/[your username] for directions on how to get started.
YUI Carousel on Public.resource.org Films Site: public.resource.org has a nice implementation of Gopal Venkatesan’s YUI Carousel on its National Technical Information Service Library of Commerce films site. Developer Greg Palmer wants to see a lot more YUI usage in government web development, as he argues in “Leveraging Yahoo’s UI Library to Speed Development” on his blog. (Original source.)
Jobseeker Site Resumebucket Using YUI: Reader “P” wrote in to tell us about resumebucket, a slick resumes site for job seekers. Resumebucket uses a broad swath of YUI components, including the Core + Loader platform, Connection Manager, and JSON. (Original source.)
New YUI 3.x Support from the Grails YUI Project: mingfai has added support for the latest YUI 3 preview release in his Grails YUI plugin; support is also provided for YUI 2.x.
YUI Sighting — Twitter for Busy People: Glenn wrote in to tell us about Twitter for Busy People. The product aims to “give users a more dynamic and intuitive way to catch up on their friends’ twitter updates. We use the Dom utility a lot for positioning the updates window and for mouse positioning; the Event utility for all mouse interaction; and the Pagination utility was great for users with many friends! We also used the ‘Dependency Configurator‘ and the YUI Compressor to minimize this site’s footprint to an amazing 43k total payload!” (Original source.)
YUI Sighting — GameFly: Dylan Oudyk wrote in to tell us about “the redesign of GameFly. We’re making extensive use of menus, tabview, overlay, grids, reset, and calendar. Also have drag/drop for our GameQ implementation; when I worked on the old site a couple years ago I used YUI version 0.10.3 with some browser workarounds, so it feels good to be all up to 2.7.0 now because I don’t have to do that anymore.” (Original source.)
YUI TabView and More in Use at Mathsbank: Luke Robinson wrote in to tell us about YUI use at mathsbank, a UK math site for teachers and students. TabView is the most prominent component used, driving navigation for many of the site’s categories. (Original source.)
C.S. Lai, “Maintaining State with YUI Event”: C.S. Lai has written up some ruminations on Adam Moore’s YUI Event Utility. Check out the blog post here.

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

YUI 2.7.0 on TaskSpeed

April 13, 2009 at 2:21 pm by Luke Smith | In Development | 9 Comments

A few months ago Peter Higgins, a contributor to the Dojo Toolkit, adapted the SlickSpeed test framework to do higher level comparisons of how various JavaScript libraries perform when doing some “common” DHTML tasks. The new test framework is called TaskSpeed. And thanks to the excellent work done by one of our favorite community members, Eric Ferraiuolo, YUI 2.7.0 now has representation in the matrix as well.

About TaskSpeed

Whereas SlickSpeed compares the performance of the respective JavaScript CSS selector engines in common libraries, TaskSpeed attempts to qualify a larger set of library functionality with less granularity. The goal seems to be to predict what a library consumer might expect for aggregate speeds when developing on top of library A vs. library B.

In addition to each of the participating libraries, a “PureDom” column represents the performance of the given task with plain old JavaScript and direct DOM interaction, serving as a healthy reminder that the benefits you get from using a JavaScript library don’t come for free. Unfortunately, “PureDom” might also be incorrectly construed as an argument in favor of not using a library at all, but that is a separate and lengthy discussion.

The results

Though YUI 2.7.0 was only added to the matrix on April 10th, the results submitted so far suggest that YUI performs the given tasks with comparable efficiency in the newer browsers, and better than most in Internet Explorer 6, 7, and 8.

IE 8 results from Apr 10 – Apr 13

Chart of IE8 performance comparisons

Take-aways

Though YUI performs ably, it’s my opinion that the numbers seen in TaskSpeed should be taken with a hefty grain of salt. The tests are designed to exercise library abstraction logic against DOM-intensive operations. The issue here is twofold:

Not all libraries (YUI included) have abstraction logic for all of the specific tasks, which breaks the apples-to-apples comparison.
And in order to get meaningful numbers, the test operations are iterated up to 500 times or performed against excessive numbers of nodes. In real-world cases, these conditions are not the norm, meaning the differences are exaggerated, perhaps even grossly.

By and large, TaskSpeed may be more of a distraction than a source of information useful to the consumer. My greatest concern is that people will make a decision to choose one library over another based on which one can add a ridiculous number of event subscribers in 25 milliseconds vs. 30, ignoring more important issues like cross-browser stability, code maintainability, documentation quality, and community support.

This is not to say that TaskSpeed is without value. Here are the interesting take-aways I’ve found:

Accounting for the lengthy iterations TaskSpeed needs to make the numbers substantial, all libraries perform common tasks pretty quickly.
Libraries are getting faster, as seen by comparing version to version of the same library where available.
There is a performance price to pay for the stability and consistency any library offers.
For the library authors and contributors, an apples-to-apples comparison of task execution can highlight potential areas where we may each be able to evolve to use best-of-breed techniques for everyone’s benefit!

I’d like to personally extend a big “thank you” to Eric Ferraiuolo for having done the fantastic legwork on this. Another great example of the importance of community contributions to the YUI library!

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

In the Wild for April 9, 2009

April 9, 2009 at 9:34 am by YUI Team | In Development | 9 Comments

News and notes from the YUI community over the past few weeks. Please let us know what we missed in the comments.

Vanguard.com Using YUI Core Plus Animation, Drag and Drop: Samantha wrote in to let us know that Vanguard.com is among the financial sites using YUI. The login page uses YUI Core (Yahoo, Dom and Event) in addition to YUI Loader. Animation and Drag and Drop are included on pages beyond the login. (Original source.)
Caterina Fake’s New Startup Hunch Using YUI: YUI Core and Jenny Donnelly’s YUI AutoComplete Control are among the components used on the Hunch beta. Caterina’s previous startup (Flickr) is also a big YUI user.
Special Masters-eve YUI Sighting — YUI on Golf.com: Not that we are golf fans or anything (here’s YUI project manager George Puckett showing off her swing; and here’s Jenny Donnelly and Luke Smith…), but on Masters’ eve we’re happy to take note of Golf.com using YUI TabView, Connection Manager, and Carousel. Bonus picture: YUI founder Thomas Sha gripping and ripping. It’s a travesty none of us were invited to the Masters this year…
YUI-based Archivd Launched, “Simple Research Tools for Teams”: Carlos Bueno wrote in to tell us about his new project Archivd, a collaborative research portal for teams. Archivd uses a wide swath of the YUI utilities and widgets in its interface, including DataTable, Button, Menu, Carousel and Panel.
Smart Polling from Eric Ferraiuolo, Built for YUI 3: Eric Ferraiuolo has launched a Smart Polling component based on the YUI 3 preview release. Smart Polling is a strategy for checking the server for fresh content. Here’s Eric’s description of how it works: “Internally the Poller class is using conditional XHR GET requests. When polling is first kicked off (i.e. start() is called) the Etag and Last-Modified header values are cached. As subsequent polling requests are sent to the server the cached Etag is set for the If-None-Match HTTP request header, if no Etag was cached (i.e. the server doesn’t send Etags) then the cached Last-Modified date is set as the If-Modified-Since header. If a server doesn’t support conditional GET requests at all, sending neither an Etag nor a Last-Modified date, the Poller class will fire the modified event with every response.” Check out his blog post for more details and to grab the source code. (Original source.)
Balsamiq Mockups for YUI Grids: We wrote last month about Balsamiq mockups for a variety of YUI components. Mockups-to-Go now has an entry for YUI Grids as well.
Les Green, “Scope Correction and YUI”: Writes Les: “The more I use the Yahoo User Interface Library (YUI), the more I am impressed with it. I have been converting my JQuery imValidateForm plugin to a YUI widget for a project that I am working on. I ran into a scope issue when a button was clicked. I have dealt with Javascript scope issues in the past, but I did not know how to fix it using YUI.” He documents his learnings in a new blog post. (Original source.)
Les Green, “YUI Selector Utility: CSS3 Attribute Selectors and Pseudo-classes”: Les has another article out in which he demonstrates how he baked 8 lines of code down to a single line using the pseudo-class support in Matt Sweeney’s YUI Selector.
YUI Compressor TextMate Bundle: According to its author, “The YUI Compressor Bundle enables easy compression of JavaScript and CSS files using the YUI Compressor, right from within TextMate.” Nice. (Original source.)
Jeffrey Cobb, “Creating a FIXED Element with Re-size and Scroll Detection Using YUI Dom and Event”: Jeffrey writes on his YUICoder blog: “We have all see them and some of us love them. It’s those elements that seem to float on the page like hovering little angels. Ok enough with the sappy crap…down to business. So you need to create a browser independent simple script to position an element on a page. I put together a simple script that will handle such a task and is flexible enough for even a newbie to configure.” Check out his post for full details.
Graffletopia — OmniGraffle Design Stencils for YUI: Graffletopia has a bunch of design stencils up for YUI controls — fantastic for rapid prototyping. See also the versions for Balsamiq on MockupsToGo. (Original source.)
Brian Love, “YUI and the DOM”: Brian Love has a new blog post up about using YUI’s Dom and Element components to interact with the DOM. (Original source.)
YUI Sighting — Power-One.com Using Menu, Animation, and More: Reader Brad Bauer wrote in to tell us about Power One, whose website makes use of YUI Reset, Fonts, Animation and Menu. (Original source.)
YUI TabView on ChartBeat.com: ChartBeat is a new realtime web analytics solution that employes a very active user interface to keep you abreast of what’s happening on your site and around the web. One of those active pieces is a prominent use of Matt Sweeney’s YUI TabView Control, used to toggle between realtime and historical data views.
Milo Timbol Combins 3D Flash with YUI Elements: Milo Timbol’s site combines the use of 15 YUI modules with extensive use of 3D elements in Flash. It’s a personal/portfolio site, and it definitely stands out from the crowd.
PHP, MySql and the YUI Charts Control: Hubpages has a new tutorial out that brings together PHP, MySQL and the YUI Charts Control.
Sanjay Ginde’s LazyLoadDataSource: Sanjay Ginde published his variation on YUI DataSource’s XHRDataSource class. Writes Sanjay: “While working on some auto-completing features for a project I realized that there was a remote retrieval mechanism missing. I had small datasets that I wanted to retrieve on demand in a single request. I thought to use the XHRDataSource at first, but there would continue to be multiple requests with each letter I typed. To solve my requirement for a lazy, single-request data source, I created the (obviously named) LazyLoadDataSource. It’s much like the XHRDataSource, except it expects to retrieve all the data in a single request. Now I can create more efficient auto-completes that can retrieve data on demand while keeping requests to the server at an absolute minimum.” The core use case here is that you have a small dataset, but you don’t want to load that data into the page until it’s needed; however, the dataset is small enough that, once it’s needed, you want to load it all at once. (Original source.)

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

Implementation Focus: Lunch.com

April 9, 2009 at 9:01 am by Eric Miraglia | In YUI Implementations | Comments Off

Dave Nesbitt of Lunch.com David Nesbitt is the VP of Engineering at Lunch.com, an online community that helps people share and discover relevant information, opinions, and ideas.

He has worked in software development for the past 20 years.

Prior to Lunch.com, he was the chief architect and director of application development at Vue Technology, which recently sold to Tyco International (TYC) for $43M. David is very optimistic about the potential of Web standards development in today’s environment and an enthusiastic proponent of the Yahoo! User Interface (YUI) framework.

When away from work, David relishes the challenges of fatherhood and is a connoisseur of baseball. Go Angels!

Special invite to Lunch’s private beta for YUIBlog readers:

Go to http://www.lunch.com.
On the right-hand side of the screen in the Get an Invite! box is a "Have an invite code?" message. Click on the click here link.
Enter the Invite Code YUIBlog and a valid email address. Click Submit.
Lunch.com will immediately send you a confirmation email.
Open that email and click on the confirmation link.
Sign into Lunch.com.

Design and interface quality are huge differentiators for startups. What are the strengths you wanted to build around in the Lunch.com interface?

At Lunch, our strengths are the community’s ability to contribute both facts and opinions about almost everything and our Similarity Network which, based on site interactions, connects each person to others who share similar interests, opinions, and ideas. To clearly deliver and communicate to the user it is important for the interface to be clean and easy to understand.

You chose YUI’s JavaScript library to help drive the UI. What led you to make that choice?

We selected YUI for a number of reasons.

First and foremost, we felt that Yahoo’s commitment to this technology gave a significant advantage in the areas of test coverage, maintenance, and longevity. Standard open source frameworks have the potential hazard of falling into the “flavor of the day” category, where there is an initial surge of enthusiasm that can quickly be abandoned for the "next big thing." We wanted a framework that was going to have a lasting presence.

Secondly, we were impressed by YUI’s architecture. The quality and modularity of the interface is impressive. Clearly, there is a concern for keeping the interface clean, whereas other frameworks have a tendency to become bloated over time. Yahoo’s architectural shepherding of the interface gives it a better chance of staying slim, usable, and maintainable over the long haul.

Thirdly, we found the documentation and supporting resources to be very helpful. The number of examples and easily navigated Web site facilitate a short learning curve and rapid development. We also appreciated the wealth of JavaScript information available from the YUI Theater.

Finally, we found the YUI blog to be a robust source of tutorial information and the YUI discussion forum to be a vibrant community of helpful implementers willing to share their knowledge and address issues. We didn’t want to feel like we were "on our own" when problems arose.

All of these reasons led us to choose YUI and we have not been disappointed.

What YUI components are in use on the site?

Yahoo, Dom, Event, Connection Manager, Get, JSON, Animation, Container, AutoComplete, ImageCropper, TabView, and OverlayManager.

What’s next for the interface of Lunch.com in coming releases?

Currently we are in private beta but we will be opening it up in the next few weeks. Our goals for the interface, are to continue to optimize the experience for both existing community members and for people just looking to gain knowledge or insight into specific areas of interest. As we move from the closed beta to an open beta it is important that new visitors can understand the value of Lunch and easily jump in and start getting personalized information based on their interests. Creating those easy on-ramps and access points that can engage and drive adoption will be the key priorities moving forward.

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

John Peloquin’s Multi-layer Calendar

April 3, 2009 at 2:41 pm by Eric Miraglia | In Design, Development | 6 Comments

YUI contributor (and author of the Interval Selection Calendar example) John Peloquin of W. Hardy Interactive has released another excellent option for Calendar implementers: a layered navigation path for selecting years and months. The layered approach provides an alternative to the built-in navigator interface that ships with Calendar.

John describes the inspiration and thought process behind this implementation on his blog, where you’ll also find API documentation and source code.

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

Implementation Focus: Confirmit

April 2, 2009 at 8:16 am by Eric Miraglia | In YUI Implementations | 1 Comment

Einar Paul Qvale works as a front-end developer for the Norwegian company Confirmit, an online survey software provider.

Confirmit is based in Oslo with offices around the world. Einar manages the web-team which does a lot of the heavy lifting in the UI department, especially when it comes to more complex JavaScript, CSS, Ajax, and the frameworks they use to develop the UI. On the server side, Confirmit uses Asp.Net; on the client side they have chosen YUI as the main JavaScript framework. Einar has been with Confirmit since 2000.

What is Confirmit? Tell us a little bit about the company.

Confirmit has been around since 1996, and we are now over 250 employees globally, with offices in Guildford, London, Oslo, New York, San Francisco, Moscow and Yaroslavl.

Confirmit targets Global 5000 companies and Market Research agencies worldwide with a wide range of software products for feedback / data collection, panel management, data processing, analysis, and reporting. Customers include British Airways, Countrywide Financial, Dow Chemical, Experian, GlaxoSmithKline, Halifax Bank of Scotland, Hewlett Packard, Intrawest, Ipsos, Nielsen, The NPD Group, Safeco Insurance, StatoilHydro, Symantec and Virgin Media.

The goal of Confirmit as a company is to revolutionize the survey, panel and reporting process through automation and integration. The goal of the R&D department is to support this by creating a high quality product that is capable of tackling current and future challenges in the market.

Confirmit Express survey designer, using Yahoo, Dom, Event, Animation, Connection, Json, and Selector.

From a frontend engineering perspective, what are the core challenges you face in your work on Confirmit?

The core challenges we face from a front-end engineering perspective would have to be the fact that most of our developers are in fact not front-end engineers. YUI helps us a lot in this area, and does so in a manner that in most instances are transparent to the developers. The less they need to know about how for instance attaching events differs from browser to browser, the better. We can’t all be browser geeks in the R&D department, but we should not have to be in order to be productive.

Now that browsers are evolving so quickly (as opposed to the first half of the decade), having a code-base that is ready for the current and future browsers is definitely the biggest challenge in creating a rich web interface.

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

I felt [YUI] would be an excellent choice as our JavaScript framework of choice, considering Yahoo’s own requirements when it comes to performance, stability, browser support, etc. For the first week of March we averaged about two million page-hits daily on our surveying servers, and about two hundred thousand page-hits daily on the survey authoring servers. Our primary strengths are security, scalability and performance, so we needed a JavaScript framework that supports these product qualities. I also felt that the YUI project would not be a short-lived one, and that I could count on it being updated and maintained for a long time considering the solid reputation of the company responsible for it.

How are you using YUI in your site today?

We are using YUI in almost every area of the product. The core library is deeply integrated into the survey authoring and reporting platforms (Yahoo, Dom, Event, JSON, Selector), and we are also using the Connection Manager a lot for XHR/Ajax.

Confirmit Express (the entry-level product for survey authoring) is also using the Animation Utility heavily.

We are also using quite a few components in the survey front-end (Slider, Calendar, Get, Cookie, YUI Loader, DragDrop, Resize) in order to create a more interesting experience for the respondent.

Screenshot of a survey using a numeric slider.

Elsewhere in the product we are using YUI AutoComplete and Rich Text Editor.

We are combining the components in use with our own core libraries during build time in order to reduce the number of requests to the server, meaning we have one combined JavaScript file for survey authoring, one for reporting, one for surveys, and one for Confirmit Express. We have of course considered using the Yahoo or Google combo handler for this, but the lack of an SLA and SSL support has prevented this so far. [Note: Google's CDN does provide SSL. -Ed.]

YUI Resize in use in the Confirmit interface.

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

My personal favorite components would have to be Event and Connection. Dustin Diaz has a great article on how and why you should use the Event Utility; it should be very educational for anyone who hasn’t had the time to get to know the Event Utility in detail.

When it comes to the Connection Manager, I love the fact that it does exactly what you need, and nothing more. Make a request, specify the http method, specify the form to send if needed, and provide a handler for the response. It’s not doing anything too fancy, but it’s all very nice and clean, resulting in very readable and maintainable code.

What’s the most innovative thing you’ve done with YUI in the current release of Confirmit?

In the Inline Surveys project we use YUI Loader to set up the JavaScript environment and the Get Utility for the cross-domain requests. If the page hosting the Inline Survey is on our own domain we switch from the Get Utility to Connection Manager for XHR, and the similarities in the interfaces of these two components makes this extremely easy to accomplish.

What would you like to see YUI developers improve on in upcoming releases of YUI?

It would be great to have some chaining functionality in YUI. We are using DEDChain internally as a chaining wrapper for YUI, and it does the job. But I would really like to see what the YUI team could come up with if they put their brilliant minds to it (since this will be included in YUI 3 I guess I will get my wish).

Some more skins would also be great. The SAM skin is excellent, but it would be good to have more than one to choose from, especially a darker blue one and perhaps a white on black skin.

I am also really looking forward to seeing the lazy load syntax in YUI 3, it seems like a very nice way of working with the different YUI components that you don’t want to have preloaded in the initial page delivered to the browser.

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

Yahoo! User Interface Blog (YUIBlog)

YUI Theater — PPK (Peter-Paul Koch): “JavaScript Events”