Christopher Herot's Weblog

AOL API

When we started Zingdom, the working title was Applied Messaging Corporation, reflecting our conviction that instant messaging (IM) was bound to be an important technology in the business world.  Since none of the major IM providers were interested in providing APIs to independent software vendors (ISVs), we developed and patented a technique for letting our users log into their favorite IM service using the standard client and then injecting ourselves into the middle of the data stream.  This avoided a lot of the problems other ISVs had in dealing with ever-changing authentication protocols, but it would never scale as well as a direct Edit Post | Post | Christopher Herot's Weblog | Your Weblogs | TypePadserver-to-server connection.  Years later, in one of life's many ironies, the same week we are issued the patent we signed a deal with AOL that makes the interception technique obsolete, at least for AOL Instant Messenger (AIM).

In the intervening years, AIM went from being one of the most closed, proprietary systems to one of the most open.  They've instituted a developer program with a link prominently displayed on the AIM home page and an SDK free for the downloading.  A simple shrink-wrap license is enough to get started, but we needed the ability to originate conversations from our server to the AIM subscriber.  This required an individually-negotiated contract but the AOL business development and technical people were a pleasure to deal with and the API worked as advertised.  They've thought through the issues of making the API work in a load-balanced, multi-server environment with asynchronous, stateless event handling.

Say, for example, that someone wants to enable visitors to his web site to be able to reach him on AIM, but doesn't want to publish his AIM screen name or require the visitors to install any software or become  AIM subscribers themselves.  So our web site owner signs up for our service and uses the HTML we provide to embed a Zingme button on the web site:

The end result looks like this:

When the visitor presses the button, he or she gets a choice of connection methods, depending on the preferences of the intended recipient:

If the visitor presses AIM, we use Javascript to pop up an instant messaging window:

And on the recipient's side, an AIM message arrives:

Note that the visitor never sees the subscriber's screen name.  On the subscriber's side, he sees information provided by the embedding web page, in this case "TravelForum User chris."

At that point, they can chat back and forth with our server in the middle.

Cool!

SpeechTEK 2007

 SpeechTEK brings together the people who build those telephone voice response systems that are becoming a ubiquitous part of our lives.  While many of these systems are downright annoying, the cost savings are impressive - one estimate was that every second shaved from the human interaction in a directory assistance application saves the phone company $7 million.  The developers are keenly aware that the caller is not always enthusiastic about speaking to a robot and in fact measure their success by reducing the percentage of the time the caller presses 0 to get to a human being.  Sometimes they cheat, e.g. removing or hiding the escape, but other times the robot can actually do a better job than a human, such as GOOG411's sending a map to one's mobile phone.

A session on Simulating the Personal Touch  provided some insights into how human and machine intelligence can be combined to offer the caller a more human experience.  In directory assistance applications valuable seconds can be saved by reserving human talent for those cases where machine interaction fails, and having the comouter serve as the intermediary between the caller and the human in the box.  One commonly used technique is to record the caller's request while simultaneously feeding it to a voice recognition system.  If the voice reco fails, the request is passed as a WAV file to a human who can say the response to the caller or make a keyboard selection which results in synthesized speech.  While these systems can be very efficient, they haven't always been popular with the employees who may find the experience less than satisfying.  This is especially an issue in European countries with powerful labor organizations.  Indeed, such systems have led to strikes in France and outrage in the press in the Netherlands.

Of course, speaking directly to a human isn't always satisfying either.  Lizanne Kaiser gave a good example of how a particularly lame system at AT&T Wireless, instead of passing the account number from the call routing system to the reps' screen pop, had all of the customer service reps reciting the same scripted excuse for having to ask the customer to provide the number again.  And this was to prevent her phone from being disconnected for an underpayment of $0.05 after AT&T mis-scanned the original check.  Sometimes the solution is not so much adding technology as it is correctly designing the entire system, including the humans in the box.

Google 411 at SpeechTEK

