899643 - Refresh Remote Tabs list visual style

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Richard Newman [:rnewman]]

Device dividers are slim grey text. If you have more than a couple of tabs, this requires reading, not scrubbing, to find. I suggest adding some striking visual (an orange line?) to allow fast fling/scan behavior, and/or stopping fast flings at the boundary of the new device section.

Comment 1

[Nick Alexander :nalexander [he/him]]

I'd add that it's not clear that we're using an ExpandableListView -- there's no affordance to open/close the set of tabs associated to a device.  Compare the arrows on the right of the list in Chrome (see attached screenshot).

Comment 2

[Nick Alexander :nalexander [he/him]]

Attachment: screenshot.png

Screenshot of Chrome for comparison.

Comment 3

[Nick Alexander :nalexander [he/him]]

This isn't a good first bug, but it is a good second (or later) bug.

There are a few things to do here:

1.  Propose a new style for the remote tabs list, and get UX feedback on it.  Before and after screenshots would be best for this, I think.

The relevant style files are

http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/resources/layout/remote_tabs_group.xml
http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/resources/layout-xlarge-v11/remote_tabs_group.xml

2.  Add an affordance of some sort to open/close the set of tabs for each device.

I assume this would mean adding a drawable to the remote_tabs_group layout, but I don't actually know; and possibly wiring in click handlers, etc, into RemoteTabsList.  Looking deeper, I see the open/close per group functionality has been blocked; I don't know why.  See

http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/RemoteTabsList.java#54

This goes all the way back to the initial landing: http://hg.mozilla.org/mozilla-central/rev/7d7ddd2fe6d8#l6.108

ibarlow, would you be for/against what I suggest in https://bugzilla.mozilla.org/show_bug.cgi?id=899643#c1?

Comment 4

[Ian Barlow (:ibarlow)]

