Yahoo! User Interface Blog

Tell us a little bit about your site redesign for Pulte Homes.

The new Pulte Homes, Inc. web redesign was launched in May 2008 to help consumers find homes using a rich and interactive map-based search tool, learn about available homes using interactive multimedia, organize and save properties of interest using personalized notebooks, and finally connect with Pulte sales agents directly through a dynamic, context-specific contact form.

The project was scoped as an end-to-end design and implementation effort lasting approximately 18 months. We used the following and YUI components as part of the redesign:

• Dom Collection
• Event Utility
• Element Utility
• Animation Utility
• Carousel Control (by Bill Scott)
• Container Family
• TabView Control
• Slider Control
• AutoComplete Control
• Button Control
• Grids CSS
• YUI Compressor
• Yahoo! Design Patterns Library

You chose YUI for the implementation of the Pulte Homes website. What factors went into that decision? You know and use other libraries on a daily basis (and choose them over YUI for some projects) — why was YUI the right choice in this instance?

The presentation layer JavaScript library decision was made based on the following factors:

1. Time to Market: a need to have solid, pre-built functional components that can be quickly customized to match the desired interaction model and “look and feel.” The web standards based approach that YUI employs makes it easy to customize components while also addressing common development issues such as browser compatibility, performance and accessibility.
2. Robust set of widgets: a desire to use a front end framework that fits with the client approved interaction specification (for example, our UX team’s use of the Auto Complete design pattern was accommodated using the YUI AutoComplete component). In the deadline-driven agency environment, integrated development practices help to reduce development time and improve continuity.
3. Reliability: a sense of comfort/security in using products that are already proven on Yahoo! web properties. The YUI website, API, and supporting community are all excellent resources in providing help, feedback, and examples.

One aspect of AA|RF implementations of YUI that’s striking is the degree to which you customize the look and feel. When you use a component like Container, Slider or TabView, you do a full custom skin. How much effort is it for you to do so? What tips do you have for other designers or developers who are skinning YUI?

Pulte is a great example of the typical clients that hire AA|RF — they do so not only because of our end-to-end service capabilities, but also because of our reputation for design and UX excellence. Since branding and user experience are so important to many of our clients, we place considerable effort into building high quality interfaces.

For example, we designed a modular front-end architecture that would accommodate not only Pulte.com, but also two sub brands: DelWebb and DiVosta. All three web sites use the same back-end, content management system, and front-end HTML templates and YUI components. We then dynamically change the CSS reference, and therefore the skin, based on domain. This was accomplished using web standards based separation of the presentation layers (HTML, CSS, and JavaScript). Since YUI also follows web standards best practices, it was easy to integrate functional components with three different skins.

In the image above, the Auto Complete, Slider, and Button Control modules use the same HTML and JavaScript, but different style sheets.

We recommend designers and developers consider using an integrated approach to web development, especially for large scale implementations involving interdisciplinary teams. For Pulte we used Yahoo! based interaction design patterns, functional components, styling guides and performance tools together to achieve the branding and user experience needs that our clients expect in world class products.

Pulte Homes is an ASP.Net site. What does a .Net developer need to know about YUI before getting started — any special tips and tricks?

YUI, like most client side JavaScript frameworks that we use, works well on any platform. The high level technical choices made at the beginning of a project are the factors that most affect developers on a day to day basis, especially in terms of integration pains. As more and more processing occurs on the browser due to demand for such technologies as AJAX and rich internet applications, architects must consider the implications of using end to end frameworks (for their standardized development patterns) versus using customized solutions. We could have used ASP.NET Ajax for most of the components, but we decided that YUI was a better fit for the level of customization and interaction that we wanted. So for this particular project, the most important “trick” was to have an architecture and development process that cleanly incorporates the customized features into the .NET environment.

In your Pulte implementation, we see a custom yui.js rollup that contains your selection of YUI components. You implement this instead of drawing the individual files off Yahoo! servers. Is it ever appropriate to use a third-party hosting service (as Yahoo would be in this case) on your customer’s sites?

Yes, absolutely. From a performance point of view, the advantages of geo-based file serving, caching, HTTP requests, etc, are compelling reasons to serve YUI from a content delivery network. We have actually referenced the Yahoo! Exceptional Performance site for best practices on how to improve performance. The new Pulte site, being a “Web 2.0″ feature rich experience, requires above average bandwidth requirements. We are planning on implementing a number of new performance enhancing tasks over the next several weeks based on information gathered using such tools as YSlow.

