ylliX - Online Advertising Network
10 Things We Learnt While Building A Top-Performing Zoom App

10 Things We Learnt While Building A Top-Performing Zoom App


A singular goal. To release as quickly as humanly possible. Laser-sharp focus. Make the most of Zoom’s new Layers API. A daring vision. To give Zoom users better meetings. The Prezi way. All of these, in many ways, are a testament to Prezi’s long history of wanting to turn the boring, the mundane, into engaging, expressive and fun. And last fall that’s precisely what we set out to do. A handful of people, a small cross-functional team with a working proof of concept, sat down to build the top-performing Zoom Marketplace app, and roughly six months later we know what got us here, but also what almost didn’t. Listicle as this may be, grab yourself a java ☕, this ain’t gonna be a short read.

Never underestimate the value of a robust POC…

Yes, we can, said Obama and said we at the end of the first sprint. Shame we didn’t have a microphone to drop. But jaws definitely did, when people saw a styled and animated web UI baked into the Zoom video output for the first time. Without any virtual camera, native companion app and socket-based workarounds.

There were far less API endpoints to work with back then compared to the long list that Zoom provides today, but whatever we could try, we did try. We had to know. It was more than a POC, it was a feasibility study. At that point, if engineering had said, “it can’t be done”, that would have been the end of it. That POC became the seed project for what’s today the Prezi Video for Zoom app on Zoom Marketplace.

Evolution is painful — literally!

Can’t speak for my team-mates, but I certainly had a few migraines induced by overnight API changes or less-than-stellar documentation. But here’s the thing. You can’t make an omelet without breaking a few eggs, so we knew that we were working with an evolving API and ecosystem. Things will inevitably break, either on our end or Zoom’s end. And they did, and it was frustrating, but also rewarding because many of those frustrations were met with solutions on both ends. I guess you only learn to really sail in choppy waters.

Every time the wave of unexpected bugs or changes hit us, we took a deep breath and remembered our goal, envisioned our vision and focused on solving the challenge at hand just like you’d solve a puzzle.

Automated testing to the rescue

But there is a difference between reactive and proactive development. We don’t believe either of these is healthy on its own, but combined, it helped us reach velocity with reduced chances for major incidents. I’ve written in the past about the testing pyramid and how engineers should take on more of the automated testing. It was time to put it all into practice. Every engineer on the team wrote their own Cypress regression tests for every feature. No test? No deployment.

In a team of four engineers, I know of at least three major incidents I avoided by having regression tests. Multiply that by four… and you suddenly see the value of a good testing culture. No, we’re nowhere near perfect, we’re behind on some unit tests, but having the security and peace of mind that our changes don’t break some other feature already live, is invaluable.

Look ma, it’s a web app!

If you’ve never built a Zoom app before, you’ll be surprised to hear that for the most part it’s a web app. The implied asterisk is probably not lost on you, though. There are a couple of exotic aspects to Zoom apps.

CEF in video context. Chromium Embedded Framework is something you might have never had to use before. It’s quirky, but useful. Debugging in Zoom, is where it gets a little less fun, but that’s expected. Pro-tip: send console logs and errors as messages from inCamera content to the inMeeting context, which then can log them in the regular browser console.

The inMeeting context is a native embedded browser. On a Mac, for instance, it’s Safari. Finally! You have an unavoidable reason to debug stuff in Safari! 😁

The inMainClient context is also a native embedded browser, so more Safari fun, if you’re on a Mac.

Context is key

You know those contexts I keep referring to? They’re basically the three pillars of every Zoom application. The easiest way I can explain this is by illustrating it with a house.

Imagine a house. It has three rooms: a bathroom, a living room and a bedroom. All have doors between them, but they’re all locked. It’s one house, but three rooms with locked doors. When you’re in one room, you only see and know what’s in that room. If you want to know what’s going on in the other room, you gotta pick up the phone and call the other room. Just like Sheldon and Missy (from Young Sheldon) communicated when they were kids. Same thing with the app. One app. Three contexts, and communication between them is the way one updates the other.

Zoom does allow transfer from one context to another, but that’s a whole topic in itself, so maybe check out their docs. Hint: you’re gonna need to rely on onRunningContextChange among other things.

Collaboration like never before

It’s tough enough as it is, finding ways to collaborate well with team-mates, especially in a remote environment where everyone is in different locations. Add to that the extra dimension of having to work closely with Zoom as they were developing their Layers API capabilities, and you find yourself having to adjust pace to fit product’s needs but also meet certain deadlines resulting from being selected for the Zoom Essential Apps bundle. It might seem obvious, but judging by how many companies and teams still struggle with communication, it feels worth highlighting just how key it was for us to rely on open, pragmatic communication throughout the entire project.

Agile taken to a whole new level

Whenever people mention Agile, the concept of minimum viable product (MVP) comes up. But guess what? Just using agile terminology in meetings won’t get you anywhere. Who knew, right? We had to live it.

As a cross-functional team, we agreed on exactly what that MVP looked like, and as soon as it was ready, we let no scope creep in, and went live. Then we took the concept further and started thinking in terms of minimum viable feature, and minimum viable implementation, and productivity skyrocketed. As many as 7 pull-requests in a single day from 4 engineers. All supported by a dedicated UX design expert and QA professional.

It’s not tech stack vs. delivery

I have worked for enough companies to know how often product and engineering can be at odds with each other. This was something we could not afford. Not at Prezi, not now. Far too much at stake. Perhaps organically, we all seemed to share a common goal–wanting to deliver a successful Zoom app as soon as humanly possible and keep building on that success for as long as it makes sense.

We put our individual professional egos aside, and took, as a team, pragmatic decisions around everything from using our monorepo, to the code we write, the language we write it in, unit testing, regression testing, where we use our own services, where we rely on 3rd party solutions, when and how we release. I call it product-driven development, where, as engineers, we were given a hard deadline, and we had to make smart technical decisions to make the most of the time we had.

A good design is worth its weight in gold

Just like you should never let an engineer name a product, you should also never let them design anything. Frankly, we got lucky for having one of the absolute best UX designers I, personally, had the pleasure to work with, and I’ve worked with many. Fully dedicated to our team, she took the minimum of minimum viable products and helped us turn it into something we all felt really proud of, both in terms of looks and UX. Can we still do better? Of course, and that’s where data comes in.

Data to rule them all

Do not underestimate the power of information. Having data on what our users do, how they use Zoom and our app within, was crucial. Within half an hour of us implementing Hotjar, my assumptions were categorically refuted about how the various Zoom app contexts were approached by people out in the wild. So, now you have product driven, data informed development. What’s that? PDDD? That’s a lot of Ds, but hey, as long as it results in success… 🤷‍♂️



Source link

Leave a Reply

Your email address will not be published. Required fields are marked *