The Fall and Rise of Embedded Plugins: How Custom UI Integrations Are Making a Comeback
As APIs become an expected feature of software businesses, the most popular web services extend their developer platforms beyond external API, allowing partners to integrate right into their interfaces. With Salesforce’s Lightning platform, Google Docs’ connecting tools like Balsamiq and ShiftEdit, and Trello’s PowerUps, custom experiences powered by third parties is proving itself to be a great way to improve one’s product and grow your business.
The story is compelling, and the opportunities seem incredible. But in practice, many of these platforms were more “cool” than valuable, or usable. There’s a large graveyard of failed embedded integrations over the years.
However, after many years of disappointment, we’re finally seeing value propositions and user experiences that make sense. And as embedded experiences become more popular, they may become expected functionality. So, let’s evaluate what has worked and hasn’t in the world of embedded integrations.
Rise, Fall, and Resurgence
You may have seen other popular but forgotten platforms with embedded experiences in the not-to-distant past, such as Google’s iGoogle, Facebook Canvas, and OpenSocial. These gained attention around 2005-2008, with mixed results, and were sunsetted over time.
Arguably, those early platforms were good tests of the viability of extending web apps, and could be improved with further iteration. We have learned a lot about User Experience over the past several users, and as our web services received upgrades, how did embedded frameworks do?
Unfortunately, for many years, we hadn’t seen as much new innovation on this front as we had hoped. Although APIs rose in demand, the focus appeared to be more toward external interface integrations and data integrations. Furthermore, the rise of the mobile application ecosystem created additional challenges to operate embedded experiences that we’ll dive into in a later article.
Many interesting experiences could still be observed through those years, such as Gmail’s multiple attempts to incorporate third-party tools. Projects included Contextual Gadgets, allowing partners to display content depending on the text of an email one receives. Unfortunately, that project never made it out of Google Apps for Business (now G Suite) before getting sunsetted.
Although experimentation and learning continued, for many years these embedded experiences didn’t show results. However, in recent years embedded frameworks are increasing again in popularity, as usability is better understood, and more solid, consistent APIs enable higher quality integrations.
Lessons from the past embeddable platforms show that embedded integrations can help a product differentiate and demonstrate otherwise unattainable value. However, to avoid the “platform graveyard,” it’s necessary to understand the needs of your users, and from there, determine how partners can best fit in.
Experimentation by other businesses with partners and customers allows us to see what’s possible, beyond the basic iframe route. Different stories and different technical means of integrations, each of which serves particular use cases with pros and cons, can be benchmarked in order to plan an embed framework for your platform that really works for your customers and partners alike.
Applying Usability to Embedded Frameworks
Usability learnings for both consumer and enterprise products, combined with improved availability and quality of APIs, can give embedded apps another shot. It’s now easier than ever to connect products, but we have to apply the same standards in usability that we now see across software, and across APIs.
Trello and Shopify have demonstrated the benefits of such extensions over the last several years, by first understanding their customers’ needs, establishing use cases, and then enabling partners to be positioned where needed to meet those use cases. The technology is similar to what we’ve seen in the old days of basic iframes, but the experience is better.
Trello’s Power-Ups allow partners to connect to various parts of the Trello interface and experience, to perform actions on a Trello board, within a Trello card, and more.
Other businesses are following the trend toward open interfaces. In 2017 Gmail announced its ”add-on” service, a new means of opening Gmail’s interface to partners. They seemingly observed what others had accomplished through unofficial hacks of Gmail’s interface through browser extensions, and after seeing what works well with users, gradually enabling some of that functionality through their interface.
This project is ongoing, with Gmail announcing more recently (October 2018) that partners can integrate into Gmail’s compose message experience.
The Gmail team is aware that they have a long road ahead, and still need to fill in gaps to enable the integrations users want. They also encountered a dilemma that is more and more common for embedded frameworks: how to work well with mobile.
Facing the World of Mobile
Developer Advocates for Gmail, Slack, and other popular services have been inundated at times with requests to enable embedded integrations. They didn’t pull the trigger due to a lack of awareness, or exclusively due to technical/security concerns (although those were factors), but out of a design concern - with the rise in use of mobile apps, how can they make the story of integrations still work?
For some time, as usage in mobile increased dramatically, companies debated how it could be possible to make an integrated experience work with a complete desktop/mobile story, and often deprioritized embedded integrations over other mobile experiences. However, new platforms have shown ways to work interchangeably. A Gmail Add-on can work in Gmail’s mobile app, giving a compelling reason to integrate officially rather than through Chrome extensions.
Similarly, Slack Actions work on Slack’s web service, desktop client, and mobile apps.
How is this possible? From a technology standpoint, they are doing something different (hint: not iframes). And the decision to do so has, thus far, had pros and cons.
These cross-device frameworks are still in their early days of market testing, and will experience hiccups over the near-term. At this time, we can still learn from the experiments, for those just starting a platform, to build more smoothly.
Developer Experience
Although user experience is vital to the success of embedded integrations, one cannot forego the developer experience. Just as standards for the developer experience with external APIs, such as the 3 column API documentation, helped to increase success rates of API initiatives, learnings from various embedded projects show patterns in developer experiences for embedded integrations.
For instance, Gmail Add-ons and Trello Power-Ups require developers to define an “application manifest” - json files that they need to custom define, and upload to said platforms to be made available to users. Other platforms such as Box instead allow developers to manage everything from a web interface in a developer portal.
The developer experience has become a science in itself. Embedded experiences are starting to move toward best practices that we’ve seen in other aspects of the API developer experience, but have farther to go.
Standards
Just as RESTful APIs defined under the OpenAPI specification have made integrations easier across services, as patterns become standards for embedded experiences, we are likely to see more platforms, and more integrations. Partners will be able to build interoperable integrations that span across a range of products (as OpenSocial intended years ago, I know, but let’s give standards another chance).
In APIs, in UX design, and in developer experience, guidelines at least can be seen, to achieve the success. For instance, the manifest definitions for an embed framework, while not consistent across platforms, are similar. Ideally, in time they will align to a standard.
What’s next
In this series, we’ll explore the various user experiences, developer experiences, and technologies of embedded frameworks, and corresponding APIs and developer portals. We’ll see what works, what hasn’t worked, and continued experiments to identify a path to successful embedded integrations. We’ll also highlight patterns and the opportunities for common standards in this space.
We look forward to seeing technologies integrate more deeply and seamlessly with the latest iterations of embedded experiences.