As for the use of third-party hosting services, we have found that some clients (and I am not talking about Pulte specifically here) are simply uncomfortable with having key components like JavaScript libraries served from a third party due to lack of SLAs (service level agreements).

What are you most proud of in the Pulte Homes project?

The new home search page is probably the coolest feature- it provides consumers with map-based searching for available homes, coupled with a rich set of filters around the most important criteria that people use to look for homes. This feature is a great mash-up of Microsoft technologies (ASP/.NET), Google technologies (Maps), and Yahoo! technologies (YUI). While the three companies are battling each other for market share, we have found a way to combine some of their best services to help people find homes. I like the symmetry of that…

What’s on the horizon for AA|RF as far as the front-end is concerned? Are there emerging technologies coming into the mainstream that you’re looking at for some clients? I’m thinking, of course, about things like AIR, Gears, HTML5, Silverlight, etc.

Since joining the Microsoft family last year, we have built a number of Silverlight applications to help bring this emerging technology into the limelight. In addition, we feel that mobile web application development is on the cusp of hitting the mainstream in the United States, especially with the advent of Apple’s iPhone and its associated SDK. We are working hard to find ways to bring value to our clients via the mobile channel.

We have always put business and user needs ahead of technology — and will continue to do so. All the new technologies that are emerging offer a lot of potential in terms of solving problems more effectively and elegantly under certain contexts. However, the reality is that many of our clients are yet to fully harness the power of the Web 2.0 technologies that have emerged in the last few years. They are looking for us to do that in the near-term before they can look ahead.

How does MiaCMS differentiate itself from other CMS projects out there? Why would someone choose MiaCMS over Drupal or Joomla or other well-known apps in this space?

Yes, there are quite a few content management systems to compete with. Luckily we aren’t really new to the game. Our team contributed toward making Mambo the CMS it is today. We will continue building on that same award-winning base with MiaCMS. (As a side note, it’s worth pointing out that Joomla was also initially based on Mambo about three years ago.)

Some of our current features are:

• Simple Installation
• WYSIWYG Content Editors
• RSS Content Syndication
• Powerful/Extensible 3rd Party Extension System
• Flexible Site Theming Capabilities
• Site Search
• Sitemap Generation
• REST Enabled Content & Statistics
• User Management
• Multilingual Core

MiaCMS will differentiate itself by making standard content management operations even easier and more flexible than they have been in the past. We will cleanup much of the old legacy code and enhance the extensions interface to simplify custom 3rd party extension development. With the 4.7 release the team will drop support for PHP4 to take advantage of the object-oriented capabilities of PHP5. The team plans to continue building close ties to the community and listening to their feedback. The next few releases will focus on building out many of the wishlist items we have already received from the community.

At some point, you and the development team made the decision to build YUI into MiaCMS. What were the factors that guided your decision?

We based our decision on a number of important factors; maturity, browser support, documentation, support community, functionality, and flexibility. YUI has a large selection of time-tested components and continues to make valuable additions with each release. For us it is important that the selected framework continue maturing and growing right along side of us. We didn’t want to add yet another library to the system and so it was important to be able to replace existing parts of the CMS with canned components and/or have the flexibility to hook into the framework and use it as a building block for custom components. The YUI documentation is first-class. In fact, it represents some of the best documentation I’ve come across for an open source project. Between the user guides, cheatsheets, api browser, examples, and developer videos, you have just about everything you could ask for. Of course, sometimes documents just aren’t enough. Luckily, we’ve found the YUI support group to be a good place to find additional answers. Last but not least is the topic of browser support. While we’d love to support every browser in existence, it simply isn’t possible. But we do our best to test and code for as many as we can. We think Yahoo! has taken the right approach with its Graded Browser Support model.

What components of YUI are used in Mia?

