A year ago we set out on an effort to revitalize PayPal’s user interface. As you may know, there are quite a few pages on our site with designs that date back years and it’s about time we got rid of them! To accomplish this, a large part of what we had to overcome was technical debt, and we needed a technology stack free of this which would enable greater product agility and innovation. With this in mind we set out to “free our UI bits”.
At the time, our UI applications were based on Java and JSP using a proprietary solution that was rigid, tightly coupled and hard to move fast in. Our teams didn’t find it complimentary to our Lean UX development model and couldn’t move fast in it so they would build their prototypes in a scripting language, test them with users, and then later port the code over to our production stack.
There are obvious issues with this approach, so we decided it was time to change things and came up with a few requirements:
- The templating must be decoupled from the underlying server technology and allow us to evolve our UIs independent of the application language
- It must be open source
- It must support multiple environments
Decoupling our templates
By the time Dust was officially released, all of our products were using it in place of JSP.
Open source all the things
We made a conscious decision to fully embrace open source in our UI. It sounds common sense, but enterprise-scale companies often have a habit of creating proprietary solutions — at least we’ve made this mistake in the past — and keeping them propriatary. There are three major downsides with this approach:
- Proprietary solutions create an artificial ramp up time for new employees to become productive
- It forces a portion of your team to focus their energy on building your solution rather than your product
- These solutions are rarely better than the ones available in the open source community
Through a bit of exploration the rest of our UI stack started to fall into place:
- Backbone.js worked out as our client-side MV* framework
- Grunt was being used for our UI build tasks, because, well, Grunt is just awesome
- Mocha was starting to be explored for enabling CI driven workflows for our UIs
Finally, let’s not forget the browser as a rendering environment. Dust allows us to easily perform client side rendering. This brings up an interesting point though: Rather than saying we’re going to render all pages in the browser because we can, we’re opting to do what makes sense for both your browser and our engineers. Client side rendering is great, but not always needed. You’ll notice on the new PayPal pages that the first page is always rendered on the server to bootstrap the app, but from there it’s up to the UI engineers to decide it they need client side rendering or not. We like this flexibility.
Live Dust apps
So, all of this is good, but where are we using Dust and the new technologies today? Well, it’s is actually live on a good portion of our website that’s been redesigned. This includes our:
- Home pages
- Checkout (currently being A/B tested)
- New user signup
- A lot more on the way!
Our UI engineers are now happy. They can iterate quickly on production-style apps with their design counterparts and get those ideas out of their heads and in front of customers. We’re now starting to see a build, test, learn culture form, which is a long way from the waterfall model we traditionally had with our design partners, and hopefully our users start to notice as more of the website gets updated.
Changing the front end technologies at PayPal was a huge success, but we’re now looking to make another step. Node.js started to organically spread through the company as a part of these efforts and we will take a look at that in Part 2.
Finally, we’re hiring, so if any of this sounds interesting come work for us!