(In reply to Nick Alexander :nalexander from comment #1)
> I'd add that it's not clear that we're using an ExpandableListView --
> there's no affordance to open/close the set of tabs associated to a device. 

Ha. *I* didn't even know that. I'll put some sketches together.

Comment 5

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

Ready for Ian to get some mockups

Comment 6

[Ian Barlow (:ibarlow)]

Anthony, can you take a look at this visual design bug? There are two parts, as I see it. 

1. Make Synced Tabs device dividers more prominent than they are
2. Add a visual affordance to show that these lists can be expanded and collapsed

Comment 7

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Will do, stay tuned!

Comment 8

[Aaron Train [:aaronmt]]

Attachment: nightly-april-screenshot

Nightly (05/09) currently, hard to discern difference between remote tab listing, timestamps and actual tabs.

Comment 9

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: FxA_synctabs_mock1.png

Took an initial stab at this. Currently, I only have the design for mobile, XXHDPI, for vertical orientation. 

Also have yet to test font legibility on a mobile screen size. But, I think I have covered most, if not all, date types that will be displayed. 

The "2 devices hidden" is designed to be smaller and more subtle due to the nature of that information/action itself. The icons for devices have been taken from the FxA Sync graphic during initial set up. Finally, I've simplified the copy for the device and build. Namely, gotten rid of "Firefox" for Nightly, Aurora, and Beta to save space and reduce redundancy. 

Will keep iterating on this.

Comment 10

[Ian Barlow (:ibarlow)]

Looking good, Anthony. I wonder if those section headings need to be even more visually distinct though -- I could still imagine having trouble scanning long lists of remote tabs and telling the tabs apart from the devices. The arrows are a nice addition, but maybe the rows need to be a different colour too?

Comment 11

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: FxA_synctabs_mock2&3.png .png

As per feedback I've made some adjustments. Namely the favicon has been removed since we can't really get that right now, and I've added a bit more visual separation between Device groups open/closed, and individual tabs.

Comment 12

[Ian Barlow (:ibarlow)]

This is nice. 

What do you think about adding a little more contrast between the colour of page titles and URLs? They are very close to the same colour at the moment, which could also make this list harder to scan.

Comment 13

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: FxA_synctabs_mock2&3B.png .png

I find that adding too much contrast in the form of brightening up the "Tab group" too much runs the risk of collision with the "on tap" state/ active state.

With that being said, I do also see a point for increasing the darkness on the right hand side one (which I prefer). I think this alongside the indentation, device icon, and un/collapsed arrow really makes for a good visual separation of the two items.

Thoughts?

Comment 14

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: FxA_synctabs_mock3.png

As per feedback, adding greater contrast (link color is now #777777) between links and page title. 

To summarize, Tabs inside a tab group now have a darker background matte (#2C3136) and the divider for those items have been made lighter to compensate (#40454A).

Might I also point out that we don't currently have the "down state" for items in this list. On tap, they should highlight the same as the tabs along the top (Tabs/Private/Sync) do.

Comment 15

[Ian Barlow (:ibarlow)]

Looks hot!

Comment 16

[Nick Alexander :nalexander [he/him]]

Comment on attachment 8427149 [details]
FxA_synctabs_mock3.png

Oh, snap, I love it.  This is why we pay you fine folks.

Comment 17

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Glad you like it! :)

Comment 18

[Nick Alexander :nalexander [he/him]]

ibarlow, antlam: discussion with margaret reveals that there is work to split the history hub panel into two panels, history and tabs.  Would remote tabs be better as a hub panel?

Comment 19

[Ian Barlow (:ibarlow)]

(In reply to Nick Alexander :nalexander from comment #18)

> Would remote tabs be better as a hub panel?

It is definitely something we want to try as an experiment, but also not as an immediate replacement for this UI. 

I'd love for us to spin off a bug to explore this though. I could see a hub panel providing much more direct access to stuff I was just doing on desktop, versus having it more tucked away in the tab tray like we do now.

Comment 20

[Richard Newman [:rnewman]]

(In reply to Ian Barlow (:ibarlow) from comment #19)
> I could see a hub
> panel providing much more direct access to stuff I was just doing on
> desktop, versus having it more tucked away in the tab tray like we do now.

See also Bug 1003608, whose data representation improvements would allow us to partition our history like this.

Comment 21

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

(In reply to Ian Barlow (:ibarlow) from comment #19)
> (In reply to Nick Alexander :nalexander from comment #18)
> 
> > Would remote tabs be better as a hub panel?
> 
> It is definitely something we want to try as an experiment, but also not as
> an immediate replacement for this UI. 
> 
> I'd love for us to spin off a bug to explore this though. I could see a hub
> panel providing much more direct access to stuff I was just doing on
> desktop, versus having it more tucked away in the tab tray like we do now.

Let's be careful we don't make Hub panels useless because they are so popular. With 7 Hub panels, it might be faster to get to the TabsTray then to open Home and pan around to find the right panel.

Comment 22

[Nick Alexander :nalexander [he/him]]

(In reply to Mark Finkle (:mfinkle) from comment #21)
> (In reply to Ian Barlow (:ibarlow) from comment #19)
> > (In reply to Nick Alexander :nalexander from comment #18)
> > 
> > > Would remote tabs be better as a hub panel?
> > 
> > It is definitely something we want to try as an experiment, but also not as
> > an immediate replacement for this UI. 
> > 
> > I'd love for us to spin off a bug to explore this though. I could see a hub
> > panel providing much more direct access to stuff I was just doing on
> > desktop, versus having it more tucked away in the tab tray like we do now.
> 
> Let's be careful we don't make Hub panels useless because they are so
> popular. With 7 Hub panels, it might be faster to get to the TabsTray then
> to open Home and pan around to find the right panel.

That's true, but I think that's a problem we're likely to encounter no matter what.  One reason I favour a home panel is that if you use it a lot, you can arrange where it lives to be better suited to your use.

Comment 23

[Ian Barlow (:ibarlow)]

Agreed, we don't want to overwhelm with millions of panels. 

It's still probably a worthwhile experiment though. Besides, the absolute worst case scenario here is that we just end up with more add-ons we can point people to. This is not an especially useful data point, but I for one would totally use a synced tabs hub panel. 

--

This also opens up all kinds of interesting areas to dig into, like

* What are sensible default panels to ship in Fennec? Are we shipping the right ones now? 
* Might we ship extra optional ones that are turned off by default? Browser-specific things like synced tabs, specific bookmarks folders, search history, etc.
* If we did have more than we could reasonably fit into a single list of panels by default, what kind of customization experience could we provide to make adding and removing panels a delight, and not a chore in Settings as it is now? Think about how cool the Australis customize mode is -- what would the Hub equivalent of that be? Because my hope is that we can find a way to get to a place where it isn't about people having 20 panels they aren't using, but rather them having a really easy and clear way to put a smaller number of the exact things they need on their homepage.



For right this moment in this bug though, let's get this synced tabs tray looking as excellent as Anthony's sketches :)

Comment 24

[Nick Alexander :nalexander [he/him]]

Attachment: Part 1: Extract RemoteTabsExpandableListAdapter. r=rnewman

Comment 25

[Nick Alexander :nalexander [he/him]]

Attachment: Part 2: Expose Sync client device type to Fennec's tabs provider. r=rnewman

This is awful, but it's the expedient thing to do.  The right thing to
do is to deprecate Sync's clients database in favour of Fennec's clients
table, but that's a good chunk of work for a small gain.

If you're cool with this approach, rnewman, I'll shuffle this to the
front of the queue and land it sooner rather than later.

Comment 26

[Nick Alexander :nalexander [he/him]]

Attachment: Part 3: Show client device type in Remote Tabs list. r=lucasr

lucasr, I'm just pushing this so you're aware of my approach before we
talk.

Comment 27

[Nick Alexander :nalexander [he/him]]

Attachment: Part 4: Show expanded/collapsed indicator in Remote Tabs list. r=lucasr

Comment 28

[Nick Alexander :nalexander [he/him]]

Attachment: BUg 899643 - Part 5: WIP on persisting expanded/collapsed state. r=lucasr

Comment 29

[Richard Newman [:rnewman]]

Comment on attachment 8429318 [details] [diff] [review]
Part 2: Expose Sync client device type to Fennec's tabs provider. r=rnewman

Review of attachment 8429318 [details] [diff] [review]:
-----------------------------------------------------------------

If it works, I'm fine with it :)

::: mobile/android/base/sync/repositories/android/FennecTabsRepository.java
@@ +40,5 @@
>      this.localClientGuid = localClientGuid;
>    }
>  
>    /**
> +   * Note that -- unlike most repositories -- this will only fetch Fennec's tabs,

Pah, you and your ASCII. Those are em dashes!

@@ +72,5 @@
>        } catch (Exception e) {}
>        try {
>          tabsProvider.release();
>        } catch (Exception e) {}
> +      clientsDatabase.close();

Any reason not to wrap this in a try, too?

Comment 30

[Lucas Rocha (:lucasr)]

Comment on attachment 8429319 [details] [diff] [review]
Part 3: Show client device type in Remote Tabs list. r=lucasr

Clearing feedback request after our discussion over vidyo yesterday. Let me know if you need any other specific feedback here.

Comment 31

[Ian Barlow (:ibarlow)]

Ping on status here? Between the lack of affordance that these lists are expandable / collapsable, and the typography, the UI in Nightly right now is in pretty rough shape: http://cl.ly/image/0W1A1n3m0p0d

Comment 32

[Nick Alexander :nalexander [he/him]]

(In reply to Ian Barlow (:ibarlow) from comment #31)
> Ping on status here? Between the lack of affordance that these lists are
> expandable / collapsable, and the typography, the UI in Nightly right now is
> in pretty rough shape: http://cl.ly/image/0W1A1n3m0p0d

vivekb has review comment to address on a "new look" based on TwoLinePageRow; activity is in https://bugzilla.mozilla.org/show_bug.cgi?id=977164.  This moves us towards a better look that is forward looking to the home panel implementation.  This is definitely 34 land.

It kind of looks like capella's patch from https://bugzilla.mozilla.org/show_bug.cgi?id=1003610 removed auto-expanding the clients, which wasn't intentional.  We can address that in a separate ticket in the 33 cycle.

Comment 33

[Mark Capella [:capella]]

Actually, I collapsed the groups by default by design to provide more of an overview of available devices on initial display. This is part of the reason I wanted to leave the groupIndicator icons in the patch, so users could immediately understand that there was further detail available.

Not a big issue either way, and we knew the code/design in this area was in flux.

Comment 34

[Mark Capella [:capella]]

fyi - Adding them "back" is simple if it helps going forward
https://www.dropbox.com/s/zimik1gfg175hfr/bug1003610Expanded.png

Comment 35

[Gian-Carlo Pascutto [:gcp]]

IMHO not having the group indicators there makes for zero discoverability and a bad UX regression, see linked bug.

Comment 36

[Aaron Train [:aaronmt]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #35)
> IMHO not having the group indicators there makes for zero discoverability
> and a bad UX regression, see linked bug.

I believe on mozilla-33, they are expanded by default.

Comment 37

[Nick Alexander :nalexander [he/him]]

(In reply to Aaron Train [:aaronmt] from comment #36)
> (In reply to Gian-Carlo Pascutto [:gcp] from comment #35)
> > IMHO not having the group indicators there makes for zero discoverability
> > and a bad UX regression, see linked bug.
> 
> I believe on mozilla-33, they are expanded by default.

On 33, they are both expanded by default, and not collapsible.

Comment 38

[Mark Capella [:capella]]

On Nightly 33.0a1 as of now, with the completion of bug 1037527, they are expanded by default, but still collapsable.

Comment 39

[Aaron Train [:aaronmt]]

I think this needs to be re-tracked

Comment 40

[Nick Alexander :nalexander [he/him]]

I'm calling this done: we now have a nicely styled Remote Tabs/Synced Tabs home panel.  Any further modifications can be fresh tickets.  (Closed by lots of tickets hanging off Bug 1002573.)