NYLE CONNOLLY

BLOG

Back

AutoTrader Valuations - A Case Study

December 13, 2015 at 20:11

In June 2014, I began work on the new AutoTrader Valuations tool. This project was the first large-scale development I had the opportunity to work on as the sole UX Developer. The development time for this project included the mobile and desktop version of the journey and also work on projects outside of Valuations, including the AutoTrader Private Plates page. This project commenced on June 2014, and was completed on December 2014.

The Brief

To write the front-end code of the new AutoTrader Valuations tool, implementing the latest AutoTrader designs and further developing the current front-end code base to be completely re-usable for other new products.

The Role

I was responsible for the front-end development of the Valuations journey. This task also included adapting the front-end code-base. I also designed and implemented the new datepicker, to be rolled out across all new AutoTrader products. I also had a small part in the planning and decision-making process of this journey.

The Technology Stack

HTML5, Sass & Compass, JQuery, Backbone.JS, Underscore.JS, Require.JS, the Grunt task-runner and numerous Grunt plug-ins.

The Software

Adobe Photoshop CC, Adobe Illustrator CC, Adobe After Effects CC, IntelliJ IDEA 13, Mac OS X Terminal

Firstly, it is important to point out that, unless stated otherwise, I am not responsible for the designs featured on this page. They are the property of AutoTrader and have been used here with the permission of the design team.

The Code-base

Before starting this project, I began life at AutoTrader with the Search squad, (a term used to describe a small team in an Agile development environment) who had just created a new front-end code-base for the AutoTrader Search page. When I first joined the company, I temporarily worked with this squad, develpoing the Search page. After two months with Search, I moved over to the Motoring Services squad, my current home at AutoTrader. At the time, the Search squad was the only squad using a front-end task-runner with Sass, Compass and a JS MVC framework. When I was then given the task of building the new AutoTrader Valuations page, I decided it would be best to use the code-base created by Search. Unfortunately, this code-base wasn't really built to be used by anybody outside of their squad. My first task was to adapt the front-end code-base to be scalable to all other AutoTrader squads and also be as consice and re-usable as possible.

Having only had approximately 7 months experience in a professional work environment at this point, I was excited to be able to make my mark on the AutoTrader code-base. As I was (and still kind of am) relatively new to working on large-scale projects, I was endlessly (also still am) researching best-practises, organisational methods and reading as many blog posts as I could find, to guide me and inform me of best practises. As part of this task I also decided to write a README instructional file in Markdown for any other developers, new to the code-base, who wish to know their way around or know certain methods of implementation.

The first task was to organise into appropriately named directories, any documents that were loose in high-level directories. I organised the root SCSS files into a page-sets directory. This essentially relates to pages, however, with the new design schemes I thought many of the pages would be largely re-usable, so creating a page-sets would allow me to create reusable themes dependant on the type of page, and this is also a little more semantic than just pages. Another positive of this workflow is that it will also force page designs to share common elements, maintaining a consistancy across all AutoTrader pages.

Having created a series of page-sets, it was then necessary to add a page-specific directory, for any pages that do require bespoke styles. The new Valuations tool being a good example, with it's funnel infographic. I then continued to organise the images, icons and mixins directories. Amongst these, I also made some much more subtle, intricate changes that I will outline in future blog-posts (once I have refined and developed the methods and organisation).

The final, and possibly the biggest change I made to the code-base was the change to the way icons are implemented in the site. This came about after extensive research into SVG icon solutions and also after being tasked with some Internet Explorer fixes for broken @font-face icons.

The Development

Another reason I was excited to start working on the Valuations page was, it featured some new components never before seen on AutoTrader. Again, this just gave me the opportunity to make my mark on the code-base. Two of the biggest features on this page are the funnel infographic, created entirely in CSS, and the subtle parallax scroll, featured on the hero of the page. If you have read other blog posts, you will know that I have recently been implementing parallax scroll into my personal projects, so it was a good opportunity for me to align some of my side-projects with my professional work.

I. The Prototype

When I was first given the brief, I decided the best thing to do would be to create a prototype of the page. I wanted to see how the new components (the parallax and the funnel) would affect page load times and also just how the page would look with these two effects working together.

I created a crude prototype, using Photoshop to quickly cut out a car from Google images and cut out the funnel from one of the early design concepts. From here I was able to create a page that featured the two new componenets, on which I could try different techniques and methods to make sure the implementation was production ready. This was also a useful excersice to get a better understanding of how the finished product would look.

