737235 - Better UX of more than 8 synced tabs in menu

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: General, defect)

Description

[Tony Chung [:tchung]]

Attachment: screenshot

The current sync'ed tabs UI only displays up to 8 tabs nicely in the menu view. but anything after that, its not obvious in the UX that there are more tabs (or other computers), until you scroll.

My suggestion is have UX with an arrow that points up and down if >8 sync''d tabs.  Or at least make the scrollbar visible by default.

See screenshot of current implementation

REpro:
1) launch nightly 3-19 build
2) sync account with more than 8 tabs from another computer
3) launch tab menu -> synced tabs
4) verify > 8 tabs is not obvious to the user they can pan up and down to see more.

Expected:
- better UX to indicate there are more than 8 tabs in the list.  (add arrows UI, make the scrollbar appear visiable on default, etc..)

ActuaL:
- no obvious way to tell more than 8 tabs on first look.

Comment 1

[Ian Barlow (:ibarlow)]

In the main tabs menu, we solved this by making sure that if the menu scrolled, the height of the menu always cropped half of a row, giving some indication that there were more things to scroll to. 

I'd like to see something like for remote tabs, as well. 

Adding Sriram to this bug, as I believe he got this working in the tabs menu.

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

Noming as a polish bug. Softblocker at best.

Comment 3

[Ian Barlow (:ibarlow)]

In addition to always cropping a row, it would also be helpful to briefly display a scrollbar in this list, if there are enough items to allow scrolling.

Comment 4

[Sriram Ramasubramanian [:sriram]]

The tabs-list condition is different. Everything is a equal sized row, and we can calculate easily. In this case, the header are around 1/3rd the size of normal row. 1 header + 8 tabs will not be the same as 2 headers + 4 tabs. This makes the calculations so hard. While scrolling, there is a possibility that we might end up in a state where everything ends on a boundary -- if we had optimized for "dont fall on a boundary" before scrolling had started.

Basically multiple row headers + multiple rows is a problem.

We can show the scrollbar briefly if there are more entries. But the boundary problem cannot be solved.

Also, how does this translate to in the new tablet UI?

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Sriram Ramasubramanian [:sriram] from comment #4)

> We can show the scrollbar briefly if there are more entries. But the
> boundary problem cannot be solved.

This is all I think we should focus on right now. Trying to get a cropped row is not straight forward. Showing/fading a scrollbar is the normal OS way to indicate a scrollable list.

Comment 6

[Sriram Ramasubramanian [:sriram]]

As per the discussion, we need to "awaken the scroll bars" when there is more in the list.
Which -- sadly -- happens by default. (Tested on Nexus S with ICS). Hence marking this WFM. :)