The case of left to right
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 :).