Closed
Bug 597767
Opened 14 years ago
Closed 13 years ago
Implement better new tab button experience
Categories
(Firefox Graveyard :: Panorama, defect, P1)
Firefox Graveyard
Panorama
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.
Reporter | ||
Updated•14 years ago
|
Assignee: nobody → mitcho
blocking2.0: --- → ?
Priority: -- → P1
Whiteboard: [b8][interaction]
Target Milestone: --- → Firefox 4.0
Comment 1•14 years ago
|
||
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?
Comment 2•14 years ago
|
||
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?
Reporter | ||
Comment 3•14 years ago
|
||
* 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.
Reporter | ||
Comment 4•14 years ago
|
||
Sketch of taking space from the last tab in the bottom row: http://img.skitch.com/20100923-qgn7dpsq2d88f74gu8gxacer6.png
Comment 5•14 years ago
|
||
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 → --
Reporter | ||
Comment 6•14 years ago
|
||
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.
Comment 7•14 years ago
|
||
(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.
Comment 8•14 years ago
|
||
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.
Reporter | ||
Comment 9•14 years ago
|
||
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
Comment 10•14 years ago
|
||
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
Comment 11•13 years ago
|
||
Bug 663613 landed.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•8 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•