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
Affiliate Growth Innovation Troubleshooting

Business Model Shift

(3/20-9/20)

Challenge

Given a steady stream of revenue, fundamentally alter the underlying business model towards CPC/CPA.

Action

Phase 1

In March 2020 pre-COVID, did a quick dive on Skimlinks documentation and put together a quick explanation/overview to demonstrate how easy it would be to include. Business climate wasn’t right so didn’t pursue.

Phase 2

Sep 2020, post-CEO-stepping-down and several months after Phase 1, explored use of Viglink (Sovrn) only to discover that business had previously been CPA-based before fulfillment was brought in-house ~2017.

Digging around, found some old Skimlinks code, then leveraged updated documentation to prove click-tracking with custom params could still work.

Phase 3

The business, being unsure whether to use one or several affiliate networks, needed partnership to figure out the best implementation path forward. For four networks, I kludge’d scripts into production and verified clicks, evaluating custom parameters as they’d flow through the lifecycle and eventually be reported through APIs.

When the business decided to focus on Commission Junction and Skimlinks, I led development to integrate JS libs (monkey-patching CJ to play-well on the same page as Skimlinks) and verify clicks / custom params.

Result

Overcame fits-and-starts to deliver affiliate model.


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
crm documenting eCommerce Innovation Leadership supply-side

Increased Leads

(The RealReal : 11/16-9/17)

Late Q3/2016

Upon joining, I inherited a lead-gen project that had gone deeply awry. Earlier in the year (March,) Product and Design had come up with an alternative lead-gen flow. An offshore company was procured to follow-through with implementation. The consultancy tackled the project but their implementation sat on a feature branch gathering dust (six months!) and lacking documentation until I arrived.

In order to get the feature into production, I tasked a Senior Engineer with soup-to-nuts verifying the feature branch. When he failed, I marshalled other engineers (at yet another near-shore company) to do the verification. They succeeded and we were able to roll out the new user experience, meeting a company objective to have it in production by the end of the year.

Mid-Summer 2017

Another executive decision was made to revisit the (same) flow and try yet another alternative, this time, in the new Phoenix environment. I spent time running point to assess the basics of the necessary (information) architecture in the new framework and then forumulating a project plan to implement. In October, the new user experience went live.

Results

  • Championed way-over-schedule experimental lead-gen flow into production, improving quantity/quality of sales leads.
Categories
Collaboration Innovation Management

Collaboration @ TRR

(The RealReal : 9/16-5/17)

Facilitated smooth cross-team (PROD, DSGN, Platform, Mobile, Web) interactions towards scoping and delegating engineering work for:

  • Black Friday/Cyber Monday
  • modifications to supply-side NUX towards increased signups
    • first in altering/improving the basic flow
    • then while incorporating different verticals (Art Home)
  • conversion of non-responsive UIs to responsive
  • shipping/up-sell through Narvar
  • payment processing through Hyperwallet
  • analytics reporting shift from Snowplow to Segment
  • Google Tag Manager modifications/optimizations
  • cross-browser test coverage of business critical paths through Rainforest QA
  • shoppability/conversion usability improvements (e.g. faceted navigation filters)

Results

  • Built rapport with business partners (Product Managers, Designers, Marketing) and direct reports to get work done.
Categories
Innovation Leadership Process Prototyping SOA supply-side

Phoenix Homepage POC

(The RealReal : 2/17-3/17)

Early in 2017, a Tiger Team formed of me, a Lead ENGR, the CTO, the VP PROD, and a PM.

The CTO and VP PROD had an idea to empower Merchandising and Marketing to further drive content/conversions from the Homepage. While they previously had some power to manage that content through an admin interface with a limited schema, the idea was to give them even more creative expression, allowing them free-reign over their HTML.

A few weeks into the project, the Lead ENGR, who had been tasked with building out the intial POC, left (leaving us in a lurch.) Under pressure, I still delivered basic CMS functionality via Rails and demo’d same to the C-suite.

Shortly thereafter, when requirements radically changed and the mandate from the CTO was suddenly to move towards a WYSIWIG experience through a 3rd party Content-as-a-Service provider as rendered via Phoenix, while moving away from a lazy-load landing page to a 3×3 grid, I built out a simple placeholder homepage in Elixir and then evaluated and prototyped against several CaaS vendors (e.g. Prismic, Kentico Cloud, Contentful.)

When the CTO settled upon Prismic for us to move forward with, I conceived the project plan for engineers to carry the effort forward while also developing the initial migration plan for porting route-by-route from Rails to Phoenix.

Results

  • Built MVP of company’s Rails-to-Phoenix migration.
Categories
eCommerce Innovation supply-side

Hackathon : Browser Extension

(The RealReal : 2/17-2/17)

Results

  • Won “Best Hack” while pairing w/DIR Design to create Chrome Browser Extension (similar to Honey) to cross-sell inventory on related retailers.
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 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.