Category: demand-side

Categories
Architecture Backend Chat Cloud demand-side eCommerce Frontend Innovation Prototyping Strategy supply-side

Launched MVP

I was brought on initially part-time into a two-sided marketplace in the holistic services space to assist the team to go from an environment where code wasn’t being shipped to a place that could launch an MVP.

Prior to joining, I commissioned my own Market Landscape (via UpWork) around holistic services potential; one finding: 2015 global revenue = ~$40B

Better Engineering

When I arrived, the POC had been built by an offshore team in WordPress via cPanel and PHPAdmin and transferred from AWS to Digital Ocean. There was no source control. The first thing I did was `git init`.

I spent time attempting to decompose the production instance into a Docker container (of WordPress and MySQL.) I learned how tricky it is when an application is not already 12-factored to spin-up an alternative instance having functional parity. In case you didn’t know, much of the application state of a WordPress site is maintained as JSON config blobs IN THE DATABASE.

Seeing opportunity to prioritize feature creation (in support of product-market fit) in lieu of operational excellence, I put the Docker initiative on hold and spun up dev and staging instances using cPanel and PHPMyAdmin, simply copying the prod DB.

dev instance after trying to decouple

CaaS : Chatroom as a Service

First Iteration

My initial task was to integrate a chat UX with a broadcast streaming experience being built out and powered by Wowza. I settled on Converse.js and ejabberd given decent documentation, an acceptable UX, and (what seemed to be) easy integration; delivering the following POC

chat, working

Next Iteration

With the web server running under CentOS on one Droplet, I had thought it smart to run ejabberd on a separate instance, installing v14 on an Ubuntu Droplet. I ran into issues opening port 5281 from the CentOS VPS to Ubuntu so I doubled-back on my strategy, opting to co-host the daemons on one Droplet (CentOS.) I then ran into package manager issues and wound up having to build and install ejabberd 18 from scratch while upgrading OTP to v20.

While this was happening, the junior engineer was working to get the Wowza live-broadcast video solution working and time wasn’t on our side to get the MVP launched.

(Additionally, at one point, I looked at using the YouTube/Hangout API didn’t find support for our use case.)

Attempt to leverage YouTube/Hangouts

Once I got ejabberd 18 built, installed, and running, we started experiencing timeout issues; manifesting in FE with a spinner that spun for 1.5 mins before the user was finally able to get into the chatroom. I dove into the ejabberd code, and realized that there was something blocking going on server-side. I never did figure out what was happening, but about that same time I realized that the junior engineer had integrated Twilio Video for the 1:1 experience and Wowza Streaming for the 1:many broadcast experience.

Seeing opportunity to reduce waste and consolidate coding paradigms, I researched Twilio Video and realized that we could, for the MVP, likely replace the Wowza experience for both of the 1:1 and 1:many experiences WHILE ALSO leveraging Twilio Chat to replace Converse.js/ejabberd.

Twilio Video, 1:many POC

Next Iteration

I found and customized React Programmable Chat

Twilio Chat, POC

The next step was to integrate with Wowza.

Wowza UX, now w/Twilio Chat

As their were some production issues with the Wowza implementation, I forged ahead creating an alternative Twilio Video React component using React Scripts.

1:1 UX, Twilio Video Chat (desktop and mobile)

At soft (internal) launch, I posited the Twilio solution and the other team members were delighted.

Though the Twilio Video quickstart project was useful, I ran into challenges around the video codecs (VP8 and H.264) between Chrome and Safari, namely getting desktop and mobile video interaction to work as expected. Digging around produced Github links helping lead to resolution (e.g. simply switching to H.264 to ensure cross-browser support.)

On 4/6/18, we had our first successful supply-side (1:many) broadcast, powered by Twilio Video and Chat.

MVP

After helping the team achieve MVP launch and when funding could not be raised in a timely fashion, I moved on.

Results

  • Swooped in when feature-delivery was woefully behind, built out (desktop/mobile) UX, and launched MVP to paying customers.