Once I had a working prototype, my colleagues and I discussed whether or not these components added value to the page and, most importantly, the product. There was a largely unanimous decision in favour of implementing these new components, so work on the real page began.

The idea for the funnel infographic was inspired by this brilliant Codyhouse article. I read through the piece and began figuring out how I could implement this into our code. The concept behind the effect is ingeniously simple, behind the entire page, you apply two position:fixed elements that are then shifted to take up the top half and bottom half of the page. You then apply a transparent SVG graphic to the foreground of the site, and when scrolled, it gives the illusion that the graphic is filling with colour.

It was necessary for me to modify the filling effect to fit this page. Firstly, the graphic is situated in the centre of the page, and secondly, the graphic had to be fluid and not snap to fixed points as it does in the demo. I set the graphic to a max-width of 100% to fill the content area. I then applied two pseudo elements, :before and :after, styled with the background-color to fill in the gaps either side of the graphic.

II. The Animation

Initially, the fill-effect only filled the funnel lines themselves, when the designer suggested we change the effect so that the icons above and below the funnel would also fill. At first I wasn't convinced this change would add to the site, so instead of spending hours of work on developing a prototype, I decided to create an animation of what the new funnel might look like in Adobe After Efffects. I was pleasantly surprised by the result and we decided to implement the change, which can now be seen on the live site.

III. The Parallax

The parallax scroll featured on this page is very similar to the one I used in the Yoki project. There is a slight difference to the way this piece works, the Yoki project was created by applying scroll rate changes to two component pieces of the page, a front "pane", and a back "pane". For this project, I kept the page content at the normal scroll rate, and only altered the back "pane", which holds the reg and mileage input form.

define(['jquery', 'backbone'], function($, Backbone) { return Backbone.View.extend({ initialize : function(){ $(window).bind('scroll', function(){ var scrolledY = $(window).scrollTop(); $('.js-parallax-back').css('top','+'+((scrolledY*0.1))+'px'); }); } }); });

The above code is composed of three separate technologies, the first of which is RequireJS. RequireJS is a JavaScript framework used to define the dependencies a piece of JS requires to run. It allows the developer to only include dependancies that are required for a particular piece of code. In the first line of the above snippet, you can see that JQuery and the Backbone MVC framework are required in this particular block of code. This small block is then required in a bundle that makes up this one page. Using Grunt, all of the small blocks are compiled into a consice, minified JS document. Alot of this workflow is still new to me and I am learning more about it every day, working closely with my squad.

The second technology that can be seen in the above snippet, is BackboneJS, an MVC framework that provides structure for web applications. I am still new to Backbone and will be writing about it a lot more in the future as I use it more and more. In this case, the parallax scroll JS is contained inside a Backbone view. Finally, the third technology is JQuery, with which the parallax scroll effect itself is written.

IV. The SVGs

The next area of interest on this page is the one I'm most proud of, the new SVG icon solution. Previously, the site used an @font-face icon set which had been used throughout the Search page. Whilst working with the Search squad, one of my tasks was to investigate why none of our @font-face icons were showing in IE8. I discovered that, although @font-face icons are supported in IE8, they are not supported when applied to :before and :after pseudo elements. As a result, I had a choice of task: create a png fallback for each icon, or, change every icon implementation from a pseudo-element to an element (which would also require some resructuring of the HTML). After discussing it with the Tech Leads, I decided it made more sense for me to do the former.

As every @font-face icon now had a .png fallback to support IE8, there was no reason to not switch to an SVG icon solution. IE8 support was the only reason (for us) not to use SVGs. SVG icons are much simpler to implement and they don't have the strange quirks (You can read a blog post I've written about some quirks we found with @font-face icons). The simplicity of this solution is that when we no longer support IE8 (a long, long time from now), it will simply be a case of deleting the fallback png folders and removing one line of HTML from each icon (more on that later). Simple!

I decided on three methods of implementation that each have their own specific use. In recent months, I've dedicated a lot of time to researching anf experimenting with different SVG icon implementations. I won't go into too much detail here as I'm currently writing a full SVG workflow article, so I will briefly speak about my method of implementation on the Valuations pages.

<svg class="icon__class-name"> <title>Icon Title</title> <use xlink:href="#icon-name" /> <image src="images/icon-fallback.png" /> </svg>

