We saw the rise and fall of embedded plugins. But are custom UI integrations now back in style?
As APIs become an expected feature of software businesses, the most popular web services extend their developer platforms. Many go beyond an external API and allow 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 finally see the stories, and the user experiences make sense. As embedded experiences become more popular, they may become expected features. 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 famous 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 decade, 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 being retired.
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. Perhaps this is because user experience is better understood, and more reliable APIs enable higher quality integrations.
Past embedded platforms were able to differentiate the product and help it attain new values. 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.
Let’s view some sample use cases to weigh the pros and cons of a few integration methods. Each of which delivers helpful insights for those of us attempting embedded experiences that go beyond the basic iframe route.
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 plugins over the last few years. They did so by first understanding their customers needs, establishing use cases, and strategically positioning partners to meet those use cases. The technology is similar to what we saw 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 at Google Next, Gmail announced its “add-on” service, a new means of opening Gmail’s interface to partners. Google observed what others had accomplished through unofficial hacks of Gmail’s interface through browser extensions. After seeing positive user benefits, they gradually enabled 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 that 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 because of a lack of awareness, but because of one serious concern; with the rise of mobile app usage, how are partner integrations still valid?
As mobile usage increased dramatically, companies debated how it would be possible to make an integrated experience work seamlessly within a complete desktop and mobile story. Likewise, many companies simply deprioritized embedded integrations over other mobile experiences.
However, new platforms show ways to work interchangeably between desktop and mobile. For example, a Gmail Add-on can work in Gmail’s mobile app, giving a compelling reason to integrate officially rather than through Chrome extensions.
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 and will experience hiccups for the near-future. At this time, we can still learn from the experiments, for those just starting a platform, to build more smoothly.
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 in a web interface from a developer portal.
The developer experience has become a science onto itself. Embedded experiences are starting to move toward best practices that we’ve seen in other aspects of the API developer experience, but has farther to go.
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, UX design, and developer experience, guidelines achieve 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.
In future articles, we’ll explore the various user experiences, developer experiences, and technologies of embedded frameworks. We’ll analyze their corresponding APIs and developer portals. We’ll see what works, what hasn’t worked and continued experiments to identify a path to successfully 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.