This is the Drupal Case Study of Zappos. We’ve been using Drupal since early 2008 and while it doesn’t power transactional parts of the site currently a major player in our tech stack
- I’m Alex - Former head of Front-End Development and User Experience With Mobile team since June Talking about: History of Drupal and the progression of how we’ve gotten to where we are now Walkthrough the pre-CMS, pre-Drupal days. first Drupal project and beyond Geoff Technical look into Advanced Landing Pages, Baffin and what’s under the hood. Daniel Dynamic Components and building on top of the Baffin platform Stephen Application Support, End-User Support and Documentation with Drupal Progression
Our small front-end development team This is an actual picture of our team in a San Francisco Apple Store during our outing
10 plus sites to maintain including: international sites, lifestyle sites white label sites called Powered By Zappos, which were sites that were themed like the brand but were powered by the Zappos infrastructure and maintain by the front-end team Powered by Zappos program ended in 2010
Our old “classic platform” Perl/MySQL platform Lots of static and non-ecommerce content Lots of requests to make small link updates and changes
“ Please Change the image and link on page” Definitely got bogged down in small updates. Baaah!!! We need a CMS of some sort! Not sustainable
- First taste of a CMS - End of 2007 implemented a 3rd party Blogs platform for blogs.zappos.com - Clearspace, J2EE Enterprise Social Collaboration Platform - Used for blogs, but potentially planned for forums, wikis and customer interaction + Feature rich out of the box: User management, Forums, Wikis, Friends, Commenting, themeing + Nice to have content be manageable via a CMS Looked promising and I have diagrams of how we were potentially going to build out our future CMS strategy using Clearspace. But….
- Early 2008 had Blogs.Zappos.com in the wild In production for about 6 months 3 groups monkeying around with Clearspace Developers customizing/themeing Blogs Sys Admins managing servers, receiving traffic, deploying code Bloggers writing 3-4 blogs posts a day
But after 6 months of monkeying around…. Starting to get the sense that this isn’t a great fit for Zappos…. Developers : Tough to customize and weird templating Written without front-end developers on the team CSS appending (1 monster CSS file for all themes, bottom theme is the most active) Sys Admins : Performance laggy, many reboots, heavy logging Upgrade path tough with any customizations Deploys tougher with Java Bloggers: Rich text editor sucked Not a lot of great 3 rd party sharing and plugins
Why not Wordpress? Probably the most popular Blog platform Sys team questioned the " enterprise "ness of Wordpress Traffic concerns - Engineer: Single Sign-on easier with Java than with PHP - New site revamp is Java
- At SXSW 2008, session called Content Management System Roundup - SharePoint , Expression Engine , Collage and Drupal - Jeff Eaton , from Lullabot gave a great presentation on Drupal - He showcased of some higher profile sites that were running Drupal. - I was impressed with the variety of sites running Drupal and the fact that they were high-traffic sites. Sony BMG, MTV etc.. - I had a chance to talk to Jeff Eaton and Mike Essl after the sessions about the strengths and weaknesses of Drupal and Expression Engine - both agreed for the things we'd use a CMS for at Zappos, Drupal would be a solid solution. - A few months later at IA Summit I talked to Christian Crumlisch from Yahoo Curator of Design Patterns Library. He said it was a solid platform, flexible and feature rich but you would need somebody that understood the internals if you were going to customize and modify it a bit.
Tony had an idea to create a new site: About.Zappos.com Culture, Company information etc.. Great to try Drupal on because: - Primarily static content or content that needed easy updating by business users - No e-commerce parts - Stand-alone site - New site, not replacing - Little risk and can throttle traffic Let's give Drupal a try!
About.Zappos.com – also a compare project! 2 Developers and 2 CMS’s (Geoff new hire, really smart) - Let’s have both Fabio and Geoff work on both projects and compare the two systems - Fabio working on Themeing and building out new Blogs - Geoff working on About.Zappos.com - Switch half way through and continue at the end compare and contrast - Drupal wins
We have our first Drupal Site! - Easy to maintain and update Little code pushes Quick turnaround on projects Customization and plenty of plugins available Awesome to have a Content Management System!
Middle of 2008 we began redoing our Zappos site architecture Ground up redesign of the site From Perl/MySQL to JAVA/MySQL/SOLR New templating system, cleaner front-end code Let’s optimize the site to leverage a CMS, therefore making content more self-service Let’s use Drupal for all our Customer Service pages, Frequently Asked Questions and Legal pages!
Frequently Asked Questions, Customer Service Pages and Terms and Conditions were great to put into Drupal Simple static content that required frequent updates and additions No complicated functionality Pretty straight forward for Drupal to handle But we had some challenges to combine 2 platforms
Challenge #1: How do you combine two technology stacks into 1 seemless experience. Different URLs, different servers, linking between sites Solution: Use our in-house proxy and rewrite engine to combine the two stacks into one, unified experience.
Challenge 2 : Dealing with common/shared code on both platforms. Make updates on both platforms? Solution 2: Parse blank Zeta (JAVA) template into Drupal to share common code. Have this blank template from the Java platform that could be parsed by Drupal and inject it’s own content into the blank space
New Project We had a new Mission Advanced Landing Pages Requirements: Expose categories Independent management of links Image management Pull information dynamically from product catalog - Drupal wasn’t the automatic choice! - Drupal is a star but we have other contenders because of deep integration with e-commerce platform - Riot Family (JAVA as back-end) vs. Drupal (our static CMS star) - After a quick 1 week prototype we chose Drupal - Drupal wins again...first step to becoming a consumer of external API's (see Jeff Eaton's talk at DrupalCon DC)
Challenge 1 : Pull information product catalog Solution 2: Make a bunch of calls to internal APIs including SOLR
Challenge 2 : Make an admin for non-technical users Solution 2: Use a variety of contributed Drupal modules including: - CCK - Filefield - Link - Nodehierachy - Views Entire project was done very quickly. Geoff worked on it and it was in production after only 6 weeks of development Saw heavy traffic relatively soon and was serving up some of the 10 most visited landing pages on our site Geoff is going to do a brief overview of Advanced Landing Pages But also go into the second generation of Advanced Landing Pages called Baffin.
Use a platform that works for your company, culture and development style. Clearspace == Feature rich, out of the box, not meant to be modified heavily or often, not easily upgraded Zappos == we’re going to heavily customize our software, lots of iterative changes, lots of rapid deploys, We need a very flexible platform Drupal better fit for Zappos company and development style Leverage the creativity of your team to bend technologies to meet business needs Solutions don’t have to be documented or blessed Remote template Hybrid tech stack Usage of API’s Are all examples of using Drupal in a non-traditional way but in a way that meets our needs.
Quick Turn Around - Due to business deadlines, we didn't have much time for design and development. - Development time took about 4 weeks. This allowed us to get something out to market rather quickly. - However, the development and scaling of what was put together could have been done much better. - In having such a quick turn around, it was much "easier" for us to learn from what went wrong or what surprisingly went well. Automation isn ’t always the answer - Even though only a small portion of these pages were automated, the business was seeing unexpected/undesired products, search listing, and brand results. - For our purposes, it made sense for us to allow for the best of both worlds. The ability for our business users to automate when it makes sense but allow for manually intervention for the cases where it makes sense. Limitations of the existing toolset - Drupal offers quite a bit out of the box. In the interest of time, we used whatever we could at the time, i.e. out of the box functionality from views and CCK amongst a slew of other modules. - We learned that if we wanted to scale and extend the system, we needed to build on top of Drupal using the built in APIs. This also included the ability to theme on much granular levels. - Instead of using what is available (with limited flexibility), it made the most sense for Zappos to develop something that was more inline with our business that hooks into the underlining infrastructure of Drupal. Allow for more configuration within reason - Not much configuration or flexibility was given with this iteration of landing pages. - The business was asking for the ability to repurpose these pages for things outside of boutiques (although that was the purpose of them). - Instead of looking to create a mechanism for just building landing pages, it made sense to build out a platform on top of Drupal that would adhere to the way that Zappos operates. In this platform, boutique pages would be a consumer of this, along with various other types of pages that had been requested in the past.
Framework Approach - As previously mentioned, instead of tailoring towards a single solution (i.e. boutique pages), this second iteration would allow for the creation of boutiques but other types of pages with very minimal development work. - Like most frameworks, this approach would entail very little development (handle redundant tasks) and allow for flexibility where applicable. One of the big pluses to using Drupal and PHP.
Layouts Components - This approach would be broken out into two destinct parts, layouts and components. Both of these would come from one centralized moudle we refer to as Baffin. - Baffin takes on an MVC-like approach that is two layers deep (maybe talk about what MVC is?). The first layer is handled on a layout level where layouts render the top layer including any page specific and region specific. The second layer is the component level where the base information is passed to the component where the component can hit various APIs, do additional queries, processing, mesaging of the data, custom view work, and a bunch of other things which acts. Anything controller related is handled by the baffin module to help in automated redundant tasks. - Baffin is responsible for permissions, reordering, removing, configuration of layouts, grandular theming, the reusing of content, API related tasks, and to name a few. Baffin by itself does nothing, its the creation of layout and components that make it useful. Its geared towards developers developing on top of it verses it being an out of the box solution.
- Layouts are the initial starting point for baffin. Layout are responsible for: - Configuration for the layout - The output of assigned regions - The output handled on a layout level (verses component level) - The gathering of additional data on on a layout level and any additional views that are needed. - Each region contains a set of nodes which are broken down into components which will be discussed next.
- A component essentially is a content type. However, a content type is treated essentially as a template for a piece of content to a layout. - A component consists of two parts, a model and view. The model handles basic operations like making API calls, post processing of data, settings view variables, the handling of views, and so on. - The view_directory is being set within the baffin_component hook. The baffin_component hook acts as more as a configuration which includes a number of options such as what directory the backend components come from, what directory the views come from, whether the view should cascade to the active theme, and so on. - The base view is located based upon what is set when the baffin_component hook is invoked. Depending if the option has been set in the hook, there is a cascading system that relates to a specific view. It goes as following: theme/view_directory/layout -> theme/view_directory -> module/view_directory/layout -> module/view_directory - We use components instead of blocks because these components are based on a page level verses a site level and the maintenance would be a nightmare if it wasn't done on such a granular level.
- A component essentially is a content type. However, a content type is treated essentially as a template for a piece of content to a layout. - A component consists of two parts, a model and view. The model handles basic operations like making API calls, post processing of data, settings view variables, the handling of views, and so on. - The base view is located based upon what is set when the baffin_component hook is invoked. Depending if the option has been set in the hook, there is a cascading system that relates to a specific view. It goes as following: theme/view_directory/layout -> theme/view_directory -> module/view_directory/layout -> module/view_directory - The view_directory is being set within the baffin_component hook. The baffin_component hook acts as more as a configuration which includes a number of options such as what directory the backend components come from, what directory the views come from, whether the view should cascade to the active theme, and so on. - We use components instead of blocks because these components are based on a page level verses a site level and the maintenance would be a nightmare if it wasn't done on such a granular level.
Geoff Covered: Basics / Fundamentals of Baffin Creating Components / Layouts with code Standard Zappos Page’s Components I’ll be covering Non-standard components Experimental / trying out ideas Common theme: Moving / Interactive But first I want to: Re-iterate or piggy back off Alex’s points Explain how we got to a point where we can: Experiment for the site Play with new ideas for the site
Moslow’s BG is Maslow Important Psychologist Born / raised in Brooklyn Human beings are naturally good Studied superb human beings rather than non-functional ones Hierarchy Human Needs Order in which attempted Typically Don’t Skip a step Water VS Belonging Air VS Friends
Physiological Needs: Food, Air Water For us: CMS Barraged with content updates We were just trying to get some AIR to breath! First Iteration of ALP’s
Safety Needs Shelter, Financial Security Personal Safety For US Second Iteration (Baffin) Solidification of Baffin through iteration Re-worked a quite a bit (API / Other Features)
Love / Belonging Belonging to social groups Making new friends Falling In Love, etc. For us Super awesomely cool stuff Really fun stuff Interactive, Flash, Moving Experimenting / Playing with new Idea’s
Esteem Seeking Recognition Attempting to win awards For us: Cat-skillz (mountain range) Next Iteration Probably Drupal 7/8
Self-Actualization Gandhi, Einstein, Ben Stein, and Nelson Mandela Attempting to win awards Not everyone reaches self-actualization For us: Just like Maslow thinks humans naturally good I think Zappos is inherently good as well Future: Open Source (Where it makes sense) Future: More Involved In Community We are definitely not anywhere near there yet
More Feature Requests / Solutions Completed The more solutions to future problems we have.
I have a couple of solid Examples of this But first Going to show just some stuff that “moves” or “animates” (This slide is pretty pointless)
Uses the Zappos API Specifically The Search Controller Admin uses “Patron Field” aka Zappos API Field, for filtering/faceting on results
Also the Zappos API Specifically The Statistics Controller (This API is open folks) Backend Magic Gives us rough City/State Information Admin Also “Patron Field” aka Zappos API Field, for filtering/faceting on results
Result of abusing WYSIWYG’s in Drupal <object> for our video player doesn’t scale If we change our player, we are screwed / hard to find random pieces all over Used Community Module (Video filter, added our custom filter the module) Two ways: [video=http://example.flv] and Component
ZCLT: Exposure to and encourage adoption of Wiki usage PBZ: Drupal exposure, I was the business client for the front end team ASS: Helped facilitate all of the above and take it to the next level
ZCLT: Exposure to and encourage adoption of Wiki usage PBZ: Drupal exposure, I was the business client for the front end team ASS: Helped facilitate all of the above and take it to the next level
Started with About.Zappos.com Standalone site with static content Typical usage of Drupal, very similar to most Drupal installations out in the wild A few internal users and some light traffic from customers
Late 2008, Used Drupal to power Frequently Asked Questions, Terms and Conditions Still pulled in static content and had light traffic but was incorporated into the e-commerce site Used the remote template parsing I mentioned in my talk
Advanced Landing Pages was the first time we had to pull in product catalog information from SOLR, Databases and other internal API’s. Our information architecture team under UX was put in charge of managing the landing pages. We also started using Drupal on multiple sites for static content. Traffic wise, Drupal was hosting some of the most visited landing pages on Zappos.com
2010 brought Baffin, which is what Geoff did a deep dive on We continued to hit internal API’s and additionally started hitting some external API’s as well With the increasing number of end-users that were managing Advanced Landing Pages and then Baffin, we brought on App Support App Support is what Stephen Hayden talked about
By 2011 and currently, our stack looks something like this: We additionally hit a Dynamic Image Creation API that can generate images on the fly Baffin has increasingly been used as a platform to develop and extend upon. - Daniel talked about building Components on top of Baffin With the increased traffic we started seeing: Caching for performance Multivariate for testing Domain manager for multisite capability Finally we started to expose our Baffin content to be leveraged for our Mobile Apps
Do It With Us! We’re hiring for Drupal positions, check jobs.zappos.com! We have a booth here at Do It With Drupal. Both Jen and Tonya are attending it! We also have a prize wheel where you can win various prizes. Thanks for coming to our Do It With Drupal presentation
We represent Zappos, Drupal was raised out in Holland photo by Adria Richards http://www.flickr.com/photos/adriarichards/
IntroductionsAlex Kirmse @alexkirmseHistory of early days pre-CMS, pre-Drupal, first Drupal project,Drupal growth and Advanced Landing PagesGeoff Berger @geoffbergerTechnical look into Advanced Landing Pages, Baffin and what’sunder the hood.Daniel Lopez @deshawnbwDynamic Components and building on top of the Baffin platformStephen Hayden @mestevoApplication, End-User Support and Documentation with Drupal
the early days…(2006-2008)Our small front-end team….
Zappos Classic- Perl/MySQL platform, proprietary templating system- non e-commerce content needed managing- Many requests to make link, image and wording changes- No Content Management System!
Typical Requests… Baaah Baaah !! "We need a simple FAQ..." "Please change the image and link on page..." "We need to change the 3rd sentence in the Terms and Conditions….baah!" Photo by: Aunt Owwee http://www.flickr.com/photos/aunto
Blogs and the first taste of a CMS - End of 2007 implemented a 3rd party Blogs platform for blogs.zappos.com - Clearspace, J2EE Enterprise Social Collaboration Platform - Used for blogs, but potentially planned for forums, wikis and customer interaction + Feature rich out of the box: User management, Forums, Wikis, Friends, Commenting, themeing + Nice to have content be manageable via a CMS
Blogs.Zappos.com - In The Wild By early 2008 Clearspace was in production, under active use: Developers we’re theming and customizing Blogs Sys admins in production, sending traffic to site and managing the servers Bloggers we’re writing 3-4 blog posts a dayPhoto by Eric Miragliahttp://www.flickr.com/photos/equanimity/
Blogs Feedback Development Team: Sys Admins - not easily customizable - Performance and logging issues - strange template conventions - Tough upgrade path - front-end issues - Longer deploy cycles End Users/Bloggers - Problematic rich text editor - Lack of 3rd party tools photo by Patricia van Casteren http://www.flickr.com/photos/patries71/
Sidebar: Why Clearspace and notWordpress?- Sys team questioned the "enterprise"ness of Wordpress- Engineer: Single Sign-on easier with Java than with PHP- New site revamp is Java
Hearing about Drupal- SXSW 2008 CMS Roundup- IA Summit, talked to maintainers of the Yahoo DesignsPattern library that uses Drupal- Very flexible platform, but definitely requires deeperknowledge if you customize it photo by Stephen hizKNITS http://www.flickr.com/photos/hmalbert
An opportunity...- Tony had an idea to create a new site: About.Zappos.com- Primarily static content or content that needed easy updatingby business users- No e-commerce parts- Stand-alone site- New site, not replacingLets give Drupal a try! Tony Hsieh, CEO Zappos.com
Compare both platforms:-Clearspace (theme and add new Blogs)-Drupal on About.Zappos.com-Switch developers!Which is easier to develop on, customize,extend?
About.Zappos.com – POWERED BY Drupal - Easy updates and maintenance – no code pushes or deploys - Quick turnaround on projects - Customization and plugins easily available
Zappos ZETA- In 2008, Zappos was building a new Zappos site from the ground up- New templating system, new back-end code (Java), cleaner front-endcode, new search indexer (SOLR)- Lets optimize the front-end to be more self-service and include aCMS for all the static content- FAQ, Legal, Customer Service pages to be managed in Drupal
FAQ, Customer Service Pages and Terms & Conditions - Simple static content, frequent updates and additions - No complicated functionality - Simple for Drupal, Some challenges to combine 2 platforms
Challenge 1: Combining two technology stacks into 1 experienceSolution 1: Use our in-house proxy/rewrite engine to combine into1 experience. Drupal Zeta Apache, PHP, MySQL Tomcat, Java, MySQL, SOLR Proxy/Rewrite technology Zappos Experience Customer
Challenge 2: Dealing with common/shared code on both platforms.Make updates on both platforms?Solution 2: Parse blank Zeta template into Drupal to share commoncode. Drupal Zeta Apache, PHP, MySQL Tomcat, Java, MySQL, SOLR
Mission: Create category shopping landing pagesRequirements:-Expose categories-Independent management of links-Image management-Pull information dynamically from product catalog
Challenge 1: Pull information product catalogSolution 2: Make a bunch of calls to internal APIs including SOLR
Challenge 2: Make an admin for non-technical usersSolution 2: Use a variety of contributed Drupal modules including:- CCK- Filefield- Link- Nodehierachy- Views
Lessons LearnedUse a platform that works for your company, culture and developmentstyle.Clearspace == Feature rich, out of the box, not meant to be modified heavily oroften, not easily upgradedZappos == heavy customization, iterative changes, rapid deploys, flexibleDrupal better fit for Zappos company and development styleLeverage the creativity of your team to bend technologies to meet businessneedsSolutions don’t have to be documented or blessedRemote templateHybridUsage of API’s
Moving on from ALPs• Quick Turn Around• Automation isn’t always the answer• Limitations of the existing toolset• Allow for more configuration/flexibility within reason
Where I come from…Started in ZCLT in 2005Helped managePowered by Zappos sites2006-2010Became an ASS in 2010
Application Support SpecialistGet It? ... GET IT???! spice via Daniel photo via: flickr.com/people/alces/
Great, we have help, now what?Own some processes, stop the frustration• Permissions• Login pages• DocumentationHelp the business collaborate• Do more with existing toolsListen to business needs, identify pain points • JIRAPut all that together...
2010 + Power End Users Application SupportStatic content Internal Drupal Website API, DB, Solr Bafﬁn3rd Party APIs
2011 + Business End Users Application Support Static content Internal API, DB, Solr Drupal WebsiteDynamic Image Bafﬁn creation API Components caching,3rd Party APIs multivariate, Mobile domain manager
Do It With Us!Jobs.zappos.comCheck out our booth at DIWDThanks for coming!