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.
I was getting close to integration and that would eventually prove the most challenging (given pre-existing styling interactions and positioning.)
I incorporated my work into the main codebase and iterated on styling and interaction from there. Also, I created a CoffeeScript spec for covering the main features.
Here’s the final product
Results
Re-purposed an existing drag/drop example using jQuery Draggable in order to facilitate data management.
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.
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.
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.
To facilitate migration between Yahoo Groups and Kinsights group functionality for a key account, I created a Command Line Interface tool for a paginated approach to parsing and importing the member list in addition to parsing and importing the archived messages (for the last seven years.)
Many iterations were necessary and several heuristic methods were applied in order to ensure the cleanest import of the messages
Additionally, I created the activation flow for the transition, partially by piecing together signup components from the existing codebase, partially by crafting new logic in the business layer.
Results
Created CLI tool to ingest 1,000s of Yahoo Groups users given numerous different, undocumented email schemas.
This was an enormous effort to overhaul a product whose UX had not been altered much in five years.
We took a piece-by-piece approach to swapping out components because of the complexity of the legacy behemoth. First, we refreshed the views in the legacy app, which involved changing styling in three different places (because the app had grown “organically” over the years, taking on three different styling paradigms styling was defined in custom stylesheets, in Less, and inline.)
In parallel, part of the team started building out the new peer Rails 3 app, the eventual destination for all views, complete with the company’s brand-new proprietary SSO solution (also built in parallel.) Finally, routing was updated to send all traffic to the Rails app.
Forming
Between August and September of 2013, we coalesced as a team under the project champion, the company’s CTO, and began formulating what the new UX should be and do.
Below is a screenshot of an example of the dashboard as seen by the end user (Merb, built in 2008)
Below is a screenshot of the progress of a microtask job, also as seen by the user (sensitive information redacted)
Norming
Between September and October of 2013, we cranked out the new experience.
Based on a design concept by the other F2E in the team, we began restyling low-risk interfaces of the system. The new design was not simply a reskin, but involved introducing a similar-yet-improved information architecture, an example of which can be seen below
Following are a few more example screenshots demonstrating the evolving look-and-feel
Configuration Panel
As we were tackling the UX, a backend engineer in a peer team was working in parallel to create a custom role-based SSO system that we would leverage for enforcing authentication and authorization in a new way for the company.
Shortly before the conference, a decision was made to go with a second design concept, not entirely different from the original, but a little more polished. A designer was requisitioned to provide the new design. From that point forward to product launch, we mostly fine-tuned the details.
The following screenshot demonstrates not only the new design but also the use of the new SSO solution, which can be seen where certain UI elements are disabled based on the user’s permissions
To QA the new experience, we ran it in alpha against production data repositories just prior to the conference.
Performing
After the launch, we maintained the product, adding features we had not been able to squeeze in.
Below is an example screenshot of how the final product shaped up
Results
Consolidated multiple styling paradigms for new UX ahead of company-sponsored conference.
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.
