Yahoo! User Interface Blog

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:

b. the sliders that allow users to set their search filters

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*).