Category: SPAs

Categories
APIs Architecture Backend Collaboration Frontend Innovation SOA SPAs

Next Gen FE

(Bluxome Labs : 7/16-7/16)

Leading the Charge

Upon returning from vacation, I disovered that the VP ENGR gave the recently-joined Team Lead carte blanche around moving ahead with the next phase of re-engnineering the codebase for a further SOA-influenced frontend and backend split.

Being intimately familiar with the current system architecture, in a race against time for Week One (only had a week before VP ENGR wanted Best Practices/new workflows/adoption of new technolgies and because one substanitally differing proposal – likely much more costly from development and operational standpoints – was on the table,) I set out to formulate a concrete strategy towards delivering in the short-term while providing a basis to iterate against a longer-term architectural shift.

Architecting the Solution

First, I advocated for the adoption of the ‘Launch Page’ as the testbed with which to move forward. Then, I reviewed that page in order to reverse-engineer whatever model attributes I might be able to use (in a Backbone model) as exposed by in a simplistic GET request on page load for initial state.

I then modeled that simplistic endpoint using the Swagger Editor

Next, I dumped the YAML of that endpoint and leveraged Swagger code gen tools to create an initial version of the endpoint in Node.js (and Ruby and Java) and fired up that Node.js for serving HTTP requests.

At that point, having proved to myself the utility of Swagger for spinning-up some simple Node.js services, I turned to building out a placeholder SPA using React that would consume a Node.js service. I opted to stay within the Rails paradigm (instead of adopting an approach of statically hosting assets elswhere) and first used react_on_rails to incorporate React and then the react-rails-hot-loader for HMR.

I wound up needing to patch the latter locally in order to get Web Sockets working correctly in my environment.

Having put the Big Rocks in place, I could hand off the SPA POC to the F2E consultant for further refinement and could focus on building more of a case for the overall approach which the VP ENGR then gave his blessing to.

Building the API

During this phase (Weeks Two and Three,) I implemented GET, POST, and PUT JSON-serving routes in Rails (not to have to worry about CORS) while also developing in the context of Amazon’s Lambda and API Gateway, taking the Node.js server stub above and dropping it in as an HTTP Proxy to collate information from existing API endpoints (as microservices.)

I also worked with five backend specialists and my work guided the conversation around establishing Best Practices for API development.

Results

  • Championed bottoms-up approach to decouple microservices, influenced VPE/Team Lead/F2E to adopt, and prototyped using React / Hot Module Reloading
Categories
Architecture Backend demand-side eCommerce Frontend Full-Stack Innovation SPAs

Demand-side UX Refresh

(Bluxome Labs : 4/16-4/16)

In a unique position given my previous experience with the UX, I took an opportunity when tasked by Product and Design to not only reskin the Listing but also to upgrade it.

Given that no one besides me really knew how RequireJS was working in the application and given its falling-out-of-favor in the general community as a module-loading solution, it was time to upgrade it to Webpack.

Here’s what the Task Listing looked like before

Here’s the mock from Design

In chronological order, here’s what I did

  1. Upgraded DataTables from 1.9 to 1.10
  2. Refactored JavaScript towards more of an OO paradigm
  3. Applied new skin
  4. Ported JavaScript for RequireJS to CoffeeScript for Webpack
  5. Deployed

…and here’s what I delievered

with modal

Results

  • Successfully advocated for adoption of Webpack to replace RequireJS and then ported most-trafficked page, while achieveing near-pixel-perfect re-skinning.

 

Categories
Collaboration Frontend Full-Stack Innovation Machine Learning SPAs supply-side

ML Workflow UX

(Bluxome Labs : 3/16-3/16)

After focusing on other priorities, I was pulled into a revision of an interface (I had also created) as delievered for the Rich Data Summit allowing customers to send any model predictions under a certain threshold to the crowd.

I took the following (revised UX) static mock from Design

and iterated to deliver the following

Results

  • Crafted SPA as lynchpin connecting platform’s Machine Learning (Python) and human-in-the-loop (Ruby) systems after convincing team SPA was optimal approach.
Categories
demand-side eCommerce Frontend Leadership SPAs

WYSIWIG Platform UI

(CrowdFlower : 7/15-8/15)

The team knew that our most-important customer-facing UI needed an overhaul. Approximately a year before, a contractor had come in to attempt that. His prototype, built early in 2014 in React, lay dormant because it had not had a project champion to fully see it into production. In the summer of 2015, the timing was right for our team (with me as the Tech Lead) to pick up the banner and carry it forward.

We revisited the prototype, shown below

No usability tests had been done on it so we didn’t really know how customers would take to it. Product handed us a design and we promptly set about its realization.

Though I attempted to introduce the use of Webpack and Hot Loading, given how much re-writing would have been necessary to move from the Sprockets dependency management paradigm of Rails to that of Webpack and with the looming deadline, that intitiative had to be abandoned.

We made progress as we extracted some modal functionality into a right-hand pane.

The UX really began to come together: the following screen capture demonstrates one of the key interactions.

We launched something similar (but more polished, see doc link) and that is running in production.