We are currently utilizing the Reset-Fonts-Grids CSS, Dom Collection, Event Utility, Tabview Control, Button Control, Color Picker Control, Rich Text Editor, Animation Utility, Element Utility, Container Family, and Menu Control. Our production releases also make use of the YUI Compressor which we have integrated with our ANT packager to compress all the CSS and JavaScript in the system. The entire YUI library is included in the system so we are hoping our 3rd party developer community will make use of the library as well. Each custom component comes with its own set of unique requirements and we are confident that YUI can meet their needs, help improve their extensions, and reduce the number of 3rd party libraries the system must carry. In the last release we also build a dynamic loader into the system which allows MiaCMS users to decide between serving files from the local YUI library and serving them from the Yahoo hosting service for the advantages its CDN can bring.

Where do you see opportunities for deeper YUI integration with MiaCMS in the months ahead?

We’ve still got a lot more planned for YUI. Mia is carrying a fair amount of legacy JavaScript code in the system since its Mambo base was started about 7 years ago. We’ll be rewriting a good chunk of the JavaScript in Mia over the next few releases and utilizing YUI where possible. Users can expect a drastic reduction in inline JavaScript. We also plan to move away from older styles of event handling like coding individual onclick/onmouseover events and instead rely on the YUI Event Utility to subscribe to DOM events and help us create custom events with the application. Future releases will make heavy use of the YUI Dom Collection as well as the Event and Selector utilities.

In addition to the custom JavaScript found in the CMS there are also a number of external JavaScript libraries included to handle specific functions like tooltips, menus, calendaring, etc. A goal for the project will be to reduce the number of external dependencies and rely on YUI where possible. Two such replacements have already been almost fully implemented within the CMS core and we have started to encourage our 3rd party developers to make the switch as well with their custom extensions. In past releases the menu system relied on JSCookMenu and all tabs within the system relied on WebFX Tab Pane. JSCookMenu has now been fully replaced with the YUI Menu Control and the WebFX Tab Pane conversion to YUI TabView is about 98% complete. We are currently in the process of replacing overLib tooltips with the YUI Tooltip Control. We will also soon replace “The DHTML Calendar” with the YUI Calendar Control. It would also be pretty safe to say you’ll eventually find ContextMenus, TreeView, DataSource, DataTable, Connection Manager, and JSON being used within MiaCMS. We recently selected Open Flash Charts, but as the YUI Charts Control matures and evolves out of an experimental state that may also find it’s way into Mia.

Having developed a complex application implementing YUI, what are your thoughts on the state of YUI as a toolkit? What’s working super well at this point? What weaknesses are you hoping the YUI team will address?

YUI is a feature-rich, well designed, state of the art toolkit. The available components cover a wide variety of the common tasks needed for web application development. We have had great success integrating YUI deeply into the MiaCMS core which we will continue to do with each passing release. The community feedback on the YUI-related changes has been very positive so far. Support for the major browsers is top-notch, the components degrade nicely, and performance is solid. Tools like the YUI Compressor and YSlow are also key in helping us take performance to the next level.

Nothing much to complain about. Overall we have been very happy with our selection of the YUI Library. One of the things I really like about jQuery is the powerful CSS style selectors. I am really looking forward to the YUI Selector Utility coming out of beta. We’ll probably start making heavy use of it even before then, but obviously the more stable it is the better. I also see a lot of potential for the experimental Charts component so I’d like to see it polished up with its functionality being continually expanded as well.

What are the next big frontiers for the MiaCMS project as a whole?

Below is the list of roadmap items in no particular order. Some are already being worked on, some are almost complete, and others are in the planning stages.

• Improved ACL’s (User/Group Permissions)
• Database Portability
• LDAP Support
• OpenID
• Dublin Core Metadata
• OAuth
• N-Level Content Organization (remove the two tier section/category limitation)
• Content Versioning
• Multilingual Content Management
• Writeable REST Interface
• Multi-Site Management
• Improved File & Image Management

Today I’m pleased to continue our occasional series on YUI implementers outside of Yahoo! with a brief interview with Matt Snider, the lead frontend engineer at Mint.com. Mint has had great press lately and made a prominent splash at TechCrunch 40, where they took the top prize. Matt has been working in the web space for more than four years, initially as a PHP developer and migrating towards a focus on JavaScript. He has a passion for JavaScript, which he finds to be powerful, fast, and flexible. In his own words: “Programming still fascinates me and I am always searching for faster algorithms and better techniques. About 9 months ago, I started a blog where I record my findings as I explore JavaScript and other front-end technologies. Over the next few years, I hope to continue exploring web-technologies and testing their limits.”

