The Fastest Path to Ubiquity: Browser extensions

Chrome Extensions

Written by Tatyana Shestopalova, Technical Product Manager

When the 4Degrees team announced our $1M pre-seed funding round in May 2018, we outlined our approach to helping professionals build stronger relationships. One pillar of our approach is ubiquity in our customers’ existing workflows. In other words, we want the 4Degrees software to be present (and adding value) across all the tools our customers use to do their work.

Since then we’ve built a number of tools for our customers to access our software, including a web app, automated emails, a mobile app, and a browser extension for Chrome. While each of our products has pros and cons, the product that’s been most successful at achieving ubiquity is our browser extension.

What is a browser extension?

A browser extension is a software package that extends the capabilities of a web browser. Popular extensions that the 4Degrees team likes to use include LastPass, Pocket, and CloudApp. Thousands of extensions are available for download in the Chrome web store, and the 4Degrees extension is one of them. It’s worth noting that while several browsers have extension ecosystems, so far we’ve only built a Chrome extension since it’s the browser our customers use most often.

Extension pros

The ubiquity

Users have to open web and mobile apps. This might mean launching a native app on a mobile device, or opening a new browser tab and visiting https://app.4degrees.ai. Opening something might sound trivial, but this is a real barrier to adoption. It’s incredibly hard to change someone’s everyday habits, and requiring someone to open a tab for your site is an action they’re not already taking in their everyday workflows (unless your site is Gmail). Emails are easier to open since they go straight to the inbox (hopefully), but we’ve heard feedback from our customers that emails can get buried.

In my opinion, the biggest advantage that our browser extension has over web, mobile, and email is that it’s embedded into the sites our customers use most. For example, many of our customers use Gmail for business. The 4Degrees extension augments Gmail by adding a panel to the right-hand side of the page. When a customer opens an email, the sidebar populates with information about the person she’s emailing with, such as recent news mentions, past conversations, and any follow-up reminders our customer might have set for that contact.

The sidebar appears without the customer needing to do anything differently. While we’ve had to iterate a number of times to make our sidebar not feel annoying, the effort has been well worth the reward of becoming a permanent inbox tool. Extensions can augment literally any website, and it’s for this reason alone that I’m surprised I don’t see more startups developing their own browser extensions. For example, an online retail startup could build an extension that literally puts a giant overlay on Amazon.com that says, shop with us instead! I’m not saying this would be a good extension idea, but it’s absolutely possible (and reasonably easy) to build.

The technology

Chrome’s extension API is based on HTML, CSS, and JavaScript. This is a huge perk for our team since the skills needed to develop our emails and web app are directly transferable to working on the extension. Plus, since JavaScript can make XMLHTTPRequests, our extension can ping endpoints that live on the Python server that powers our web app. These endpoints often use methods that the web app also shares, eliminating the need to write code from scratch just because we’re working in a different product environment (cough, mobile).

Releases are *fast*

When I first started working on our extension, every time I needed to publish changes to the code base, I would have to wait one hour for the web store to review my new code. While that used to feel long, when I later started working on our iOS app I realized that an hour was nothing compared to how many days it takes Apple to review apps. Anyway, Chrome has since launched an update to its web store that approves app updates almost instantly. It’s pretty neat to not have to wait anymore. We push out updates as often as we need and Chrome handles distribution automatically.

Extension cons

The technology

Google’s documentation for how to build an extension kind of sucks. While it’s pretty common for developers to complain about poor API documentation and there aren’t that many technologies that have good documentation, I did find Google’s documentation mostly unhelpful. It doesn’t help that extension development (at least in my opinion) is generally confusing. At first, I really didn’t understand the difference between the browser and its tabs, where background pages live, and how to pass messages between a browser’s different levels (or why it was necessary to do so). There also aren’t that many people building extensions so the support community feels small. To put this in perspective, another startup with way more funding than we have and a much larger development team asked me to come into their office to lead an info session on how to build extensions. Climbing this learning curve is not easy.

You have no control

If your browser extension alters a website you didn’t build, like Gmail, you’ll constantly be on the lookout for changes to the underlying website. Thanks to a lucky coincidence, our extension development coincided with Google releasing “new Gmail.” This meant that right from the start, we had to support two versions of Gmail (with entirely different page structures), and both versions would change overnight all the time. I still get a headache thinking about how often I’d write JavaScript that started with document.getElementByID(…) and the ID would literally change the next day. Since Gmail doesn’t give us any heads up when they update their site (wouldn’t that be nice), we’ve always been in the position of having to react to changes after they’d already happened. We would also usually hear about these changes when our customers would report that our extension was broken, so that’s been nice.

You have to play nice in the sandbox

Particularly for popular websites, such as Gmail, plenty of extensions will try to augment the same real estate. If you decide to build an extension, you’ll have to play nice in the sandbox with the other guys. If your extension is newer, hasn’t been around as long, and your users aren’t yet as reliant on your extension as they are on some others, your users will uninstall your extension if they notice it breaks their other extensions. This is true even if you know other extensions aren’t playing nicely in the sandbox themselves. While other extensions might not even be business competitors, you’re still competing for the page space. Hence, it’s paramount (and also very difficult) to fit nicely onto a page. For us, this has meant that I’ve had to build listeners for various Chrome extensions and do things like hide or unhide certain page elements when our customers have certain other extensions enabled. We also have no advance notice when other extensions update, exacerbating the problem of having to react to changes after they’ve already happened.

Summary

There’s no doubt in my mind that all the headaches I’ve personally dealt with not only being the product manager for our Chrome extension but also having written the majority of our extension’s codebase have been absolutely worth it. I can’t understate the benefits of having our 4Degrees software present at the forefront of our user’s workflow without them having to do their work any differently. 10/10 would build again.

If you’d like to try out the 4Degrees Chrome extension that’s mentioned in this article, you download it for free from the Chrome Web Store.

Related Content

Share this post:

Subscribe to the 4D Newsletter: