How Streamline focuses on what matters
My name is Fyodor and I’m the tech lead in Streamline. I have good news and bad. Today I announce that we’re deprecating the Streamline NPM package and Sketch plugin. Instead, we’ll focus on the web app and Figma plugin, which are used by a noticeable share of our customers. I’ll explain why in this article; it’s a story about over-engineering and sunk cost fallacy.
We understand that you might feel frustrated about the removal of NPM package and Sketch plugin. We admit that it sucks. Migrating from one tool to another isn’t how we wanted your experience with Streamline to be. We care about you and want to make Streamline’s web app as easy to use for you as possible. Please take 2 minutes to share feedback so that we can provide a better experience for you.
In the past, we at Streamline were too naive and ambitious. We have tried to support as many platforms as possible: Sketch, Figma, NPM, VS Code, and others. What’s more, we planned to work on creating integrations for software like Powerpoint, Adobe XD, Word. At the same time, we maintained and released features for our flagship product — the web app.
Even though Streamline provides one of the largest and highest quality icons and illustrations packs in the world it’s being operated by a small team. That’s why we must ensure we don’t lose our focus. We need to stop supporting platforms that didn’t prove useful enough for our customers and which cause the largest amount of issues.
NPM package and Sketch deprecation plan
- We’re sunsetting the Sketch plugin on 1st November 2021.
- Old private NPM packages are going to be deleted on 1st November 2021. We have deprecated them since March and announced back then that we’re deleting them in summer 2021 so there was plenty of extra time.
- The current open-source NPM package will receive minimal support until 1st November 2022, after that it will be deleted.
What should I do as a Streamline user?
Use our feature-rich web application.
If you use the Streamline Sketch plugin
- Visit our web app and from now on copy the images from it.
If you use the Streamline NPM package
We know that this is inconvenient to do and it involves some manual work. We’re truly sorry that this is required and we wish there was a better way.
- Uninstall the Streamline NPM package from your project(s)
- Find each icon/illustration which was added to your project(s) from the Streamline NPM package. You can search for imports with `@streamlinehq/streamlinehq`.
- Find each imported image in our web app. First, go to a family page of the image you’ve imported and then search for its name there. Eg for `@streamlinehq/streamlinehq/img/streamline-mini-bold/interface-essential/user/interface-user-circle.svg` go to https://app.streamlinehq.com/icons/streamline-mini-bold page and search for `Interface User Circle`.
- Select SVG as the format, download it and import it as a plain image file in your project(s). If your build system supports it, I’d recommend importing it as a component so that you can easily change colors, size, etc.
How did we end up with this?
History of Streamline NPM package
Streamline NPM package has a long history of rewrites, poorly planned architecture, and faulty execution. The root cause of all issues is the package is both:
- Not necessary
- Too complex.
Streamline NPM package has been started a long time ago as the means to ease the life of our users who are developers. The initial architecture of the NPM packages system consisted of:
- The so-called images packages: a private NPM package per a Streamline family.
- The so-called wrappers: private NPM packages for React, Angular, and Vue frameworks which accepted images from the images packages and rendered them.
The packages were hosted on a paid 3rd party service so that only Streamline users with an active license did get access to them.
This architecture had the following major issues:
- Each time a Streamline images family was updated we had to update the corresponding NPM package. That meant that we had to either do it manually (which was practically impossible, considering the number of Streamline images and the frequency of their updates) either we had to create a sophisticated system of automatic updates for our packages.
- We had to support 3 different wrapper packages and different framework versions (Vue, I’m looking at you).
- We had to write and maintain custom logic in order to synchronize the licenses between Streamline and the NPM package hosting platform.
- Images in these packages were served not in the standard SVG but in a house-built custom format, which dramatically increased the difficulty of maintenance. That’s why wrappers were required.
All these difficulties have been a constant source of headaches. Developers and customer support at Streamline had to distract themselves from solving NPM packages issues instead of working on the web app.
The hilarious thing is that users could just download an image from the web app and import it as any other image in their code. Therefore, the NPM package didn’t really solve any issues for the majority of our users.
We thought: what can we do in order to get rid of these problems?
If we had the same question today, the answer should’ve been:
- Accept that the NPM package doesn’t solve any major use case and is over-engineered
- Count the customers who use the Streamline NPM package
- If the number is not large (it’s not), slowly deprecate the packages
- Focus more on the parts of Streamline which are used by the majority.
However, we’ve been too optimistic and overly confident. We decided to revamp the NPM packages.
The new architecture consisted of a single open-source NPM package which during installation fetched the required images and made them accessible as SVG files. Users could specify the needed images families via a custom configuration file or with standard environment variables. The images would be provided in plain SVG format so there would be no need for any wrappers.
This architecture seemed to be reasonable. It has reduced the complexity and decreased the amount of maintenance required. No longer there was the need to update NPM packages when our images got updated.
We felt very optimistic about the launch. However, after the release the following major issues swiftly became apparent:
- Since the new NPM package fetched images from Streamline, it relied on our backend stability. Whenever our server was down, users with the NPM package would not have been able to build their projects. That sucked.
- Making any changes to images’ slugs that are used in import paths or moving images between subcategories was no longer possible in Streamline since these changes would have caused NPM package users’ builds to break. As a consequence, our images structure became immutable, which sucks.
- Requesting all images for several families at once put noticeable pressure on our server. This, however, has been more or less solved with cache, but still would have posed a real threat to our performance in the future.
Imagine that your build would break because out of the blue something went wrong on Streamline server of and because of that you could not deploy your website anymore. If I were a customer I’d be pissed off.
None of the issues listed above were straightforward to fix. Solving them would have required major changes to our images structure and god knows which bugs could have waited for us ahead.
We’ve spent months trying to solve problems with the NPM package but we have never had any major breakthroughs. We have always felt that the final fix is right around the corner, but, alas, it never happened. We’ve fallen to a sunk cost fallacy.
Considering all these complications, we decided to get rid of the NPM package. The moving factor here, of course, was the fact that our customers could just copy images directly from the web app and the feature wasn’t crucial to their experience.
Key lesson: don’t work on “cool-to-have” features. Instead, focus on improving the core of your product.
History of Sketch plugin
We’ve added the Sketch plugin a long time ago because we believed that many of our users will benefit from it.
The issue with the Sketch plugin is that it relies on our backend in order to serve the Streamline images. Therefore, we had to keep supporting the old backend for the sake of this plugin, which increased the difficulty of maintenance.
What’s more, in the last years the UX tools trends have changed. Nowadays Sketch is swiftly losing in popularity.
We had a feeling that not many people use Sketch but we hesitated to count the numbers. When we finally did we realized that a mere 0.03% of requests we receive to our backend come from Sketch. That was the final nail in the coffin of our plugin. Even though we care about our Sketch plugin users it’s unfortunately not realistic for us to support every platform.
What is the good news?
Deprecating these platforms means that we can focus on the tools which our customers actually need — the web app and the Figma plugin.
This is great because you, a Streamline customer, will get more cool stuff faster.
Our web app is a solid alternative to the NPM package and Sketch plugin. Did you know that it got 500% more performant than a year ago?
What’s more, in the last months we’ve added several awesome features to it:
- Global colors change
- Multi-download
- More free sets
And we have more in plans, such as global search, favorites, collections and the new Figma plugin. Exciting times are ahead for Streamline! ✨
Thank you for reading. Hopefully, this honest article about over-engineering was both entertaining and helpful for you. As a reminder, please share your feedback with us.
If you have any feedback or questions about the decisions we have made please contact us directly via support@webalys.com or via Intercom in our website.
See you in Streamline!
