esjewett.com

Laura Fitton's post on tools she'd like to see for Twitter got me thinking about a related problem in aligning attention and interest, so I'd like to add to her list. The problem: It's hard, though not impossible, to align the attention a given blog/tweet/IM/email demands to the interest we have in it.

As an example, take myself and three of interests that I occasionally mention on Twitter.

The set of people that are actually interested in all three of these things is pretty minimal, and that's just a sampling of three things I mention on a regular basis.

Twitter's approach to this issue is to minimize the attention that everything receives. That seems to work pretty well for Twitter. Other systems (I'm looking at you Email) tend to maximize the attention that every message receives. Some systems make an attempt to match attention to interest and I'd like to see more of that type of work either as built-in features or as add-ons facilitated by an API.

We're starting to see some movement in this area among collaboration and knowledge management vendors. There are also tentative steps from social sites like Ma.gnolia.

Let's also remember that this is personal. The relative importance of any given piece of information is different for you than it is for me. So this approach is especially important in our personal communications software, be that software a feed reader, an email client, or an service like Twitter.

Twitter is a big ol' international hodgepodge of communities, conversations, and observations to the tune of 700,000+ active users.  Being international, it also tends to be multi-lingual.  Herein lies a problem: I can't understand, say, Arabic.  Or French or Japanese for that matter.  In our brave new world of computerized , automated everything, there's no technical reason these conversations can't be translated on the fly, if only we had a little metadata.

Metadata, in this case, would be data about the language someone is tweeting in.  You see, from a consumer perspective the real problem of automating translation isn't the translation part.  Google and Yahoo! have that pretty well nailed on the level of 140 character tweets that often appear to have been run through a translation program anyway.  The problem is figuring out, automatically, the language of the post and the language it should be translated into.

Enter Twitter nanoformats.  Nanoformats are closely related to microformats.  So closely related that they even live on the Microformats wiki.  Anyway, nanoformats are little pieces of text you can insert into tweets and other things to provide some sort of metadata, like location, tags, or (surprise) language.  The language nanoformat consists of the string "lang:" followed by the iso 639-1 code for whatever language the Tweet is tweeted in.

In order to enable auto-translation, a Twitter user would have to do two things.  First, our user would insert a lang nanoformat in their own bio to indicate the language they normally tweet in.  This bio nanoformat will also be used to figure out the language our user would like to receive other tweets in, so choose wisely.  Second, our user would insert a lang nanoformat in tweets they make that are not in the language their bio indicates.

So, for example, I normally twitter in English, so my profile indicates that with the "lang:en" nanoformat.  But if I tweet something in Spanish, I would add the "lang:es" nanoformat to that tweet.  (Don't worry, I won't subject you to any Spanish tweets, notwithstanding the example below.)

Okay, here's how it works

Now that we've done all that groundwork, the magic can begin.

Warning, the following paragraphs contain forward-looking statements.  No client actually does this stuff yet, though it's conceivable that I am under-informed on that point.

When I fire up my Twitter client and log in, the client checks out my bio and sees that I want my posts in "en", which means "English" in ISO-ese.  We'll call this imaginary client Litter, but we could just as well call it Twhirl, Snitter, Tweetr, or Twitterific.

Now, whenever Litter sees a tweet, it checks the tweet for the lang nanoformat and if it finds one, and it isn't "lang:en" it makes a quick call to http://translate.google.com to translate the tweet, sans nanoformat.  If the client doesn't find a lang nanoformat in the tweet, it should check the bio of the person the tweet belongs to for a lang nanoformat and perform the same call.

So the tweet "Hablo español lang:es" would result in the following call in my Litter client:

http://translate.google.com/translate_t?text=Hablo español&langpair=es|en

Click that and see what comes out.

What happens next involves some screen scraping of dubious legality, but maybe some agreement can be reached.  Anyway, Litter then pulls the result of this query out of the HTML mishmash it receives back.  It provides that translated result as the content of the tweet.

A little discussion goes a long way

There are a lot of reasons this won't work.

First of all, there is a 70 request per hour limit on the Twitter API.  Litter would exhaust that limit in about 5 minutes if it were trying to translate every tweet in the stream I receive.  As a result, I suggest that the translation function be implemented with a manual trigger, at least initially.  The imaginary Litter allows a user to right-click on a tweet and choose "Translate" from the context menu.

