686417 - [Tablet] Add a way to hide the tabs sidebar in landscape tablet mode

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

Tabs on the left take way too much space from the content on tablet, and
I couldn't figure out how to hide the tabs.

(This is my immediate first-run user experience)

Comment 1

[Matt Brubeck (:mbrubeck)]

Madhava, Brian - Can we discuss a way to hide or shrink the sidebar?  I can think of lots of cases where this will be desired, such as games.  (Eventually we will have a full-screen API that some games will use, but I think we'll still want a way to hide the tab thumbnails sometimes.)

Comment 2

[Mounir Lamouri (:mounir)]

(In reply to Matt Brubeck (:mbrubeck) from comment #1)
> Madhava, Brian - Can we discuss a way to hide or shrink the sidebar?  I can
> think of lots of cases where this will be desired, such as games. 
> (Eventually we will have a full-screen API that some games will use, but I
> think we'll still want a way to hide the tab thumbnails sometimes.)

Some web apps already have a sidebar (like Google Reader, tt-rss, GMail, Zimbra, etc.) and having our sidebar and the app sidebar might leave not a lot of space for the actual content.

In general, I wonder why we want to have the sidebar always visible? IIRC, desktop users have around 2 and 3 tabs opened in average and I believe mobile users very likely have less than that. Is that really useful to have the sidebar always visible for that?
I'm not a UX guy at all but my feeling is that for most users having the sidebar always visible will most of the time be a burden more than a help. Couldn't we get the previous behavior of the sidebar but allow the user to lock it if wanted? (like with a long pressure maybe?)

Comment 3

[Hilary Hall [:hillzy]]

quickest fix I've encountered so far is to flip to portrait view - I must say I do dig the tree-style tab preview, but auto-hide tabs would be nice to have. All release channels seem to boot up lightening fast ( >5s) overall is a great experience so far (day 2 of using the Samsung 10.1)

Comment 4

[Ian Barlow (:ibarlow)]

Matt, can we try enabling a similar interaction to our phone browser, where you slide the tabs in and out from the left?

Comment 5

[Matt Brubeck (:mbrubeck)]

(In reply to Ian Barlow from comment #4)
> Matt, can we try enabling a similar interaction to our phone browser, where
> you slide the tabs in and out from the left?

In the phone UI, we slide the browser partly off-screen when the sidebar appears.  But in the tablet UI, we shrink the browser to make room for the sidebar.   So sliding the tabs away would make the browser resize.  We can try this, but the interaction might be a little weird...  Let's experiment with it.

Comment 6

[Mike Hommey [:glandium]]

Here is my experience with the new tab bar: I like it. But as mentioned in this bug, I already wished I could make it disappear an several occasions. And there's another aspect that is starting to bother me: I usually don't have more than 2 or 3 tabs opened, which leaves a whole lot of black on the screen...

As a side note, the screenshot updating seems to make the UI feel slightly sluggish.

Comment 8

[Matt Brubeck (:mbrubeck)]

Attachment: WIP

This work-in-progress patch works by making the "tabs" button visible in both portrait and landscape; in landscape mode it toggles the sidebar.  This patch applies on top of the patch from bug 685839.

We'll probably want a different icon for this button when the sidebar is visible, and it should be styled similar to the new portrait "curvy" tab button (bug 685285).

Comment 9

[Wilhelm Fitzpatrick]

Just a comment as someone who uses the current "phone" version of Firefox Mobile on my tablet, and really likes the fact that it give me a full screen browsing experience. Please consider the value of the full screen browsing experience before losing it in favor of a "fancier" interface.

Comment 10

[Henri Sivonen (:hsivonen)]

My first-run user experience was like smaug's. I wanted to make the tab bar go away in the landscape mode, but couldn't figure out how.

Honeycomb keeps it's own button bar at the bottom of the screen at all times. It's also possible for apps to add a button to the bottom bar. I suggest hiding the tab bar and the location bar when browsing and having a button in Honeycomb's bottom bar for showing Firefox's tab bar and location bar. In this scenario, it would make sense to make both the tab bar and the location bar horizontal and stack them at the bottom of the screen to put them near the button for showing them.

Comment 11

[Ian Barlow (:ibarlow)]

Attachment: Mockup of tab interaction

Hi all, here is my proposed solution for opening and closing tabs on fennecomb. As you can see in the mockups, the default state is to have the tabs open. 

Users can dismiss the tab bar by swiping left anywhere within the tab bar, or within 15-20px to the right. This should minimize inadvertently closing the menu while panning around a page, but allow a big enough swipe area to make the menu easy to close.

NOTE: There is no button to close tabs. This is a deliberate choice; our hope is that the swipe gesture will be discoverable enough that no button will be necessary. We have thoughts on how to add a button if needed, but in the spirit of keeping a minimal UI, let's keep it out unless our assumptions are proven wrong.

When the tabs are closed, the action bar basically matches the styling of that in portrait mode, showing a tab icon and number of open tabs. Users can tap this menu to open tabs, or swiping from the left edge of the content view will open them as well. 

--

I am still working on some styling tweaks to the action bar when tabs are opened (basically I want to see if that tab shape can be worked into the bar in an attractive way), but let's not have that stop us from creating a prototype based on what I described above.

Comment 12

[Sriram Ramasubramanian [:sriram]]

Between images 3 and 4 in the mock-up, there seems to be some glitch.
After swiping the tabs away, the number of tabs shown is fine.
But, there is a shift in the Back/Foward buttons, and a new button pops-in there. (Will this be animated?)
I feel this could cause some problems with constant changes in the navigation bar.
Having a permanent button is better, I feel.

Comment 13

[Henri Sivonen (:hsivonen)]

(In reply to Ian Barlow from comment #11)
> When the tabs are closed, the action bar basically matches the styling of
> that in portrait mode, showing a tab icon and number of open tabs.

Is there a reason why the screen real estate of the navigation bar is used for this instead of using the (unused) real estate in Honeycomb's bottom bar (the one that houses the Android home button, etc.)? (See comment 10.)

Comment 14

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

(In reply to Henri Sivonen (:hsivonen) from comment #13)
> (In reply to Ian Barlow from comment #11)
> > When the tabs are closed, the action bar basically matches the styling of
> > that in portrait mode, showing a tab icon and number of open tabs.
> 
> Is there a reason why the screen real estate of the navigation bar is used
> for this instead of using the (unused) real estate in Honeycomb's bottom bar
> (the one that houses the Android home button, etc.)? (See comment 10.)

Are we sure Android allows applications to add their own buttons to the OS bar at the bottom of the screen? All the Android UI guidelines I have seen use the ActionBar concept, at the top of the screen.

Comment 15

[Ian Barlow (:ibarlow)]

Henri, Mark is right: We don't (and shouldn't) put any of our own UI in the bottom bar (except notifications). This is standard for all Android 3.0 apps.

Comment 16

[Matt Brubeck (:mbrubeck)]

Attachment: WIP 2

This proof-of-concept patch implements the dragging UI from the mockup.  There's still some work left to do:

* This patch only allows dragging from the edge of the browser area, not from anywhere in the tab bar.
* The tab bar moves/animates as you drag, but the toolbar and browser do not.
* Need to test performance on device.
* Need to show/hide the tab button in the action bar.
* The code is very hacky, needs to be cleaned up.

Comment 17

[Matt Brubeck (:mbrubeck)]

Attachment: WIP 3

This shows/hides the toolbar button correctly, and adds animation of the browser and action bar.  Resizing  the browser is very slow even on desktop fennec, though.  I think we'll need to make that part happen after the drag is finished.

Still need to clean up the code, and allow dragging anywhere in the tab bar.

Comment 18

[Henri Sivonen (:hsivonen)]

(In reply to Ian Barlow from comment #15)
> Henri, Mark is right: We don't (and shouldn't) put any of our own UI in the
> bottom bar (except notifications). This is standard for all Android 3.0 apps.

Almost every app I've obtained from Market puts an extra button in the bottom bar and the button calls up some UI that's otherwise tucked away. Even Google+, which is a recent app from Google, does this.

Are all those pre-3.0 apps and the button is for pre-3.0 app compat? (It's not clear that not having that button and having an analogous button in the top right corner of the part of the screen owned by the app is a win.)

Comment 19

[Ian Barlow (:ibarlow)]

Henri, Google + adds a "menu" button to the footer, which is an indicator that the app is actually made for phones, and hasn't been optimized for tablets. This is a workaround created by Android to allow phone apps to work on tablets without having to change the design. 

You really aren't supposed to use the footer for tablet UIs.

Comment 20

[Matt Brubeck (:mbrubeck)]

Attachment: part 1: Make the tab bar hideable

Just another snapshot.  Some minor bug fixes and some significant cleanup.  Still need to implement dragging over the sidebar.

Comment 21

[Matt Brubeck (:mbrubeck)]

Attachment: 3/3: allow dragging in the tab sidebar

This adds the ability to drag within the tab bar.  I still need to clean up a few things before requesting review, but I expect to have these patches finished tomorrow.  There's a new test build with both patches here:

http://people.mozilla.com/~mbrubeck/fennec-slide-tabs-2.apk

Comment 22

[Matt Brubeck (:mbrubeck)]

Attachment: 1/3: cache sidebar width

Comment 23

[Matt Brubeck (:mbrubeck)]

Attachment: 2/3: make the tab bar hideable

Comment 24

[Matt Brubeck (:mbrubeck)]

Comment on attachment 561613 [details] [diff] [review]
3/3: allow dragging in the tab sidebar

I think these patches are ready for review.  They'll require some additional changes to work in RTL locales, which I plan to do in bug 685308.  There's a new test build at: http://people.mozilla.com/~mbrubeck/fennec-slide-tabs-3.apk

The previous versions resized the browser and action bar dynamically while the sidebar moved.  This was too slow and made dragging unresponsive.  The latest patches resize the action bar and browser just once.  This adds some sudden changes at the start or end of a drag, but I find this overall much more pleasant than the jerkiness from trying to resize them continuously.

Comment 25

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

Comment on attachment 561654 [details] [diff] [review]
2/3: make the tab bar hideable

Can we move the grab/ungrab sidebar code out of ViewAreaObserver? That code should probably be in Browser, with the other sidebar related code.

Otherwise this looks ok.

Comment 26

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

Comment on attachment 561613 [details] [diff] [review]
3/3: allow dragging in the tab sidebar

r+, but update this for the ViewAreaObserver -> Browser change

Comment 27

[Matt Brubeck (:mbrubeck)]

Attachment: 2/3: make the tab bar hideable

Move sidebar-grabby code into Browser.

Comment 28

[Matt Brubeck (:mbrubeck)]

Attachment: 3/3: allow dragging in the tab sidebar

s/ViewableAreaObserver/Browser/g.  Carrying r=mfinkle.

Comment 30

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/31f2a1d947be
https://hg.mozilla.org/integration/mozilla-inbound/rev/8547992229cc
https://hg.mozilla.org/integration/mozilla-inbound/rev/99280262eba3

Comment 31

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/99280262eba3
https://hg.mozilla.org/mozilla-central/rev/8547992229cc
https://hg.mozilla.org/mozilla-central/rev/31f2a1d947be

Comment 32

[Cristian Nicolae (:xti)]

Verified fixed on:
Mozilla/5.0 (Android;Linux armv7l;rv:9.0a1)Gecko/20110926
Firefox/9.0a1 Fennec/9.0a1
Device: Acer ICONIA A500
OS: Android 3.1