{
  "$type": "site.standard.document",
  "canonicalUrl": "https://bradestey.com/writing/redesigning-bimmershops/",
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreihzglsrt2z7zwihudgt3hph3xit7ww2ubtorc4nlz2djznpbns7aq"
    },
    "mimeType": "image/png",
    "size": 622793
  },
  "description": "Redesigning BimmerShops in React",
  "path": "/writing/writing/redesigning-bimmershops",
  "publishedAt": "2016-03-31T04:00:00.000Z",
  "site": "at://did:plc:gjryzxv62p6dfiy4knry3mzt/site.standard.publication/3mn73eclrks2d",
  "tags": [
    "design"
  ],
  "textContent": "In December <abbr>2005</abbr>, Andy Powell launched BimmerShops, a directory of independent <abbr>BMW</abbr> repair shops. The network of directories has since branched out into other (mostly European) manufacturers, like Mercedes-Benz, Audi, Porsche, Volkswagen, and around ten others. In June <abbr>2012</abbr>, I was hired to take over the day-to-day web development of BimmerShops along with its sibling sites. Soon after, we launched a new responsive design. (version 3)\n\nLike most sites, our mobile traffic over the years has overtaken desktop as the primary way that visitors choose to interact with the directories. Our foresight had paid off, however there were many parts of the <abbr title=\"User interface\">UI</abbr> that needed addressing. We had too many textures, gradients, rounded corners and minor inconsistencies that made pages feel busy and content hierarchy confusing.\n\nTo coincide with the redesign, I also wanted to move to a single-page app that communicated with the server though small <abbr title=\"JavaScript object notation\">JSON</abbr> payloads, to improve the site’s overall performance and responsiveness.\n\nDesign\n\nUnlike most web apps, many of the visitors who come to BimmerShops are already frustrated. Maybe they got up Monday morning to find that their car wouldn’t start or they pulled us up on their phone while broken down on the side of the road. Whatever the case, we want to do everything we can to get out of their way and help them find a repair shop as quickly as possible. That means no annoying newsletter sign-up modal windows, no native app splash screens or any other nonsense.\n\nOn the design side, I implemented Bootstrap as our base front-end framework and many Material Design guidelines. It’s our hope that our visitors will immediately feel familiar and comfortable with the experience, given the popularity of these design components.\n\nThe search results pages are the most common entry point into our directories. We added imagery of geographical regions (mountains, snow, beach, etc.) and major city skylines to help make the search results look more like a curated list and less like a dynamically generated database dump. This recycles some old Perry Marshall page optimization advice that suggested using geo-localized imagery on landing pages to help the page feel familiar and increase engagement.\n\nAs part of our effort to avoid visitor annoyance, we present information as upfront as possible. The main call to action on a shop’s listing page is the shop’s phone number, not a “write a review” button. We’re also not hiding the phone number just to encourage clicks or showing any distracting advertising above the fold. If the shop has their hours filled in, then we let you know at a glance if the shop is currently open or when they will be open again. Custom header images, cleaner photo galleries and a list of amenities have also been added to many of the new listing pages.\n\nSigh… JavaScript\n\nOur 3 year-old site had an array of spaghetti jQuery functions compiled together using some Gulp tasks and Browserify. Even though BimmerShops is relatively simple, we needed a more structured foreward-thinking approach. I had been playing around with Angular and Backbone, but was running into a lot of trouble when it came to server-side rendering.\n\nA majority of the visitors to BimmerShops come from search engines. A great deal of time is spent to ensure that our shop listings have the best unique content available. From an <abbr title=\"Search engine optimization\">SEO</abbr> aspect alone, server-side rendering is a must. Coupled with our mission to be as frustration-proof as possible, we also needed server-side rendering to improve the time to first page load. Even if Google can crawl Javascript rendered pages now, the added fault tolerance that progressive enhancement provides allowed us to continue to support older browsers (<abbr title=\"Internet Explorer 8\">IE8</abbr> & below) without a great deal of additional effort.\n\nWhen I ran across Spike Brehm’s talk, _The Evolution of Airbnb’s Frontend_, I was convinced that React was a good way to go. Even though our server-side app is <abbr title=\"PHP: hypertext preprocessor\">PHP</abbr>-based, using Airbnb’s approach meant all I needed was a Node installation somewhere on the same network to send <abbr title=\"Hypertext transfer protocol\">HTTP</abbr> requests to and get fully rendered <abbr title=\"Hypertext markup language\">HTML</abbr> as a response. Testing the render time against plain <abbr title=\"PHP: hypertext preprocessor\">PHP</abbr> views or compiling Handlebars views, the difference was non-consequential. Better yet, since the Node app is completely stateless, if we ever needed to, we could scale up to more view rendering servers with relative ease. If the Node server times-out or goes down for whatever reason, an empty div will be returned by the <abbr title=\"PHP: hypertext preprocessor\">PHP</abbr> server and React will populate it like normal.\n\nKey selling points for React were that we could use <abbr title=\"Node package manager\">NPM</abbr> for package management, <abbr title=\"ECMAScript 6\">ES6</abbr> and <abbr title=\"JavaScript XML\">JSX</abbr> syntax, and most of all, React Router made Webpack code splitting really painless. Code splitting is particularly important in our use case because we have two main groups of visitors, those looking for a repair shop and the repair shops themselves. There are many support pages that are geared toward repair shop owners, so it doesn’t make sense to burden normal visitors with those assets.\n\nUsing Facebook’s Flux architecture made it possible to easily implement features such as skeleton screens, modals, geolocation, and page preloading. Events on a component could now change the state of a completely unrelated component somewhere else on the tree. For example, based on years of data we know that <abbr>50%</abbr> of visitors, who view a search results page, will visit one of the first three shops. With this in mind, after the search results page loads, we go ahead and preload the first three shops into our page store.",
  "title": "Redesigning BimmerShops"
}