Building technology to drive sales Company websites have traditionally been viewed as marketing portals. They are places to define the brand, have clear messaging, and capture leads. They can also help build a community and promote engaging content. However, as web technology has grown, we’ve seen a shift for the website to play a much larger role. In addition to all of the traditional marketing content, sites now include account creation, on-boarding and other product flows. So the question many start-ups ask is: Which team should own the website? Should it fall under the marketing team? Or should the engineering team be responsible for its delivery? From an engineering perspective, CTOs often shy away from any website involvement. They fear that marketing will eat into their product development time. While on the other hand, engineering teams can become possessive with the company website, making it difficult for marketing to accomplish their goals. From a marketing perspective, most marketers would love to have engineering resources. Content driven sites like have shown that marketing content which includes interactive features such as calculators, comparison tools and other software widgets, really help engage readers and drastically SEO. This is pretty cool stuff! Nerdwallet To put it simply, websites have become a difficult balance between marketing, product and engineering. Fuzzy’s Approach At Fuzzy we want to have the and marketing flow into product features seamlessly. I’ve seen companies whose product looks nothing like what’s on their marketing website, this results in a horrible user experience. A lot of B2B businesses can get away with this, but as a B2C company we wanted to have a clean and consistent experience. website At their core, websites are pieces of software At their core, websites are pieces of software, so it made sense to us to have the engineering team create a platform that would empower marketing to accomplish their goals. This means that the engineering team would own the website, so it was essential that we chose technology that engineers would enjoy working with to develop features into the site. The original Fuzzy website was built with WordPress — an engineer’s worst nightmare. WordPress purposely restricts the technical work you can do, but it is great for marketing teams that want to be able to draft and publish content and blog posts. Plus, all of our existing content and blog posts were already in WordPress. So we wanted to come up with a platform that harnessed the existing features of WordPress that we liked and expand the site’s capabilities with some Fuzzy engineering. The Tech What most developers don’t know is that WordPress is completely open-source and ships with a . WordPress is really just a clunky PHP application on top of a MySQL database. So if you’re willing to write some PHP, you can really get WP to do whatever you want. REST API Since we have zero desire to be PHP developers and most of the rest of our stack is Javascript, we decided to write a stand-alone front-end for our website. We would restrict our usage of WordPress to just being a content management system, and use its API to display the content with our React chops. React This way we wouldn’t disrupt the current workflow of the marketing team, and they could continue to develop their content in WordPress (using all of its publishing and drafting features). It also set us up to call our internal Fuzzy API when developing features like the sign up flow (and whatever other product features we will want on the site moving forward). Framework is a relatively strict framework when it comes to getting and displaying data, so we followed most of the typical conventions there. Conveniently, it also has a really nice server-side rendering feature that comes in handy when you want to return a completely rendered HTML page (rather than render in the browser). We wanted all of our content pages to be rendered server-side for SEO purposes. Accomplishing this takes a few different pieces. First we start with the basic React ES6class for the page: React with Redux You’ll notice the array appended to our ES6 class in order to make the server-side requests to the WordPress API while the page is rendering. The parameter is gathered from the URL. From there, we use standard AJAX to run the following request to WordPress: need pageName GET: <wordpress_url>/wp-json/wp/v2/posts?slug=${pageName} The content page from WP is then set in our Redux reducer and shows up in our content as React then takes care of the rendering from there. That’s pretty much it! this.props.page. Fuzzy Components Using React as a front-end also allowed us to develop our own widgets that our marketing team can use on our website. For example, let’s take a look at our LeadCaptureWidget: <FuzzyLeadCapture buttonText="Sign up" label="Join the Fuzzy Community" /> It then renders on the website to look like: So we’ve given marketers the power to use components developed by our engineers! Rendering The easiest place to render Fuzzy Components is after the markup has been rendered into the DOM. In React, this is in the lifecycle function. For the FuzzyLeadCapture component: componentDidMount The code above accomplishes 4 discrete tasks: Finding the FuzzyLeadCapture elements Reading their label and buttonText attributes Creating the React FuzzyLeadCapture element Inserting the React element into the DOM. As you can see we’re just parsing the rendered DOM and replacing the existing FuzzyLeadCapture elements with our FuzzyLeadCapture React components. Some developers might say it’s a bit of a hack, but it gets the job done. That’s just about it! You can imagine how we can extend this concept and create more interactive components for the marketing team. We plan on building calculators, comparison charts, and other interactive tools to add to our marketing content. Thanks for reading and please check out our . website
