Hello there

The set up of Plurk organization is very unique. Everyone works remotely. Is it true that you have never met one of your co-founder, Amir?
Yes that is true. I understand how this might seem weird in the context of today’s more traditional corporation set up, but it is not new in the start-up world where you get various team members working from their home in different locations. Amir and I ‘talk’ everyday, we argue almost every week and he’s still as annoying as ever, in a good way. :)

To elaborate more on this, I think we have been very lucky in terms of building our core team. Start-ups can easily get killed by HR problems, IP lawsuits and internal fightings. You get start-ups which spend most of their time moving offices and presenting big ideas in expensive Demos or conferences. We are not like that.

Here at Plurk, we wake up everyday, drink coffee and start working. As simple as that. While Amir continues figuring out ways to scale Plurk, Ryan is putting together new servers, me checking emails and Kan is conferencing with our partners. We all know our tasks and what we need to do. Sure, differences do exist but when you think how everyone just wants the best for our product, they rarely go beyond any personal dissatisfaction. Respect and communication is of paramount importance when everyone is working remotely. If anything, I’m glad we spend time arguing about things that matter.

What is Plurk revenue model, if any?
We have many ideas on this front and personally I think all of them will work :D. The key to getting revenue on social web is usage. If you have 10 million users and only 1% of them pay for whatever your revenue model offers every month, you will get 100k/month. But if you only have 1 million users, you will need to get 10% of them to pay for the same thing to get to 100k. Which is why we intend to focus on growth now and Plurk is growing fast. Hopefully we will be able to roll out some sort of money making machine by the end of this year.

Growing a social services. How do you get from 0 to the first 100k users?
I wish there’s a secret recipe that I can share with you all. It really comes down to the usual ingredient: being persistent, hard work, having the passion to improve your product and listen to your users. Plurk has spent almost 0 dollar on advertising or any sort of related promotion. We grow primarily via grassroot efforts. Never underestimate the power of word of mouth. If a user likes your service, she will invite 10 of her friends to play along. Out of this 10, maybe 4 will invite 10 more each and if it keeps going on like that, you will have what we call as a sustainable viral loop. We are happy Plurk is something our users feel worth sharing with their friends.

Push something out early. Let it runs for a week (or two). Analyze users reaction using a combination of internal and analytic data. Focus on a metric you are trying to improve (sign up conversion, user activity, time on site stats and etc). Work on an improved version based on the data. Let the new version runs for another full week or two. Repeat the process.

It is much easier to do iterative improvement in the early stage of a development cycle. When you already have an established size of userbase (ie. Facebook, Gmail), it’s much harder to iterate interface changes without throwing off some users especially when the new version delivers significant aesthetic and functional differences than the old one.

There are usually 2 solutions to this problem: bucket and parallel testing. Bucket testing involves showing a small portion of your userbase (randomly picked or based on specific/demographic data) the new interface. Parallel testing means running both versions of the interface to different type of users right from the start. The cons of bucket is that you only get a small sample of representative data from the test. Sometimes that is enough to justify certain design decisions. The cons of parallel is users confusion might arise. It’s not uncommon we get instances where user A try to explain to user B where and how to complete a task but parallel testing means that they might get different version of the same interface.

Some call iterative improvement an agile work flow. Others call it AB testing. Regardless of the term, interface design should not be a static process. Constant studying of user behavior helps evolve an interface to better meets its functional goal.

The early version of plurk’s post-register screen displayed a list of recommended plurkers. As shown above, we displayed a list of thumbnails, names and check boxes.

In an attempt to simplify the interface, we removed the names and enlarged the size of thumbnails. People judge by looks most of the time. Sad but true.

Turns out users want to know more about the people they are about to follow. Name might not be important, but age, location and gender are. So we included that in the final iteration.

I wanted to write this post for a while to share some of my thoughts in regards to Plurk’s unconventional timeline design decision that flows from left to right (LTR), as opposed to the more intuitive and commonly accepted practice of right to left (RTL).

I think it would be helpful to establish some common grounds on why RTL with the latest object appearing on the right side is widely considered as an ‘intuitive style’ when it comes to displaying the relationship between multiple objects within a chronologically organized space. One of the reasons is related to the way the Cartesian coordinate system works. This fundamental concept of point plotting shapes our cognitive style early on in determining where to look first when being presented with a group of objects spreading across a linear space. The right-est point of an object is always considered as the most ‘current’ state of it. This thinking is reflected in many of the interface designs that we’ve came to familiar with.

The right-est point on iTune’s playbar is an indicator of where the song is currently at.

Safari’s download progress bar goes from left to right with the right-est contrast border indicating the latest point of completion.

TV guide UI uses the conventional RTL concept.

So why do it differently?

The early design mockup for Plurk did follow the norm of RTL. At that time, it seems to be the most intuitive and correct way to design a timeline based UI, based on the reasons I stated above. Every user-centered design researches points to the same direction. Why we changed it later on can be reasoned by 2 factors: the technical implementation and interaction aspects of it.

When Amir started to work on the implementation side of it, he found that it will be easier if we went with LTR for the timeline design. It’s not hard to see why. Because of the way browser engines render block objects starting from the top left by default and how text is align from left to right, it will take constant offset calculation to measure the appropriate position  of plurks from the right side of the timeline. It is certainly doable by his standard, but we were really just trying to throw out a quick proof of concept and improved it from there. As we went through the alpha and beta phase of the application, this early design decision seemed to start proving itself, not just from the ease of implementation aspects of it, but also from the user interaction side of things.

To elaborate more on my last point, let’s look at a simple eye tracking exercise of the timeline design, assuming a user is scanning through the plurks on his timeline chronologically. This assumption is fairy accurate even though such reading sequence might not necessarily be followed by all plurk users all the time; user research has shown that it is certainly their main pattern. Below are the 2 screens of RTL and LTR eye tracking result.

RTL

LTR (current plurk’s timeline design)

Because of the way we read from left to right, and how in LTR timeline design, an older plurks will always appear on the right side of a newer one, there’s less tendency to pull a crossed path zig-zag when your eyes are scanning to read the plurks. A more streamlined flow of reading path can be more easily achieved via LTR whereas in RTL, you always have to go back to the left side to read older plurks but the left side is not where your eyes are when you finish reading the previous plurk.

The trade off, of course, is that new users will have to get used to the concept of LTR. This is also a classic case of contrast between user-centered design and activity centered design, but we’ll leave that for a future post :).