Results

  • Led a team of three Rails engineers (two local, one remote) to upgrade and overhaul a React app towards improving usability and throughput in the system.
Categories
Architecture demand-side eCommerce Frontend Full-Stack Growth Performance Engineering SPAs

Improving Demand-side UX

(CrowdFlower : 2/14-4/14)

Contributors, as they are called, are the +5M people around the world who do work on CrowdFlower’s platform. The application that enables them to do work is one of the company’s heavily trafficked as well as most complicated – blending a Rails backend with MooTools, jQuery, and RequireJS in the frontend.

The application’s UX

…had largely stayed the same for the last five years. In Q1/2014, we decided to enhance it by making it more interactive and towards engaging our users more and conveying the just how much work there is in our system.

Working with the Product Manager and an external Designer, we came up with the following high-resolution mock

Because the application is so heavily used, we knew we couldn’t merely throw the switch on a new design overnight; both from a community management standpoint as well as application performance. Instead, we chose a strategy of introducing a first at the company: use of A/B Testing to determine a design that would perform as well as if not better than the original.

Our key metric for performance in that regard had to do with contributor’s performance after being exposed to the new UX, particular the messaging around our forthcoming gamification and introduction of Levels. In the beginning, we did not have the infrastructure to determine the value for that metric so we simply settled on ‘clicks’ as a (conversion) proxy to understand if the new design was having an impact.

Infrastructure

Without an A/B Testing framework in place, I needed to choose one. As requirements were not concrete for such, I did some due diligence in vetting several options, coming up with a review of A/B testing frameworks for Rails.

It became obvious that Vanity was best suited to our needs. (Since it doesn’t yet have the ability to throttle a percentage of the traffic receiving experiments, I augmented it with Flipper.)

Once that was in place, we could begin iterating on the design, knowing with confidence how we were impacting the user experience.

Server-side

We knew we wanted the experience to be snappy, but completely replacing the existing experience with a Rich Internet Application was far out of the scope for the first month, particularly as there were infrastructure changes to be made to retrofit the stack with A/B Testing. We decided to make progress iteratively over several sprints.

In our first test, we pitted the control (original) against a bare-bones implementation version of the high-resolution mock as the new design.

original

The new version out-performed control (in terms of clicks) 21.3% vs 20.3% (at 95% confidence) so I continued to iterate on the implementation, coming up with the following

To calculate the overall satisfaction by other contributors for a task (denoted by the stars) proved to be too inefficient in this iteration; it wound up losing.

Client-side

On the assumption that we needed to make the experience snappier in order to drive engagement, it was obvious that we would need to have more (and faster) interaction and therefore, an interactive client-side implementation.

As what was essentially a completely parallel product, leveraging only some of the infrastructure that the server-side rendition was utiziling, I begin to flesh out the following

Further refinement (an actual data) was necessary to get it looking more like the high-res mock (and like its server-side-rendered peer)

At this point, we implemented and integrated with our own homemade badging solution, beginning to display badges in the following iteration

The new version out-performed control (in terms of clicks) 21.3% vs 20.3% (at 95% confidence) so I continued to iterate on the implementation, coming up with the following

Testing the impact of particular messaging was also of interest, so we added a Guiders variation as well. At this time we also leveraged Google Analytics Events on the Guider buttons to track how the far the user got in our messaging.

Letting the experiments run a few days with sufficent traffic, we found that client-side-rendered version peformed no worse than the server-side-rendered version (23.9% vs 22.9%) and that having guiders also performed not significantly worse (23.1% vs 23.7%) so we decided to keep both.

By that time, the new version was out-performing control (the original design) 22.2% vs 20.7% (at 99% confidence) so a decision was made to move forward rolling out the new experience to 100% of contributors, doing some polishing (copy/styling) work before finally settling on the following

Results

  • Used A/B testing to upgrade company’s most highly-trafficked page (5+M views/month,) increasing user engagement by 5% and saving $2K/month (in Bunchball costs) by rolling own simple badging solution.
Categories
CMS demand-side Frontend SPAs

Demand-side Internal Tooling

(CrowdFlower : 7/13-8/13)

The CrowdFlower platform is consumed via a number of microtasking sites. Each site registers and maintains its own users, but to better track unique identities across the CrowdFlower platform, we built a Single Page App in Ember.js to allow associating users across partner microtasking sites with one unique identifier in the CrowdFlower platform.

Results

  • Implemented a CRUD tool for managing users using Ember.js while iterating in conjunction with Product Manager as requirements changed.
Categories
Architecture demand-side Frontend Innovation SPAs TDD

Improving QA with SPA

CrowdFlower : 4/13-7/13)

Test Questions are used as the gold standard of quality in the CF platform, but they can be laborious to create, particularly for work that’s periodically repeated.

As no templatized solution existed, a team of three of us (me as F2E, Product Manager, and Backend Engineer) tackled creation of an internal product to simplify the workflow.

The user flow was to create “Cases” of Test Questions that got sent to jobs as “Batches”; where the composite idea of a “Mold” encompassed all “Cases” and “Batches” for a particular set of target jobs.

