Hello there

Found some interesting thing:

• A song recording by my ex-girlfriend. I must say, it is pretty good.
• My work place at UNL. Good times.
• UI for validator.unl.edu
• Very, very early version of Plurk
• Burrrrppppp!

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.

“What is the purpose of good design if there is no one who can use it? Like the mythical tree that falls in a forest if no one heard it crash, is a product’s design any good if it remains on a museum’s pedestal? […]

When a product is lauded by the industry and the critics as an example of good design but struggles to reach the hands of the people it is meant for, is that an example of art or sculpture, a creative expression of the artist’s personal vision manifested tangibly rather than any validation of what is good in design? […]

What is the purpose of a design award for a product that failed to meet its own creative brief?” ~Niti Bhan [via putting people first]

When it comes to user interface design, what pleases the designerati may not always coincide with the needs of end users. Both are not mutually exclusive, of course. But we as designers have a subconscious tendency to choose one over the other. It’s easy to say ‘design for the users’ and argue it with [insert your favourite design philosophy]. At the end of the day, what really matters to me personally, is to not assume too much of what I know about my users.

Let the data helps you. Don’t skim on contextual studies, ethnography, qualitative insights or simple things like personas creation and structured analysis. Interaction or interface design is not about guesstimating or well blended gradient.

Interaction designers prefer to use design patterns in their works. Design philosophy like UCD demands it. Design components that are ‘promoted’ to the pattern status have the advantage of being intuitive to users. It’s not something they have never seen before, and with such prior interaction experience, they don’t have to develop new cognitive style when using the application.

But sometimes an interface has to incorporate some sort of experimental pattern, be it a new navigation structure or mouseover action. What would be the best way to introduce this to users without resulting in a negative experience?

At Plurk, with the timeline concept, we are constantly studying how users are adapting to the design. I would like to share some tips and hopefully some might find them useful.

Keep it simple. Strip away uneccesary things.
Here we are already using an interface component that most users probably haven’t  seen before. The idea is to not make it any more complicated. The timeline concept that Plurk has is not exactly new in the non-geek world: there are already several projects/websites out there that are using it. When you compare those timelines with Plurk’s, you will notice that we don’t have things like a secondary timeline for navigation, zoom function, colorful guiding lines, drop down selections, expandable content or vertical dragging.

Keep it simple, as always. Let the data shines. Don’t overwhelm users with unneccesary bells and whistles because they are already trying to learn your new concept here. Don’t ever use experimental design because you want to WOW the users, but use it because you believe it will lead to a better interaction experience. We are working on a web application here, not a promotional/marketing website and at Plurk, we really do believe a ‘river stream’ display design is a better way to get an overview look of your social activity, as opposed to the traditional list-based inteface.

Keep the attention away from the experimental component
When I first designed Plurk’s interface, I wanted users to not pay too much attention to the timeline itself, but rather what’s on it. User adaptation process is much easier when the UI is not forcing them to learn new tricks in order to get things done. The content is there (in this case, the plurks). Users will see it right away. The most recent plurks will always appear upon loading the profile page without users having to zoom or expand or click on anything on the timeline.

Collapse-view on gmail is a brilliant UI idea. But it’s not something new users will notice right away, because they are busy reading their emails. When the email conversations get longer, the AHA! moment steps in.

Good ol’ spoon-feeding and hand-holding
Help tips and text can be useful in introducing new things. Contextual explanation clarifies hidden aspects of UI components. It is being used when the UX team doesn’t think the self-exploratory ‘click and learn’ process will work. The reason I put this as the last tip is because I think we should use them with discretion. It is unwise to have a full blown 500 characters, 6 slides, tips popups splattered across the UI. Keep the text concise and meaningful. Make the tips elements adaptive (in most cases, only first time users need to see it). Don’t make them appear in areas where they might be obtrusive to other UI interactions. Always have an option to make all tooltips go away.

I like the recent FB redesign. But the yellowish tooltips are too much. And they won’t go away unless I hunt them down with the X one by one. =(

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 :).