Categories
demand-side eCommerce Frontend Innovation OOJS Process Prototyping

Better NUX

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

Towards improving the New User Experience, Design came up with the idea to use Callouts around page elements whose affordance wasn’t intuitive.

Given the mockup, I set about implementing it pixel-perfectly.

For the first pass, I simply crafted the markup based on Bootstrap’s Alert and hid it by default, revealing it with JS if logic was met.

Then, realizing that the Bootstrap Alert wasn’t sufficient for Design’s needs and that the Bootstrap Popover was, as well as that there would be opportunity to re-use the code elsewhere in the platform, I created a JS Class for the NUX (a.k.a. “Callout”) and subclassed (example) accordingly, modifying the markup accordingly.

Results

  • Established team habit around refactoring and improving OOJS.
Categories
Architecture Building buy-in Collaboration demand-side eCommerce Frontend Leadership Performance Engineering Process

UI Tech Debt

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

A remnant of the legacy codebase from the company’s origins eight years ago, the two most important routes on the platform for quality assurance had never been moved from the company’s original Merb app to its companion (upgraded) Rails experience (back when a first movement towards SOA happened three years prior.)

They were rightly regarded with trepidation given their dependence on MooTools when the rest of the platform had been moved to jQuery, especially as the Jasmine suite for their coverage had been mothballed about 18 months before and those same MooTools libs were tightly-coupled between two platform applications.

Towards a future of less frontend tech debt, I seized on the opportunity to champion and shepherd the project (as a Q2 engineering goal) through to completion.

Over the course of three months, I led the effort around project scoping, weekly communication around engineering effort, and architecting and leading the implementation, interfacing with Product and Design to ensure quality in light of the absent test coverage.

Results

  • Delivered on decoupling strategy for static asset management / Webpack’d bundles while collabratively iterating with VPE/VP PROD and Sr. Engineers
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
Architecture Building buy-in Collaboration demand-side eCommerce Management Process

Overhauling Quality

Bluxome Labs : 4/16-4/16)

Test Questions have long been the quality assurance mechanism of the CrowdFlower platform.

The interactivity behind them was created around 2008 in MooTools as part of a Merb application; that interactivity was never ported, even as the company increasingly adopted Rails and jQuery. For over three years, discussion has been of porting the Test Question interface out of Merb (the last presentation-layer in that app) and into a company-standard Rails app. Given the expected amount of effort with little user-benefitting ROI to be realized for simply a straight port, it’s easy to understand why it had only ever remained a discussion.

Finally, in April, 2016, the stars aligned when the VP of Product expressed a desire to spend time on improving Test Questions usability while the VP of Engineering decided the time was right for moving forward on a micro-service architecture, dividing “frontend” and “backend” responsibilities accordingly. I seized on the opportunity (without being mandated to do so) because I saw that we could kill two birds with one stone

Following is an inventory (I created the initial format for) of JS libs across three different routes (completed by a junior engineer)

I then used this inventory in conjunction with a Jira report to help scope the effort and parcel out work to likely candidates, an example of which can be seen below

Finally, I tracked progress in a wiki page, providing status updates to key stakeholders.

Results

  • Laid groudwork for complete FE overhaul, including success criteria and risks, after shopping technical ideas around with Lead engineers, VP PROD, VP ENGR.
Categories
Architecture demand-side Distributed Teams eCommerce Frontend Full-Stack Management Process Prototyping supply-side

Styleguide

(CrowdFlower : 8/15-10/15)

In late August 2015, given previous successes in the year, I was tapped to lead the engineering team for delvering a visual identiy refresh (in conjunction with conference-ready AI deliverable) by early October.

Week 1

  • took Bootstrap 3/Flat UI/custom styling from Designer and created a static page as ‘gold standard’ for other engineers to reference
  • identified priority routes on which the new design would need to be rolled out
reference page

Week 2

  • created a new layout for and and began rolling out new design on the Rails app
  • drafted a plan for updating the Merb app seamlessly
  • began to onboard other engineers

