QuickFuse
quickfuseapps.com
quickfuseapps.com
The homepage is: http://quickfuseapps.com/
We think it's really neat stuff--it basically takes the web mashup power of Yahoo Pipes and applies it to telephone calls. The technology behind it is also pretty impressive. If you have any questions, please send them to me here, and I'll do my best to answer them!
Only one point of frustration: There should be an obvious way to get variables from the call row. You can update the call row with the "Update Call Row" module in the "Outbound Campaigns" section, but there should be a "Reserve Variable From Call Row" module, too. Otherwise, it seems the only way to do it is to "Reserve Variable" for every one you want to use, and manually set them as pre-filled every single time you create a campaign, which is a hassle.
Also, $0.05 cents per minute feels kind of steep. You have a very novel and wonderful service, though, so maybe it isn't such a big problem. It was so easy and intuitive to make a demo app, assign it to a number after I registered and watch things coming together. You guys are Doing It Right. Kudos, kudos!
One more thing... it'd be nice if there was an easy way to filter outbound calls on whether the person has already been called, according to whether the "outbound_result" field in their row is populated. There's a filter option "is..." that lets you select between "present" and "not present," but it's not clear whether that means "empty" or "is not even a hash key for that row," or if those two things are even different.
Oh, and for God's sake, make sure you block requests on your site that have "4chan" as a referrer... ;-)
Re: filtering, this needs to be better documented, agreed. "present"==="field exists for row, with any value". There's a distinction between empty grey and empty white cells that we tried to make but it may not be apparent to non-programmers.
Re: price, we are only a couple cents/min higher than what other barebones API providers are charging. But we are obviously much more than an API service. Hosting all apps in their entirety, along with slick web-based tools to build them, is the extra value we are hoping to provide.
Ok, maybe that's sad, but hey.
I'm not sure if this will work for everyone else since I didn't create an account, but I guess you can try here if you'd like: http://quickfuseapps.com/app/edit?x#a=5WNw04UUdu0,r=1go
I notice that it's a mish-mash of div and canvas tags.
We don't know of any framework for this sort of interface, and we did not want to use Flash, so we just rolled up our sleeves and made it ourselves. jQuery and jQuery UI, however, were instrumental; for this sort of new-ish UI, it was useful to have the ability to progressively layer functionality onto HTML elements. We also made extensive use of the $.Widget framework to construct our widgets in the same fashion as jQuery UI's.
Thankfully because the interface doesn't use Flash, that shouldn't be too difficult. We'd have to rework some of the event handlers, but that should be it.
FYI, the reason we periodically reset the scroll position is because the main <body> on normal windowed browsers is meant to never scroll in this editor interface. Even if you disable scrolling in CSS, some browsers like to scroll when you do things like (accidentally) highlight text near the window border, and we needed a way to make sure the interface stayed within the browser window.
Out of curiosity, how long did it take to develop & launch? How many people were responsible for the product?
We wouldn't have been able to develop as fast as we did without the foundation provided by great projects such as Kohana (we used 2.3) http://kohanaframework.org , jQuery, and jQuery UI. For us, these frameworks turned out to be a superb combination.