At the SpeechTEK conference this morning, Mike Cohen, Manager of the Speech Technology Group at Google talked about GOOG411, the free directory assistance service they have been operating.  While he refused to say anything about what was coming in the future, he did provide a few useful tidbits about Google's approach to speech applications.  They see mobile devices and speech as an important mechanism for providing access to data and are building speech into Gogle's core infrastructure.

One of the more interesting parts of Mike's talk was about how they measure usability and go about refining the system.  One of the measures of "user happiness" they used was the percentage of calls that the caller allowed Google to transfer after receiving the initial information.  They did A/B comparisons on new features, such as offering to connect the first match before listing the rest of the results.  They found that this increased the transfer rate by 1.5%.  In order to verify that this was really the result of happiness and not just passive acceptance of the transfer, they did interviews with 34 subjects.  They did verify that people realy did find the feature useful, but also found that many people using the service didn't want to actually make a call but just wanted to get the information.

I learned about one useful feature, which is that in addition to saying "SMS" to get the results sent to my phone, I can say "Map It" to get a map of the results.  Pretty cool!

Geek Party

In his blog today, Michael Cerda likened Zingdom, the company where I co-founded and am CTO, to Userplane and his own Jangl.  I'm flattered by the comparison.  We came across Userplane when we were operating as Convoq and offering a Flash-based web-conferencing product.  Like Convoq, Userplane used the built-in audio and video capabilities of the Flash Player and the Flash Media Server to provide a no-download real-time communications experience.  We built a complete, stand-alone web conferencing system while they built a widget that could be integrated into any web site.  They sold the company to AOL for a reported $30-40 million.  Valuable lesson there.

Jangl is the one company of the J Companies that has thought deeply about how people want to communicate and has gone about reinventing the telephone experience.  I share Michael Cerda's belief that we are at the beginning of an era where communications can be centered around people and relationships rather than devices and phone numbers.  We think we've found many innovative applications for this concept beyond the obvious ones such as dating and social networks and look forward to sharing some of those ideas in the near future.

In the meantime, here are a few screenshots of what we have built to date.

Zingme button embedded in a web site:

When the user presses the button, he or she gets a choice of connection methods, depending on the preferences of the intended recipient:

Selecting a connection mode dials the requester's phone, the dials the recipient:

I'll have more in a future post about how all of this gets set up.

Cisco Global IP Traffic Forecast

Cisco released a report this week forecasting how much Internet traffic will grow over the next five years and where that traffic will come from.  Some of the key findings and predictions:

• The Internet is not collapsing from streaming video, although traffic is expected to grow at 35% a year, mostly due on-line video and peer-to-peer file exchange, and the growth may not be evenly distributed.
• YouTube alone represented 4% of US traffic by the end of 2006.
• Pre-recorded Video content is 11% of consumer traffic worldwide, 18% in North America.
• Video communications will dwarf everything, although this probably won't happen until 2015.
• Total IP traffic will double every two years.
• Consumer traffic will surpass business traffic in 2008.
• Internet video-to-PC will grow by 10x in the next 5 years.  By 2011 reaching the equivalent of 250 million DVDs each month.

One of the more interesting conclusions of the report is that, contrary to the conventional wisdom that "content is king," that the more powerful driver is the combination of communications and content.  The social aspect of YouTube accomplished something that many pundits had dismissed: getting people to watch low-quality video on a small screen.  Traditional television may be less desirable than video that can be shared, tagged, mashed up, and discussed, with the result that the PC may continue to be an attractive alternative to the big screen TV for a lot of content.

Cisco believes that video-related Internet traffic will come in three waves:

1. Video viewed on the PC.  This was 8% of IP traffic in 2006, not including P2P file sharing.
2. Video to the TV set-top box.  With HDTV, this could be huge.  Three hours of HD a week would be 27 GB per month - a point that today would be lableled a "bandwidth hog" and kicked off the network.
3. Video Communications.  Perhaps the most controversial projection is that PC-based video calling will succeed where the videophone has not.  If this happens, by 2015  it could  be the largest consumer of bandwidth, since it is generated by  millions of individuals and, being real-time, can not be cached.

