Launching Instagram Messaging on desktop

Furthermore, we haven’t found any evidence that the Instagram desktop web experience cannibalizes engagement from the native apps. In fact, it’s quite the opposite — users who use both interfaces spend more time on each interface, compared to users who use each interface exclusively.

Taking into account these findings, we have focused on building products that can enhance the user experience throughout the Instagram ecosystem, including web interfaces. Messaging was a natural fit and one of the most requested features to develop for the desktop web interface based on our user research. Not only it enabled casual use cases, such as messaging from your computer while performing various other tasks, it also created new use cases geared towards power users, such as the ability to use a large screen and keyboard to reply to hundreds of messages.

Part II a): Engineering, from hack project to testing

Before Instagram Direct messaging (also referred to as simply messaging) was developed for the desktop web experience, it started off as an offering for the mobile web experience. The messaging experience was one of the first new product areas we had added in a while and was architected in a way that would allow its independent usage with or without the rest of the website. Some of the technical achievements included:

  1. Being the first part of our website to be written in purely functional components with React hooks, which was a newer paradigm at the time.
  2. It was our primary venture away from GraphQL usage and towards RESTful endpoints, which aligned us closer to the other Instagram applications
  3. It was the only area of ​​the website that relied on real-time communication, and so was our first primary usage of MQTT.
  4. It was the first area of ​​the website to use encrypted push notifications, as well as our first major expansion of our existing ServiceWorker framework.

Considering the design decisions above, we made the architectural decision to separate data for messaging away from the rest of the web application, which had the data being unified through an inefficient GraphQL and Redux combination.

This change resulted in :

  1. An isolated Redux store that could be operated without needing data from the rest of the website.
  2. This also led to an independent client-side caching architecture, allowing Messaging on Mobile Web to boot quickly from cache independent of the rest of the website.
  3. Code that was very reusable on both Mobile Web and Desktop. The website as a whole shares a lot of the underlying architecture between the two surfaces, but messaging’s implementation strictly separated the models from the views allowing for its easy re-use in this project, and further projects down the line.

We launched Messaging on Mobile Web at the end of H1 2019. After the launch, we noticed that many users were trying to get around the mobile web restrictions to use the experience on Desktop. After seeing the success the application had on Mobile Web, Messaging on Desktop started off as a Hackathon project in 2019.

The project took the already-existing Instagram Messaging on Mobile Web and wrapped it in a container to frame it into a seamless desktop web experience. This, along with the data we received over multiple user research sessions, showed that messaging on desktop had the potential to find product market fit.

When building out the experience for desktop, we had to take into account the larger interfaces and the different needs of Desktop web users. Some of the major changes we made:

  1. Improving the UX experience, from badging support and message flows to desktop-centric actions such as drag and drop images.
  2. Adding key missing features such as Presence, Voice Messages, Permanent Camera Messages, Gallery Views
  3. Support for Creator and Business accounts, and the handling of multiple inboxes
  4. Changes to the way we handle caching, as Desktop web users expected a more up to date experience

Part II b): A/B testing and shipping decision

We launched the test to 2 percent of the Instagram desktop web population. The main metrics that we were keen on monitoring was usage of the messaging product, as measured by the number of users who send at least one message per day and the overall number of messages they send across both the native apps and desktop web. The results exceeded our expectations, with increases in both of those metrics. We also had guardrail metrics to ensure that enabling Instagram messaging on desktop would have no negative effect on the usage of our native apps. The only regression we observed was in the usage of messaging on the mobile web. We believe that some of the loss was organic since users now had one more option to choose from if they couldn’t access their native app. But some of these lost mobile web users were artificial, because we know that many users were using third party extensions and tools to disguise their desktop web browser as a mobile web browser in order to get access to messaging (since messaging was available on mobile web before it was available on desktop web).

Part III: Why desktop web features are more relevant than ever.

2020 has been an unprecedented year. The global pandemic has pushed the world into remote working and learning, which, along with social distancing measures, forced people to spend an increased amount of their time online. Because of this, products like Instagram Messaging and Instagram Live became even more important in helping people stay connected with the people and things they love. It was important that we enable users to access those products from their desktop computers.

Across Instagram’s three main interfaces (native apps, mobile web and desktop web), desktop web was the one that grew (percentage wise) the most during the pandemic.

Comments are closed.