League TL;DR

League is a digital health platform whose value proposition lies in an excellent user-experience with robust platform extensibility. League sells it’s platform to other insurance companies or health care providers to use as their client facing user-experience. As a platform, League is super modular, and includes an activity library with dynamic and interactive content, real-time nurse support, personalized care plans, and an insurance/claims/benefits management system with a bit of gamification to tie it all together.

Health Journey

League is a digital health platform that, in my opinion, centralizes the all the health-benefits and resources that an organization provides to their staff and makes it easy to consume. As a platform, League makes the administration of these health benefits and resources easier for its clients, while presenting it all in a way the makes it easy to consume and interact with.

At the heart of League’s platform, is Health Journey. This is the fun part of the app; the part that gets people to come back, and the part that reminds them to use their benefits. It encourages behaviour that ultimately leads to healthier, and more health-conscious people. This is the team that I work on.

From a user’s perspective, we can distill Health Journey down to:

Activities are grouped in to topical Campaigns, such as smoking cessation, sex-education, or active living. Activities have a broad range of functionality. They can collect biometric information via wearables, handle app-onboarding, and manage forms, or quizzes too.

An Activity might reward a user with points for making their blood cholesterol marginally better, or for filling out an onboarding form, or completing a quiz on fibre. You get the idea, I'm sure.

Points are an in-app currency that can be exchanged for real money added to a Lifestyle Spending Account (LSA), or spent in League’s in-app marketplace.

User Flow

A few things I've done:

My tenure of 3+ years at League have been centred around the Health Journey web experience.

In addition to my normal (Senior Software Engineer II) roles & responsibilities here's a few of my contributions that I'm particularly proud of of:

1. Architected a web SDK for composing dynamic content using League's component Library and CMS system to bridge the gap between Content Authors, Product Managers, and Engineers.
2. Helped to lead efforts to refactor League's in-house application into a series of client-facing SDK's and micro frontends.
3. Rebuilt the entire Health Journey web experience twice from scratch
4. Built a business-case for the adoption of TypeScript, which was implemented in 2022, or something like that.
5. Contributor to League's guidelines for web code-style and conventions.
6. Tech-Lead for 4 successfully launched projects

What is it?

Marjoram is a tiny, 0-dependency library to build stateful user-interfaces with on web. I wanted it to be the alternative I wish I had when React wasn't an option.

In that vein there are 4 facets of Marjoram that make it a good fit for when your library of choice isn't an option:

1. Tiny bundle-size
2. 0-dependencies
3. TypesScript support
4. Does everything at runtime

Marjoram is intended to make building web interfaces both easier and more intuitive using JavaScript when compared to the native spec, without bloating your codebase with additional dependencies or tooling requirements.

1import { html, useViewModel } from 'marjoram'
2
3const viewModel = useViewModel({ firstName: 'Patrick', lastName: 'Stewart' })
4
5const view = html`<h1>Hello, ${viewModel.$firstName} ${viewModel.$lastName}!</h1>`
6// h1 text: Hello, Patrick Stewart!
7
8viewModel.lastName = "Star"
9// h1 text: Hello, Patrick Star!
10

What's cool about it?

Rendering

Marjoram won't rerender child components (in most cases). This is because it's approach to state-management relies on changing the text/attribute node directly.

Because of this, I suspect the most performant patterns and practices will quite different to those found in other libraries like React.

Proxies! ViewModels! State!

Updating state updates the DOM Node directly. Children won't re-render _{(necessarily)}

Building user-interfaces with native Javascript alone is a pretty miserable experience. There are no enforced patterns to follow, so logic to manage the application's "state" gets all spaghettied with the logic to manage the UI.

Marjoram provides structure, allowing developers to easily separate the logic that manages and binds the data to the UI from the logic that creates the UI itself. Like a ViewModel!

State is achieved using JavaScript proxy objects to act as the liaison between the data-object and UI such that when the data is altered, the proxy object is able to reconcile the all of the referenced DOMnodes "getting" that value in order to update them. That includes "computed" or derived values!

HTML-like Syntax

Marjoram uses JavaScript `templateLiterals` to convert your HTML-like code in to an actual DOM node that you can interact with.

By prefixing your viewModel properties within your view with a $ you now have a stateful property!

Similarly you can referance any node by adding a ref attribute, that you can .collect() from your view later.

1import { html, useViewModel } from 'marjoram'
2
3const viewModel = useViewModel({ cta: 'Continue' })
4
5const view = html`<button ref="ctaButton">${viewModel.cta}</h1>`
6
7const {ctaButton} = view.collect()
8ctaButton.addEventListener(() => {
9  viewModel.cta = "Done"
10})
11

Example

365 Integrated is a marketing and brand strategy consultancy that works with leading brands across the United States and Canada to help define and align their brand identity with their business objectives.

The Project

A fundamental aspect of 365’s business is defining brand’s identity and finding ways to express it through it’s marketing material. The Toronto-based designer Janelle Lamothe had just redesigned the 365 visual brand identity, and we worked with one another to build a new website does exactly this.

It needed to be fully custom and was on a very tight budget, with a 3-month delivery date.

Technical Requirements

• Minimal maintenance
• Built for SEO
• Dynamic page content and layout through a CMS
• Can handle forms

Solution

Given the technical requirements, and having gone through the design review process, it was fairly clear that this website would be well suited as a Jamstack application.

The designs included a blog and contact form per the client's design requirements, with interchangeable sections and components. It also featured a well defined theming system with fully custom animations throughout.

By building a Jamstack application comprised of Gatsby, Contentful, and Netlify, I was able to meet all the technical requirements both in-budget and on time.

A static site was a natural choice. They're great for SEO and make it easy to maintain a blog. Because they are inherently stable when deployed, the site has only required maintenance once in 3+ years.

The integration of Contentful allowed for a robust and fully dynamic component module system and has allowed for the site to change over time. It went from being single-page to multi-page, with whole sections being changed or added.

The use of Netlify allowed us to handle forms, manage deployments with webhooks, and QA the site in a safe non-production environment without stretching the client's budget at all.