For the most part, the core of the Internet is not likely to be a major source of bottlenecks.  However, consumers are not accustomed to paying a lot for video bits.  The report contrasts the $0.0001 a consumer will pay for a megabyte of video to the $20.00 they will pay for an SMS message.  Also, the rerport states in several places that it's estimates may be conservative and that if services such as Joost catch on, bandwidth could grow a lot faster than projected, which does raise the issue of how the service providers will finance all that Cisco gear they need to purchase.

The White Paper summarizing the report is available here.

The methodology is in a paper Global IP Traffic Forecast 2006-2011.

A useful site to find similar papers from Cisco is here.

Updated 17 August 2007 to provide Cisco links.

One Minute Friend

As I mentioned in a previous post, Zingdom has been working on a platform to enable any web site to offer real-time voice and instant messaging communication.  We've built a set of web services that deal with typical communication scenarios, including those where one or both parties may not be ready to share all the intimate details of their contact information and schedules.  The idea is to offer a set of SOAP methods and AJAX user interface components that allow a web application to make phone calls, sent instant messages, and connect people together.  We provide these to partners who can quite easily integrate these capabilities into their own web site.

In parallel to signing up partners, we have started building a few applications of our own.  The first, which we tried out on the general public for the first time today, is a Facebook application, One Minute Friend. 

The concept is very simple: you add this application to your Facebook account, give it your phone number (just US and Canada for now), provide some selection criteria, and wait for your phone to ring.  You’ll be connected, for free, to another person on Facebook who made matching selections.  You talk for a minute and it disconnects.  You see their first name and their photo, but no other information, such as your phone number or profile, is revealed.  At the end of the call, if both of you so agree, the application will re-connect you for a more extended conversation.  Otherwise you can move on to the next person.

Facebook provides a lot of the infrastructure.  They have a community of over 25 million users and an API that provides access to a rich set of demographic information, making it possible for a person using One Minute Friend to specify whether they want to be connected to other college students, members of a geographic network, members of a group, and the all important selection of Male, Female, or None of the Above.  There is also a directory of close to 3,000 applications, together with a highly viral mechanism that allows people to invite their friends to try out their favorite app.

Since One Minute Friend needs a critical mass to get things moving, we are staging a number of events to attract people to show up and certain times.  We did one this afternoon and it was fun to catch up with some old friends, and to let them meet each other.  You can try it yourself by going signing into your Facebook account (membership in Facebook and in One Minute Friend are free) and going to the following URL: www.facebook.com/apps/application.php?id=4255800247.  You supply a phone number where you can be reached, let the system make a test call to verify your number, and your ready to talk.

There's also a Facebook group where you can correspond with other members and leave comments for the developers.  Enjoy!

Freddi Staur?

In a story that's getting a lot of coverage today, Sophos released the results of a study that purports to show how Facebook users carelessly expose themselves to identity theft by being too eager to share personal information with total strangers.  While I am saddened that so many people (41% of 87 responses) have so few friends that they will accept a friend request from a frog named Freddi Staur (sort of an anagram for Fraudster), the "personal information" they were sharing turns out to be things like addresses and phone numbers.  Last time I looked, I could get this information more quickly by looking in that thick, white book that my local phone company leaves on my doorstep every spring.  If we want to deal with identity theft, the place to start is with institutions such as banks and phone companies that accept as proof of identity information that is widely disseminated.  Even the favorite Social Security Number is not so good - it's not a secret if every company you do business with has a copy.  (Look at your Social Security Card.  If you got one before 1972 it says right on the front "Not to be used for identification.")

Sophos does have some good tips on how to configure Facebook's privacy settings.

Trattoria Di Monica