Weeks 3-5

  • prototyped and tested the idea for asset precompiling in the Rails app and replacing the base assets of the Merb app
  • continued polishing
  • guided other engineers on implementation
  • continued polishing

Week 6

  • coordinated bug-free deploy in conjunction with Marketing (who was working for similarly refreshing the third-party-hosted home page)

Results

  • Organized work of four engineers (two local incl. CTO, two remote) as Tech Lead while planning (and tracking against) engineering sprints and deliverables over two months.
Categories
Architecture demand-side eCommerce Frontend Full-Stack Innovation Machine Learning Management

Delivering AI

(CrowdFlower : 8/15-9/15)

In late August 2015, given previous successes in the year, I was tapped to lead the engineering team for delvering a conference-ready AI deliverable by early October.

In the months leading up to that, the CTO had been prototyping an intial verion of the app in Rails which, for the conference, was to supposed to be integrated with other legacy apps (Rails 3.2 and Merb) and have its UI overhauled to be compliant with the newly-created company Styleguide.

Week 1

  • Given Balsamiq wireframes, put together a few layouts
  • Put basic routes in place
  • Began architecting common styling solution between AI app and legacy apps
basics coming together

Week 2

  • Continued work on common styling
  • Made choices aobut JS libs and prototyped interactions given wireframes; got buy-in from CTO, Product, and Design
  • Began work integrating with ML Python web service

first index page of models

Week 3

  • Given higher-resolution mockups by Designer, started to polish look-and-feel
  • With architecture in place, began to parcel work out to other engineers

first version of export

Week 4

  • As conference neared, knew we weren’t going to be able to deliver everything; worked with Product to focus on MVP
  • Oversaw work of other engineers

adding data to the model

Week 5

  • Continued to lead other engineers and refine interactions
annotating a model

Week 6

  • Applied final polish
  • Delivered for the conference! Following are a few screenshots demonstrating some of the deliverables

Results

  • Led team in coordination with CTO to deliver AI application (Rails) for company-sponsored conference on Machine Learning, Artificial Intelligence, and Data Science.
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 Collaboration demand-side Distributed Teams eCommerce Innovation Process SOA

Legacy App Port

(CrowdFlower : 4/15-8/15)

In the Spring of 2015, seven years after the company’s inception and three years after the intital movement towards an SOA paradigm and away from the monolith Merb app (essential to the company’s business,) the architectual shift was still not finished.

Towards further paying down the tech debt of needing to maintain that app, I lobbied for, organized, and oversaw the extraction of the final presentation layer components into a more modern, more maintainable Rails app.

While not quite the magnitude of the previous major refresh, I recognized it would still be a mammoth effort. In order to attack the port, I created a spreadsheet project plan, inventorying all platform routes torwards prioritizing for the eight most-important, portable, customer-facing routes.

Following is a before-and-after example of what was achieved across those eight routes over four months.

Results

  • Secured adoption by CTO, VP PROD, Lead Engineer, and VPE to port view layer from legacy Merb app to Rails app.
Categories
demand-side eCommerce Frontend Full-Stack Innovation Leadership Process supply-side

Key UX Upgrade

(CrowdFlower : 6/15-7/15)

After two years of usage, the company could tell that the paradigm previously introduced had led to improved Usability overall of the product but users were still confused about workflow.

After having tackled the welcome, we launched into rolling out a complete overhaul of the UX, moving from a left nav Master-Detail paradgigm to a top-nav Subway-Map approach.

The main challenge with rolling out a new UX was that it had to happen for both a Rails and a Merb application. Neither uses the same paradigm when it comes to layout so the approach had to be adapted to each and yet made general enough to not incur (even more than was already present) tech debt.

I served as Tech Lead and architected a solution, led other junior engineers in implementation, and managed interactions and expectation with Product and Design.

Following is a general impression of where we began and where we wound up

Results

  • Led engineering efforts around a complete UX overhaul of the company’s most important customer interaction.