Category: Frontend

Categories
3D Architecture Distributed Teams eCommerce Frontend Innovation Management Performance Engineering VR

New VR UX For Nurseries

(3/19-10/20)

Challenge

Ship new, web-based, VR-powered, eCom experience as requirements changed.

Action

Act 1 : 3/19-5/19

While on my trip to India in April 2019, I formed a Tiger team of one of my best Lead Engineers, a project manager, and two junior engineers, coaching them to see the similarity between what was the business was asking for and current existing components of the system (PLP, PDP, NUX, and Checkout,) setting a plan in motion towards delivering an MVP for the 6/26/19 deadline.

They went heads-down and we successfully shipped v1 (following) on 5/29/20.

ecom landing page

Business priorities shifted and the project was moth-balled, leading to Act 2.

Act 2 : 8/19-10/19

Having shifted focus to more product-based eCom (see Act 1,) the business decided to leverage existing shop-the-room modeling infrastructure in a more user-friendly, web-based purchase flow.

While the original plan was to have them spin up a completely new POC with a new checkout flow, I intervened and met with the remote Technical Project Manager and Architect, providing guidance around the existing monolith marketplace system, knowing it could serve as enough of a “buy” to meet requirements so as not to have to “build” a custom solution.

Shipped v1 in Oct 2019:

Landing Page

Room Detail Page

I saved $40K in redo work after guiding the non-primary, remote, web team around component re-use while then shipping web-based, VR-powered shop-the-room.

Act 3 : 3/20-10/20

Under tight deadline, coached the Pakistani team to iterate and improve perceived and actual load times using CSS Sprites, caching via HTTP headers, use of a spinner, and gzipping in order to get a usable UI to market sooner:

Landing Page

Drilling down, a user looking to design a nursery can swap out items (made possible by a compositing technique with Three.js and photo spheres)

Room Page

Lastly, recognizing future strategic value-add within corporate partnerships, guided the team to decouple the frontend as a Single Page App for iframe embedding after having decreased page load times, introduced progressive enhancement / graceful degradation, and led the SPA strategy.

Results

New VR-powered site finally launched in Feb 2021.

Categories
3D eCommerce Process

Product Catalog ftw

Challenge

To scale v2 of our shop-the-room experience, the business turned to me to understand how our process would grow cost-wise.

Action

The interim CEO asked me to determine costs as we considered beefing up our rendering pipeline by orders of magnitude.

Applying a KISS paradigm, I threw together an inital back-of-napkin estimate. That was good enough, but then the interim CEO needed a deeper level of understanding, so I worked with my Pakistani Technical Project Manager to build out a more comprehensive version of the model, taking parameters into account like the following:

  • Scale Factor
  • Model Throughput Per Week
  • Aspirational Efficiency Factor
  • Cost Per Model
  • Number of Modelers Needed
  • Model Category

Result

Delivered cost model iteratively for a 3D modeling pipeline to support shop-the-room.

Categories
Backend eCommerce Frontend Performance Engineering Process

What To Do With a 9s Page Load?

(Decorist : 9/18-12/19)

Challenge

Inherited a two-fold challenge: 1) less-than-optimal user experience of 9.01s Avg. Page Load Speed and 2) a culture that did not yet value performance engineering.

Action

Idenfitied initial frontend and backend low-hanging fruit (e.g. page structure, image resolutions, N+1 queries, lazy-loading, etc.) Identifed and delegated KRs to FE leads. Introduced process to methodically follow up each week, pressing the case for performance engineering over months.

Below, a sampling …

Some initial efforts shaved ~3s of the Homepage:

Lighthouse score soared from 5 to 61:

There were multiple speed improvements of up to 50% on various pages across the site as a result of backend query improvements and a +300% bump YoY in SEO traffic (verified by 3rd party SEO consultant)

After Dec 2019, we shifted focus to non-converted UXes after having addressed low-hanging fruit for all UXes.
Sept 2018 to Dec 2019

Results

  • Record Avg. Site Page Load Speed of prevous four years : 9.03s (Sep 2018) to 4.13s (Dec 2019.)
Categories
3D Collaboration Process Troubleshooting VR

Salvaged PR Opportunity

(Decorist : 3/19-3/19)

Challenge

Marketing opportunity showcasing company’s proprietary shop-the-room modeling was four months behind and at-risk after key in-house designer departed and PR client was losing patience.

Action

I took ownership of project management, working with new designer and remote Pakistani VR engineering team, introducing a lightweight process (spreadsheet-based and daily 15m check-ins) in order to get backlog of shop-the-room models modeled and bundled into our VR (Unity-based) design app.

Results

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
Building buy-in Distributed Teams Frontend Optimization Performance Engineering

Making an Operations Excellence Frontend Excellent

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

For the client, I probed their UX using multiple tools to determine low-hanging fruit, worked with the CTO and VP PROD to understand resourcing constraints given the product roadmap, and enumerate several tactics in a (prioritized) phased approach towards improving performance.

Heuristic discoveries included FE perf bottlenecks such as:

  • multiple inline JS snippets causing slowdowns
  • un-optimized JS libs, including of React components
  • multiple 3rd party JS libs that were no longer necessary
  • JS libs that loaded neither async nor defer
  • retrieval of multiple styling resources

I found that the greatest opportunity to optimize existed for two key user experiences at ~6s avg page load and ~4.5s average page load respectively.

During one iteration, changes lead to a 52% reduction in the Webpack bundle of React components, improving page speed by 10% or better across four key user experiences.

During another iteration, one key UX was sped up by 39.4% without Cache, 53.8% with Cache.

During a final iteration, changes lead to a 20% page speed improvement on one key user experience and 10% or better on two others.

Results

  • Introduced Performance Engineering mindset leading to 20% page-load speedup.
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
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
Building buy-in Frontend Optimization Process

Shifting Mindset

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

Prior to Q2 2016, the team had supported Product’s goals for delivering feature-value without ever considering engineering goals (better code quality/maintainability, page performance, workflow improvement, etc.) I took initiative to flesh out high-level deliverables for the quarter.

Below is an example of a set of performance metrics around the most-highly-trafficked page on the platform.

Though we didn’t meet this particular goal for the quarter – mostly because of a move to Webpack from RequireJS in late-April and then the introduction of React on the page in mid-May – the simple fact that the data was being tracked represented a major paradigm shift towards that of being a data-driven team, whether around page performance OR engineering deliverables.

Results

  • Introduced quarterly, data-driven, engineering KPIs.