Matt, tell us a little bit about Mint’s history and the problem space you’re addressing with your product.

Mint was founded in 2006 by Aaron Patzer, after he realized that software could do far more than had been previously achieved to help people understand and manage their money. He quit his day job and began coding — forming the earliest parts of the application that powers Mint.com today.

Mint was a big hit at the TechCrunch 40 event this year, taking home the top award and a $50,000 prize. From an engineering perspective, what did you learn from that event about the current generation of startups and what it takes to be exceptional in this second generation of web-based companies?

It became apparent that a lot of companies had flashy UIs with lots of AJAX goodness, but few sites had a clean and clear UI with enough substance to stick. It drove home the point that just because I can use AJAX, it is not always prudent to do so. (It also doesn’t hurt to solve an actual need and have a real revenue model.)

Obviously, inspiring trust in your product is crucial to you, so a frontend experience that feels simple and secure was a high priority. What were the aspects of Mint as a web application were a particular focus for you? What were the big challenges you were facing in the browser?

We spent several months developing and iterating on the account page. It had to be simple enough that the user could add an account in under a minute, but complex enough to manage all the accounts of a user. It takes approx. 30 seconds to add a bank account to Mint — not a long time considering you only do that once — but we still wanted to make it as easy and fast as possible. We needed a UI that conveyed clearly that you could start adding all your accounts in parallel, without waiting for the first one(s) to finish [see screenshot below] . We choose a wallet-like design, where you have specific slots for each “card” — each of which uses AJAX and has its own independent status indication and progress bars. All interaction, with an account or collection of accounts, then needed to be driven through this paradigm.

Since we are using the core YUI package, we had few cross-browser issues. Consequently, the biggest challenge ended up being with the regex engine in Safari 2. The JSON object used to update each card can become quite large. I use Douglas Crockford’s JSON parser to validate that the response is a valid JSON object. However, in Safari, if the JSON object was larger than 5000-7000 characters, it would crash the browser without warning.

[Note: Luke Smith on the YUI team has adapted Douglas’s work for inclusion directly in YUI as of the 2.4.0 release; see the YUI JSON Utility User’s Guide for more. -Eric]

You adopted YUI early in the process, and it continues to be an important part of the mix for your frontend architecture. We know you guys take your JavaScript approach seriously, as your blog attests. What informed your decision to go with YUI as opposed to a pure home-brew solution or one of the other free alternatives?

We choose YUI for many reasons — here are a few of them: well documented and cross-browser safe code, large development team, high adoption, very active community, and the clout of Yahoo! behind it. There was no reason to reinvent the wheel, when such a solid (free) product already existed. And, our UI development team won’t rival the size of YUI’s team for several more years (although Mint is hiring!), so we wouldn’t be able to keep up with improvements.

What’s worked well for you so far? In what ways has YUI seemed like a great fit for your specific challenges?

The Event Utility is by far my favorite package. The ability to easily attach events, manipulate scope, and pass objects through to the event callback function was exactly what we needed. YUI was also one of the first frameworks to offer a CustomEvent object, which is one of my favorite parts of YUI. The onDomReady() function was also very valuable for improved performance, at least until I moved the JavaScript out of the header.

We always ask, and genuinely want to know: Where has YUI not worked well for you? If you were going to pick a few things that would make YUI a more effective toolkit for Mint, what would those things be?

It would be nice if there were DOJO/MooTools-like tool, where I could choose which browser matrix I wanted to support (like all A-Grade browsers) and/or which methods I want [to reduce overall file size].

Q: Please tell us a bit about your company, TripIt

A: Over the past year or so I have been working on building TripIt, after a six-year hiatus from web application development. TripIt is a personal travel assistant that helps you organize your travel plans and stay in touch with your friends and colleagues.  We want to replace the manila travel folder as the preferred way to manage your travel plans.

The core of the application is a set of technologies that we call The Itinerator.  The Itinerator has three primary responsibilities.

• Consume all of your travel information and understand it so that it can enhance it with all kinds of meta-information such as maps, directions, and weather.
• Provide tools for both organizing and sharing your travel information
• Provide as many channels for re-distributing your travel information through a variety of open standards and protocols such as iCalendar, email, etc…

After months of development, TripIt launched our open beta on September 17th, 2007 at the TechCrunch 40 conference and the response so far has been incredible.  There is no greater joy for engineers than when people use what they have built.  That said, TripIt is at the very beginning of its life, and we are constantly learning and improving the application to better serve our customers.

Q: Can you tell us why you chose YUI, and how you’re using it?

A: When we started TripIt, one of the first choices we made was to pick our web development framework.  We chose Symfony, which, like a lot of the web development frameworks out there, comes with an embedded copy of Script.aculo.us.  At the time, I hadn’t done any UI coding for the web in over six years and we had to get this thing started (FAST!), so we just used what we were given.  Script.aculo.us is a great library and is very fast and lightweight.  The problem was that it didn’t have all the widgets we needed and we were moving so quickly that we couldn’t afford a lot of time finding the best calendar widget, the best menu widget, etc…  So, I began looking around to see what else was available, and came across YUI.

YUI was perfect for us.  It had the best combination of widgets, lean design, comfortable programming model, and, most importantly, good documentation and examples.  It also had a small but growing — and seemingly excited — community of people who were using it (all important things to look for when evaluating any piece of open-source software!).  We got everything moved over to YUI and have never looked back.

Q: What are you using in YUI?

A: At this point, TripIt is using most of the library’s controls (AutoComplete, Calendar, Container, and Menu).  Of course, we’re using the core Yahoo Global Object, Dom, and Event components, as well as Animation, and Connection Manager,

Q: Every adoption of a new technology comes with some pain. What have the pain points been in adopting and using YUI so far?

A: The biggest pain we had in first getting started with YUI was the visual styling of the widgets.  We started using YUI before it was skinnable (i.e. pre-2.3) and ended up reverse engineering a lot of the YUI styles that control the look and feel of the calendar and menus.  This led to some instability in the UI.  One of the main reasons we upgraded to YUI 2.3 (which was a bit painful as well) is that we can, over time, sort those issues out.  We were very happy that the YUI development team recognized this problem in the community and added Skins.

Q: What role did YUI play in the building of TripIt?

A: When we started building TripIt I was the UI engineer (among other things!) but I hadn’t programmed a real web application in about six years.  Back then AJAX existed as a technique but most web developers (myself included) probably would have said it was a bathroom cleaner.  Nowadays, of course, it’s expected that web sites have both dynamic elements and communicate asynchronously with the web server.  The one thing I noticed that hadn’t changed over the years was the lack of consistent and current support of web standards across all of the major browsers.  YUI was critical in enabling someone like myself (i.e. a software engineer who hadn’t done much UI development) to get up to speed quickly and build a modern website that worked well across all of the major browsers.  YUI doesn’t solve all of your problems, but it does make a lot of the more basic issues go away.  Fortunately for TripIt, I don’t do most of the UI development these days so you will see the UI dramatically improve over the next couple of months under our UI engineering lead’s expert guidance.

Q: What’s next for TripIt?

A: We’re going to continue to make TripIt smarter and smarter so that it can do more complex tasks for our travelers.  You can expect us to work hard to support more vendors and input formats, as well as add more ways to access and use your travel information.  The goal is for TripIt to be able to integrate your travel plans wherever you choose to book and to give that information back to you in the format or application you find most useful.  Examples of the types of things you will see us work on are:  features such as "TripIt To Me," which we just introduced as a Launchpad company at the recent Web 2.0 Summit.  With this feature, you can get instant access to all of your travel information on your e-mail enabled smartphone or PDA using a very simple and intuitive command language.

It’s important to keep in mind that TripIt is just getting started. We have an engineering and product development team that is passionate about listening to user feedback.  We’re also fortunate to have a traveler community that is excited about what we’re doing and giving us a wonderful stream of feedback. A lot of what comes next will be heavily influenced by the TripIt community itself, so let us know what you think!

Q: Final thoughts?

A: I just wanted to thank you for the opportunity to talk directly with the YUI community.  We appreciate the work the YUI development team is doing with YUI and are very happy that Yahoo is releasing this great work for use by the development community.

Tell us a little bit about Nestoria’s product — what problems are you solving for your users?

