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.
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
Still the problem of the skipping scrollbar on infinite scroll keeps popping up (pun intended).
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 :-).
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
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
With infinite scroll the list is infinite, so point 2 does not apply.
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”.
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
Does it make sense to think of it more as a vertical progress bar for your reading instead of a scroll bar?
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.
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
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.
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?
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
.
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
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.
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.
Have you tried Carbon?
I think, from the description, it’s the same idea as the scrollbar in the HackerNews2 app on Android.
Tweetdeck on Android used to have precisely the same thing (but yellow rather than red).
Do you remember which version? Version 3 doesn’t have it – I may have to dig out my 3GS and try an older version.
I don’t, I’m afraid; I haven’t had it installed in quite a while. It was definitely present though.
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.
The Chrome 32 beta has removed them too. It’s annoying; I miss them more than I would’ve expected.
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.
Wrong link, should be: http://www.filedropper.com/scrollbar2
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
http://www.youtube.com/watch?v=6UfRoht6FcY
Those Microsofties / Windows Phonies really know their games!
Sims! Trivial pursuit! Monopoly! Such awesomeness! Can’t wait to play them! How exciting!