18. • Lots of user error we weren’t expecting
• Broken web-cams, bad video drivers, other applications stealing the
camera
• You’re often at the mercy of the network, and users blame your app
L E S S O N S L E A R N E D
19. • Make sure you’re getting good stats on everything you can:
• Calls attempted, completed, dropped
• Repeated short calls between the same two people
• Really short calls that might indicate a problem
• Network quality during calls
• Video quality on each end
• And make sure you track user feedback: ask for a rating at the end of
each calls
L E S S O N S L E A R N E D
20. • Self-diagnostic tools are super useful:
• A "test sound" button to test your speakers or
headset
• Indicators for when your mic is picking up
sound
• Camera display so the user can see
• Detailed logging that the user can access
L E S S O N S L E A R N E D
21. 1. Building vs. Buying: Is video the core of your
application? Are you able to do it differently/better than
everyone else?
2. Partnering: look hard at their SDK and API before
choosing your provider. You’re making a long term
commitment.
3. Running: The real world is messy. Make it easy for users
to self-diagnose and record as much data as you can.
Notas del editor
The first reason was platform support. We needed to support every browser, including IE. Vanilla WebRTC isn’t enough. Our provider gives us a plug-in that abstracts all that away from us. As far as we’re concerned, it doesn’t matter what browser someone is using.
And we weren’t just building for the web — we have applications on five other platforms. Our provider gave us a library and and SDK for Mac, iOS, Windows, Linux & Android.
They abstracted away all of that pain, and we could program every app to the same API.
And that’s the second consideration: the provider has to have a power, well documented API that makes sense for what you need to do. There were plenty of libraries that we looked at that failed this test.