KrankyGeek WeRTC Conference 2014

  • 114 views
Uploaded on

Presented at the KrankyGeek WebRTC Show (http://www.krankygeek.com) on June 27, 2014

Presented at the KrankyGeek WebRTC Show (http://www.krankygeek.com) on June 27, 2014

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
114
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
7
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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.
  • And that’s how we built

Transcript

  • 1. JONATHAN NOLEN • HIPCHAT PM • ATLASSIAN • @JNOLEN K R A N K Y G E E K W E B R T C E V E N T
  • 2. USER EXPERIENCE AVAILABLE FEATURES API PLATFORM SUPPORT BUSINESS MODEL
  • 3. USER EXPERIENCE AVAILABLE FEATURES API PLATFORM SUPPORT BUSINESS MODEL
  • 4. USER EXPERIENCE AVAILABLE FEATURES PLATFORM SUPPORT BUSINESS MODEL API
  • 5. USER EXPERIENCE PLATFORM SUPPORT BUSINESS MODEL API AVAILABLE FEATURES
  • 6. PLATFORM SUPPORT BUSINESS MODEL API AVAILABLE FEATURES USER EXPERIENCE
  • 7. • 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
  • 8. • 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
  • 9. • 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
  • 10. 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.