Closed Bug 597767 Opened 14 years ago Closed 13 years ago

Implement better new tab button experience

Categories

(Firefox Graveyard :: Panorama, defect, P1)

defect

Tracking

(blocking2.0 -)

RESOLVED WONTFIX
Future
Tracking Status
blocking2.0 --- -

People

(Reporter: aza, Unassigned)

References

Details

(Whiteboard: [b8][interaction])

Specification here: http://img.skitch.com/20100629-ghhe5crt9c4qjx9w6ckfn585p.png

This is how I expect the feature to be implemented:

* We already have code around for handling the old new tab groups which keeps a tab position at the end occupied with a button that looks like a blank tab.
* Re-use that code, so that every group lays itself out as if it contained one more tab than it actually has, and that the tab is visually displayed as a slim sliver (as per the mockup).
* It is incredibly important that the animation that happens when the new tab is created is very very fast. When you want to make a new tab, waiting is unacceptable so we should be less than 300ms total on an animation.
Assignee: nobody → mitcho
blocking2.0: --- → ?
Priority: -- → P1
Whiteboard: [b8][interaction]
Target Milestone: --- → Firefox 4.0
Blocks: 597043
Aza, what should we do in groups where the last row of tabs fill the entire last row? As we also want to decrease the whitespace below the last row of tabs (bug 595224), it would not make sense to force an additional row of space just in order to place the thin new tab button at the very left of that bottom row. What do you think?

Also, Aza, how should we handle animations where adding that new tab will rejiggle the layout so that it tips the scale and adds another column, or what to do if that new tab causes it to stack?
Here's another exciting question: where does the "new tab" button go on a stack? Perhaps for stacks we keep the current style of "new tab" button?
* In stacks, the new tab button should remain as it is now (in the lower-left corner)
* In terms of animation, this is how to do it: once clicked, the sliver of a new tab doesn't cause any reflows. Instead, it starts the zoom in animation. This way it feels super quick (just 300ms). It does mean that the animation will do the zoom in, the change in aspect ration, and a fade of background color of white all at the same time.
* I think in the edge-case that the bottom row is filled (and only in that case), we'll need to jigger things a bit. Either we'll need to steal a little room from each tab in the bottom row to make room for the new-tab sliver, or from the last tab in the bottom row. Mockups to follow.
Sketch of taking space from the last tab in the bottom row: http://img.skitch.com/20100923-qgn7dpsq2d88f74gu8gxacer6.png
I think - as much as it might suck - we can live without this feature in Firefox 4, and would rather we focus on the other blockers we have before adding new functionality.
blocking2.0: ? → -
Priority: P1 → --
Beltzner, you are right that we can ship without this fix. On the other hand, we've gotten reports that people haven't found the new-tab button, and the animation is certainly too long.

The quick fix is to simply remove the animation.

I believe, however, that Mitcho has a mostly done WIP to implement this.
(In reply to comment #6)
> I believe, however, that Mitcho has a mostly done WIP to implement this.

I do hope to get to this soon, but I should note that I do *not* yet have a mostly done WIP. If we are reconsidering whether this should be done, or what the spec should be, now would be the time for that.
We can also just speed up the animation by removing the first stage (where things rearrange). I realize we wanted that to make it clear what was going on, but I don't think we really need it; it's plenty obvious where your new tab went when you zoom back out from it. 

As for not being able to find the new tab button, I think that's fine as well, as it's not essential to the experience. You can still create new tabs by going into a group and clicking the plus on the tab bar, and the new tab command key also works from within Panorama. The new tab button nicely rounds out the experience, but people can get along just fine without discovering it.
After implementing bug 600646 (Speed up the new tab animation) I think it is less important to get the new tab stuff. Even though it makes me sad, I'll bump this to the future as there are more high priority things to work on.
Assignee: mitcho → nobody
No longer blocks: 597043
Priority: -- → P1
Target Milestone: Firefox 4.0 → Future
An "add tab button" like that I think is too intrusive and could confuse the
user trying to move that button around like normal tabs.

I suggest a related usability feature: a different new tab button for newly
created groups.
For example: when I create a new group dragging the mouse in a empty area I
have an empty group that will be used either for dragging other tabs in or
because I'm going to start another workflow; in the latter case I usually
create a new tab inside the empty group; in this situation the + button is too
small so I suggest that double clicking (or single clicking) the empty group
should zoom(with the default animation) the group with a newly created empty
tab.

This because in many laptops pointing the small plus button in the left bottom
corner is sometimes difficult.
Maybe the mockup of the new group should have a big plus sign button (grey on
grey with no borders) in the center of the rectangle and not a small one on the
left-bottom corner.
This big center button should fallback to the default one if I drag some tab
from an old group to the new empty one.

I hope that this motivation is sufficiently clear and why I'm filling this
bug/suggestion.

thanks!

FF 4.0b7
Depends on: 663613
Bug 663613 landed.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.