677669 - In tablet mode, the tab bar should be always visible

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Matt Brubeck (:mbrubeck)]

When the tablet layout is active (bug 656329), tabs should appear in a fixed-position sidebar on the right side of the screen.  The sidebar should show a single column of tabs, and it should scroll if the tabs overflow the screen.

Wireframe:
http://flickr.com/photos/49885370@N03/6007122319/in/set-72157627228117277/

Comment 1

[Wesley Johnston (:wesj)]

Attachment: WIP

This is a WIP. Mostly seems to work, but fails a few "urlbar text should/should not be selected" tests in browser_awesomescreen.js. Shots no an ASUS transformer at:

http://www.flickr.com/photos/digdug2k/sets/72157627396682370/

Comment 2

[Wesley Johnston (:wesj)]

Comment on attachment 551946 [details] [diff] [review]
WIP

Doh. Wrong bug.

Comment 3

[Matt Brubeck (:mbrubeck)]

Attachment: WIP

This is a kinda-working start of a patch to move the tab bar back to the left and keep it visible next to the browser.  The urlbar position is wrong, and there are some issues with things like scrollbars.

Comment 4

[Matt Brubeck (:mbrubeck)]

Attachment: WIP 2

This fixes scrollbar positioning and some layout issues.  It doesn't yet feature the planned differences between portrait and landscape modes.

Comment 5

[Matt Brubeck (:mbrubeck)]

Attachment: part 1

This moves the tab bar to the left in landscape tablet mode, and keeps it as a popup in portrait tablet mode.  It does not provide any new theming for either of them.  It also does not change the tab bar to be single-column and scrollable.

I moved the tablet CSS into a single include file so that I don't have to keep it in sync across three files.  I think we should do something like this to more of our CSS.

Comment 6

[Matt Brubeck (:mbrubeck)]

Attachment: part 1

Rebased against latest mozilla-central code.

Comment 7

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

Comment on attachment 557980 [details] [diff] [review]
part 1

I'm willing to give this style of CSS a try. I have a pessimistic worry that the amount of %ifdef sections in toolbar.css will grow and might become a maintenance issue.

We'll never know unless we give it a shot though.

Comment 8

[Lucas Rocha (:lucasr)]

Matt, it would be nice if you updated your patch to use Util.isTablet() instead of checking for 'tablet'  attribute. See the patch 1/3 in bug 680077.

Comment 9

[Matt Brubeck (:mbrubeck)]

Attachment: patch v3

Just removed an unused line of code.  Carrying r=mfinkle.

