Hello there

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