Closed Bug 677669 Opened 8 years ago Closed 8 years ago

In tablet mode, the tab bar should be always visible

Categories

(Firefox for Android Graveyard :: General, defect)

defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED
Firefox 9

People

(Reporter: mbrubeck, Assigned: mbrubeck)

References

Details

Attachments

(1 file, 5 obsolete files)

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/
Attached patch WIP (obsolete) — Splinter Review
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/
Assignee: nobody → wjohnston
Comment on attachment 551946 [details] [diff] [review]
WIP

Doh. Wrong bug.
Attachment #551946 - Attachment is obsolete: true
Depends on: 682037
Attached patch WIP (obsolete) — Splinter Review
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.
Depends on: 651821
Blocks: 680077
Attached patch WIP 2 (obsolete) — Splinter Review
This fixes scrollbar positioning and some layout issues.  It doesn't yet feature the planned differences between portrait and landscape modes.
Assignee: wjohnston → mbrubeck
Attachment #555848 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attached patch part 1 (obsolete) — Splinter Review
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.
Attachment #557299 - Attachment is obsolete: true
Attachment #557368 - Flags: review?(mark.finkle)
Blocks: 682467
Attached patch part 1 (obsolete) — Splinter Review
Rebased against latest mozilla-central code.
Attachment #557368 - Attachment is obsolete: true
Attachment #557368 - Flags: review?(mark.finkle)
Attachment #557980 - Flags: review?(mark.finkle)
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.
Attachment #557980 - Flags: review?(mark.finkle) → review+
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.
Attached patch patch v3Splinter Review
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.
Attachment #557980 - Attachment is obsolete: true
Attachment #558618 - Flags: review+
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.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Summary: In tablet mode, the tab bar should be always visible and single-column → In tablet mode, the tab bar should be always visible
Target Milestone: --- → Firefox 9
Blocks: 685310
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
https://hg.mozilla.org/integration/mozilla-inbound/rev/984bb7e03a11
Status: REOPENED → ASSIGNED
Whiteboard: [inbound]
Target Milestone: Firefox 9 → ---
http://hg.mozilla.org/mozilla-central/rev/984bb7e03a11
Status: ASSIGNED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → Firefox 9
Depends on: 685541
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
Status: RESOLVED → VERIFIED
Blocks: 685878
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)
(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.
(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.
(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.
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.
(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.
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.
(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.
(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?
(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).
Depends on: 686417
Bug 686417 has been filed to figure out how to hide or shrink the sidebar.
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!
You need to log in before you can comment on or make changes to this bug.