Boston's North End is a popular destination for locals and tourists alike.  It is the city's oldest residential community and has been a center of Italian culture since the early 20th century.  It is one of the few places in the US which feels like a European city, including narrow, stone streets, a vibrant pedestrian scene and, by last count, at least 100 restaurants.

The North End's restaurants range from large, glitzy places on Hanover Street to tiny little rooms on equally narrow streets.  One excellent find that is more in the latter category is Trattoria Di Monica.  The location was the site of the original Monica's Restaurant which has since expanded into new quarters on Richmond Street.  Meanwhile the owners, Patrick & Frank Mendoza (Monica was their mother), opened the Trattoria in the old venue.  While most of the guidebooks and the restaurant's own web site tout it as a pizza and pasta place, local food critic Robert Nadeau was one of the few to point out that this place had far more interesting offers if one was willing to explore the "specials" off the main menu.  Indeed after bringing complimentary glasses of Prosecco, our waitress recited a long list of enticing dishes completely from memory, and this was only her third day on the job.  One caveat, which Nadeau warned about in his review, is that the specials can be considerably more expensive than the items on the regular menu.  Usually I find it tacky when a waiter states the price after each item, since  most people can figure them out by finding comparable items on the printed list, but here the specials can cost 50 to 100% more than the regular items, so beware.  That said, the specials were more elaborate presentations of more expensive ingredients and worth the cost, although you can easily drop more than $100 here for two people before you get to dessert.

We started with the special Caprese salad ($21 but big enough to share).  It had a generous helping of fresh buffalo Mozzarella that was especially soft and creamy, with two kinds of ripe tomatoes, basil, and greens.  We had a few glasses of Insolia ($7) a crisp Sicilian white to go with it.

For our main course, we had theLinguini with Mussels, Clam and Sausage ($30) and the Rack of Lamb ($32) - four small chops (perfectly cooked), arancini, and a salad of baby lettuce, tomatoes, peppers.

I splurged on a glass of 2003 Umani Ronchi Cumaro  ($17), a Montepulciano that sells in the wine shop for $32 and is on the wine list at $67, so I shouldn't have been surprised at the price.

I would definitely go back again.

Trattoria Di Monica
67 Prince Street
Boston, MA  02113
617-720-5472
www.trattoriadimonica.com
Reservations Accepted - phone or Open Table
33 seats
Parking - the nearest lot is 34 Cooper Street ($15)

SCO Loses in Unix Suit

On Friday, Judge Dale Kimball of the U.S. District Court for the District of Utah  issued a Summary Judgement in SCO Group vs. Novell (2:04-cv-00139-DAK) that effectively demolished SCO's claims to the copyright for Unix and will most likely end SCO's long running suit against IBM (2:03-cv-00294-DAK).  The case, which was once seen as a threat to the open source software movement, started when SCO accused IBM of incorporating parts of SCO's copyrighted Unix code into open-source Linux.  The case took an unexpected turn when Novell pointed out that SCO didn't own the copyrights to begin with.  Novell claimed that when it sold its Unix business to Caldera (the predecessor to SCO) it merely licensed the code and did not actually transfer the copyrights.  Indeed, the Asset Purchase Agreement incorporates a list of Excluded Assets which clearly states that "All copyrights and trademarks, except for the trademarks UNIX and UnixWare" and "All Patents" are not among the assets being sold.  SCO argued from a number of angles that the agreement didn't mean what it said, or had been modified by other subsequent events, but the judge shot all of them down and declared that Novell still held the copyrights, and had the sole discretion as to whether to proceed against IBM for using Unix code in Linux.  While SCO never really established that any of the Linux code came from Unix, the issue will be rendered moot if Novell, as expected, remains on good terms with IBM.

Unix and the Origins of Open Source Software