We’re a search engine for property in Spain and the UK (http://www.nestoria.es, http://www.nestoria.co.uk).

We focus on one thing and one thing only — helping people find property to buy or rent as quickly and easily as possible.

That has a couple of pieces: data quality, freshness, speed, and of course the usability. That’s where YUI comes in — helping us build the interface that allows users to intuitively understand our site and find the content they are interested in.

We work hard to make things very simple for the users. It may sound counterintuitive, but creating simplicity can be exceedingly complex technically — you can imagine ranking algorithms, geocoding, etc.

The Nestoria site itself is a mashup of properties with maps and overlays of all kinds of relevant content like schools, tube lines, pubs, photos. We also make data available via an API, geoRSS, KML, all kinds of widgets and a Facebook app, so we’re pretty busy.

Here are some examples:

• Flats for rent in Edinburgh
• Houses for sale in Sevilla

We’re a small start up of internet veterans. The company has been around since 2006, and the site is made with LAMP where the P is perl.

You transitioned the product recently to YUI. What factors led you to choose YUI for Nestoria?

As a small company (9 people — that’s total, not just developers), it’s very difficult for us to test on all OS/browser combinations, so we love the fact that YUI comes with A grade browser compatibility. In the past we spent days debugging keystroke event handling.

Other major factors were the well organized documentation and examples, the continual innovation, and the great community that supports YUI.

The icing on the cake was that we don’t need to serve the libraries ourselves. This is good for two reasons: lower bandwidth costs for us, but also our pages are faster because users are more likely to have the libraries cached to begin with.

Finally, we appreciate the effort that goes into consistent namespacing — we’re running other bits of javascript like mapstraction and Google maps on the page as well.

What parts of the library are you using today?

Right now we use four pieces:

a. the autocomplete for our search boxes — which is truly amazing in how customizable it is:

c. we’re testing the use of animations to hide more advanced features from users until they really need them

d. some of the CSS libraries for styling

How is YUI performing for you so far?

Beyond all expectations. The libraries do what they claim (which I can’t say for other libraries we looked at), so that part has been great. What’s been amazing though has been the support of the community. Questions to the support list get answered quickly, by absolute experts.

What’s missing? What’s been hard about using YUI so far?

I’d like to see the examples expanded — I think that would reduce the volume of basic questions on the support list.

One challenge I see for the YUI team going forward is the need to simultaneously serve both advanced power developers and also first time javascript users. Not easy. The sheer volume of questions and feature requests is rising.

I think the only sustainable solution is to give the community the tools to support itself. As an example, there are times we’d love to save time and just pay a YUI expert to spend an hour or two building a prototype showing us how to implement something. Perhaps Yahoo! could facilitate these sorts of things?

Another simple solution might be to divide into a newbies and advanced list.

In terms of technical specifics — I would love a dual slider — though we were able to find and extend a user created version.

Also, a tool to tell us which libraries we need - we want to load only the absolute minimum and not reference 10 javascript urls. Mootools does a good job in this respect.

In terms of rich-client work, what’s next for your product? What are the hardest problems you’re trying to solve on the UI side in upcoming versions?

We recently launched access to ‘meta’ data — things like average house prices. We’re looking for some interesting ways to visualize this information.

Nevertheless, the focus for us is always simplicity and speed, so it’s unlikely we’ll be adding much heavy rich-client type stuff to our site. We focus on presenting highly relevant data as quickly and in as user friendly a manner as possible.

That being said, we do offer all of our data via our API. We’d love to see folks get their design freak on and do some crazy data visualisation stuff (*hint*, *hint*).

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

Gaia is very graphically oriented by comparison to the typical web site, with a focus on avatars and a virtual world experience. As a result, the site has a constant need for rich visualizations to convey that sense of “world”. From the header down to the graphical heavy modules on the site (contest winners, featured content, upcoming events, etc), just about every piece of the page is given a graphical treatment. In many ways, our goals were directly opposed, both to build as many unique visuals into the site as possible while reusing as many elements as we could to reduce load times and ease the strain of content development. At Gaia Online, we were building a new look and feel for a site that has been around for several years. Due to the size of the site (and legacy code issues), the entire site could not be upgraded in one fell swoop. Instead, we needed to find a way to introduce UI components for the required functionality without disturbing the existing infrastructure on the site; all while letting us still plan for the interactivity and internal page refreshes slated to appear over the next several months.

What role is YUI CSS playing in your project?

YUI Reset CSS and Grids CSS were the keys to creating our layouts in such a way they looked consistent across all browsers. During our migration, we created an alternate version of the reset.css, prefixing the declarations with #gaia_content. This let us mark the body tag on pages that had been converted to use both the reset.css and Yahoo’s grid system. Once we have migrated all of the, the body#id becomes obsolete and can be phased out of the document, leaving us with the pure YUI CSS.

Because of Gaia’s heavy graphical nature, we also found ourselves working with pixel based constraints as opposed to the em flexibility provided by the traditional YUI grid layouts. Not wanting to lose the all the power the grid layouts gave us, we made minor adjustments to our own core.css (an override loaded in addition to the YUI Grids and Reset). In this file, we used one higher layer of specificity to change the relevant measurements from em to px. It worked perfectly out of the box:

 
/* adaptation of yui-t7 */
/* 
 */
#gaia_content{
    width:950px;
    padding:10px 9px;
    border-left:1px solid #000;
    border-right:1px solid #000;
    margin:0;
    background:#e4ded8 url(/images/gaia_global/body/shared/rs_bodygradient.gif) repeat-x top left;
}