(“The Forge” was the product’s original name, derived from a time when “Test Questions” were known as “Gold.”)

One of the more challenging aspects of the project was the testing of the app. Selenium has always been a robust solution for testing even JS-heavy experiences, but given its heft, Poltergeist was used instead.

The product was to eventually be made available externally but never was.

Results

  • Built internal workflow tool using Ember.js.
Categories
Architecture Collaboration eCommerce Frontend Innovation Prototyping SPAs supply-side

A New Way To Shop

(Shop It To Me : 1/12-4/12)

Shop It To Me has been a beloved service for years when it comes to finding the best deals across retailers, but we wanted to enable the user finer-grained abilities to find exactly the item(s) of interest for them.

We often had feedback about being able to drilldown by clothing type and brand (e.g. “Rebecca Minkoff handbags”) but our previous tools didn’t enable that kind of granularity.

Enter “Threads.”

As the brainchild of our CEO, project “Threads” has become a way for users to track the specific items of interest to them. We now empower the user with the ability to get as general (e.g. “Black dresses”) or as specific as they want. (e.g. “Rebecca Minkoff handbags under $300.”)

Below, you’ll see the hi-res) mockup we came up with (after having previously white-boarded the idea) in early March (click to view.)

inspiration (as mocked-up in Photoshop)

Over the following two weeks, I ramped up on Ember.js and implemented the first version of the app while the other engineer built out the pseudo-RESTful backend. I won’t claim that the code we produced was the cleanest either one of us ever wrote; while doing the best we could, getting to market was the true driving motivator.

We went live – that is, deployed to production for internal and a select group of test users – on March 27th, 2012, with the following (click to view)

very first landing page

Based on user tester feedback, we decided to bolt-on onboarding and improve the look, so four days later on March 31st, 2012, we deployed the following (click to view)

revised landing page with header and pseudo-onboarding

Based on observations during user testing, we realized the opportunity to incorporate a feed of site-wide activity as that would benefit discovery. We also took a few cycles to flesh out onboarding and a “Things To Do” list given challenges users’ had in making sense of the new product. We also tweaked styling to highlight the very newest items in the users’ results; screenshots follow (click to view.)

onboarding modal on landing page (4/11/2012)
 
1st try: TTD/activity feed on landing page (4/11/2012)
 
2nd try: TTD/activity feed on landing page (4/12/2012)
emphasizing new items (released 4/12/2012)

We brought in more and more user testers. Here’s a screenshot from April 17th, 2012, showing progress we made from our observations

4/17/2012 release of results page

While observing user testers, we discovered that they wanted tastemakers to help them navigate the overwhelming number of apparel items, so we introduced the concept of curation. We also made the assets/images larger by popular demand.

curation (4/23/2012)
results page (4/23/2012)
results page w/larger assets/images (next day : 4/24/2012)

After April 24th, we stepped back to assess how we were doing. I was rotated onto our bread-and-butter projects but the team was augmented with other talent and continued forward, contracting the look-and-feel out to a third party.

The product has since been retired.

Results

  • To revolutionize personalized shopping, a team of three (the CEO as product manager, me as the F2E/architect, another as backend engineer,) created a new shopping experience using Ember.js over two sprints
  • Ramped up quickly on Ember.js
  • Architected frontend as a Single Page Application
  • Worked with backend engineer to agree upon/implement integration between FE and BE
  • Drove development through four major iterations during a two one-month sprints
  • Suggested (though not responsible for implementing) lazy-load as a way to improve performance
  • Picked up design slack when we lost our Graphic Designer
  • Scoped frontend deliverables and managed expectations
  • Worked with CTO to coordinate out-of-cycle releases to production
  • Planned, conducted, and analyzed user testing
Categories
Frontend Full-Stack SPAs

Experience Monitoring at Scale

(Yahoo! : 5/07-2/09)

Yahoo invests a lot of resources into making sure that each of its properties is available around the clock. To assist in that task, a centralized, black-box service was created as part of dev tools to help everyone from senior management to service engineers monitor and understand the health of properties.

On the backend, the service consists of the data store, a metrics collector, aggregation tools, and the configuration store (database-driven.) On the front end, there’s dashboarding, custom reports, and a self-service configuration tool.

Results

  • built and maintained web tools for a Nagios-based experience management solution checking 10,000+ URLs worldwide daily generating 63M measurements per month
  • reduced workload of system engineers by creating (from scratch) a web-based, MySQL-driven, MVC-architected, self-service configuration tool for creation of and management of Nagios checks
  • led SCRUM-influenced development and improved the quality of the team’s SE process by standardizing on championing the use of Catalyst (an MVC framework in Perl.) Improvements included shortened dev cycles, the introduction of TDD, improved performance, better documentation
  • created snappy, responsive interfaces using custom JavaScript along with YUI in conjunction with JSON-serving REST web services (Perl.) Also achieved performance gains through page-weight optimization
  • reduced development costs through the use of VMWare virtual machines for testing, building, and deploying as part of continuous integration. Implemented a packaged solution for automated regression testing using Firefox, Selenium, X, WWW::Mechanize