For most of the brief history of the computer business, the operating system (OS) has provided a set of useful abstractions and services, such as a file system, memory management, a process scheduler, device drivers, and network stacks, but this convenience came at the price of flexibility.  Whether the OS came with the hardware or was sold separately, the source code was only available under very restricted circumstances.  If your project required some new form of memory management or a different user interface, you were basically out of luck until the vendor got around to it.  The one exception was Unix.  Originally a skunkworks project at AT&T Bell Labs, it was designed to be portable among different hardware architectures and offered many innovative features.   Since the 1956 consent decree that settled AT&T's antitrust case prohibited the company from entering the Information technology business, it couldn't aggressively sell Unix but it did license it widely to universities and research organizations.  Since the license included source code, many of those licensees made improvements to the software.

I experienced this phenomenon years ago when I was at CCA building the Spatial Data Management System, which included a facility for moving a finite display window over an infinite data surface.  It needed a way to have one process manage the scrolling of the display while a separate one loaded from disk the data just off-screen, similar to how Google Maps works, except that everything happened on one machine.  Since the volume of data was far too large to move through Unix pipes, we needed a way to share memory between processes, a feature not present in Unix at the time.  No problem.  We retained Unix guru John S. Quarterman and he added the feature to the OS for us.  Years later, Unix System V offered a similar feature but we didn't need to wait.

Our experience was hardly unique.  There was a thriving culture around Unix, but with the peculiar licensing arrangements from AT&T, there was no organized, legal way for people to share the innovations.  The situation improved somewhat when UC-Berkeley's Computer Systems Research Group started developing and distributing a version of Unix,  but the Berkeley distributions were still entangled with the AT&T situation.  It was into this breach that Linus Torvalds launched Linux.  Linux was written from scratch, with no code derived from any previous versions of Unix, was available for free, and incorporated code provided my volunteers all over the world.  It became, by most accounts, the most successful open-source software project in history.  As it grew, it also became a target for occasional accusations that some the material provided by all of these volunteers may have been tainted by copyright or patent encumbrances.  The most vocal and well-funded of these accusations came from SCO and had SCO prevailed would have been a serious setback for open source in general and Linux in particular.  If Judge Kimball's ruling stands, and Novell sides with IBM, most of the fear, uncertainty, and doubt this case started will be dispelled and the open source software movement will continue to thrive.

Convoq becomes Zingdom Communications

Convoq, Inc., the company Chuck Digate and I co-founded in 2002, has been renamed Zingdom Communications, Inc.  to reflect our new direction and new product line.  Chuck has moved on, but over the past five years the company built an extremely talented and cohesive engineering team that pioneered the use of Flash and AJAX in real-time audio, video, instant messaging, and other forms of real-time communications.  Our first product, ASAP, put these resources to use in the context of corporate collaboration.  Now we are organizing the company around a new opportunity in more personal, one-on-one communication, concentrating initially on the telephone.

Voice communications have evolved considerably since the days of The Phone Company.  AT&T has been broken up and reassembled and the locus of innovation has shifted away from the traditional providers of local loops to a new wave of companies who offer services that offer new ways of connecting people to each other.  In this new paradigm, connectivity itself has become a commodity, although voice can be transported over the Internet or a wireless connection in addition to the traditional copper, and it is supplemented by instant messaging, SMS, email, and video.  The voice on the other end of the line can be a person or a robot.  In this world, the issues become finding the right person, allowing that person to control his or her privacy, and providing context that helps a person decide whether to answer the phone and be prepared when the conversation begins.

With all the progress that has been made, real-time communications applications are still a challenge to construct and deploy.  Unlike the typical web application which navigates from page to page, a communications app must deal with events at both ends of the conversation.  It's not enough to wait for a screen refresh to reflect that the party at the other end has closed the connection, but building a fully interactive AJAX application is a lot of work.  Our intention at Zingdom is to provide real-time voice communication through a compelling user experience, and to enable partners to provide that same level of experience in their applications without needing to become experts in either telephony or AJAX.  I'll say more about where we came from and were we are going in future installments.  In the meantime, feel free to check out zing.dm.