The first method of implementation uses the Grunt task SVGStore. I used SVGStore to take a directory full of SVG icons and concatenate them to one string template which is then included in the top of the page. Doing this reduces the amount of HTTP requests for assets and allows me to include the icons inline in the HTML. Another reason I loved this method of implementation was that it allows me to add a title element to the SVG which aids aids screen-readers and other accessibility issues. And finally, it allows me to place a PNG fallback icon right next to the SVG one. Meaning when we finally stop supporting IE8 I can just whip out each image line on the icons.

The scond implementation, in the snippet below, is used for animated SVGs. Unfortunately, SVGStore seemed to alter the way the animation performed, meaning I was forced to find another solution. I used this implementation for the bouncing scroll to more icon. Again, this solution offers a PNG fallback solution in the form of the onerror tag.

<img class="icon__class-name" src="icons/icon.svg}:image_path()$" onerror="this.src='icons/icon.png'" width="185" height="120" alt="Icon description" />

The final implementation method is via Base64 encoding. So far, I have only used this method on the datepicker, which I will talk about more below. I decided to add the left and right navigation arrows in the form of SVG Base64 in an attempt to keep the datepicker as a stand-alone component which can easily be used everywhere without worrying about any dependencies, such as separate image files.

V. The Datepicker

Whilst working on this project, we realised that because we were starting a new front-end code-base, we had to recreate common elements used across the site. This includes things such as non-native drop-downs, select-boxes and, in this case, datepickers. Previously, AutoTrader had used a version of JQuery UI for the datepicker, however, for this new, clean code-base we felt that JQuery UI was too heavy and didn't offer the ease of control and customisation we wanted. The squad Tech lead began researching more suitable solutions for a datepicker and found a brilliant open-source datepicker that gave most of the functionality needed.

As an interim solution, I built the datepicker to be very simple and functional, as seen in the bottom left image. This first iteration was much too simple and didn't stand out enough from rest of the page. After performing some user testing we found that this was a real pain point. As a result, I designed a much more elegant and obvious solution. The latest version can be seen in the bottom right image. This version features a clear border that gives the user's interaction with the device boundaries, it also has a drop-shadow applied to make it lift off the page. This new design will be rolled out across all new AutoTrader product pages.

VI. The README

Finally, as this project came to a close, I decided to write a README.md file that would outline what each directory in the new front-end code-base should be used for and a set of step-by-step instructions for various tasks such as creating PNG sprites or how each type of SVG should be implemented. As well as a set of instructions, the README also outlines a list of rules that should be adhered to in order to keep the SCSS and HTML as semantic, readable and consice as possible. Again, this is something I aim to write about in the future.

The Code Assessment

The desktop site received a Google PageSpeed insights Summary score of 93 / 100. We are currently investigating ways that we can improve this score, some areas of investigation are: inlining all of the above-the-fold styles and JavaScript to eleminate render-blocking on page load. One area where points have been lost is in minifying JavaScript. All AutoTrader JavaScript is minified, however the site suffers where third-party JavaScript, such as analytics tracking is involved, meaning the site itself would be a few points higher without the third-party code. The mobile site received a Google PageSpeed insights UX score of 99 / 100, only losing points on the sizing of text-link tap targets in the site footer.

As well as Google PageSpeed, I have been testing my own CSS to find things like selector counts and specificty graphs. These allow me to analyse how well I am writing my SCSS. Featured below is a specificty graph of the Valuations landing page. It is expected that a site will have a bas-line of 10 and will generally be very flat for the first half, with the odd spike. As the graph gets towards the right-hand side, we expect there to be a general upwards curve as the styles at the bottom of a stylesheet get more specific for overwrites.

Because this page has some large components, such as the funnel, that are specific to only this page, overall, I am very happy with the analysis of the page. One other piece of data I am very interested in is the amount of slectors used. This helps to determine how wasteful the CSS is and how reusable the classes are. The AutoTrader Valuations page has 1,610 selectors, a number I'm very happy with. One area that the UX Developers and Designers are currently working to improve is the consistency across page designs. At the moment, there is too much change from page-to-page and so, through collaboration, we are working to build a style-guide that all future pages will adhere to. Doing this will reduce the amount of font-sizes and colors that need to be included in a page's CSS.

The Future

Overall, I am extremely happy, and most importantly, proud of the work I have done on the AutoTrader Valuations journey. There is still a great deal of improvement that will made to these pages over the coming months, and I am most excited about bringing the new style-guide to life through our code. I aim to write more in-depth articles about SVG implementation and my experiments with BackboneJS in the future, so look out for those in the near future! If there is anything I have mentioned in this article that you believe could be improved or would like more information on, please feel free to contact me at: contact@nyleconnolly.com.

Thoughts, Development
Back