A long time ago—before Gmail ditched the red envelope logo, before Periscope and Vine were acquired and shuddered by Twitter, well before the bluebird app gained its edit button—was the first era of modern web design.
I’m not talking about the garage offices of Google, Amazon, or any of that Silicon Valley lore. The earliest of early days were about uncertain bets; the web was still going from nothing to something. But after the web started to take shape similar to its current form, we started to see real, repeatable trends in software design.
In particular, one trend that has shape-shifted throughout history was that of third-party embedded apps, often called widgets.
The Three Waves of Software Design
A Necessary Caveat
At any point in modern web history, there were products on both ends of this spectrum: those that heavily used third-party widgets and those that shunned them. However, third-party widgets have shifted (and shifted back) in popularity over the years. This piece explains why those trends happened.
The First Wave—the Era of the Widget
As the web started to hit mass adoption, a laundry list of expected features grew. Any news site—even a blog—was expected to have a commenting feature. Also an RSS feature. And social media like and share buttons.
For other apps, social sign-on became commonplace. So did internal pop-ups. And sign-up boxes to subscribe to newsletters and such.
Building these features typically wasn’t too hard, but they added to ever-growing engineering dockets. So, engineers leveraged widgets—little plug-and-play interfaces that took care of table-stakes features.
A good example is Disqus, a commenting suite with support for upvotes, replies, and replies to replies. Before long, nearly every blog or publication had a Disqus box.
Widgets delivered reliable functionality with a templated form factor. What more could you want?
The Second Wave—the Era of In-House
Again, what more could you want? Well … brand.
At some point, around the early 2010s, we experienced a shift to in-housing everything surrounding app development. Suddenly, widgets were cheap. Widgets were tacky. They were associated with hacky Google Sites and Tumblr blogs that were sharply going out of style.
Professional websites couldn’t afford to appear pre-manufactured anymore. Or less vainly, professional websites couldn’t afford to have limited, non-extensible widgets anymore. Engineering and design teams wanted to craft an end-to-end experience form-fitted for the website’s users’ needs. Anything else was inexcusable.
This wave saw an explosion of libraries and packages. Engineering teams still wanted to extend pre-written code but with npm instead. Instead of using a widget for a color-picker, apps utilized an open-source, configurable React package.
But was the widget dead? Not exactly. Instead, widgets needed to innovate, and once they did, we saw the emergence of the third wave of modern web design.
The Third Wave—The Embedded App
Today, widgets are everywhere. They just look and feel different.
Netlify, Gusto, Yotpo, and Freshworks have wonderbars (action-packed searchbars similar to Superhuman’s), all powered by CommandBar.
Gitbook, Pitch, and Stacksi have their notifications panel powered by Magicbell.
Pfizer, Toast, AMD, and Outreach have authentication panels by Auth0.
Saleshood, Rho, and Copy.ai’s integration authentication and configuration panels are powered by Paragon. Heck, we’re no strangers to this phenomenon at Explo—Lunchbox, Plivo, Juniper, and Worksmith have analytics dashboards rendered by our embedded app.
The list goes on and on and on. Suddenly, incredible companies shipping beautiful products are using plug-and-play interfaces again. Suddenly, widgets are cool again.
Fairly, one might contest if these products are actually widgets. After all, most allow custom code, custom CSS styles, and other inputs by engineers. But, at the end of the day, these products are typically managed by someone in product departments, not engineering; likewise, they involve more no-code styling and management than code-heavy configurations. At the same time, given they are significantly more involved than a bunch of pre-configured social media engagement buttons, calling them embedded apps instead of widgets is probably in good taste.
So why the return? This clearly isn’t a fad; these are all paid products, purchased after due diligence by product teams. So why the sudden reversion?
Five core reasons.
Core Reasons for why Embedded Apps are popular
The reasons why embedded apps are growing in popularity can be split into two categories: qualifiers and newer priorities. Qualifiers are things that made widgets unsavory in the past but have been alleviated via modern product design. Newer priorities are the broad, changing opinions on how products should be launched and maintained.
Reason #1: Qualifier—Personalization and Customizability
Widgets weren’t always so personalizable and customizable. Embedded apps nowadays are.
Personalization and customizability are different things cut from the same cloth. For designers—without personalization—embedded apps might break design conventions around a brand’s fonts, padding, colors, or even letter spacing. For developers—without customizability—embedded apps might not be ultimately suitable should a product eventually need a more bespoke implementation of a feature.
Nowadays, embedded apps excel in both of these categories.
For instance, for CommandBar, the magic searchbars are extraordinarily personalizable—you can alter the fonts, the format, the colors, etc. Arguably, they are so personalizable that one wouldn’t realize that they’re maintained by the same third-party application.
Meanwhile, Paragon, a tool engineered to make integration management easier, has varying levels of customizability. Paragon provides the widget to authenticate and map permissions to a third-party app, but it also offers a headless version should a development team want to fully control the interface in the future.
Explo is no stranger to these categories, either. From the early days, Explo had to make dashboards personalizable to a customer’s brand. And, if a customer wants to include a custom graph design unique to a product, Explo supports users mounting a component within a box. In other words, Explo is fully extensible.
The widgets during the first era of web design seldom had these degrees of freedom. But today, personalization and customizability are table stakes.
Reason #2: Qualifier—Better Experience relative to In-House
Nowadays, embedded apps ship with so many action-packed features that they often provide an experience that couldn’t be built in-house given opportunity costs. Developers’ time is limited, and nice-to-have features after often postponed into perpetuity due to opportunity cost.
However, embedded apps often make implementing these pro features nearly as easy as implementing the simplified version. And good example of this is Paragon supporting data field mapping. Many, many applications need to build integrations with third-party tools to fulfill customer demands; however, a big nice-to-have feature is custom data field mapping so that users don’t need to augment their third-party tools to work with a new application.
When implemented in-house, custom data mapping isn’t usually included because it’s a lot of work on top of the core integration. But with Paragon, it’s a feature that’s configurable out of the box.
We’ve experienced similar feedback from customers at Explo.
Imagine a fictional Hubspot competitor that needs an analytics dashboard. If implementing the dashboard in-house, the team will likely learn how Highcharts or Vega works, spin up a micro-service, feed the data, run it through some edge case testing, poll customers over what charts are needed, what filters are needed etc. A lot of work, for a rather simple end result.
But if that customer used Explo, not only do they skip all the infrastructural issues, but they can enable customers to personalize their dashboards out of the box. Suddenly, the dashboard page in that product isn’t just a dashboard page; it’s one of the best in their category.
In short, embedded apps enable features to happen that weren’t initially worth building. These nice-to-have features add up, molding a better end-user experience.
Reason #3: Newer Priority—UX over UI
Unquestionably, utilizing third-party embedded apps limits how perfect UI consistency could be. No matter the personalization features available, chances are something—be it padding, a border-radius, or a box shadow—will be inconsistent between pages.
Today, however, product teams care more about UX than UI. It’s not about a button’s gradient, accent, or shape—it’s more about where the button is placed to contribute to a logical UX. This is partly because SaaS software is looking more and more alike; users who jump into products have preconceptions about where certain nav-bars should be and what icons represent what.
This new paradigm makes a case for embedded apps. Embedded apps have a proven form-factor that is easily recognizable to users because they are designed to work across broad categories. By utilizing widgets, companies don’t need to worry about their app’s UX feeling foreign.
Familiarity is king, and embedded apps achieve that without hassle.
Reason #4: Newer Priority—Cost versus Risk
Building a feature in-house is often more expensive than purchasing it. Features often take months between designing, building, testing, and shipping a feature across high-paid roles such as design, product, and engineering. Worse, if a feature’s UX is foreign or the release ends up being buggy, additional engineering cycles might be needed.
Then, there is the additional risk that the feature doesn’t meet the expectations of engagement. Sometimes users request a feature and then don’t take advantage of it. After all those engineering cycles, what if the feature doesn’t pan out?
Embedded apps solve this conundrum.
I remember meeting James Evans, CEO of CommandBar, at Alamo Park in 2021. I asked him, how do you deal with “build versus buy”? His response surprised me at the time. He told me that it’s not about build versus buy—rather, it’s build versus try. Nothing about implementing CommandBar prevents an organization to build an in-house version later on. Rather, CommandBar de-risks an organization testing an action-based search-bar, and if an organization wants to build an in-house version for whatever reason, they still could.
Reason #5: It’s a Rat-Race Out There
If you’ve been following venture capital gossip, you’ll know that the summer of 2020s experienced a boom in startup funding. Every product, alongside its four competitors, was getting big checks. While things have obviously slowed, it is still a competitive environment for SaaS products.
Embedded apps allow teams to ship features faster, which may be necessary when they’re trying to edge out their competition. End of the day, SaaS startups win by not having the prettiest feature, but by having the best one.
Conclusion
Times have certainly changed. Managed, plug-and-play embedded apps are starting to replace assemblies of React packages. Product teams are playing a more active role in feature management, and experimentation of newer features is made easier by widgets.
Embedded apps or widgets, likewise, have improved to adjust to the increasing requirements of how features are built, shipped, and upgraded. Their support for personalization and customizability makes them more satiable for modern engineering and design teams.
It’s unclear if we will ever enter a fourth wave of software design that’ll phase out embedded apps, but I wouldn’t bet on it.
Other Embedded Analytics Resources:
