Tuesday, June 16, 2009

Cogi Mobile

So, for the past half year, I've been working with Cogi to create an API for their underlying system. Cogi provides phone recording and speech to text services, but their only forms of access is either through:

1) Their flash applet on their website.
2) Using their landline.

Technically though, their landline only allows you to make the calls and will not allow you the access the recordings at all. So in all actuality, the only real option users have is the flash applet.

Granted, this isn't a terrible thing at all. Flash penetration is ridiculously high; Adobe claims 99% penetration (reason? Youtube). With such a high penetration rate, it isn't all that bad to make users go through a flash applet rather than using plain HTML/AJAX, plus you can make it look all snazzy.

There are contradicting claims to Adobe's penetration rate though. If you count any internet-capable device as possible access points, then thinner devices like smartphones that don't have Flash capabilities yet are cut out. There is Flash Lite (haha, Flash lite, get it? /groan), but as far as I know, speaking with the people at Cogi, it wasn't compatible or something. Given that a large part of the market base is targeted towards business-oriented users (think managers, lawyers, agents, etc.), a lot of these people aren't going to have access to a flash-capable device all the time. Maybe they're out in meeting all day, or driving from place to place. You get the idea.

So our solution was to create API was something essentially akin to one giant set of accessor methods. All the information was already available on their servers, so all we had to do was package this information in an easily accessible format and keep it such that it would be easy to get. The information was all sent in XML format, over HTTPS. Given that basically any language/platform combo is capable of parsing XML and using HTTPS, it was a wise choice.

Of course, that was the easy part. Writing a bunch of accessor methods on top of a database is mindnumbingly dull. Get info get info get info, serialize into XML, ship over HTTPS. The problem remains though; XML is not exactly a friendly format for endusers. At best, it's a good format for a client application to understand information. We still needed to create that client application.

In retrospect, spending several months creating a client application was probably not the greatest idea. As it is, a lot of the smartphones are disjoint from eachother, so creating a client application for a specific platform would only open the market to a single platform. However, that's what we did: we created a client application for the Google Android OS (currently, the G1 HTC Dream is the only phone that can run Android). Oh well. It wasn't something we had a choice about; we only had an iPhone and an Android phone available, and since iPhone development requires a Mac + $99 developer fee, we went with the only choice. We did, however, create a very snazzy looking interface. It worked relatively well, and thanks to some Photoshop prowess, everything managed to look shiny and nice.

A better choice for a client application was only created much later, about one month from the end of the project; instead of creating a platform specific application, why not obviously create something that is even more accessible? Something that's common to all smart phones is internet browser capabilities. So, I whipped up a small web app that accessed the previously created API and parsed the data into a readable format. A working copy can still be found at: http://cogimobile.deviange.net/ The web app isn't exactly as polished or graphically pleasing (read: text-only) as our client application (icons and colors galore), but in terms of accessibility, it's worlds beyond what a platform specific app can give. And I think that's extremely key.

No comments:

Post a Comment