« June 2011 | Main | August 2011 »

July 28, 2011

Google Plus: On Trust, Reputation, Pseudonyms, and Value

Much has been made over the choice Google made to require real names, rather than pseudonyms, for Google+ users. There has been speculation that Google did it to increase the value of a user for advertising purposes. While I agree it was done to increase the value of a user, I don't agree is simply about advertising (although there is that).

To start, let's talk a bit about reputation. Consider the following diagram from a paper by Mui et al entitled A Computational Model of Trust and Reputation:

The relationship between reputation, trust, reciprocity, and social benefit

We define reputation as the perception that a person creates through past actions about her intentions and norms. Trust is a subjective expectation a person has about another's future behavior based on the history of their encounters. Reciprocity is a mutual exchange of deeds (such as favor or revenge). Social benefit (or harm) derives from this mutual exchange.

If you want to build a system where entities can trust one another, you need a system where reputations can be created since reputation is the foundation of trust. And reputation depends on identity. You cannot have both privacy and reputation since establishing one necessarily diminishes the other. If we are to build a perception about a person's actions, we need to know who that person is.

You're probably thinking, "yeah, but I can build a perception about a pseudonym as well as a real name" and you'd be right. There's just one problem. In a paper entitled The Social Cost of Cheap Pseudonyms, Friedman and Resnick argue that pseudonyms are single-sided: positive reputation's stick but negative reputations don't. You can see why: people just dump any pseudonym that has a negative reputation.

Real names are more valuable than pseudonyms because they more strongly encourage people to behave well and the result is increased social benefit. In the case of a platform like Google+, users perceive that your system is creating more social benefit if there are stronger reputations that lead to more trust that encourage positive reciprocal acts. For example, real names reduce spam because your reputation as a spammer is going to follow you. You can't just create identifiers willy nilly, use them until they acquire to much baggage and dump them.

There are downsides, of course. Negative reputations don't stick to pseudonyms because its easy to just "start fresh." Heaven knows that the Internet has allowed many people to be someone online who they could never be offline. There are discussions that people are more likely to engage in when they are pseudonymous.

I believe Google's policy requiring real names is an architectural decision aimed at fostering a particular kind of social interaction and excluding others. They may change it at some point, but for now requiring real names is likely going to make Google+ a different place than Twitter even though both allow asymmetric follow. The overall value of the platform--not just for advertising, but in how much people use it and what they use it for--will be higher as a result of the policy.

10:46 AM | Comments () | Recommend This | Print This

July 20, 2011

The StackExchange Podcast is Back on IT Conversations!

StackExchange Logo

A while back Jeff Atwood and Joel Spolsky discontinued the StackOverflow podcast ending what was one of the most popular shows on IT Conversations.

Jeff and Joel recently started back in, calling their new effort the "StackExchange" podcast in recognition that their franchise has expanded beyond simply StackOverflow. I'm pleased to announce that we'll be carrying the StackExchange podcast on IT Conversations.

I just published this week's show Episode # 12. We'll get the previous episodes on the server and linked to the series page soon. Here's the description from this week's show:

This week, Jeff and Joel are joined by Patrick McKenzie - StackOverflow contributor, internet commentator and SEO expert (especially when it comes to driving traffic for bingo cards). After a few early tech issues we jump right into things, with tons of discussion covering everything from creating bingo cards to optimizing question formats. Also - how much does upvoting someone's first question make them more likely to come back? Tune in to find out.

2:40 PM | Comments () | Recommend This | Print This

July 11, 2011

Getting Good Descriptions When Sharing on Google Plus

Mi Blog !

Recently I've ben playing with Google Plus (G+) a lot. I noticed when I shared items from my blog, however, that the decscription that G+ grabbed automatically wasn't very good. Turns out it's getting the description from the meta item named description in the header. My blog was setting that to a static string.

I don't know if I just have a bad set of templates (could be--they're old and I've hacked them a lot), but mine didn't put anything about the blog entry in the detail page's description. I use MovableType, so I put the following in the HTML header in the Individual Archive template:

<meta name="description" content="<$mt:EntryExcerpt$>" />

MovableType's EntryExcerpt tag is smart in that if you've filled in the "Excerpt" box when you create the entry, it will use that. If the "Excerpt" box is empty, MT generates one from the first N words of the blog entry body. I usually just leave it empty, but I'll start using it now if the first paragraph isn't as descriptive as I'd like.

So, now my blog entries are more sharable on G+. Who know's, it will probably help them be more findable in search results too.

2:24 PM | Comments () | Recommend This | Print This

Using Schema.org Microdata in KRL

[]

