Right now they're very similar, but we're working on getting Awesometalk onto more platforms than just the web. We want you to be able to send anyone an Awesometalk link, and no matter what device they're using, have a conversation.
Isn't that exactly what the web is good at though? Cross-platform? Right now I can send a friend an appear.in link and they can open it on their Android device and join the chat. I don't think Safari on iOS has WebRTC support yet, but I can't imagine that they're not working on it.
Let's say you send a link to someone on an iOS device -- we can prompt them to install a native app, then as soon as they open the app, with no login, your call starts.
Apple actually is refusing to add WebRTC to Safari, because if you have good HTML5 support and WebRTC, you can do much more outside of a native app, which hurts their ability to control the app ecosystem, and helps developers ship to Android and iOS on the same day. I hope this changes, but right now it doesn't seem promising.
Hey there, I just tried it and my experience was not very satisfactory. I imagine you are interested on the feedback so there it goes: video quality was low (super choppy, video was getting frozen at several points), voice quality was low (I could understand about 50% of what was said) and when a third person tried to join it got a message "This call is full right now" (which I don't know if it's a bug or by design - it's not clear if this is just a 1-to-1 service).
Anyways, the concept is very cool and I hope you get to make it work. A reliable service like this would remove a lot of my communication headaches.
Thanks for the feedback, sorry your first call didn't go well.
When the connection is poor, as it sounds like it was in this case, would you be okay if we fell back to audio-only and explained why? This seems like a better experience than trying to fight through lag, but we want to be careful not to arbitrarily cut off your video feed.
In Skype I have the option to show call technical info turned on.
It is immensely helpful since it shows continually updated values for latency, packet loss (in both directions), codec in use, bitrates etc. From that I can easily tell what the issues are (latency spikes vs packet loss are hard to distinguish due to the same symptoms).
That isn't helpful for the masses, but you can display some sort of connection quality indicator. You can also offer suggestions on seeing latency spikes or packet loss (try to work out of they are upstream or downstream).
The usual solution to video is to reduce bitrate, resolution and framerate. Blocky video that is taking seconds to update is an obvious indicator of connection quality issues.
Totally understandable - we don't want to exclude you based on the number of characters in your desired username. We just don't have a good set of all the words we need to reserve upfront - what we really want to avoid is ever forcing someone to change their username because of a conflict like this.
We'll see what we can do to allow shorter usernames without ending up in this situation. Thanks for the feedback.
Thanks! Let's take a stab at getting you setup with something small tomorrow ;)
It's funny that you said that about our landing page, because before this, we were probably the most egregious offender of having landing pages that didn't convey what we did. Takes a lot of work to find the right words and presentation, and we still want to make it better.
Our goal is to integrate with your source control, no matter where it's hosted. Anything that can send us a webhook should work just fine - just a matter of timing for us to build the integration. Email me at email@example.com and let's talk.
As far as getting information out of Awesomebox, you're the first person to ask - what type of information would you want? There's a few use cases we've thought of, but I'd love to hear your ideas first.
Great question - here's a few problems that Matt and I have encountered with Github issues and screenshots:
1) Clients, managers and other "non-developers" usually don't have Github accounts. When we tried making them use Github Issues, most of the time they'd use it for a week and then go back to emailing us or just stop giving feedback.
2) When new code is pushed to Github, how do you show non-developers? Usually this requires maintaining staging servers. What if you want to show different things to three different people? Three servers to maintain. With Awesomebox, you don't have to worry about this - we could even send them notifications to check out new versions, so that you don't have to bug them.
3) It's hard to keep screenshots and their associated conversations organized - it requires a lot of discipline, and when building things I've found that I tend to lose track of UI/UX feedback overtime, even if it's within an issue tracker.
4) Not all feedback is an "issue" or a bug. Github Issues are great, but are designed to track problems, not to help people discuss ideas or provide positive feedback.
I hope that helps answer your question - just a few of the reasons that Matt and I started working on Awesomebox. I'd love to hear more about how you work with people who aren't developers, and if our product doesn't fit your needs, tell us what we could do better. Feel free to reach out - firstname.lastname@example.org
Awesomebox only works with client-side code that runs in a browser - HTML/CSS/JS. If you have a Rails app that serves up a "single-page" app (like Angular, Backbone, Ember, etc.), we can work with you to make Awesomebox work. If this applies to what you're building, email me at email@example.com and we'll do our best to get you running with Awesomebox.