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.

Order by: Score:
Comment by flypig
by flypig on Wed 27th Nov 2013 00:51 UTC
flypig
Member since:
2005-07-13

After watching the video it looks like a nice idea. Now that scrollbars are more for information than control, there should be flexibility to do interesting things like this.

Perhaps the obvious solution for an infinite list would be to have the length of the bar follow the formula

screenheight * (1 - (1 / x))

where x is the position in the list increasing from one. This would ensure the scrollbar never grows to the bottom of the screen: it just grows slower, and slower, and slower...

Edited 2013-11-27 00:52 UTC

Reply Score: 6

RE: Comment by flypig
by Invincible Cow on Wed 27th Nov 2013 22:25 UTC in reply to "Comment by flypig"
Invincible Cow Member since:
2006-06-24

Still the problem of the skipping scrollbar on infinite scroll keeps popping up (pun intended).

Reply Score: 2

Form / Function
by HappyGod on Wed 27th Nov 2013 02:40 UTC
HappyGod
Member since:
2005-10-19

It sounds like a good idea, and with the amendments suggested by flypig, it would actually work.

But as described by Thom, I don't think it flies. I would prefer a scroll bar to jump up when the list grows, than have it just run out of ideas. Especially on a mouse-driven device.

A scroll bar should:

1. Convey your position in the overall list, and;

2. Give you the ability to scroll the pseudo-bottom of the list.

In it's current form it doesn't do either of those functions well (I'm aware that function 2 doesn't apply on mobile devices :-).

Reply Score: 5

RE: Form / Function
by mutantsushi on Wed 27th Nov 2013 08:00 UTC in reply to "Form / Function"
mutantsushi Member since:
2006-08-18

Agreed. The 'jumping' is of course conveying information that the list is getting longer. Going with that, I think having a specific animation rather than just instantly re-locating the scroll widget to the newly correct location would be a better way to convey what's going on, that the list is being enlarged and the proportional position in that list is being regressed. Having the scroll widget 'suddenly' shift from conveying information to not conveying further information doesn't seem any better than the scroll widget 'jumping' to the newly accurate position.

Edited 2013-11-27 08:01 UTC

Reply Score: 3

How is that a good idea?
by leos on Wed 27th Nov 2013 07:15 UTC
leos
Member since:
2005-09-21

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

The tweedle scrollbar doesn't accomplish #1 if you are scrolling past some predetermined length, and doesn't accomplish 2 at all (unless you are interpolating the speed that it grows).

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.

Much better would be a scrollbar that simply smoothly moves to the new location if the list size changes, or hides itself during the change so you don't notice.

Edited 2013-11-27 07:16 UTC

Reply Score: 9

RE: How is that a good idea?
by Invincible Cow on Wed 27th Nov 2013 22:26 UTC in reply to "How is that a good idea?"
Invincible Cow Member since:
2006-06-24

With infinite scroll the list is infinite, so point 2 does not apply.

Reply Score: 2

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 Score: 3

Progress bar
by dnebdal on Wed 27th Nov 2013 09:33 UTC
dnebdal
Member since:
2008-08-27

Does it make sense to think of it more as a vertical progress bar for your reading instead of a scroll bar?

Reply Score: 3

RE: Progress bar
by Glynser on Wed 27th Nov 2013 09:38 UTC in reply to "Progress bar"
Glynser Member since:
2007-11-29

Yes, or the bar representing how much of "new" information you are hiding, as seen from the top. I think it might be a good solution.

Reply Score: 2

The Jumping...
by Glynser on Wed 27th Nov 2013 09:40 UTC
Glynser
Member since:
2007-11-29

The jumping of scrollbars is the most annoying thing nowadays... especially if you grab the scrollbar with your mouse, and move it down, then suddenly the jump occurs and you just don't know anymore where you have been... it's really about time to solve that issue

Reply Score: 2

Comment by MechR
by MechR on Wed 27th Nov 2013 10:01 UTC
MechR
Member since:
2006-01-11

This doesn't seem like an improvement to me. It's only a cosmetic difference up till you hit the autoload line, at which point it becomes useless, whereas a regular scrollbar adjusts and keeps working.

I have a better idea: Kill infinite-scroll. With fire.

Reply Score: 4

Surprising
by Heard on Wed 27th Nov 2013 12:44 UTC
Heard
Member since:
2009-12-24

For me it's surprising that you mention that the app does not "shove any non-standard UI crap in" your face when the article actually is about you praising a non-standard UI element.

I definitely prefer apps to behave in the same way. The fact that it looks exactly like a traditional scroll bar makes it even worse. How can you know how a certain scroll bar behaves if every single app has a different concept but the same look?

Reply Score: 3

RE: Surprising
by Thom_Holwerda on Wed 27th Nov 2013 12:51 UTC in reply to "Surprising"
Thom_Holwerda Member since:
2005-06-29

Sometimes, careful experimentation that is well-thought out leads to improvements. Take pull to refresh for instance - it used to be non-standard, but now it's everywhere - and it's more pleasant (if implemented properly) than a separate refresh button.

While it's clear that opinions on this new element are divided (at least in our comments), time will tell if it has a similar impact. I would really love to see it used on every infinite scroll surface, but that's just me ;) .

Reply Score: 1

RE[2]: Surprising
by Heard on Wed 27th Nov 2013 13:27 UTC in reply to "RE: Surprising"
Heard Member since:
2009-12-24

I agree with you that differing from a standard can lead to big improvements sometimes.

But: I think there is a difference between adding a completely new feature and changing the behavior of an existing feature for a special type of application. The second could in my opinion create a real mess.