In my blog post, Anonymous eCommerce: Building a Real 4th Party Offer Application with Kynetx, I mentioned that I used HTML Microdata in the form of a Schema.org product microdata as the means of getting product data from the page to the app. A few people have asked for more details on that.

Microdata, like microformats and RDFa, is a means of encoding semantic mark-up inside HTML. I'm not going to try to take a stand on which is better for a particular job (see the results of a microdata vs microformats vs rdfa" if you're curious). Suffice it to say that the Schema.org product microdata met my needs and I went with it.

The idea, for the app I was building, was that the app would place a "want" button on product pages and when the shopper clicked it, the product data would be sent with the click event as attributes. To do this in a general way required programmtic access to the product data. I could have assumed that everyone had a product API, but that's not very general--the app would only be able to work on sites that had been integrated with it. A more loosely coupled solution needs a standard way of getting product data and the Schema.org product microdata is a good answer. Any site can easily add it by updating their product templates and then it's immediately available. Given that Google and others have announced that they'll use microdata to determine relevancy for search results, it's not a stretch to imagine that ecommerce sites will mark up their pages with more semantic data.

I was fortunately to find a jQuery plugin for processing microdata that Philip Jagenstedt wrote. I modified it slightly for my purposes:

  1. I put two files juery.microdata.js and jquery.microdata.json.js together by putting the function in the second into the first.
  2. I modified them to work with the KRL runtime by wrapping them in a closure that is applied to $K so that they extend the KRL runtime-included copy of jQuery.

The final result was included in the KRL ruleset by adding the following line to the meta block:

use javascript 
        resource "http://www.windley.com/want/jquery.microdata.js"

We place the "want" button on the page using a KRL action:

after("#buy_button", want_button);

But rather than using the watch action to attach a listener to the button, I emitted the following JavaScript:

emit <<
$K("#want_button").click(function(){
  var jsonText = 
       $K.microdata.json("[itemtype='http://schema.org/Product']");
  var prodprops = jsonText.items[0].properties;
  var offer = prodprops.offers[0].properties;
  var seller = offer.seller[0].properties;
  app = KOBJ.get_application("a16x108");
  app.raise_event("product_found", 
                  {"prodname":prodprops.name[0],
                   "modelno":prodprops.model[0],
                   "produrl":prodprops.url[0],
                   "price":offer.price[0],
                   "shipping":offer.shipping[0],
                   "seller":JSON.stringify(seller.name[0], 
                                            undefined, 2)
                  });
});
>>

The final two lines in this JavaScript raise an event to the KRL engine called product_found when the "want" button is clicked. The event attributes are gathered using the microdata library. We get the JSON text using the $K.microdata.json function referencing the nodes in the DOM that have an attribute named itemtype that has the value http://schema.org/Product.

The reference returns an array of items that have the right itemtype. In my case, I only cared about the first, so I'm referencing items[0]. Note that the data is arranged hierarchically in a manner that matches the Schema.org product microdata specification. I get the product properties from the first time, get the offer from that and get the seller from the offer.

The rule that responds to the product_found event merely pulls the data from the event attributes

rule process_product {
  select when web product_found
  pre {
    price = event:param("price");
    shipping = event:param("shipping");
    final_price = price+shipping;
  ...
  }
...
}

If more sites start encoding semantic data in microdata, I'll be tempted to find a generalized way of allowing access inside KRL The easiest way to do this would be to allow for a microdata specification in the watch action and then just return all the JSON for processing inside KRL using JSONPath expressions. I'd also like to enable discovery, so an event is raised when microdata is found and why kind. That way, for example, you might automatically place a "want" button on any page that has product microdata.

11:58 AM | Comments () | Recommend This | Print This

July 8, 2011

Google Plus Comment Filter

Plus Comment Filter

One of the things I dislike about the G+ streams is the way comments are handled. For most people it's OK, but for folks like +Robert Scoble and +Jesse Stay who have tons of followers, they're comments come in fast and furious making it tough to even scroll past their posts to see what's below.

I'm used to having things my way, so I wrote a Kynetx app that hides the comments. In their place it puts a link with the number of recent comments. Clicking on the link shows the comments. The link is a toggle, so clicking again does what you'd expect and hides the comments.

This makes it easy to scroll down, find the posts I'm interested in, and--if it seems interesting--look at the comments.

This is a Kynetx App, so it works inside the Kynetx Browser (KBX) extension. If you already have KBX, getting the +Comment app is easy. If you don't the KBX will be installed as part of the app installation (then you can check out the other cool Kynetx apps too). Because it runs inside KBX, the app will work on Firefox (even 5), Safari, and Chrome. If you really want it for IE, let me know and I'll generate one.

Try it out and let me know what you think.

11:22 AM | Comments () | Recommend This | Print This