Monthly Archives: April 2011

The nature of “things”: Mukund Narasimhan’s talk at Facebook

Mukund Narasimhan, an alumnus of Microsoft and Amazon who is currently a software engineer with Facebook in Seattle, gave a very interesting presentation at Facebook’s Seattle offices this week. It was a right-sized crowd, in a right-sized office: just enough people, and the right sort of people to afford interesting conversations, and a very generous serving of snacks and beverages from Facebook in an open-plan office that had the look-and-feel of a well-funded startup.

Mukund isn’t posting his slides, and we didn’t take notes, so this isn’t an exhaustive report of the evening, but rather an overview of some aspects of the discussion.

Mukund’s talk was principally about data mining and the ways that Facebook is able to collate and curate vast amounts of data to create metadata about people, places, events and organizations. Facebook uses a variety of signals, the most important of which is user input, to deduce the “nature of things”: i.e. is this thing (entity) a place? Is this place a restaurant? Is this restaurant a vegetarian restaurant?

Some very powerful data mining techniques have been developed already, and this was illustrated most compelling by a slide showing a satellite image of a stadium: quite close to the stadium, on adjacent blocks, were two place markers. These marked the “official location” of the stadium, as told to Facebook by two separate data providers. The stadium itself was pin-pricked with a large number of dots, each marking a spot where a Facebook user had “checked in” to Facebook’s Places.

The visual contrast was dramatic: the official data providers had each estimated the position of the stadium to within a hundred yards, but the checkins of the Facebook users had perfectly marked the actual contours of the stadium.

Mukund’s talk was repeatedly interrupted by questions from the audience, since each slide offered a gateway to an entire topic, and eventually he ran out of time and we missed some of the material.

During the Q&A, Nikhil George from Mobisante asked a question that seemed highly relevant: was Facebook trying to create a “semantic Web? Mukund sidestepped the question adroitly by pointing out there was no established definition of the term semantic Web, and that is certainly true – the Wikipedia article linked above is tagged as having “multiple issues”– but while Facebook may not be using the specifc protocols and data formats that some might argue are indispensible to semantic Webs, one could certainly make the case that deducing the nature of things, particularly the nature of things that exist on the Internet, is the main point of creating a semantic Web.

While much of the Q&A was about technical matters, a more fundamental question occupied our own minds: at the outset, Mukund asserted that the more people interact with (and, in particular, contribute to) Facebook, the better the Facebook experience is for them and all of their friends.

This, clearly, is the underpinning of Facebook’s business model: people must continue to believe, on a rational basis, that contributing data to Facebook – so that Facebook can continue to deduce the nature of things and offer these things back to their users to consume – offers some direct, reasonably tangible rewards for them and their friends.

Presumably, then, Facebook must be taking very concrete measures to measure this sense of reward that their users experience; we didn’t hear much about that last night since that wasn’t Mukund’s area of focus, but it must surely be well understood within Facebook that the promise of continued reward for continued user interaction – which is essentially their brand promise – must be kept at all times. Has a lot of research been done in this area? (There is, of course, the outstanding research done by dana boyd on social networks in general.)

At a more practical level, a question that bedevils us is how we can improve the signal:noise ration in our Facebook Wall! In our physical worlds, we all have some friends that are exceptionally chatty: some of them are also very witty, which makes their chatter enjoyable, but some are just chatty in a very mundane way. In our Facebook worlds, it is very easy for the chatty people (are they also exceptionally idle or under-employed?) to dominate the conversation.

In a physical world, if we find ourselves cornered by a boor at a party we would quickly, determinedly sidle away and find someone more interesting to talk to, but how does one do that in Facebook? One option, offered by Mukund, would be to turn off their posts, which seems rather like “unfriending” them altogether. But we don’t want to unfriend these people altogether, we just don’t want to hear every detail of every day.

Mukund suggested that by selecting hiding individual posts, as well as “liking” others more aggressively, we could send clearer indications of preferences to Facebook that would help the system improve the signal:noise ratio, and that’s what we have been trying over the past few days.

It is an intriguing topic to consider, and undoubtedly a difficult problem to solve, because you need to weed out individual messages rather than block entire users. For example, one Facebook friend used an intermission of the movie “Thor” to report that he was enjoying the movie. It’s great that he is enjoying the movie, but this low-value update spawned a low-value thread all of its own. We don’t want this person blocked altogether; we need some way of telling Facebook that updates sent during movie intermssions are not very valuable. If Facebook misinterprets our signals and relegates him to the dustbin, we might miss a more useful notification in the future, such as a major life event or career move.

The problem seems analogous to developing a version of Google’s PageRank, but at the message level. In the example above, if a post sent during a movie intermission is of low value, it would affect the ranking of everyone who piled on to create its low-value thread.

People like us who are more technical would probably prefer a more direct way of manipulating (i.e. correcting) the signal:noise ratio. Presumably someone at Facebook is working, even as we write this blog, on some visual tools that provide sliders or other ways for people to rank their friends and notifications. One idea that comes to mind might be a sort of interactive tag cloud that shows you who posts the most, but which also lets you promote or demote individual friends.

Some email clients and collaboration tools assume that people who email you the most are the ones that matter the most, but with a social network, wouldn’t this bias have the opposite effect? Wouldn’t the most chatty people be the ones who have the least to say that’s worth hearing?

One piece of good news from Mukund is that Facebook is working on a translator: one of our closest friends is a Swede, and his posts are all in Swedish which makes them incomprehensible. Having a built-in translator will certainly make Facebook more useful for people with international networks, although it will be very interesting indeed to see how Facebook’s translation deals with the idiosyncrasies of slang and idiom.

Update: we got it wrong. Facebook isn’t working on a translator; Mukund was referring to a third-party application.

One topic that particularly intrigues, but which we couldn’t raise with Mukund for lack of time, was Paul Adam’s monumental slideshare presentation on the importance of groups within social networks. Paul argues that people tend to have between 4-6 groups, each of which tend to have 2-10 people. (This is based upon the research behind Dunbar’s Number, which posits that there is a limit to the number of friends which whom one can form lasting relationships, and this number is around 150.)

Facebook still doesn’t have groups, which is surprisingly since Paul Adam decamped Google for Facebook soon after making his presentation available online. It is a massive presentation, but fascinating material and surprisingly light reading: just fast-forward to slide 64 and the picture there sums up the entire presentation rather well.

Update: we got that wrong, too. Faceb0ok does have a groups product, and it is becoming increasingly popular within the company itself

All in all, one of the most enjoyable presentations we have attended in recent days. Mukund needs special commendation for his fortitude and confident good humor in standing up before a savvy crowd and braving any and all questions about Facebook’s past, present and future.

Seattle’s “evening tech scene” is really getting interesting these days: perhaps we are seeing the working of a virtuous cycle where meetups and other events start to “up their game”!

Up next: a replacement for the Google Docs Gadget

The current version of Kerika uses an embedded Google Docs Gadget, that’s part of the Sidebar within the application. There’s no polite way to describe this software, which comes in four different flavors from the mighty Google itself; let’s just say that the technical term for it is “p.o.s. software”.

A Google Docs Gadget is supposed to be something that you can easily embed within a website or application: it supposed to provide easy, direct access to your Google Docs from within your site or Web App. There are at least four official Google Docs Gadgets out there:

  • There’s this one from “Claudia C. and Ted C.“, both employees at Google – as you can easily see by viewing the XML code for this Gadget. It doesn’t work, which probably explains why Claudia and Ted are coy about revealing their last names. And when we say it doesn’t work, we don’t mean that it has some subtle bugs that are unlikely to surface for most users: just visit this Gadget, at Google’s own official website, and try setting the number of documents to show in the list. It doesn’t work.
  • Here’s another one: presumably a later one than the first, since it’s authorship is attributed to “Claudia C. and Ted C. Modified by Gordon Bunker”. We don’t know who Mr. Bunker is, but he couldn’t get Claudia and Ted’s Gadget to work properly either.
  • Here’s a third one: also the work of Claudia C and Ted C. This one is hilariously broken: just visit the link that says “Add to your home page” and you see the helpful message “Error parsing module spec: Not a properly formatted file missing xml header”. So, here we have an example of two Google employees, hosting an official Google Gadget, on Google’s own website, that is completely broken…
  • Finally, we have this one, attributed to “Claudia C., Ted C., and Sam B.”. Sam, like Claudia and Ted, found it wiser not to disclose his last name given he somehow managed to reduce the utility of the original Gadget.

So, there you have it: four different, official versions of the embeddable Google Docs Gadget, none of which work… The situation became untenable for us because with the latest version of Google’s Chrome browser, the drag-and-drop function stopped working altogether. No small irony here, that Google’s own browser doesn’t work with their own Gadgets, when Firefox’s drag-and-drop continues to work.

We can’t fix these Gadgets because they were built by Google employees; instead, we are building our own replacement for this Gadget which we expect to release this weekend. It’s simple, functional and reliable. It will let you perform a search across all your Google Docs, and drag-and-drop results from this search straight onto your Kerika pages. And, it will work on all browsers.

A single-click if you are under 35, a double-click if you are over 35

When we first built Kerika, we deliberately modeled the user interface using the desktop application metaphor: projects were organized in folders, and mouse actions were as follows:

  • Select an item on the page with a single mouse click.
  • Open (or launch) an item on the page with a double mouse click.

It seemed the most natural thing in the world to us: everyone on the Kerika team liked it, and we assumed that our users would like just as much.

So it came as a very considerable surprise to us when we observed a generation gap among our beta users, in terms of what they considered to be the most natural way to open and launch items.

The breakpoint is roughly at the 35 years-old mark: people older than 35 had a strong preference for the double-click metaphor, and people under 35 had an equally strong preference for the single-click metaphor: where you select an item with one gesture, and then you select the action you wish to take from a menu that pops up.

The preference grew almost exponentially in intensity as you moved away from the 35-year breakpoint: people in their 50s, for example, had a very strong preference for double-clicking, while people in their early 20s were, for the most part, surprised by the notion that a double-click might do anything at all.

Our theory for this phenomenon is simple: roughly 15 years ago, the Netscape browser came into wide use. People who are older than 35 started their careers before the Web, and first learned to use desktop applications before learning to browse the Web. People under 35, on the other hand, probably first learned to use computers by surfing the Web at college.

(You might guess from all this that the Kerika team’s average age is well over 35, because it never occurred to us that the double-click metaphor might be strange or unappealing to anyone.)

At any rate, Kerika now supports the single-click metaphor exclusively – at this time. The initial feedback we got from our beta users was skewed by the younger demographic, and this caused us to reluctantly abandon the double-click in favor of the single-click. However, we are now hearing more from older users, and a future version – very soon! – will support both the single-click and double-click metaphors.

And while the Kerika application doesn’t run completely smoothly on iPads – for one thing, the Google Docs application doesn’t really run on iPads – supporting the single-click metaphor positions us to ensure that Kerika will run, intact, on tablet computers in the near future.

Use AT&T: it will boost your self-esteem

When you are in a startup, you always a sense of frustration that you haven’t been able to deliver all of your wonderful vision. Of course, it could happen in a big company as well, if you are really passionate about your job, but in a startup it happens all the time because entrepreneurs are wildly, dangerously passionate about what they do!

All the compromises that you had to make because of time and money constraints, the features you were forced to postpone, and this nagging sense of embarrassment that your 1.0 wasn’t all it could have been: “If only I had had more time and money, I could have built all these other cool features for our first release” you say to yourself.

If you ever feel a little depressed about the state of your version 1.0, there are two ways to boost your self-esteem and feel re-energized:

  • Remember the experienced entrepreneur’s mantra: “if you aren’t embarrassed by your first version, you have waited too long to ship“. We are not sure who coined this phrase – it’s been attributed to a number of people over the years – and there’s a great post called “1.0 is the loneliest number” that makes the case for shipping early, warts and all, and then iterating fast in response to customer feedback.
  • The other way to quickly start feeling better about your product is to visit the AT&T website to do something relative straightforward, like adding money to a pre-paid phone. The user experience that AT&T provides is guaranteed to make you feel better about your own product.

First, we kill all the managers. (Or, maybe not.)

In earlier posts we described our decision to chose Amazon’s EC2 over Google App Engine in recent days, and as part of the business perspective we noted that:

Amazon is accessible: both Amazon and Google have engineering centers in our neighborhood, and Amazon’s is, of course, the much larger presence, but the real issue was which company was more accessible? Amazon does a lot of outreach to the startup community in the Seattle area – Jeff Barr is everywhere! – whereas Google is a lot more aloof. It’s much easier to find an engineer or product manager at Amazon who will talk to you, and that really makes a difference for a startup. Real people matter.

Events in the past week have reassured us that we made the right choice. The very end of that post on choosing EC2 included a passing grumble about some long-standing problems with Amazon’s Elastic Load Balancer.

What happened following that blog post was a pleasant surprise: an old colleague saw the post on LinkedIn and forwarded it to someone at Amazon, who promptly contacted Jeff Barr, the peripatetic and indefatigable evangelist for Amazon Web Services.

And within just one day after our griping, Jeff asked for a meeting with us to see how Amazon could make things better for us. This level of responsiveness was, frankly, astonishing when one considers the size of Kerika (rather tiny) and the size of Amazon (rather Amazonian).

We met Jeff today, and are happy to report that this ELB issue will soon go away for us and everyone else. But that was a minor aspect of the meeting: much of our discussion was a wide-ranging conversation about Kerika, collaboration platforms and the many uses for cloud computing in different market segments.

And the best part was finding out that Jeff had taken the trouble, earlier in the day, to try out Kerika for himself.

Returning from the meeting, we couldn’t help but reflect upon cultures of the two companies that we are relying upon for our business model: Amazon and Google. Amazon is providing the cloud computing infrastructure, and Google is providing the OpenID authentication and, more importantly, the Google Docs suite that is integral to the Kerika product offering. Both sets of technologies are essential to Kerika’s success.

But the cultures of these two companies are clearly different: Amazon relies on both technology and people, whereas Google, it would appear, is purely an online presence. (To be fair, we must note that while both companies have engineering centers in the Seattle area, Amazon’s footprint is many times larger than Google’s.)

But, still: who could we have tried to reach at Google? Who is the public face of Google’s App Engine? Or, of Google Docs, for that matter? There are two substantial Google engineering centers nearby, but Google the company remains a cloud of distributed intelligence – much their servers – accessible only via HTTP.

A recent article at All Things D speculates that Larry Page may eliminate Google’s managers in large amounts, in order to free the animal spirits of the engineers, and a similar article on TechCrunch notes that “Page famously has a low opinion of managers, especially product managers who try to tell engineers what to do.”

There can be no gainsaying Google’s engineering talents, or its remarkable achievements, but will Google 3.0 be an organization that has even less human contact with its customers and partners?

Jakob Nielsen’s Power of Ten Principle

We like to think that we have done a fairly good job in terms of designing our user interface. A major influence was the writings of Jakob Nielsen: Kerika’s CEO had the good fortune to meet Mr. Nielsen at a conference in the mid-90s, when corporate America was slowly waking up to the reality – and permanence – of the Web, and Mr. Nielsen just been laid off from Sun Microsystems, which, in its infinite wisdom, decided to get rid of their entire Advanced Technology Group as a cost-savings measure.