(In reply to Lucas Rocha from comment #8)
> Matt, it would be nice if you updated your patch to use Util.isTablet()
> instead of checking for 'tablet'  attribute. See the patch 1/3 in bug 680077.

I'll update your patch in bug 680077 to do this.  I don't want to do it here, because this bug might land first and I'd rather not make that change without the other changes in bug 680077.

Comment 10

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/24d45fb71421

Marking this bug resolved; I'll file a separate bug to make the tab bar scroll vertically in tablet mode.

Comment 11

[(no longer active)]

This was part of the backout that I did because of possible zooming (bug 685541) and panning regressions (bug 685540):

http://hg.mozilla.org/mozilla-central/rev/4be2da039559

Comment 12

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/984bb7e03a11

Comment 13

[Matt Brubeck (:mbrubeck)]

http://hg.mozilla.org/mozilla-central/rev/984bb7e03a11

Comment 14

[Aaron Train [:aaronmt]]

Samsung Galaxy Tab 10.1 (Android v3.1)
Mozilla/5.0 (Android; Linux armv7l; rv:9.0a1) Gecko/20110909 Firefox/9.0a1 Fennec/9.0a1

Comment 15

[Antoine Turmel [:GeekShadow]]

The sidebar is eating web page space, it would be better to have tabs on top or the ability to hide the sidebar, like on phone interface.

Fennec 9 : http://dl.dropbox.com/u/364419/temp/fennec9_tabs.png (200px left)
Honeycomb 3.2 Browser : http://dl.dropbox.com/u/364419/temp/honeycomb32_tabs.png (60px up)

Comment 16

[Asa Dotzler [:asa]]

(In reply to Antoine Turmel from comment #15)
> The sidebar is eating web page space

Yes. That was intentional. See the Summary of this report and the first Description comment. The designers and developers were aware that this was going to use up space. You can see that in the Description and the Wireframe mock-up linked there.

Comment 17

[Mounir Lamouri (:mounir)]

(In reply to Asa Dotzler [:asa] from comment #16)
> (In reply to Antoine Turmel from comment #15)
> > The sidebar is eating web page space
> 
> Yes. That was intentional. See the Summary of this report and the first
> Description comment. The designers and developers were aware that this was
> going to use up space. You can see that in the Description and the Wireframe
> mock-up linked there.

You seem to be replying to something else, I don't think Antoine's comment was asking if it was intentional or not but that on-top tabs would be better compared to tabs on the left.
There is indeed a mock-up with the tabs on left design but I don't see anything in the bug explaining why this has been chose against tabs on top.

Comment 18

[Asa Dotzler [:asa]]

(In reply to Mounir Lamouri (:volkmar) from comment #17)
> (In reply to Asa Dotzler [:asa] from comment #16)
> > (In reply to Antoine Turmel from comment #15)
> > > The sidebar is eating web page space
> > 
> > Yes. That was intentional. See the Summary of this report and the first
> > Description comment. The designers and developers were aware that this was
> > going to use up space. You can see that in the Description and the Wireframe
> > mock-up linked there.
> 
> You seem to be replying to something else, I don't think Antoine's comment
> was asking if it was intentional or not but that on-top tabs would be better
> compared to tabs on the left.

No, I'm not replying to someone else. Antoine made the comment that tabs on the side was eating too much space. I made the comment that this bug was in fact explicitly about putting tabs there and that the designers and developers who did this knew full well that it was going to take up space. I don't think that Antoine added any new information to this bug other than "I don't like this feature and would prefer it were designed and implemented differently".

I've been following this design progression very closely and I can assure you that tabs on the side and always visible was not some accident of coding or confusion in the design. This has been in design stages for months with a wide variety of mocks and experiments, and "you should do it the other way" in the implementation bug isn't really that useful.

This bug is resolved and verified fixed, and working "as designed".  If you think there's something wrong with the design or the implementation, I suggest starting a UX discussion group post or filing a bug on anything that's not currently matching the spec.

Comment 19

[Mounir Lamouri (:mounir)]

I remember seeing some mockups with a tabs on top design like in the stock browser. I don't see any justification why this design as been kept instead of the other one. Mobile UX designer chose it isn't really the kind of justification I'm expecting from an open project.

Comment 20

[Asa Dotzler [:asa]]

(In reply to Mounir Lamouri (:volkmar) from comment #19)
> I remember seeing some mockups with a tabs on top design like in the stock
> browser. I don't see any justification why this design as been kept instead
> of the other one. Mobile UX designer chose it isn't really the kind of
> justification I'm expecting from an open project.

I accept when engineers make decisions about how to write code. I accept that engineers know what they're doing, have really solid skills, and have a rigorous review process to make sure they're writing decent code. But you don't accept that designers can also know what they're doing, have really solid skills, and have a rigorous review process to make sure they're producing decent designs? A community where coders are trusted to make difficult decisions on code and designers aren't trusted to make difficult decisions on design isn't the kind of open source project I want to work on.

Comment 21

[Wesley Johnston (:wesj)]

We're reading and thinking about feedback, but bugzilla probably isn't the best place (i.e https://bugzilla.mozilla.org/page.cgi?id=etiquette.html). I think Ian/Madhava are happy to take feedback on his blog:

http://ianbarlow.wordpress.com/2011/08/30/firefox-for-tablets/

Or you can send in feedback through newsgroups, email, irc, etc:

http://groups.google.com/group/mozilla.dev.platforms.mobile/

Things are constantly evolving/changing. Happy to respond to questions/concerns like this there.

Comment 22

[Matt Brubeck (:mbrubeck)]

(In reply to Antoine Turmel from comment #15)
> The sidebar is eating web page space, it would be better to have tabs on top
> or the ability to hide the sidebar, like on phone interface.

I agree that the persistant sidebar often gets in the way.  We're talking now about adding a way to hide or toggle the tab sidebar (no bug filed yet).

In addition to the discussions linked above, http://www.briandils.com/blog/?p=65 has some more background on the many options we considered for tabs.  This is what we've decided to implement for now, but it's still very experimental and we are learning what is good and bad about it.  We'll file some follow-up bugs in the next few days and link to them here.

(In reply to Asa Dotzler [:asa] from comment #18)
> This bug is resolved and verified fixed, and working "as designed".  If you
> think there's something wrong with the design or the implementation, I
> suggest starting a UX discussion group post or filing a bug on anything
> that's not currently matching the spec.

Sorry, Asa, I appreciate your intention here, but as the developer who implemented this change I disagree with this.  Just because the UX designers and developers discussed and implemented this doesn't mean it's the final outcome of a process that is over.  We were wanting and expecting feedback about this change and questions about our next steps.  I'm happy to use this bug to provide that information.

Comment 23

[Gabriela [:gaby2300]]

(In reply to Matt Brubeck from comment #22)> 
> Sorry, Asa, I appreciate your intention here, but as the developer who
> implemented this change I disagree with this.  Just because the UX designers
> and developers discussed and implemented this doesn't mean it's the final
> outcome of a process that is over.  We were wanting and expecting feedback
> about this change and questions about our next steps.  I'm happy to use this
> bug to provide that information.

Matt, by the above, do you mean you are expecting some feedback here on the bug's comments?

Comment 24

[Matt Brubeck (:mbrubeck)]

(In reply to Gabriela from comment #23)
> Matt, by the above, do you mean you are expecting some feedback here on the
> bug's comments?

In the bug comments is fine, or at any of the blog and newsgroup links above (especially if you have longer feedback or would like to discuss it more).

Comment 25

[Matt Brubeck (:mbrubeck)]

Bug 686417 has been filed to figure out how to hide or shrink the sidebar.

Comment 26

[Gabriela [:gaby2300]]

I actually like the all present tab bar, but it does take up a lot of space. 
Maybe the simplest fix would be going back to a few builds ago when there was a tab's button showing the number of open tabs inside. In those, tapping the button would toggle on the bar tab and after selecting the wanted tab the tab bar disappeared. In fact, I'd like the actual bar tab with the earlier behaviour!