Closed Bug 628235 Opened 13 years ago Closed 11 years ago

Moving selected tab to another group should still display selected tab

Categories

(Firefox Graveyard :: Panorama, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: fryn, Unassigned)

References

Details

(Keywords: ux-consistency, ux-userfeedback)

Steps to reproduce:
1. Open two tabs.
2. Select the right tab.
3. Right-click the right tab, and select "Move to" -> "New Group".

Expected result:
The selected tab is still selected and displayed its new group.

Actual result:
Only the left tab is left, with no visual indication of where the formerly selected tab went. (For users unfamiliar with Panorama, this might be perceived as dataloss.)

An example of existing tab movement feedback: When moving a tab to another window, the newly created window becomes active.

An advantage of the current behavior: User selects a tab to examine its contents before moving it. User moves the tab to another group. Now, the user can quickly select other tabs in the current group to view or move.

A disadvantage of the current behavior: User moves the selected tab. It was selected, which is an indication that the user still wants to look at the tab's contents, but now it takes several keypresses or clicks to get back to it.
This issue will be mitigated by the fixing of bug 626525.
See Also: → 626525
Another advantage of the current model is that we can right-click on tabs that we are not currently viewing and move them to other groups.

It's true that we are optimizing for the above case instead of "I am viewing this tab, which I'd now like to move to another group and follow it there", but I think it's a more common/useful case.

I'd be open to making the behavior different depending on if you were acting on a tab that you were or were not viewing. i.e. keep the existing behavior if you right click on a tab that you are not viewing, and use your proposed behavior when you right click on a tab that you are currently viewing.

Assigning to Faaborg for some ux thoughts.
Assignee: nobody → faaborg
Priority: -- → P3
Target Milestone: --- → Future
Just a thought (let's discuss a bit more before we implement anything):

What if background tabs just disappeared when moved, but if you were to do the action on the active tab (or in the future a set of multiple selected which includes the active tab) we zoomed out, quickly animated the move, and then zoomed back in with the new set of surrounding tabs.

It's a bit Google earth, but might help users build up a better mental model of where they are.
Google earth indeed! My concerns are (a) that, with our current zooming animation speeds, it'd either be very choppy (and unclear what we're doing) or take too long and (b) this would take too long for beta 11 timeline.
yeah, I was thinking more Firefox 5 with that suggestion
I was just thinking on this, before even seeing this bug, of creating another bug about adding menu items new tab menu to manage tabs or organize tab groups, that would really help this issue, make it possible that users can find Panaroma in the first place from the Firefox Menu.  Why didn't we of needing menu items for Panorama being the obvious necessity for users and not just tab->move hope I find where it went?
(In reply to comment #3)
> Just a thought (let's discuss a bit more before we implement anything):
> 
> What if background tabs just disappeared when moved, but if you were to do the
> action on the active tab (or in the future a set of multiple selected which
> includes the active tab) we zoomed out, quickly animated the move, and then
> zoomed back in with the new set of surrounding tabs.
> 
> It's a bit Google earth, but might help users build up a better mental model of
> where they are.

Sounds like a good way to address Fryn's complaint and build associations with what's actually happening. Granted we can get zoom fast/pretty enough, I like it.
(In reply to comment #3)

Awesome!

(CC'ing you, in case the assignee value gets replaced with an implementer.)
Keywords: ux-userfeedback
Whiteboard: ux-feedback
Assignee: faaborg → nobody
Keywords: ux-consistency
Priority: P3 → --
Target Milestone: Future → ---
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.