Linked by Thom Holwerda on Tue 26th Nov 2013 23:07 UTC
Graphics, User Interfaces

It's rare these days, but it happens: a (what I think) is a completely new UI element (or 'widget', in proper parlance).

In my quest for an Android Twitter client that doesn't suck, I stumbled upon Tweedle, a no-frills, properly designed Twitter client for Android that, as far as I can tell after a few days, does not suck. It integrates properly with Android and has an actual Android user interface - unlike other Android Twitter clients, it doesn't shove any non-standard UI crap in my face. Really, the complicated, overdesigned user interfaces many Android developers come up with just to show several snippets of text in a scrollable list (that's all Twitter is, folks) is remarkable. Let's save that rant for another day, however.

What I find most intriguing about Tweedle is that it includes a UI widget I've never seen before. Instead of a regular scrollbar, Tweedle has a vertical line that increases in length as you scroll down in your timeline, and decreases in length as you scroll upwards. If you reach the newest tweet, the bar disappears. It's a different take on the traditional scrollbar, but to me, it feels like a better fit for a timeline than a traditional scrollbar.

If you scroll far enough down, the line will reach all the way to the bottom. If you keep scrolling beyond that point, the line just stays there. A traditional scrollbar, like in, say, Tweetbot 3 for iOS 7, acts differently. Once the scrollblob hits the bottom of the screen, a new set of tweets loads, and the blob erratically jumps upwards, which is just plain weird when you think about it.

The traditional scrollbar - even a proportional one - does its job best when used with finite scrollable areas. Timelines on Twitter, Facebook, Google+, and so on, however, are essentially infinite lists, which causes traditional scrollbars to jump around whenever you reach the 'bottom' of your timeline and new content is loaded. The line in Tweedle does not have this issue, but it does introduce a new one - once the line fills up and hits the bottom, but you keep on scrolling - it stops conveying any new information.

Still, I find it a fascinating rethinking of the traditional scrollbar, and I hope to see it in more applications.

Thread beginning with comment 577661
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: How is that a good idea?
by galvanash on Thu 28th Nov 2013 18:19 UTC in reply to "How is that a good idea?"
galvanash
Member since:
2006-01-25

So in order to fix a cosmetic issue (scrollbar jumping) you've completely ruined the whole point of a scrollbar on a mobile device.
A scrollbar on a mobile device has two jobs:
1. show you where you are in the list and
2. approximately how large the list is (by how big the scroll blob is).


If the list is of infinite length, it is impossible to do either of those things in absolute terms - it can't be done.

A conventional scrollbar used in an "infinite" list usually does the following:

1. Show where you are in the list in terms of what is currently loaded.
2. Show how large the list is by shrinking in size relative to the number of items in the list that is currently loaded.

When more items are loaded both the position and size of the bar have to be adjusted to reflect the new list size, hence the "jumping" some people complain about.

I think the point of trying something different is that although the conventional approach works, it is also arguably focusing on information that the user probably doesn't need to care about in an infinite list...

What you want to indicate is:

1. How far do I have to scroll to get to the top?

That's it. You actually don't want to indicate how far you have to scroll to get to the "bottom" (the next load threshold) because the entire point is to make the loading of additional data transparent - to the user the list should just appear to go on indefinitely and ideally they shouldn't be able to detect that data is loading in the background at all.

This implementation (however flawed) tries to do that:

1. There is no "position" in the conventional sense - the scrollbar is locked to the top of the scrollbox.
2. The scrollbar's size actually indicates position.
3. There is nothing indicating the size of the list (either the virtual size or the actual size).

It acts more like a progress bar than a scrollbar, indicating your progress as you scroll down. Makes a lot of sense in some ways as on a touchscreen device the scrollbar is nothing more than a passive indicator anyway - you cannot interact with it.

It is somewhat flawed however as it grows linearly, so once you get far enough from the top the scrollbar size hits 100% and it no longer does anything useful.

As someone else mentioned, this could be addressed somewhat by slowing the growth of the list as it approaches 100%. This would be better, but arguably it doesn't make all that much difference because you will still reach a point where it just doesn't convey anything useful.

I would add that a conventional scrollbar suffers from exactly the same problem... The scrollbar size shrinks as the list gets larger, but it can't shrink forever - there is always a minimum size that is reached where it no longer conveys any useful information about the list size other than "it is a really big list".

When this implementation hits it's limits, it is saying "the top is very far away".

Why not just throw away the scrollbar entirely rather than making a useless one? This is a great example of developer wasting a lot of time on reinventing widgets and ending up with a worse result than the standard.


I don't find it's useless, but I would agree it is flawed. Thing is though that both approaches are flawed when dealing with an infinite list. This one is less flawed imo. Also, it would make no sense at all to use this type of scrollbar for a finite list, so it accomplishes something useful by indicating to the user that they are not dealing with a conventional scrollbox by not trying to act link one.

Edited 2013-11-28 18:29 UTC

Reply Parent Score: 3