#gaia_content.lrec_mainLanding .yui-b .yui-gb .yui-u{
    width:310px;
    margin:0 0 0 10px;
}
#gaia_content.lrec_mainLanding .yui-b .yui-gb .first{
    margin:0;
    width:200px;
}
#gaia_content.lrec_mainLanding .yui-b .yui-gb .second{
    width:420px; 
}
#gaia_content.lrec_mainLanding #yui-main{
    margin:0 0 10px 0;
    height:250px;
    overflow:hidden;
}
#gaia_content.lrec_mainLanding .middle{
    margin:0 0 10px 0;
    height:260px;
    overflow:hidden; 
}

(Note: In the above example, we created several variations of the yui-t7 layout by adding an additional class to div#gaia_content.)

Beyond the CSS, we found ourselves using Yahoo’s markup for more than just the YUI components. To remain consistent, modules were given the typical hd/bd/ft classes which could then be overridden with ID specific CSS. For our “pure graphical” modules such as advertisements, this let us give more semantic meaning to the modules, defining themselves for browsers that were not using CSS. Without knowing how the scope of the project would change after its launch, using these core class names and consistent styles make it possible to easily implement Drag/Drop, Panel, and Menu in the future depending on how the design might evolve.

You’re making use of YUI’s JavaScript Core (YAHOO, Dom, Event), Utilities and UI Controls, too?

• YUI Menu Control both from HTML (primary navigation) and for the Shortcuts menu (from JS)
• Panel Control for the world map navigation and the Daily Chance rewards
• Connection Manager in the map navigation and Daily Chance
• Animation Utility in the map navigation
• Event Utility attachment in the header (menu items, map launching, Daily Chance)
• TabView Control for rotating “features” on the logged in home page
• Drag and Drop Utility in the Gaia Profiles
• YUI’s Logger Utility to avoid alert() everywhere

For a tour of Gaia’s current use of YUI the YUI components listed above, check out video below (also available as a QuickTime movie):

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

In Gaia’s current release, the map navigation was a milestone for the site. It set the direction towards interactivity, making use of the existing “browse the world map” concept we had, and reusing it in a much more engaging way. On the content level, the adaptation of the grids.css made it possible to enjoy Yahoo’s strong support for standards while accommodating the pixel-perfect requirements of the visual design team.

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

The YUI documentation is very good, although sometimes we found it lacking in practical examples and applications, specifically on many of the more obscure (but very useful) methods that aren’t covered on the default YUI site. In our most recent development, we’ve used the YAHOO.util.Dom.generateId() method for many situations where we need a unique element, but do not actually need to know the ID outside of the module’s context.

In the actual code, the Menu Control has placed itself in a very interesting position. At present it’s hard to have both a lightweight and robust menu at the same time. We’d love to see Menu (and some of the “heavier” components) to make use of the YUI Loader once it is out of beta to include only as much code as needed. The second thing we would love to see improved as YUI grows is a way to access the underlying nodes that are created with so many of YUI’s build-from-markup utilities. Being able to access a Menu’s nodes and subnodes when built from HTML would be a prime example.