Another thing is that I don't think a twitter app is important enough to change the way most apps behave, but I may be wrong there. :-)

Edit:
I just wanted to add that I think it's a little bit similar to what you described in your article about modes (http://www.osnews.com/story/18904/Common_Usability_Terms_pt._V:_Mod...). The user might not realize the difference between the two "modes" (finite/infinite).

Edited 2013-11-27 13:33 UTC

Reply Score: 2

RE[2]: Surprising
by leos on Thu 28th Nov 2013 05:24 UTC in reply to "RE: Surprising"
leos Member since:
2005-09-21

Sometimes, careful experimentation that is well-thought out leads to improvements.


I still don't see any improvements. Is the cosmetic one the only one? Since when are you all about form over function?

Reply Score: 2

RE[3]: Surprising
by galvanash on Thu 28th Nov 2013 22:18 UTC in reply to "RE[2]: Surprising"
galvanash Member since:
2006-01-25

I still don't see any improvements. Is the cosmetic one the only one? Since when are you all about form over function?


I think you are missing the point...

You don't want to indicate a position relative to the size of "a part of the list", and you don't want indicate the size of "part of the list".

You are trying to create the illusion of the list being infinite...

By using a conventional scrollbar behavior you are exposing the "man behind the curtain" - the information destroys the illusion.

Its a list. It has information going back in time forever. I don't have to load it, its just there. That is the conceit you are trying to achieve.

A conventional scrollbar exposes the very thing that you are trying to abstract away. It can't help but do that, because that is what it was built to do. This implementation doesn't expose the illusion. Its not perfect, but it is loads better than the alternative imo.

Reply Score: 2

v New... new... not new!
by capi_x on Wed 27th Nov 2013 12:48 UTC
RE: New... new... not new!
by Thom_Holwerda on Wed 27th Nov 2013 12:49 UTC in reply to "New... new... not new!"
Thom_Holwerda Member since:
2005-06-29

Is not new. It's a bad copy of the iOS 7 scroll bar.


Have you used iOS 7? Or this application?

Because your comment makes it clear you haven't.

Reply Score: 2

RE[2]: New... new... not new!
by henderson101 on Thu 28th Nov 2013 15:48 UTC in reply to "RE: New... new... not new!"
henderson101 Member since:
2006-05-30

Have you tried Carbon?

I think, from the description, it's the same idea as the scrollbar in the HackerNews2 app on Android.

Reply Score: 3

It's not new
by BeamishBoy on Wed 27th Nov 2013 12:55 UTC
BeamishBoy
Member since:
2010-10-27

Tweetdeck on Android used to have precisely the same thing (but yellow rather than red).

Reply Score: 4

RE: It's not new
by Thom_Holwerda on Wed 27th Nov 2013 13:00 UTC in reply to "It's not new"
Thom_Holwerda Member since:
2005-06-29

Do you remember which version? Version 3 doesn't have it - I may have to dig out my 3GS and try an older version.

Reply Score: 1

RE[2]: It's not new
by BeamishBoy on Wed 27th Nov 2013 17:46 UTC in reply to "RE: It's not new"
BeamishBoy Member since:
2010-10-27

I don't, I'm afraid; I haven't had it installed in quite a while. It was definitely present though.

Reply Score: 2

Pretty sure...
by leech on Wed 27th Nov 2013 14:53 UTC
leech
Member since:
2006-01-10

I'm pretty sure that I've seen something similar to this elsewhere, just can't recall where. Possibly on the Amiga.

But this just reminds me that lately I've been rather irritated at scrollbars. Where the hell did the arrows go on Gnome? Sometimes (especially when you have a touch screen) it's way more precise to click on the arrow rather than try to drag a scrollbar.

Reply Score: 2

RE: Pretty sure...
by MechR on Thu 28th Nov 2013 23:12 UTC in reply to "Pretty sure..."
MechR Member since:
2006-01-11

But this just reminds me that lately I've been rather irritated at scrollbars. Where the hell did the arrows go on Gnome? Sometimes (especially when you have a touch screen) it's way more precise to click on the arrow rather than try to drag a scrollbar.

The Chrome 32 beta has removed them too. It's annoying; I miss them more than I would've expected.

Reply Score: 2

Infinite scrollbar REVAMPED
by Invincible Cow on Wed 27th Nov 2013 23:00 UTC
Invincible Cow
Member since:
2006-06-24

I made a better scrollbar for areas without a fixed limit. Give it a try:
http://www.datafilehost.com/get.php?file=9eb01de4 (32-bit windows exe)

Supports grab to pan or grab to scroll (default).

If you don't want to run an untrusted exe, that's FINE, just don't and don't WHINE about it.

Reply Score: 2

RE: Infinite scrollbar REVAMPED
by Invincible Cow on Thu 28th Nov 2013 10:32 UTC in reply to "Infinite scrollbar REVAMPED"
Invincible Cow Member since:
2006-06-24

Wrong link, should be: http://www.filedropper.com/scrollbar2

Reply Score: 2

FreeGamer Member since:
2007-04-13

If you want to showcase something, set up either a web page with screenshots or link screenshots or post a youtube video of it in action.

Nobody in their right mind will download a random exe.

Edited 2013-11-28 12:34 UTC

Reply Score: 4

Wow @ Windows Phone
by aliquis on Wed 27th Nov 2013 23:09 UTC
aliquis
Member since:
2005-07-23

Those Microsofties / Windows Phonies really know their games!

Sims! Trivial pursuit! Monopoly! Such awesomeness! Can't wait to play them! How exciting!

Reply Score: 0