Cannot drag & drop Tabs to Bookmark Toolbar in Firefox 9
Malcolm Turmel
The only way I can bookmark stuff now is by pressing the Star button.
How do I get the drag and drop function back in Firefox 9 nightly?
James May
https://bugzilla.mozilla.org/show_bug.cgi?id=675451
https://bugzilla.mozilla.org/show_bug.cgi?id=675444
https://bugzilla.mozilla.org/show_bug.cgi?id=674732
https://bugzilla.mozilla.org/show_bug.cgi?id=675438
As it stands, you have to hold down control before you start dragging in
order to do these things again.
Hope this helps,
James
Matt Brubeck
> I cannot drag and drop Tabs to the Bookmark Toolbar in Firefox 9.
>
> The only way I can bookmark stuff now is by pressing the Star button.
You can also still drag the favicon from the address bar to the bookmark
toolbar.
Dietrich Ayala
That would allow the behavior that has existed for so long to continue for those that use it, while also providing a cohesive model to build upon for the future detaching scenarios you reference in the bug.
We've spent years convincing people that Firefox answers to no-one but them... but then with functional regressions like this we've decided we know better. While these changes might make sense to us implementers, some of our biggest cheerleaders feel like they got punched in the face.
----- Original Message -----
> I ran into that too, but I found these:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=675451
> https://bugzilla.mozilla.org/show_bug.cgi?id=675444
> https://bugzilla.mozilla.org/show_bug.cgi?id=674732
> https://bugzilla.mozilla.org/show_bug.cgi?id=675438
>
> As it stands, you have to hold down control before you start dragging
> in
> order to do these things again.
>
> Hope this helps,
> James
>
> On 21 August 2011 18:25, Malcolm Turmel <malcolm...@gmail.com>
> wrote:
>
> > I cannot drag and drop Tabs to the Bookmark Toolbar in Firefox 9.
> >
> > The only way I can bookmark stuff now is by pressing the Star
> > button.
> >
> > How do I get the drag and drop function back in Firefox 9 nightly?
> >
> >
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Gervase Markham
> Frank, is there a reason why we can't have the detached tab snap back
> to it's original spot when dropped on an undroppable spot (toolbar,
> text field) yet *still* have the URL dropped?
Dietrich,
Not sure which "Frank" you are addressing, but this seems like a good
fix to me. Can you open a bug?
Gerv
Daniel Johansson
> fix to me. Can you open a bug?
Frank Yan who wrote the patch for bug 455694.
I like Dietrich's solution as well.
Drugoy
And it was marked as WONTFIX three times by now.
So now you are are going to confirm it? A great win for the users,
thank you Dietrich for your wise decision.
P.S.: here was discussed only one case, where we drag a tab to
Bookmarks toolbar, but it also doesn't work anymore if we drag the tab
to Bookmarks button.
Alex Faaborg
> is there a reason why we can't have the detached tab snap back to it's
> original spot when dropped on an undroppable spot (toolbar, text field) yet
> *still* have the URL dropped?
>
Not really, it makes tab tear off a more difficult UI operation because it
introduces a number of targets that all behave different (create a new
window, create a bookmark, etc.) We made a design decision that tab tear
off was a more important operation for the user and should take precedence.
Now obviously not every user is the same, and since this is a direct trade
off some people will disagree, but that's the nature of making high level
design decisions. I should also note that while Frank implemented this, it
was the UX team's call to focus the interaction purely on tab tear off.
-Alex
On Tue, Aug 23, 2011 at 10:06 AM, Dietrich Ayala <diet...@mozilla.com>wrote:
> Frank, is there a reason why we can't have the detached tab snap back to
> it's original spot when dropped on an undroppable spot (toolbar, text field)
> yet *still* have the URL dropped?
>
Dao
> We made a design decision that tab tear
> off was a more important operation for the user and should take precedence.
Is this describing, based on actual observations / data, or prescribing,
based on an idea how users /should/ interact with Firefox?
If it's describing, I'm pretty sure it's false. Lots of users don't even
seem to want multiple windows.
If it's prescribing, I'm not sure it makes sense, as I wouldn't /want/
users with <10 tabs (i.e. the majority) to mess with multiple windows.
Peter Lairo
> On 30.08.2011 00:04, Alex Faaborg wrote:
>> We made a design decision that tab tear
>> off was a more important operation for the user and should take
>> precedence.
>
> seem to want multiple windows.
Datapoint: I *only* dragged tabs to create bookmarks. I *never* use it
to create a new window.
To create a bookmark, the current design forces me to find and target
the much smaller favicon at the beginning of the URL. (I don't like the
"two clicks on the yellow Star" method because the folder selection UI
sucks)
> If it's prescribing, I'm not sure it makes sense, as I wouldn't /want/
> users with <10 tabs (i.e. the majority) to mess with multiple windows.
Agreed. And users who open >10 tabs will know how to use context menus
("Move to new window").
I suspect this is a classic case of "I figured out how to show this cool
thumbnail of the web page while dragging it. I'll put it into the
drag-tab-function so everyone can see how cool I am and how cool Firefox
is".
--
Regards,
Peter Lairo
Bugs I think are important:
https://bugzilla.mozilla.org/show_bug.cgi?id=250539
https://bugzilla.mozilla.org/show_bug.cgi?id=391057
https://bugzilla.mozilla.org/show_bug.cgi?id=436259
https://bugzilla.mozilla.org/show_bug.cgi?id=446444
Islam: http://www.jihadwatch.org/islam101/
Israel: http://www.jewishvirtuallibrary.org/jsource/myths2/
Church of the Flying Spaghetti Monster: http://www.venganza.org/
Anthropogenic Global Warming skepsis: http://tinyurl.com/AGW-Skepsis
Martijn
> On Di. 30.08.2011 08:11, Dao wrote:
>>
>> On 30.08.2011 00:04, Alex Faaborg wrote:
>>>
>>> We made a design decision that tab tear
>>> off was a more important operation for the user and should take
>>> precedence.
>>
>> If it's describing, I'm pretty sure it's false. Lots of users don't even
>> seem to want multiple windows.
>
> Datapoint: I *only* dragged tabs to create bookmarks. I *never* use it to
> create a new window.
I sometimes use it nowadays, because I often have too many tabs open
and with a new window, I can easily find that page.
That being said, I very occassionally use it.
Regards,
Martijn
> To create a bookmark, the current design forces me to find and target the
> much smaller favicon at the beginning of the URL. (I don't like the "two
> clicks on the yellow Star" method because the folder selection UI sucks)
>
>> If it's prescribing, I'm not sure it makes sense, as I wouldn't /want/
>> users with <10 tabs (i.e. the majority) to mess with multiple windows.
>
> Agreed. And users who open >10 tabs will know how to use context menus
> ("Move to new window").
>
> I suspect this is a classic case of "I figured out how to show this cool
> thumbnail of the web page while dragging it. I'll put it into the
> drag-tab-function so everyone can see how cool I am and how cool Firefox
> is".
> --
> Regards,
> Peter Lairo
>
> Bugs I think are important:
> https://bugzilla.mozilla.org/show_bug.cgi?id=250539
> https://bugzilla.mozilla.org/show_bug.cgi?id=391057
> https://bugzilla.mozilla.org/show_bug.cgi?id=436259
> https://bugzilla.mozilla.org/show_bug.cgi?id=446444
>
> Islam: http://www.jihadwatch.org/islam101/
> Israel: http://www.jewishvirtuallibrary.org/jsource/myths2/
> Church of the Flying Spaghetti Monster: http://www.venganza.org/
> Anthropogenic Global Warming skepsis: http://tinyurl.com/AGW-Skepsis
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
--
Martijn Wargers - Help Mozilla!
http://quality.mozilla.org/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
Mike Shaver
> If it's prescribing, I'm not sure it makes sense, as I wouldn't /want/ users
> with <10 tabs (i.e. the majority) to mess with multiple windows.
I rarely have > 10 tabs other than app tabs, and never multiple
windows for organizing them, but I routinely drag off a tab in order
to be able to see two pages at once. (Also to let my daughter watch a
youtube video while I do something else. That parallel media
consumption is also a very common pattern in China AIUI, and probably
for some other people who are neither me nor Chinese.)
Mike
Dao
Would you be annoyed by the bookmarks toolbar accepting dragged tabs and
thereby preventing tab detaching? (I.e. the Firefox 3.5-7 way.)
If no, we don't have a problem. If yes, at least the shaver and China
cases could be covered by a hidden pref, I guess. My gut feeling is
still that dragging tabs to the bookmarks toolbar is more popular than
detaching.
Boris Zbarsky
> Datapoint: I *only* dragged tabs to create bookmarks. I *never* use it
> to create a new window.
Counter-datapoint (or rather counter-anecdote): I never drag tabs to
create bookmarks. I create bookmarks by hitting Cmd-D. I sometimes
drag tabs to reorder them, or much more commonly to drag them out to a
new window because I need to split up a task into two subtasks. This
last part sadly being pretty broken on Mac right now. :(
Also, I'd like to echo Shaver here: dragging a tab out so I can have a
youtube window for my kids to watch next to the window I'm reading an
article in is a _very_ common workflow for me. I think those without
children may underestimate how common it is for those with children,
though I am probably overestimating how common it is for people with
small screens.
That said, I've never had it be a problem that the bookmark toolbar was
not a tearoff drop target for my use cases, because I typically want to
drag to a totally different screen location, outside the current browser
window.
-Boris
Alex Faaborg
the exact usage of current drag and drop of tabs onto targets like the
bookmarks toolbar and text fields. The only way to build a fair comparison
though is to have this feature landed for awhile (so that people get used to
it), and then compare to the usage of tab tear off for the purpose of
tearing off tabs and moving them around.
A less metrics and more principled way to think about this would be to note
that IE / Chrome / Safari all have this style of tab tear off, so users
switching over to Firefox are going to come in with strong expectations of
behavior.
Another aspect is that the tab is visually represented as a thing (with
mass) so should the notion of it transforming into a string in a text field
is kind of strange. The URL however starts as a string, so when it is
dragged to a text field it does not have to go through an unexpected
transformation.
-Alex
> ______________________________**_________________
> dev-apps-firefox mailing list
> dev-apps-firefox@lists.**mozilla.org <dev-apps...@lists.mozilla.org>
> https://lists.mozilla.org/**listinfo/dev-apps-firefox<https://lists.mozilla.org/listinfo/dev-apps-firefox>
>
Mike Shaver
> That said, I've never had it be a problem that the bookmark toolbar was not
> a tearoff drop target for my use cases, because I typically want to drag to
> a totally different screen location, outside the current browser window.
I find it to be a bit of a problem because the new window doesn't
appear where I drag, so the smallest motion is as good as the most
extravagant relocation of the tab, but I just disabled the bookmark
toolbar and now I don't randomly file my pages.
Mike
Boris Zbarsky
> On Tue, Aug 30, 2011 at 9:27 AM, Boris Zbarsky<bzba...@mit.edu> wrote:
>> a tearoff drop target for my use cases, because I typically want to drag to
>> a totally different screen location, outside the current browser window.
>
> appear where I drag
On current trunk, it actually does.
-Boris
Mike Shaver
Ah, it just won't let the window be partially off-screen. Nonetheless, better!
Mike
Dao
> Individual data points are of course, individual. We can pull metrics on
> the exact usage of current drag and drop of tabs onto targets like the
> bookmarks toolbar and text fields. The only way to build a fair comparison
> though is to have this feature landed for awhile (so that people get used to
> it), and then compare to the usage of tab tear off for the purpose of
> tearing off tabs and moving them around.
What's a while? Should we ship it and sit out the looming outcry?
> A less metrics and more principled way to think about this would be to note
> that IE / Chrome / Safari all have this style of tab tear off, so users
> switching over to Firefox are going to come in with strong expectations of
> behavior.
I'd be more concerned about promoting the transition *to* other browsers
right now...
> Another aspect is that the tab is visually represented as a thing (with
> mass) so should the notion of it transforming into a string in a text field
> is kind of strange. The URL however starts as a string, so when it is
> dragged to a text field it does not have to go through an unexpected
> transformation.
Yes, I do not think we should support this. We didn't support it in the
past anyway, did we? I think we should support dragging to the bookmarks
toolbar and probably to the sidebar (niche anyway), with appropriate
visual feedback.
Robert Kaiser
> Not really, it makes tab tear off a more difficult UI operation because it
> introduces a number of targets that all behave different
We already have differently behaving targets, btw: dragging a tab to the
tab bar is not creating a new window but reordering tabs. ;-)
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
Alex Faaborg
> Should we ship it and sit out the looming outcry?
>
looking at the percent of users who drag the tab to the bookmarks toolbar
and text fields, I think we can estimate ahead of time how looming the
outcry might be. The assumption is that the outcry will be whatever the
opposite of looming is.
Normally we just launch test pilot studies on things that are controversial
or need more exploration. In this case the UX team quickly and unanimously
came to the conclusion that tearing off to create a window (or move a tab to
another window) should be the dominant use case. The bookmarks toolbar is
off by default, and dragging a tab into a text field is at best a 1% use
case.
A test pilot study would verify if our assumptions were correct, but also at
the cost of taking resources away from considerable more interesting and
relevant test pilot studies that are being created.
-Alex
Dao
> Normally we just launch test pilot studies on things that are controversial
> or need more exploration. In this case the UX team quickly and unanimously
> came to the conclusion that tearing off to create a window (or move a tab to
> another window) should be the dominant use case.
I asked this before: What does "should be" mean? Is it not the dominant
use case right now but we want to make it so?
> The bookmarks toolbar is off by default,
Right, any change we'd make here would only affect users who enabled the
bookmarks toolbar. I don't see how this is a counter argument.
> and dragging a tab into a text field is at best a 1% use case.
Not sure how and why this entered the discussion.
Alex Faaborg
> What does "should be" mean?
>
It means without having immediate access to the data we are making an
informed speculation. Of course if you phrase it that way it basically
sounds like guessing, but the informed part gives us a much higher chance of
being correct than random chance.
here's a our pseudo data:
dragging a tab to another window / creating a window: pretty common-ish
dragging a tab to create a bookmark: pretty uncommon-ish (based on the known
percent of users who bookmark, and the known percent of users who have
turned the toolbar back on)
dragging a tab to a text field: probably <1%-ish
Benjamin Smedberg
>> here's a our pseudo data:
>>
>> dragging a tab to another window / creating a window: pretty common-ish
>> dragging a tab to create a bookmark: pretty uncommon-ish (based on the known
>> percent of users who bookmark, and the known percent of users who have
>> turned the toolbar back on)
>> dragging a tab to a text field: probably<1%-ish
on, the relevant data would be "among users who have enabled the
bookmarks toolbar, how many of them are used to dragging the tab to the
toolbar to create a bookmark", right?
I personally drag the favicon to the bookmarks toolbar to create a
bookmark, not the tab, but that may be due to ancient muscle memory from
pre-Firefox.
--BDS
Adam Kowalczyk
>>
>> is there a reason why we can't have the detached tab snap back to it's
>> original spot when dropped on an undroppable spot (toolbar, text field) yet
>> *still* have the URL dropped?
>>
>
> Not really, it makes tab tear off a more difficult UI operation because it
> introduces a number of targets that all behave different (create a new
> window, create a bookmark, etc.)
I disagree with this assertion. It is very common for dragging to
perform different actions depending on drop location. On your desktop
dragging an mp3 file and dropping it onto a folder moves it to that
folder, dropping it onto an media player application plays it, while
dropping it onto the Recycle Bin deletes it. It is intuitive that the
action is determined by the drop location and this flexibility is
actually the main advantage of dragging as a UI operation. I think you'd
agree that "take something and throw it anywhere on the screen" is a
less common pattern, so I think it's backwards to choose it for the sake
of simplicity.
Let's focus on the use case at hand, though. When you want to put a link
on the Bookmarks Bar, dragging is more convenient than clicking on the
star in the Location Bar and using the drop-down folder picker. In fact,
it's particularly convenient for casual users, such as my parents, who
have only a handful of bookmarks and keep them all on the Bookmarks Bar.
Dragging is the solution I taught them and they find it the easiest.
Again, I don't see why it would be confusing for dragging tabs to
perform different actions depending on where they are dropped, as long
as visual feedback is provided.
- Adam
Dao
>> What does "should be" mean?
>
> It means without having immediate access to the data we are making an
> informed speculation. Of course if you phrase it that way it basically
> sounds like guessing, but the informed part gives us a much higher chance of
> being correct than random chance.
>
> here's a our pseudo data:
>
> dragging a tab to another window / creating a window: pretty common-ish
Could you provide some insight here?
I've never seen people in the wild do this, but I probably don't observe
people long enough. What's maybe more relevant is that I can't recall
having seen laptops or private desktops with multiple windows.
Workstations might be different, but I heard those aren't our focus :)
Do we have data on how often users have more than one full browser
window? I know we do have data on the average tab count being quite low.
> dragging a tab to create a bookmark: pretty uncommon-ish (based on the known
> percent of users who bookmark, and the known percent of users who have
> turned the toolbar back on)
Again, data that suggests most people don't have the toolbar doesn't
suggest that the toolbar shouldn't accept dragged tabs when it's turned
on...
Alex Faaborg
> how many of them are used to dragging the tab to the toolbar to create a
> bookmark", right?
>
we don't want to dive into a boundary case covering a small fraction of the
overall population of users, but rather design for the entire mainstream
audience. So the assumption is that the filter:
-user who creates bookmarks
-user who turned the bookmark toolbar back on
-user who attempted to drag a tab onto the bookmark toolbar
ends up in the realm of "pretty uncommon-ish" relative to the full
population of users.
On Tue, Aug 30, 2011 at 11:30 AM, Benjamin Smedberg
<benj...@smedbergs.us>wrote:
> On 8/30/2011 2:25 PM, Alex Faaborg wrote:
>
>> here's a our pseudo data:
>>>
>>> dragging a tab to another window / creating a window: pretty common-ish
>>> dragging a tab to create a bookmark: pretty uncommon-ish (based on the
>>> known
>>> percent of users who bookmark, and the known percent of users who have
>>> turned the toolbar back on)
Alex Faaborg
> Again, I don't see why it would be confusing for dragging tabs to perform
> different actions depending on where they are dropped, as long as visual
> feedback is provided.
>
The bookmarks toolbar is directly under the tab strip (by default), so the
visual feedback is of a tab turning into a window momentarily, and then
turning into a bookmark, and then turning back into a window. This ends up
feeling kind of random if you aren't aware that the bookmarks toolbar is
actually a special target.
Alex Faaborg
> The bookmarks toolbar is directly under the tab strip (by default)
>
and of course by directly I mean kind of close, under the navigation
toolbar.
On Tue, Aug 30, 2011 at 11:46 AM, Alex Faaborg <faa...@mozilla.com> wrote:
> Again, I don't see why it would be confusing for dragging tabs to perform
>> different actions depending on where they are dropped, as long as visual
>> feedback is provided.
>>
>
> The bookmarks toolbar is directly under the tab strip (by default), so the
> visual feedback is of a tab turning into a window momentarily, and then
> turning into a bookmark, and then turning back into a window. This ends up
> feeling kind of random if you aren't aware that the bookmarks toolbar is
> actually a special target.
>
>
>
>
> On Tue, Aug 30, 2011 at 11:35 AM, Adam Kowalczyk <adam-ko...@o2.pl>wrote:
>
Alex Faaborg
> I've never seen people in the wild do this, but I probably don't observe
> people long enough. What's maybe more relevant is that I can't recall having
> seen laptops or private desktops with multiple windows.
>
Data on Firefox users (prior to us landing this change) wouldn't be useful
as the action was previously undiscoverable and clunky. I've observed
enough Safari / Chrome / IE users interacting with their tab strips in this
way that I think it's become expected behavior for those users coming over.
Dao
>> relevant data would be "among users who have enabled the bookmarks toolbar,
>> how many of them are used to dragging the tab to the toolbar to create a
>> bookmark", right?
>
> overall population of users, but rather design for the entire mainstream
> audience. So the assumption is that the filter:
>
> -user who creates bookmarks
> -user who turned the bookmark toolbar back on
> -user who attempted to drag a tab onto the bookmark toolbar
>
> ends up in the realm of "pretty uncommon-ish" relative to the full
> population of users.
Supporting a minority without affecting a majority doesn't defeat
designing for the entire mainstream audience. Benjamin is asking exactly
the right question.
Dao
>> I've never seen people in the wild do this, but I probably don't observe
>> people long enough. What's maybe more relevant is that I can't recall having
>> seen laptops or private desktops with multiple windows.
>
> Data on Firefox users (prior to us landing this change) wouldn't be useful
> as the action was previously undiscoverable and clunky. I've observed
> enough Safari / Chrome / IE users interacting with their tab strips in this
> way that I think it's become expected behavior for those users coming over.
I didn't ask for data on tab tear-off, but tab tear-off is just a means
to managing multiple windows. So I was asking for data for getting an
idea of how many users want multiple windows. It should be discoverable
enough and wildly known how to create new windows, open links in new
windows, etc.. We could of course still assume that that data would be
an understatement because of improper tab tear-off support, but probably
not by an order of magnitude.
Alex Faaborg
> Supporting a minority without affecting a majority doesn't defeat designing
> for the entire mainstream audience. Benjamin is asking exactly the right
> question.
>
Launching a test pilot study to determine user behavior after they have
already modified the default UI feels like a waste of resources to me.
Additionally the number of bookmarks one can create directly on the
bookmarks toolbar is artificially limited by the physical size of the
toolbar. So assuming people don't delete their bookmarks that often, we can
assume with some level of confidence that the number of actions is going to
be low.
Dao
>> Supporting a minority without affecting a majority doesn't defeat designing
>> for the entire mainstream audience. Benjamin is asking exactly the right
>> question.
>
> Launching a test pilot study to determine user behavior after they have
> already modified the default UI feels like a waste of resources to me.
Why? It's one of the more popular modifications / an inherited default
setting. We didn't hide the bookmarks toolbar for users that had put
bookmarks on it.
> Additionally the number of bookmarks one can create directly on the
> bookmarks toolbar is artificially limited by the physical size of the
> toolbar. So assuming people don't delete their bookmarks that often, we can
> assume with some level of confidence that the number of actions is going to
> be low.
The number of users doing this at all seems more interesting than the
frequency. I don't think people are complaining because they want to do
this ten times a day, but when they do it once every couple of days,
they still expect it to work.
Hasse
fir...@lists.mozilla.org>, Alex Faaborg wrote...
> Additionally the number of bookmarks one can create directly on the
> bookmarks toolbar is artificially limited by the physical size of the
> toolbar. So assuming people don't delete their bookmarks that often, we can
> assume with some level of confidence that the number of actions is going to
> be low.
Have you heard of folders? You can drop as many bookmarks as you like
since folders on the bookmarks toolbar will spring open when you hold
the dragged link over them.
--
Hasse
sv-SE l10n team
Adam Kowalczyk
>>
>> Supporting a minority without affecting a majority doesn't defeat designing
>> for the entire mainstream audience. Benjamin is asking exactly the right
>> question.
>>
>
> Launching a test pilot study to determine user behavior after they have
> already modified the default UI feels like a waste of resources to me.
>
> Additionally the number of bookmarks one can create directly on the
> bookmarks toolbar is artificially limited by the physical size of the
> toolbar. So assuming people don't delete their bookmarks that often, we can
> assume with some level of confidence that the number of actions is going to
> be low.
>
Folders?
I used to modify contents of Bookmarks Toolbar a lot. I had a folder
called Check Out Later that I would often put stuff in, I had temporary
folders related to research I was doing. Dragging is by far the quickest
way of putting bookmarks in a particular place. I use Panorama for this
purpose now but we know not everyone likes it.
It's worth explaining why I prefer dragging tabs to dragging the favicon
from the Location bar. In part it's just a habit, sure, but I think
there is more to it. When I want to bookmark a web page by dragging, I
want to drag the object that instinctively represents a "web page" in my
mind - and in the realm of Firefox UI, that's a tab. I operate on tabs
all the time: open them, close them, select them, reorder them. I hardly
ever interact with the favicon.
And weren't we removing the favicon from the Location Bar, anyway?
- Adam
Barry van Oudtshoorn
> The bookmarks toolbar is directly under the tab strip (by default), so
> the visual feedback is of a tab turning into a window momentarily, and
> then turning into a bookmark, and then turning back into a window.
> This ends up feeling kind of random if you aren't aware that the
> bookmarks toolbar is actually a special target.
Perhaps it'd be worth creating a smaller target on the bookmarks toolbar
when you start dragging a tab -- a greyed-out dotted-bordered box with a
star that says "Drop to add a bookmark", for example. I would also
suggest that the tab "morph" into a bookmark only after a second or so
of the pointer being over this target. This way, users can still easily
create bookmarks from tabs, we reduce the risk of this happening
unexpectedly or unintentionally, and the dragged tab doesn't change too
much as it's dragged.
--
Barry van Oudtshoorn
www.barryvan.com.au
Not sent from my Apple πPhone.
Christian Legnitto
I'm not saying we should change anything, but why not make holding control or option while dropping the tab switch behavior to not opening a new window? Seems like that wouldn't trip up people moving from other browsers but lets that < 1% of users have their bookmark and textarea tab dropping feature with minimal migration pain. Mode switching sucks, but it is at least similar to how Finder and Explorer moves/copies (drag with no key down = often used behavior 1, do the same thing with key down = less used behavior 2).
I feel like someone suggested this already in the thread but I can't seem to find it right now. I also rarely tear off tabs so I don't know if this key combo is already used.
Thanks,
Christian
Adam Kowalczyk
> I'm not saying we should change anything, but why not make holding control or option while dropping the tab switch behavior to not opening a new window? Seems like that wouldn't trip up people moving from other browsers but lets that< 1% of users have their bookmark and textarea tab dropping feature with minimal migration pain. Mode switching sucks, but it is at least similar to how Finder and Explorer moves/copies (drag with no key down = often used behavior 1, do the same thing with key down = less used behavior 2).
>
> I feel like someone suggested this already in the thread but I can't seem to find it right now. I also rarely tear off tabs so I don't know if this key combo is already used.
>
> Thanks,
> Christian
It already works but, judging by reactions among nightly testers, this
isn't discoverable enough for those migrating users. And there is a
caveat, you have to press CTRL before you click, as pressing it while
dragging doesn't work. I trip on this every time and I have to cancel
the drag and start over. There was a bug to enable pressing CTRL while
already dragging but even that request was WONTFIXed. By the way,
cancelling dragging is particularly annoying because you can't do it
with ESC - in order to avoid detaching you must manually drag the tab
back to the tab bar (?!).
- Adam
Dao
> but lets that< 1% of users have their bookmark and textarea tab dropping feature with minimal migration pain.
This figure is bogus, please don't reproduce it :/
This thread isn't about textareas and I'll assert more than 1% of our
users drop tabs on the bookmarks toolbar, unless someone has opposing data.
Mike Ratcliffe
window. and also drag into the bookmarks toolbar very often. If
Panorama was a visual representation of bookmarks in folders (like the
bookmarks toolbar) I would use that instead.
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Robert Kaiser
> dragging a tab to a text field: probably<1%-ish
And tearing off to a new window is a >1% case? I already doubt that. But
then, I'm no UX researcher and I have no data - other than having never
had any complaints that I read in any relevant channels that SeaMonkey
doesn't support tear-off at all.
Alex Faaborg
> why not make holding control or option while dropping the tab switch
> behavior to not opening a new window?
>
Interactively that's fine (main concern we are trying to avoid is confusion
and accidental bookmark creation for people who are expecting to tear the
tab off). The only downside would be the extra implementation effort and
code complexity, but those aren't aspects that I spend time caring about.
-Alex
On Tue, Aug 30, 2011 at 6:06 PM, Christian Legnitto
<cleg...@mozilla.com>wrote:
>
> On Aug 30, 2011, at 5:52 PM, Barry van Oudtshoorn wrote:
>
> > On 31/08/11 02:46, Alex Faaborg wrote:
> >> The bookmarks toolbar is directly under the tab strip (by default), so
> the visual feedback is of a tab turning into a window momentarily, and then
> turning into a bookmark, and then turning back into a window. This ends up
> feeling kind of random if you aren't aware that the bookmarks toolbar is
> actually a special target.
> >
> > Perhaps it'd be worth creating a smaller target on the bookmarks toolbar
> when you start dragging a tab -- a greyed-out dotted-bordered box with a
> star that says "Drop to add a bookmark", for example. I would also suggest
> that the tab "morph" into a bookmark only after a second or so of the
> pointer being over this target. This way, users can still easily create
> bookmarks from tabs, we reduce the risk of this happening unexpectedly or
> unintentionally, and the dragged tab doesn't change too much as it's
> dragged.
> >
>
> I'm not saying we should change anything, but why not make holding control
> or option while dropping the tab switch behavior to not opening a new
> window? Seems like that wouldn't trip up people moving from other browsers
> but lets that < 1% of users have their bookmark and textarea tab dropping
> feature with minimal migration pain. Mode switching sucks, but it is at
> least similar to how Finder and Explorer moves/copies (drag with no key down
> = often used behavior 1, do the same thing with key down = less used
> behavior 2).
>
> I feel like someone suggested this already in the thread but I can't seem
> to find it right now. I also rarely tear off tabs so I don't know if this
> key combo is already used.
>
> Thanks,
> Christian
alex_mayorga
Alex
Drugoy
> > why not make holding control or option while dropping the tab switch
> > behavior to not opening a new window?
>
> Interactively that's fine (main concern we are trying to avoid is confusion
> and accidental bookmark creation for people who are expecting to tear the
> tab off).
Why don't you try to avoid confusion and accidental tab tearing the
tab off for people who are expecting to create a bookmark?
harshid
I agree with Adam, the LEAST you cant do is add the ability to press
CTRL (mid-drag!!) and be able to add a tab to as a bookmark. People
who use Firefox and have been using it for long time expect things to
work in a certain way. You've improved look and feel of an existing
feature. Well done. But you've also regressed the feature to the point
where its actually broken for many users. Firefox currently allows you
to BOTH drag a tab to the bookmark toolbar or drag it outside the
window to create a new window. When dropping one feature for another,
you should at the very least make it easy for users to adjust to a new
way of doing things!
The way things are right now is really half-assed and its not
something people expect from Mozilla.
Adam Kowalczyk
the decision even if I don't agree. There are still a few loose ends
from the discussion and I'd appreciate if you could give your final word
on them.
There are a couple of regressions that make migration more frustrating
than it has to be. A decision needs to be made on bug 675438 - "Cannot
duplicate tab if started holding CTRL key AFTER you started dragging the
tab". I trip on this every time and I have to cancel the drag and start
over. This is exacerbated by a regression that makes it impossible to
cancel detaching by pressing Escape (bug 674789). There doesn't seem to
be any controversy whether the latter bug should be fixed, so can we
please at least make it a priority to fix that?
The current combination of intentional changes and accidental
regressions is so unfortunate that it seems designed to annoy users who
relied on dragging to bookmark.
My final concern is the ability to drag the favicon in the Location Bar.
There are long-standing plans to redesign the identity button and remove
the favicon, which would presumably remove the ability to drag it. I
think I recall this concern was brought up and the response was that
you'd still be able to drag the tab instead... Could you comment on the
current status of that?
- Adam
On 2011-08-30 00:04, Alex Faaborg wrote:
>>
>> is there a reason why we can't have the detached tab snap back to it's
>> original spot when dropped on an undroppable spot (toolbar, text field) yet
>> *still* have the URL dropped?
>>
>
> Not really, it makes tab tear off a more difficult UI operation because it
> introduces a number of targets that all behave different (create a new
> window, create a bookmark, etc.) We made a design decision that tab tear
> off was a more important operation for the user and should take precedence.
> Now obviously not every user is the same, and since this is a direct trade
> off some people will disagree, but that's the nature of making high level
> design decisions. I should also note that while Frank implemented this, it
> was the UX team's call to focus the interaction purely on tab tear off.
>
> -Alex
ty.m...@gmail.com
ty.m...@gmail.com
outcry might be."
Then, you followed it by saying, "A test pilot study would verify if our assumptions were correct..."
So what you are actually saying is, you made this decision based on how the designers use Firefox and now how your actual customers use it.
ty.m...@gmail.com
You cannot excuse your decision to take away useful functionality by falsely claiming the functionality wasn't very useful.
Why not just tell current Firefox users that you do not actually care how they use Firefox, if all you really care about is making Firefox exactly the same as every other browser to attract new users?
Of course the fallacy with this decision is that people switch to Firefox not because it is the same, but because it is better. If it is just like the browser they are already using, they don't have any incentive to switch.
ty.m...@gmail.com
There are very few things that I actually want from a browser.
1. '/' to search within page
2. drag tabs to create bookmarks
3. extensions that are not broken every six weeks by browser updates
Up until about year ago, that's what Firefox gave me. Now the only one left is number 1. I refuse to switch to Chrome, because it does not support '/' to search. And at the rate Firefox is changing to be more like Chrome, I expect it to be gone in 6 months.
Firefox 8 does away with number 2, so I'm done with Firefox. It's been a good run. I've loyally supported Firefox since 2004. I've promoted it to family and friends and convinced people to convert. Other than Microsoft Word, there is no computer program I have used longer. I hate to change now, but I just can't put up with it any more.
It feels like the designers suffer from the same arrogance lots of businesses display. I feel like the Firefox designers care more about the customers they are trying to get than the customers they already have.
Firefox 8 gave the impetus to see what other browsers fit my needs. Opera 11 does that, so I am switching. I just wanted you to know why you have driven one loyal user away.
Asa Dotzler
Ty, that's not what's being said here.
It's clear that you disagree with the change, and I'm not going to try
to convince you that it's the right change for you, but I do want to
correct you on this one point:
Our designers do not design Firefox for themselves. Our developers do
not develop Firefox for themselves. Firefox has always been and will
always be designed and built for others, the hundreds of millions, even
billions, of users who are not in the business of designing and building
browsers.
Because our designers and developers cannot know for certain what every
user wants in every possible case, they make educated guesses --
assumptions informed by years of study and experience, about what will
work out the best for users. Your characterization of those assumptions
as "how designers use Firefox" is incorrect.
- A
Ron Hunter
I am sure there are MANY features of FF that I have never used, and this
is one of them. I may not be a typical user, but I would never have
noticed this feature being missing. Frankly, it makes MUCH more sense
to me to just drag the icon from the URL to the bookmarks toolbar, which
is because I rarely use ANY tabs.
There does seem to be a trend to simplify the interface by reducing the
number of ways something can be done. I also see this as a negative trend.
Eric Sh.
drag the tab instead since they are used to dragging and dropping tabs.
Eric,
WLS
> Actually most users won't even think about dragging the icon, they would
> drag the tab instead since they are used to dragging and dropping tabs.
>
> Eric,
>
I always use Ctrl + D, then Show All Bookmarks, find the one I just
bookmarked, highlight it, cut it, find the folder in Bookmarks Toolbar I
want it to be in, then paste it. NOT!
Really I just drag the favicon. Didn't even know you could drag the tab,
and never tried.
--
SeaMonkey 2.5b2 on openSUSE 11.3 Linux
Robert Buecheler
and I thought I was like most users and come find out I'm not.
pulled the favicon at the left of the URL (now the awesomebar) onto
the bookmark toolbar or -folder ever since I started with FF. Once --
it's been a while ago -- I found out that pulling the tab would either
move its position or open it in a new window.
I do am a little peeved that the app-tab doesn't keep the original web
address and saves the last used one, as I keep gmail in it and end up
having to figure out where I am as it might be opening the last
message I was reading... but that doesn't have to do with drag&drop
tabs to bookmarks... - which I never used anyway :)
Dao
There are plans to remove the favicon from the location bar, since it's
redundant (it's already on the tab) ;-)
Robert Buecheler
I sure hope that the plans include a similar easy way to bookmark a page...
If drag&drop to bookmark of tab is "implemented or reinstated", then
go for it, otherwise think about the user...
al...@yahoo.com
news:tvOdnceei6XHmw7T...@mozilla.org...
> There are plans to remove the favicon from the location bar, since it's
> redundant (it's already on the tab) ;-)
Tab bar can be hidden, so urlbar favicon is not redundant.
Eric Sh.
aesthetically, and now that "http" is gone it helps me feel on what type of
page I am.
If you want to minimize chrome then how about removing the "https" string?
It is already possible to recognize a secure page because the favicon clock
is highlighted.
Eric,
Alex Limi
> If you want to minimize chrome then how about removing the "https" string?
> It is already possible to recognize a secure page because the favicon clock
> is highlighted.
>
We're looking into ways to do this too, but it's a bit more complicated, as
the current security indicator isn't doing a very good job at explaining
what's going on. But we're working on a better solution for it. :)
--
Alex Limi · Firefox UX Team · +limi <http://profiles.google.com/limi> ·
@limi <http://twitter.com/limi/> · limi.net
Ron Hunter
Please don't. MANY users never see the tab bar as they (we) don't often
(or ever) use tabs. This would make the favicon unavailable.
Ron Hunter
And don't forget the users who don't always HAVE a tab bar!
Eric Sh.
just remove it if the user has his tabs showing and if they are hidden show
it?
Asa Dotzler
> Please don't. MANY users never see the tab bar as they (we) don't often
> (or ever) use tabs. This would make the favicon unavailable.
We have actual data saying that single tab users are a tiny minority our
users http://66.43.220.232/james/mozilla-challenge.html and even single
tab users have the tab strip showing unless they've configured Firefox
to hide it. So, the single tab user with the tab strip hidden is
probably not the best audience to optimize for.
- A
Ron Hunter
One of the strengths of Firefox has always been flexibility. If you
want to make things better, you don't do it be taking away alternative
ways of doing things. I have found through reading the support groups
for many years that everyone has a slightly different way of using
Firefox, and different needs, and narrowing the choices users have
always tends to alienate people. I am pretty flexible, but since 90% of
the time, I am only using ONE tab, I can't see sacrificing a whole scree
line to display a tab bar. Loss of this flexibility would be quite
annoying to me. Then title of this thread should indicate that even
though you and I may never have used the ability to drop a tab on the
bookmarks toolbar, some do, and get rather unhappy when it is removed.
If Firefox is to be stripped down to the lowest common denominator, then
there should be a concomitant payback to be had for all users. This is
rather like 'tabs on top', which makes absolutely no sense to me, even
after reading the justification for it. In the end, it just draws
Firefox closer to looking like IE and GC. I don't consider that a good
thing.
Eric Sh.
Tabs on top is an optional feature, don't like it - don't use it.
And that is exactly how this feature should be, remove the favicon from the
url bar if the user has the tab bar visible and show it when the tab bar is
hidden.
This is not the only feature in firefox that exists for a minority of users,
there are hundreds like this, but it doesn't mean that firefox can't be
improved for the rest(majority) of the users.
Regards,
Ron Hunter
Panorama. A rather major inclusion, and useful to a small percentage of
users.
Asa Dotzler
> On 10/12/2011 2:25 AM, Asa Dotzler wrote:
>> Ron Hunter wrote:
>>> Please don't. MANY users never see the tab bar as they (we) don't often
>>> (or ever) use tabs. This would make the favicon unavailable.
>>
>> We have actual data saying that single tab users are a tiny minority our
>> users http://66.43.220.232/james/mozilla-challenge.html and even single
>> tab users have the tab strip showing unless they've configured Firefox
>> to hide it. So, the single tab user with the tab strip hidden is
>> probably not the best audience to optimize for.
>>
>> - A
> Since when has the Firefox team decided to make options unavailable?
reason we created Firefox in the first place was to make options
unavailable, and instead move on to where we are today.
Firefox is designed to have the most impact for the most users. Where an
option is easy to maintain from a code and test standpoint, and where it
doesn't get in the way of the use cases we're optimizing and designing
for, it can make sense to have an option.
When it's difficult to maintain and test -- like cases where it requires
a different code implementation or won't get good test coverage, it
makes a lot less sense to devote our resources to maintaining that
alternative code and to test it well enough to ensure that it doesn't
break.
When it doesn't make sense, for the kinds of reasons I've mentioned, to
maintain flexibility and customizability in Firefox, we count on our
community of add-on developers to fill that role.
Firefox will never have every feature or every feature variation that
every user wants. We are highly customizable and configurable thanks to
our various built in capabilities and the extensibility of Firefox
through add-ons. This is how we balance the requirements of the many
with the requirements of the few.
Does that answer any or all of your question?
- A
jeanphili...@gmail.com
But now, what can I do ? Firefox do what I don't like him to do ? I just feel that since Google is the main investor in Mozilla they try to please him to do things in the same way chrome does.
The drag and drop tab to toolbar is the best user experience I have with Firefox. I don't care if some people don't see the need of that or don't use it. I need it and many people need it as I can read through several posts.
That's not just an option i need to learn to use in another way. There is no other way ! just an option removed but an option witch is a way of life in my surfing experience. Very very sad.
I am really disappointed.
Ron Hunter
No other way? Of course there are other ways. I believe someone
pointed out about 10 different ways to set a bookmark. If it's the way
YOU like to set a bookmark, then it is important to you. I grab the
favicon in the URL bar, and drag that to the bookmarks toolbar. As long
at that functionality is still available, I will be happy. If not, then
I will be more than a bit miffed as other ways are just not as quick,
and easy.
Eric Sh.
improve speed/memory in some way or another(since it is helping code
maintainability) then I'm all for it.
I would love to see the statistics of how many people don't use this and
other features,
Are there any plans to remove the option to hide the tab bar?
Gepeto
Ron Hunter
You can still control updates.
Robert Kaiser
> You can still control updates.
You can also kill a fly by dropping a two-story-high block on concrete
on it, but it may not be the solution to go for every time a fly annoys
you somewhere.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
Ron Hunter
> Ron Hunter schrieb:
>> You can still control updates.
>
> You can also kill a fly by dropping a two-story-high block on concrete
> on it, but it may not be the solution to go for every time a fly annoys
> you somewhere.
>
> Robert Kaiser
>
updates. This is just not true. You can turn off the updates in the
UI. I don't know of any plan to change that, and would strongly protest
any such idea as being sure to driver away users.
Robert Strong
Robert
Robert Strong
On 10/14/2011 2:33 PM, Ron Hunter wrote:
tril...@gmail.com
In the current beta, when I drag a tab, it doesn't tear off until my mouse cursor is below the navigation bar. In other words, the animation of the tab becoming a window doesn't appear until I'm over my bookmarks bar. It seems it would be a small change to make it so that the animation didn't appear until I was no longer over any part of the browser's chrome. The old functionality remains, and the new functionality isn't hurt. Those that don't use the "drag to bookmark" functionality will never even notice the difference. It seems a win/win.