Mr. Nielsen fast became a popular speaker at the few Web conferences that were held in the early days, and one could listen to his speeches practically for free. (Now, we understand, it costs about $15,000 to get Mr. Nielsen’s attentions for a single day…). Mr. Nielsen went on to found the Nielsen Norman Group, with Donald Norman who had done pioneering work on product design, and he created a simple newsletter-based website (www.useit.com) that remains a wonderful source of research on Web usability.

What was remarkable about Mr. Nielsen’s approach then, and which we think still is a relatively rare ability among the many design pundits today, is a rigorous emphasis on scientific observation and testing. Mr. Nielsen has never given the impression of being someone who has relied very much on his instincts when it comes to design; he has always emphasized the need for usability testing.

Too many other “pundits” – and here we use that phrase in the American sense of a talking head, rather than the Indian sense of a priest or wise man – rely upon what they believe, often erroneously, to be a superior design aesthetic which they deftly package with enough jargon to make it appear more like fact than opinion.

(Today, we have a beta version of Kerika that we are using to gather usability data: we are sitting down with our initial users, directly observing their reactions – their many sources of confusion and occasional moments of delight – to see fine-tune our user interface. We believe we have done a good job on the main aspects of the design, but there are many rough edges that we still need to sand over, to get the “fit-and-finish” just right. So, while we are immensely proud of what we have accomplished – and the tens of thousands of lines of Javascript and Java code we have written in a remarkably short period of time – we are only too aware of our shortcomings as well…)

Mr. Nielsen writes mostly about website usability, but his observations and principles are very apropos to the design of Web applications as well. We have tried to incorporate his suggestions on perceived affordance and information scent in the various elements of our user interface, but when we expand the discussion from UI to UX – from user interface to user experience – it is clear that performance is a key contributor to an overall good experience.

In his article on the “Powers of Ten” principle, Mr. Nielsen points out that 0.1 second is the response time limit if you want users to feel like their actions are directly causing something to happen on the screen. If a system responds within 0.1 seconds, the system essential disappears from view: the user believes he or she is directly manipulating the objects on the screen.

(A simple analogy is the mouse: when one moves the mouse, the cursor moves immediately on the screen, which is why it is so easy to learn to use a mouse: one quickly forgets its presence altogether, and concentrates upon looking at the screen instead. We often see people who hunt-and-peck at their keyboards; when was the last time you saw someone look down at their mouse to make sure they were moving it correctly?)

To that end, we have tired to ensure that most user interactions when using Kerika fall within the 0.1 seconds time limit: when you add an item to a page, or move it, or delete it, it happens instantly.

Next up is the 1 second time limit, and here we quote Mr. Nielsen:

When the computer takes more than 0.1 second but less than 1 second to respond to your input, it feels like the computer is causing the result to appear. Although users notice the short delay, they stay focused on their current train of thought during the one-second interval.This means that during 1-second response times, users retain the feeling of being in control of the interaction even though they notice that it’s a 2-way interaction (between them and the computer). By contrast, with 0.1 second response times, users simply feel like they’re doing something themselves.

In the Kerika user interface, there are moments when a user will experience a 1 second response time, although not very often: most commonly, this happens when we are waiting for an external website to respond. For example, if you have built a “video wall” of YouTube videos, you may have to wait a second (or two or three) for YouTube to respond when you decide to play a video. This, regrettably, is out of our control. But for the parts of the user interface that are within our control, we have tried to stay within the 1 second time limit.

After 1 second, users get impatient and notice that they’re waiting for a slow computer to respond. The longer the wait, the more this impatience grows; after about 10 seconds, the average attention span is maxed out. At that point, the user’s mind starts wandering and doesn’t retain enough information in short-term memory to easily resume the interaction once the computer finally loads the next screen. More than 10 seconds, and you break the flow.

Nothing, in Kerika, breaks the flow.