It also appears Google's terms of use don't allow this sort of use of the Google Translate service.  Similarly Yahoo! doesn't appear to allow this use of Babelfish.  However, there are a lot of dubious uses of these sorts of tools, so maybe we can come to some sort of agreement.  In the meantime, a working proof on concept would be pretty neat.

Lastly, there should always be some way to easily get at the original tweet within the client, just in case something goes horribly wrong in the translation.  This is technically an opt-in system, since it won't work on a person's tweets if they don't use the nanoformat, but we should still be considerate.

Despite these hurdles I'm certainly looking forward to this type of functionality becoming common, and not just on Twitter.  I know others are as well.  What do you think?  How can we make this happen?

Privacy controls are an area of continuing concern in social applications. Michael Krigsman has hit on the point in a sensationalist manner on his IT Project Failures blog in a post titled Twitter is Dangerous. I think Michael is off-base because I think Twitter gets it right by keeping it simple: Your stuff is either private or public. It's hard to misunderstand that.

The important thing is that users of a given system clearly understand the privacy implications of entering data into that system. In order for this to happen, the user interface and explanation within the application have to correspond with the terms of service and technical platform. As I said, I think Twitter gets it right, but others may disagree.

We see a more muddled case with the recent addition of social sharing in Google Reader. Google could have done better with the initial launch of this feature, but to the credit of the Reader team, they got the message and fixed the problem. For the interaction design nerds out there, I think that the problem here was actually not with the sharing feature per se, but with a user/developer disconnect around the privacy implications of "Sharing" an item via a publicly indexed feed with an obfuscated URL. Many users thought of the feed as private while I'm pretty sure the Reader developers thought of the Shared items feed as public.

Let's wend our way to the point of this post, which amazingly enough isn't Facebook's Beacon. No, I'm going to talk about the Plaxo Pulse and a conversation I've been having with John McCrea on Twitter. The situation is that I, apparently, had a misconception about how Plaxo shares my Pulse items when I elect to make them "Public".

Specifically, I thought that making a feed "Public" would broadcast it to all of my Plaxo Connections. Connections on Plaxo are like Facebook Friends, both they and I have to agree to being connections. When you make a connection, you categorize the contact as any combination of business, friend, or family. As such, I assumed that I had exact knowledge of who would receive my Plaxo Pulse broadcasts, though I recognize that the material being broadcast is totally public for anyone who actually looks for it.

I was wrong. What actually happens is (apparently) that anyone who uses Plaxo and has me in their address book receives a broadcast in their Pulse feed of entries I set as "Public". In other words, I have no idea who I'm spamming with these entries.

At the risk of sounding self-righteous, I'm going to blame the Plaxo user interface for this one. (Whew, I feel better already.) Here's why:

1. The copy reading "choose which of your connections ..." clearly indicates that I'm choosing which Connections have permission to see the feed. Plaxo creates a strong division between the Pulse feature and the Address Book feature in their documentation (for example) so when Plaxo says "Connections", I assume they mean it. There is an expectation of consistency in copy across a site.
2. When "Public" is checked, it automatically checks and grays out the business, friends, and family options, creating the possibility that "Public" corresponds to "All of the above" or "All connections". This interpretation is clearly ambiguous and draws on my (fairly common) experience with HTML check-boxes and multiple choice tests, but any ambiguity is probably a bug in a scenario like this one.

I'll be clear that no damage was done here and all of the Pulse feeds I share are public information, so Michael Krigsman can rest easy. For me this is an academic exercise. But it is conceivable, for example, that a client who has me in his or her address book and uses Plaxo was getting spammed by my tweets and del.icio.us bookmarks 10-15 times per day. I'm a pretty public person, at least online, but I prefer to allow people the choice of whether they want to subscribe to a steady stream of my random thoughts. As such, I've un-Publicized all of my Plaxo Pulse feeds. If you want to see 'em, Connect with me.

I think this is a good example of one thing that can go wrong while designing and changing privacy settings. The complexities are similar to other UI problems, but the ramifications in this area are often invisible to the user and the consequences of misunderstanding could be severe. Combined, these two ingredients put the user at the mercy of the developer and this trust should be respected by taking care in design decisions and testing against real user expectations.