Safari 3.0: Dragging tabs up or down to move them sideways
Posted by Pierre Igot in: MacintoshJanuary 31st, 2008 • 10:41 am
Safari 3.0 now allows the user to organize his tabs in various ways. When you have a browser window with multiple tabs, you can shuffle the tabs around in the Tab Bar, by dragging them to the left or to the right:
As well, if you take a tab in a Safari window and drag it up or down beyond the top or bottom of the Tab Bar, it turns into a proxy for the entire page loaded in the tab and you can either drop this proxy in another Safari window to add the tab to that window or you can release the mouse button while not hovering over an existing Safari window and then Safari will open a new window with the page in question:
What is important to note here, however, is that these are two separate procedures, and it is the direction of your initial mouse movement that will decide what Safari allows you to do. If you grab a tab and start moving horizontally to the left or to the right, then all you can do is shuffle the tab order in the current Tab Bar. You cannot drag the tab beyond the edges of the Tab Bar.
If, on the other hand, you grad a tab and start moving vertically up or down, then Safari allows you to either take the tab out of the current Tab Bar and into another window’s Tab Bar or to create a new window with it or change your mouse movement to an horizontal slide across the current Tab Bar to shuffle its tab order.
In other words, if your initial mouse movement is vertical, Safari does not restrict you in what you can do with the tab. But if your initial mouse movement is horizontal, Safari restricts you to shuffling tabs within the current Tab Bar.
I find this rather strange. Why should my initial mouse movement determine what I can do or not do with the tab? Consider the following situation: You have two Safari windows open side by side on your screen. They are level with each other, meaning that their Tab Bars are in perfect horizontal alignment. Now you click on the second or third or fourth tab in one of the Tab Bars and try to drag it to the other window’s Tab Bar. Since the Tab Bars are aligned with each other, the natural thing is to drag your tab horizontally in the direction of the other Tab Bar.
But if you do that, the restriction described above will apply and you will not be able to drag the tab beyond the left or right edge of its current Tab Bar. Instead, if you want to drag the tab from one of the windows to the other, you first need to do a counterintuitive thing: You need to start by dragging the tab up or down. Then if you change the direction of your mouse movement and drag horizontally you’ll be able to take the tab beyond the edges of its current Tab Bar and move it to the other window.
It gets even stranger, though: The restriction I’ve just described with horizontal movements applies to all tabs in the Tab Bar except for the very first one on the left. When it comes to the very first tab in the Tab Bar, you can take the tab beyond the left edge of the window even with a strictly horizontal mouse movement. If you do that, Safari uses the same proxy behaviour as with vertical mouse movements and lets you take the tab beyond the edges of the window. But this only works for the very first tab on the left.
I really don’t see the purpose of the restriction for the other tabs in horizontal mouse movements. After all, it’s not like people are really likely to accidentally drag a tab too far horizontally. You cannot drag a tab by its left-most area, because that’s where the small close button is:
You have to click somewhere to the right of this close button in order to be able to drag the tab. This means that the “hot spot” in the item you are dragging (the actual tip of the mouse pointer’s arrow), which determines the actual location of the drop, is somewhere near the middle of the tab. So this makes it rather unlikely that you will accidentally move your hot spot too far to the left or to the right when shuffling tabs around in a Tab Bar. Yet this is the only purpose that I can think of for this restriction in horizontal tab dragging.
(On a side note, the option not to show the Tab Bar by default when opening a new Safari window is gone from Safari’s preferences. Now, when you open a new Safari window, Safari simply uses the current Safari window as the reference for deciding whether to show or hide the Tab Bar. If the current Safari window has its Tab Bar hidden, then the new window will have its Tab Bar hidden too. If the current window has its Tab Bar visible, then the new window will have its Tab Bar visible too.)
January 31st, 2008 at Jan 31, 08 | 11:23 am
I am not dragging tabs frequently, but this behaviour puzzles me every single time I do it
January 31st, 2008 at Jan 31, 08 | 1:57 pm
It allows you to be imprecise. As long as you start dragging horizontally, you don’t have to keep moving in a straight and careful line to your destination.
You’re not likely to accidentally grab a tab too far horizontally, but you’re quite likely to drag a tab too far vertically when you only wanted to move it horizontally.
This is similar to scroll bars — you can start dragging the scroll thumb up or down, and the mouse can wander left or right all the way to the edge of the screen; yet you keep scrolling. Compare to Windows, where a small amount of motion in the other dimension will reset the scroll bar to its original point. It’s quite frustrating, and you end up spending much more energy on precision that doesn’t factor into the action you’re actually trying to take.
The leftmost tab stays restrained to the tab bar if you move it to the right, it’s only if you move it away from the tab bar with your initial movement — that is, toward the left — that it doesn’t. (Logically, this probably “ought to” apply to the rightmost tab too, but maybe only when it’s actually near the window edge.)
January 31st, 2008 at Jan 31, 08 | 2:14 pm
Dan: The difference is that the Tab Bar is much wider (thicker) than a scroll bar… So there is already a lot of room for imprecision without getting out of the Tab Bar.
And it also does not explain why the user cannot take the tab beyond the window’s edges. Vertical precision within the relatively narrow Tab Bar is one thing. Horizontal precision within the width of the Safari window is quite another :).
January 31st, 2008 at Jan 31, 08 | 3:14 pm
My tab bar is only 5 pixels taller than my scroll bar is wide (14 v. 19).
I expect that the most common tab movement is to move a tab to the far right or far left, in which case there’s a Fitt’s Law argument with regard to the window edges — you can fling the tab to the edge and it will stick.
I certainly could be wrong about those being most common, that’s based only on my own behavior. (When I move tabs, I’m usually moving something to the left edge; with my intent being “I want this to be the only item remaining when I’ve read and closed the rest of the tabs.”)
January 31st, 2008 at Jan 31, 08 | 4:07 pm
5 pixels does make quite a difference, I find :).
I understand what you’re saying about Fitt’s Law, but what I am trying to say is that the likelihood of “overshooting” in the case of tabs is pretty remote, because the mouse pointer is usually somewhere in the middle. If you study the behaviour carefully, you’ll see that, when the mouse pointer is in the middle of the tab and you move the tab right against the left edge, the tab stops moving as soon as its left edge hits the left edge of the window, even if you continue to move the mouse pointer to the left. So there is already a margin of tolerance for overshooting built in because of this behaviour.
What I am saying is that if the user drags his tab all the way to the left edge of the window and continues to move his mouse pointer all the way to the left edge of the tab and beyond, even after the tab has already gone as far to the left as it could, then there is a very good chance that he actually does mean to take the tab beyond the left edge of the window.
Same thing on the right hand side, where there is also a built-in margin of tolerance for overshooting, because the mouse pointer will always be more or less in the middle of the tab (unless you deliberately try to click near the right edge of the tab).
But of course maybe some people do throw their mouse all the way to the other side of their screen each time they want to move something to the left or to the right :-).
January 31st, 2008 at Jan 31, 08 | 5:17 pm
Pierre,
The tab view behavior is under the view menu. I think they removed it from the preferences since you can always have them showing or turn them off with the view menu command. In multi tab windows the command is grayed out, so it’s only available when you have a single page open in a window.
This is most likely a concession to the ability to drag tabs from one window to another. If you don’t want new pages to open with tabs make sure the menu command says “Show Tab Bar”.
As far as the tab behavior I disagree that the up or down movement is counterintuitive. Considering this is a new behavior and any real life metaphor is limited, how can its behavior be counterintuitive? I feel they are akin to lifting the page out of a ring binder, up then over to a different binder. The up or down move says, “I want to remove this tab from this tab bar.” I think your argument is based on your screen real estate. On most laptops, the windows will not be side by side. On my iBook I will move one window lower than the one behind it and drag the tab up to move it to the other window. So, perhaps it’s a case of not being able to account for all configurations.
The single tab behavior is strange to me. If I have 2 windows each with a single tab, when I select a tab it should automatically create the proxy. Why would I want to move a single tab horizontally if when i release the tab it returns to the far left side of the window.
February 1st, 2008 at Feb 01, 08 | 9:03 am
Yes, I suppose that the fact that I have a large screen might have something to do with it, although the two Safari windows don’t necessarily have to be both fully visible to be aligned horizontally with each other…
Still, I can’t help but feel that the restrictions placed by Apple are quite unnecessary, even on smaller screens. As you pointed out yourself with the single tab behaviour, the whole thing could use a little more fine-tuning.
February 1st, 2008 at Feb 01, 08 | 3:24 pm
I think the current behavior is on the right track. If I were tweaking it, I’d do three things. First, if you’re doing a horizontal drag, and you drag outside the window area, but you also move vertically, I’d switch to the proxy. If you stay on or near horizontal line with the tab bar, but overshoot the window edge, that’s one thing; but if your mouse ends up significantly out of the zone of the existing tab bar both horizontally and vertically, I think a clear case can be made for the user’s intent being to create a new window.
Second, if you drag a tab outside the window boundary and the mouse is over the tab bar of another existing Safari window, it should move the tab to that new window regardless of any other rules — even if it’s directly lined up horizontally with the existing window’s tab bar.
(The other tweak I’d make is only tangentially related, but I think you should be able to option-drag a tab to duplicate it.)
February 1st, 2008 at Feb 01, 08 | 5:03 pm
Sounds reasonable to me :).
April 9th, 2008 at Apr 09, 08 | 11:37 pm
I like the way it works.
It feels natural to “pluck” the tab off the tab bar to wave it around freely. But I can slide it around in the tab bar while hardly taking my eyes off the page, and I don’t worry about an unexpected change of context by absently dropping it into another window.
I can’t help thinking that the behaviour is more complex, like the split-second pause required to drag a window’s proxy icon or some selected text, but whenever I slow down to test the theory, it just seems like a 45° dragging threshold that determines the result.
April 10th, 2008 at Apr 10, 08 | 1:17 am
[…] Source: Safari 3.0: Dragging tabs up or down to move them sideways. Secondary, source: Safari’s Tab Dragging Modes. […]
April 12th, 2008 at Apr 12, 08 | 10:52 pm
I also thought Safari’s tab dragging was a little weird, but also familiar. I was thinking about it and the bookmarks bar works in a similar way. It has two dragging modes, one that removes and another that rearranges. Like the tabs, the mode is determined by the initial direction in which you drag.
With the bookmarks bar this mode specific dragging makes sense. It’s convenient for the user to grab an item and move it left or right without worrying about precisely dropping it back on the bar. It’s likely that the cursor will stray from the bar while rearranging an item, but through initiating the drag the user is protected against accidental deletion. It look like Safari actually gives preference to horizontal dragging over vertical dragging, if you drag at 60? from the horizonal (i.e. mostly vertical) Safari will still assume you’re wanting to initiate a horizontal drag. You need to show more intent if you want to remove items from the bookmarks bar.
I think they were probably trying to maintain some design integrity when making the tab-bar and bookmarks bar behave in similar ways due to their close proximity. While it isn’t as important to protect the user against spawning new windows compared with deleting a bookmark, it still speeds up the interface (preventing the creation of the translucent page thumbnail when just shuffling tabs) and makes it easy for the user to rearrange tabs without having to keep the cursor along the thin tab-bar strip.
April 13th, 2008 at Apr 13, 08 | 4:06 pm
It’s true that there is some degree of consistency with the Bookmarks Bar. But then, I’ve never liked the way the Bookmarks Bar works either. The prevention of accidental deletion would be much easier to achieve by making deleting items in the Bookmarks Bar less easy!
If moving items around in the bar required the use of a modifier key, it would be much less likely to have accidental poofs. Same with the Dock. I cannot count the number of times I have had to help users recover their lost Dock icons. It’s ridiculous.
Most of them don’t know how to properly manage the Bookmarks Bar anyway, though. So it’s very likely that the nuances of the two modes is completely lost on them. And most of them don’t use tabs in Safari anyway.
As for people who actually use these features, I think they know enough about what they are doing that they don’t need the extra “protection” that Apple purports to give them through these two modes.