Blog

Read/WriteWeb has an interesting article about a new phone service called fonolo. 
The basic idea is that the fonolo web site provides a navigable
interface for a bunch of different companies that have deep phone menus
(“press 1 for …”).  You select the part of the company you want to
speak to on fonolo’s web site.  Fonolo then calls the site, and calls
you back once they’ve reached the part of the company you want to talk
to! 

Sounds like a cool hack … but the long-term solution is to have much
better navigation and naming in the phone system.  This solution
reminds me of the early days of the Web, when Gopher — developed here
at the University of Minnesota! — was a significant competitor.  One
of the problems with Gopher is that it had no naming system beyond the
site.  To tell someone how to find a Gopher resource, you would tell
them the location of the site, and then tell them a bunch of menu
choices to make to get where they wish to go.  By contrast, of course,
the Web has a rich namespace in which nearly every accessible page has
a unique name.  You can direct someone to a Web page by just giving
them the URL — which takes them directly there, with no navigation.

The phone system is still in the bad old days: each company has a phone
number, and then you need to follow a path from that phone number to
the resource you wish to access.  Companies like fonolo (and GetHuman)
will do the navigation for you.  But this is window dressing on a
broken system.  Really, once we’ve looked up the resource we wish to
access, we want the equivalent of an URL that will take us right
there.  Re-engineering the phone system to support such a service will
likely be difficult; perhaps internet telephony can get us there first.

Note that there is no financial conflict here between the companies and
their customers.  It is true that the companies prefer to use phone
menus to get people to information, rather than have a human
representative read the information (because it’s much cheaper to have
the customer navigate the phone menu than to have a human
representative do the navigation for them).  However, the company would
be happy to have its customers connected to their information more
quickly.  Doing so would just reduce phone costs further.

Of course, an alternative would be for the phone system to stop being
used for this sort of information.  For instance, on an iPhone,
customers can access the web site rather than dial the company.  There
are many situations, though, in which a voice interface is more
convenient than a screen interface.  For these situations, a better
“PhoneURL” would be useful for everyone.

John

Fascinating article on the limitations on running J2ME apps on the major US cell phone carriers. The bottom line:

• Verizon makes J2ME impossible
• T-Mobile makes standalone J2ME easy, but requires a signature from T-Mobile or a more expensive plan if you want to write a networked app
• AT&T is the most open: apps that wish to use HTTP can use it. (Lots of other apps that also interact with handset data, like the address book, must be signed)
• Sprint is similar to AT&T, though rumor has it that getting your app signed may be easier
• Nextel (which is owned by Sprint, but is a different network) requires that the app either be on the Nextel portal, or that you download it through a cable.

Overall, this means that experimentation with the really interesting J2ME apps that are likely to change the world is difficult to do outside of companies that have marketing relationships with the phone companies. This approach to a closed platform seems likely to cramp creativity. Why not turn the platform loose, and let millions of apps develop, ala Facebook? (There are serious concerns here about security: the first phone virus to wipe out a carrier’s network is going to be intriguing. But: it seems important that we think carefully about how to provide sufficient security without sterilizing the platform.)

John

We’ve been exploring the effects of conflict among the editors of Wikipedia pages. As part of that research, I’ve been looking for Wikipedia talk page activity surrounding conflict events. I find the discussion between editors and their motives (expressed or apparent) gives insight into how conflict events grow and affect the participants.

A rather interesting example that I followed for the last couple of days is a conflict over the inclusion of content in the article about COMET, a web architecture paradigm. This particular conflict can be characterized as “inclusionists vs. deletionists“. One side wants all possible information to be available; the other side wants all content that doesn’t fit the strictest standards to be removed. The two opposing views are characterized by their preferred versions of the article (inclusionist – deletionist).

One especially interesting characteristic of this particular conflict is the way that the request for comment was handled. A link to the diff between the inclusionist and deletionist versions of the page was submitted to reddit.com (a news aggregation site) where the link was promoted quickly to the front page. Whereas it is much more common to simply ask other Wikipedia members to get involved in the discussion, this approach brings in a wider audience and shows them the side of Wikipedia that, usually, only dedicated editors care to see.

If you have the energy, I recommend looking through the request for comment section of the talk page. This discussion is a fascinating example of how editors from around the world, that work for free, can hold a reasonable discussion about what does and does not belong in an encyclopedia.

Scientific American has some fun examples of people who have been doing spamming the blogosphere. They create an identify that in some way conceals their ulterior motives, and then post blog comments or posts that push their agenda.

Google has announced that they are providing versioned hosting of the major AJAX libraries. Very cool! They’ll put the libraries on their servers, so they’re fast to access from anywhere in the world, and they promise to keep all versions going forward, so you can always get the one you want.

The big win, according to the article, is that browsers will already know that they have a version of a library if many apps use the same libraries from the same host. In that case, the browser won’t even have to download the library when the app requests it.

My favorite quote from the discussion: “Is this charity, or world domination?”

John