The Complexity of Simplify
Warning: this post may make your head hurt. Read on if you'd like a look behind the curtain at what it takes to keep Simplify working for everyone and why a one-time fee wouldn't keep the lights on.
Moving Simplify to a paid product is going well so far. It looks like about 5% of customers will sign up for a paid plan, which is pretty good conversion from a free product.
I’ve tried to keep the price as low as possible to maximize the affordability of Simplify. Keep in mind that fees and taxes eat up nearly half of a monthly payment and over a third of an annual payment.
But some still believe I am price gouging.
I’ve tried to explain why a paid plan and not a one-time fee is the right pricing model for Simplify but I’ve always glossed over the details afraid to bore you to death. This post is going to dive into those details.
Simplify is much more than “Just an extension that makes Gmail look prettier”
Setting aside that Simplify does a lot more than “make Gmail look prettier,” I have sympathy for those who ask why a paid plan is needed instead of a one-time fee.
Simplify is “just” a browser extension, right? How much ongoing work could it really need?
And Gmail seems like a simple product with only a few views (list view, message view, compose, and settings) and some app chrome & functionality (action bar, navigation, search, chat, add-ons, menus, banners, alerts, and overlays).
The challenges are (1) Gmail is always changing and (2) these views and areas of Gmail are different depending on your Gmail settings and other variables. Sometimes the differences are visible to the user and sometimes they are invisible differences in the code that Simplify builds on.
Over 100,000 unique Gmail setups...
Each of the Gmail settings and user setups below acts as a multiplier on the number of unique Gmail setups that Simplify needs to support:
Inbox types: 5x (default inbox w/ tabs, default inbox without tabs, multiple inbox vertical, multiple inbox horizontal, and priority inbox)
Theme types: 5x (default theme, dark theme, high contrast theme, and color/image themes with either a dark or light interface)
Reading pane options: 4x (Vertical split, Horizontal split, No split, and Disabled)
Nav open/closed: 2x
Add-ons open/closed: 2x
Right side chat on/off: 2x
Quick settings open/closed: 2x
Text buttons vs icon buttons: 2x
Chat mode: 3x (Hangouts, Google Chat, or disabled)
Screen resolution ranges: 4x (< 1200px wide, 1200-1440px, 1440-1600px, and >1600px); Not included are (a) screen height (impacts things like the width of compose moles) and (b) the browser zoom level, which can cause numerous issues as well.
Browsers: 3x (Firefox, Safari, and all Chrome-based browsers)
This adds up to 115,200 unique setups!! But that’s not all. Not even close.
Ok, so actually, BILLIONS of unique Gmail setups...
There are other settings, setups, and ways to change how Gmail looks and works, bringing the number of unique setups into the billions.
Workspace Accounts differ in design and functionality from @gmail consumer accounts. For instance, currently, Rooms is a feature only available to Workspace and it changes how the Nav is coded. Workspace Accounts have a company logo next to the profile image and warnings about emailing people outside your domain. The upcoming design update is also rolling out to some Workspace accounts first.
Other extensions and add-ons can dramatically change Gmail in many ways (Simplify plays nicely with and sometimes even improves over 30 other Gmail extensions and add-ons)
Simplify itself adds over 40 options. I resisted adding any options for a long time but eventually decided it was unavoidable.
Language can change things too. And there are actually two ways to set the language: (1) the OS language setting and (2) Gmail's own language setting which supports 73 languages. These have implications for things like date grouping, fonts, availability of certain features and options like right-to-left language toggle in compose, how much space is needed for various elements, and more).
Compose can be an inline reply, compose mole (mini window in the bottom right corner), full screen, or popped out into a separate browser tab. And messages can be inline, popped out, or shown in a print view. The code around these elements change in each mode.
Enabling offline adds buttons and changes how some things work.
Browser alternatives like Shift, Mailplane, and Flotato work differently as they don't truly support extensions, and instead just inject Simplify's code into Gmail manually. They also sometimes run on older versions of the browser which has made for some very interesting bugs. And Gmail installed as a PWA (Progressive Web App) changes a number of things with theming.
And then there are delegate accounts, vacation auto-responders, email signatures, attachment previews, and on and on...
Exhausted just by reading this list?
I feel you. Imagine what it’s like to support all these permutations. Taking into account just the items listed, our 115,200 unique setups easily jumps into the billions.
But wait, there’s more. On top of all that, there is the fact that email is inherently a container for other people's code (rich HTML emails). Anything Simplify does to messages or compose (maximum width, dark mode, font settings, etc) has to be careful not to break the messages themselves. I’ve even built fixes for several obscure Gmail bugs around rich HTML emails.
So, how do you support billions of unique setups?
Disclaimer: Feel free to skip this section as this gets technical.
Here is the current state of the evolving system I’ve built up over the last 2.5 years to support all combinations of Gmail settings and user setups.
For starters, you build something and see where it breaks over time. The first version of Simplify launched in April 2019. It was based on an extension I had built and maintained over the years for just me and a few friends. The rest of 2019 was scaling up to support the many features and options I didn’t support at launch as well as keeping up with Gmail’s ever-changing code base.
Then in May 2020, I took all I had learned and started rebuilding Simplify from scratch, to force myself to retest everything and look for better ways to detect, understand, and modify Gmail. This took ~9 months and launched in February 2021.
I’ve mapped over 650 obscure CSS selectors to elements along with where they sit in the DOM (Gmail’s code) and how they work. For example, .G6 is the container for the search filter chips while .g6 (lowercase “g”) is the container for a message snippet in message view. The search chips (.G6) are directly under the list container (.BltHke) when Reading Pane is off, but are inside the the action bar container (.G-atb) when Reading Pane is on. There are hundreds if not thousands of these tiny differences. Simplify currently has over 7,000 lines of CSS to consider all these things… but the challenge of figuring out all these things is hard to measure by number of lines of code. Sometimes, 100 lines only took a day. Other times, it takes a week to write a single line.
To make use of these mappings, I use SCSS which lets me use variables for CSS selectors. Currently I compile the SCSS into CSS before I ship each update to the extension, but I have been working towards a version where I ship the SCSS with the extension. Then, the extension downloads and caches the variables separately as a JSON file. Then the extension compiles and injects the CSS when you load Gmail. To do that, I ended up needing to write my own SCSS parser which I will eventually open source. This will let me change the CSS selectors safely, securely, and instantly without everyone waiting for an update to the extension when Gmail’s DOM or code changes.
But some selectors change too often and are not uniform across customers. For those, Simplify takes stable selectors and walks the DOM to add stable selectors to those elements. It took some time to figure out which selectors were stable and which ones change regularly.
Beyond the CSS, I’ve built out models for how Gmail functions so I can detect your setup as well as when things change. Some of these are easier than others. For instance, detecting that the theme changed was very difficult and requires I observe mutations to the css in a specific style tag. It took a long time to figure that out. Compose was also very challenging as contenteditable (the tech that Gmail uses) does many unexpected things. One example: hitting backspace at the start of a bullet to combine it with the previous bullet injects a bunch of inline styles on the merged bullet. There are over 8,000 lines of JavaScript right now but again, the number of lines of JS do not capture the complexity or challenge of the task.
From all of the above and my years working on Gmail, I've built up a spidey sense of what kinds of modifications might break different configurations. But I still miss things. To help catch issues before you see them, I always launch updates to the Canary version of Simplify first, which has ~400 lovely people who enjoy being the first to get updates and report issues when they see them. If all goes well, I launch to Firefox and 5% of Chrome users and wait a couple more days to see if anything comes up before launching the update to everyone.
Gmail’s always changing and we didn’t even cover everything
Another dimension to this whole puzzle is the fact that Gmail is continually changing. So even after I’ve figured something out, I often have to figure it out all over again months later by staring at the obfuscated code and reverse engineering how Gmail works now.
Building extensions for Gmail is so hard, in fact, that there is actually a 3rd party paid platform for building extensions for Gmail. I’m not aware of a platform like this for building extensions on any other product. A lot of extensions use this but it isn’t open source nor does it support the kind of modifications and enhancements Simplify makes.
And we didn’t even get into time spent on customer support or what it takes to do the many other things Simplify does like detect and customize inbox zero, support hiding the Inbox and disabling notifications, block over 250 email trackers, add Simplify’s many keyboard shortcuts, customize the interface font, and more.
It doesn’t matter how complex any of this is…
Beyond convincing you that I’m not some greedy jerk trying to take advantage of everyone, knowing how hard it is to build and maintain Simplify doesn’t really matter.
At the end of the day, either you get enough value from the product that makes it worth paying for or you don’t.
None of this post is to complain. I enjoy the complexity and challenge of Simplify. I just hope it helps explain how big a task building and maintaining Simplify is and why a one-time payment wouldn’t be sustainable.
The good news is, for each negative review complaining about the pricing, I’ve gotten several lovely emails from people saying how happy they are to pay, knowing it means Simplify will continue to be well supported and maintained. I really appreciate those emails and I’m excited to focus my efforts on building a product for these people and anyone else that find Simplify worth paying for. Onward!