Closed Bug 630792 Opened 12 years ago Closed 7 years ago

Add a close button and small toolbar to Tab View

Categories

(Firefox Graveyard :: Panorama, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: faaborg, Unassigned)

References

Details

(Keywords: uiwanted)

Two problems with the current close behavior of Tab View:

1) When panorama is displayed, you can't close the application on Windows (Bug 617352)

2) The panorama button significantly changes location when you have a maximized window (not yet filed):

To solve both of these, I would like us to consider reverting Bug 587043 which introduced a mode to the application close button, and instead present the user with an actual close button in Tab View.

I believe the main reason that users are currently going for the window control is that the panorama button does not seem to be a convincing target for closing the view.  Also, the user may not have entered panorama using the button (in the case of the menu and the keyboard shortcut) so we can't plan for them to exit the same way that they came in.  It's not that Bug 587043 wasn't a problem, it's just the solution we currently have of a modal close button isn't a clean solution, and creates an additional set of problems.

If we switch to using a close control:

-The path out will be clearer
-We won't have to conflate closing a feature versus closing the application (especially after all of the work we put into creating a browser level versus a tab level)
-We won't have to worry about maintaining the position of the panorama button, which is a moving target (especially now that it is starting in the customization palette)
I am all for getting the behavior of bug 617352 and/or bug 608330 worked out. 

Some work that's been done in this area is here:

https://wiki.mozilla.org/Firefox/Projects/TabCandy/Design/FirstRun

... under the "getting out" section. I think this style of those exit buttons not only serves as a way to get out of Panorama, but also helps educate the user as to where they are (one of the reasons bug 587043 was implemented). We can be much more explicit about what the button does (option g, specifically) than a small red x, or red ball, have a smaller UI footprint as it's in the toolbar, and keep the different platforms similar.
I think for the Fx4 time frame, all we can realistically do is revert bug 587043. Adding the new button bar is a feature, and we'll probably want to kick around a few designs before implementation.
Priority: -- → P3
Target Milestone: --- → Future
There could also be string implications which make this impossible for fx4. :( Future indeed.
Blocks: 603789
(In reply to comment #4)
> *** Bug 633832 has been marked as a duplicate of this bug. ***
How is it a duplicate if it has an entirely different idea?
(In reply to comment #5)
> (In reply to comment #4)
> > *** Bug 633832 has been marked as a duplicate of this bug. ***
> How is it a duplicate if it has an entirely different idea?

Please re-opern bug 633823.  Since I think we are going to implement this but it's likely to happen for Fx4
bugspam
Target Milestone: Future → ---
Is this the design we are planning to implement?
http://areweprettyyet.com/4/panorama/
(In reply to comment #8)
> Is this the design we are planning to implement?
> http://areweprettyyet.com/4/panorama/

I think that design was rushed so we'd have a chance to get it in Fx4. Now that that deadline has passed, let's take our time and get it right.
Keywords: uiwanted
Version: unspecified → Trunk
When thinking about the new design we should also consider bug 607383. I like the direction of Matthew's proposal :)

https://bug607383.bugzilla.mozilla.org/attachment.cgi?id=508350
(In reply to comment #10)
> When thinking about the new design we should also consider bug 607383. I like
> the direction of Matthew's proposal :)

Reducing redundancy is good.
Matthey proposes more UI on hover, and that is not good.
(Limi could give you a whole lecture on this.)

> https://bug607383.bugzilla.mozilla.org/attachment.cgi?id=508350

This proposal is by Debloper, not Matthew. I like it.
The UX team has discussed ideas similar to this, but it's always nice to have a mockup.
(In reply to comment #11)
> > https://bug607383.bugzilla.mozilla.org/attachment.cgi?id=508350
> 
> This proposal is by Debloper, not Matthew. I like it.

Oops. The link was correct but not the name. So we two like the same proposal, perfect :)
I'll need to go over this again with the rest of the UX team.  A few things we are looking for though:

-non-redundant app tabs
-(probably) an on screen control for creating a new group, instead of relying on clicking and dragging
-(probably) an actual close button, instead of relying on the panorama glyph to exit
Blocks: 586175
No longer blocks: 603789
bugspam
No longer blocks: 653099
bugspam
Blocks: 660175
Blocks: 626666
bugspam

(Fx7 was branched, removing open bugs from Fx7 meta bug, we won't create new meta bugs for upcoming Fx versions)
No longer blocks: 660175
Blocks: 607383
Panorama has been removed from Firefox 45, currently in Beta and scheduled for release on March 7th. As such, I'm closing all existing Panorama bugs.

If you are still using Panorama, you will see a deprecation message in Firefox 44, and when 45 is released your tab group data will be migrated to bookmarks, with a folder for each group. There are also a few addons offering similar functionality.

See https://support.mozilla.org/en-US/kb/tab-groups-removal for more info.

We're removing Panorama because it has extremely low usage (about 0.01% of users), and has a large number of bugs and usability issues. The cost of fixing all those issues is far too high to justify, and so we'll instead be focusing our time and energy on improving other parts of Firefox.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.