Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

VERIFIED FIXED in Firefox 9

Status

Fennec Graveyard
General
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: smaug, Assigned: mbrubeck)

Tracking

(Depends on: 2 bugs, Blocks: 2 bugs, {ux-minimalism})

Trunk
Firefox 9
All
Android
ux-minimalism
Dependency tree / graph

Details

Attachments

(4 attachments, 6 obsolete attachments)

(Reporter)

Description

6 years ago
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)
(Assignee)

Comment 1

6 years ago
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.)
Blocks: 677669, 655762
tracking-fennec: --- → ?
Keywords: uiwanted, ux-minimalism
Summary: Tabs on the left take way too much space from the content on tablet → [Tablet] Add a way to hide the tabs sidebar in landscape tablet mode
(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?)
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)
Matt, can we try enabling a similar interaction to our phone browser, where you slide the tabs in and out from the left?
(Assignee)

Comment 5

6 years ago
(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.

Updated

6 years ago
Blocks: 686522
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.

Updated

6 years ago
Duplicate of this bug: 685534
(Assignee)

Comment 8

6 years ago
Created attachment 560581 [details] [diff] [review]
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).
Assignee: nobody → mbrubeck
Status: NEW → ASSIGNED
(Assignee)

Updated

6 years ago
Depends on: 685285, 685839

Comment 9

6 years ago
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.
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.
Created attachment 560988 [details]
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.
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.
(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.)
(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.
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.
(Assignee)

Comment 16

6 years ago
Created attachment 561315 [details] [diff] [review]
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.
Attachment #560581 - Attachment is obsolete: true
(Assignee)

Comment 17

6 years ago
Created attachment 561332 [details] [diff] [review]
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.
Attachment #561315 - Attachment is obsolete: true
(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.)
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.
tracking-fennec: ? → 9+
(Assignee)

Comment 20

6 years ago
Created attachment 561600 [details] [diff] [review]
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.
Attachment #561332 - Attachment is obsolete: true
(Assignee)

Updated

6 years ago
Attachment #561600 - Attachment description: WIP 4 → part 1: Make the tab bar hideable
(Assignee)

Comment 21

6 years ago
Created attachment 561613 [details] [diff] [review]
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
(Assignee)

Comment 22

6 years ago
Created attachment 561650 [details] [diff] [review]
1/3: cache sidebar width
Attachment #561650 - Flags: review?(mark.finkle)
(Assignee)

Comment 23

6 years ago
Created attachment 561654 [details] [diff] [review]
2/3: make the tab bar hideable
Attachment #561600 - Attachment is obsolete: true
Attachment #561654 - Flags: review?(mark.finkle)
(Assignee)

Comment 24

6 years ago
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.
Attachment #561613 - Attachment description: part 2: allow dragging in the tab sidebar → 3/3: allow dragging in the tab sidebar
Attachment #561613 - Flags: review?(mark.finkle)
Attachment #561650 - Flags: review?(mark.finkle) → review+
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.
Attachment #561654 - Flags: review?(mark.finkle) → review-
Comment on attachment 561613 [details] [diff] [review]
3/3: allow dragging in the tab sidebar

r+, but update this for the ViewAreaObserver -> Browser change
Attachment #561613 - Flags: review?(mark.finkle) → review+
(Assignee)

Comment 27

6 years ago
Created attachment 561762 [details] [diff] [review]
2/3: make the tab bar hideable

Move sidebar-grabby code into Browser.
Attachment #561654 - Attachment is obsolete: true
Attachment #561762 - Flags: review?(mark.finkle)
(Assignee)

Comment 28

6 years ago
Created attachment 561763 [details] [diff] [review]
3/3: allow dragging in the tab sidebar

s/ViewableAreaObserver/Browser/g.  Carrying r=mfinkle.
Attachment #561613 - Attachment is obsolete: true
Attachment #561763 - Flags: review+
(Assignee)

Updated

6 years ago
Blocks: 685308
(Assignee)

Updated

6 years ago
Duplicate of this bug: 685878
Attachment #561762 - Flags: review?(mark.finkle) → review+
(Assignee)

Comment 30

6 years ago
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
Keywords: uiwanted
Whiteboard: [inbound]
https://hg.mozilla.org/mozilla-central/rev/99280262eba3
https://hg.mozilla.org/mozilla-central/rev/8547992229cc
https://hg.mozilla.org/mozilla-central/rev/31f2a1d947be
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → Firefox 9
(Assignee)

Updated

6 years ago
Depends on: 688800
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
Status: RESOLVED → VERIFIED
Blocks: 689494
(Assignee)

Updated

6 years ago
Depends on: 690740
(Assignee)

Updated

6 years ago
Depends on: 690739
(Assignee)

Updated

6 years ago
Depends on: 690760
(Assignee)

Updated

6 years ago
Depends on: 690816
status-firefox9: --- → fixed
You need to log in before you can comment on or make changes to this bug.