Closed Bug 899643 Opened 6 years ago Closed 5 years ago

Refresh Remote Tabs list visual style

Categories

(Firefox for Android :: General, defect)

All
Android
defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
fennec - ---

People

(Reporter: rnewman, Assigned: nalexander)

References

(Depends on 1 open bug)

Details

Attachments

(8 files, 3 obsolete files)

89.34 KB, image/png
Details
176.82 KB, image/png
Details
216.87 KB, image/png
Details
26.32 KB, patch
Details | Diff | Splinter Review
11.27 KB, patch
rnewman
: review+
Details | Diff | Splinter Review
12.35 KB, patch
Details | Diff | Splinter Review
30.10 KB, patch
Details | Diff | Splinter Review
6.61 KB, patch
Details | Diff | Splinter Review
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.
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).
Attached image screenshot.png
Screenshot of Chrome for comparison.
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?
Flags: needinfo?(ibarlow)
Whiteboard: [mentor=nalexander][lang=java][good second bug]
(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.
Flags: needinfo?(ibarlow)
tracking-fennec: --- → ?
Ready for Ian to get some mockups
tracking-fennec: ? → 32+
Flags: needinfo?(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
Assignee: nobody → alam
Flags: needinfo?(ibarlow)
Nightly (05/09) currently, hard to discern difference between remote tab listing, timestamps and actual tabs.
Attached image FxA_synctabs_mock1.png (obsolete) —
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.
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?
Attached image FxA_synctabs_mock2&3.png .png (obsolete) —
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.
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.
Attached image FxA_synctabs_mock2&3B.png .png (obsolete) —
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?
Attached image 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.
Looks hot!
Comment on attachment 8427149 [details]
FxA_synctabs_mock3.png

Oh, snap, I love it.  This is why we pay you fine folks.
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?
Flags: needinfo?(ibarlow)
Flags: needinfo?(alam)
(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.
Flags: needinfo?(ibarlow)
Flags: needinfo?(alam)
(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.
(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.
(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.
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 :)
Assignee: alam → nalexander
Status: NEW → ASSIGNED
Summary: Synced Tabs divider improvements → Refresh Remote Tabs list visual style
Whiteboard: [mentor=nalexander][lang=java][good second bug]
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.
Attachment #8429318 - Flags: review?(rnewman)
lucasr, I'm just pushing this so you're aware of my approach before we
talk.
Attachment #8429319 - Flags: feedback?(lucasr.at.mozilla)
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?
Attachment #8429318 - Flags: review?(rnewman) → review+
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.
Attachment #8429319 - Flags: feedback?(lucasr.at.mozilla)
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
(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.
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.
fyi - Adding them "back" is simple if it helps going forward
https://www.dropbox.com/s/zimik1gfg175hfr/bug1003610Expanded.png
IMHO not having the group indicators there makes for zero discoverability and a bad UX regression, see linked bug.
Depends on: 1038042
(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.
(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.
On Nightly 33.0a1 as of now, with the completion of bug 1037527, they are expanded by default, but still collapsable.
I think this needs to be re-tracked
tracking-fennec: 32+ → ?
tracking-fennec: ? → -
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.)
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.