159431 - [META] How should bookmarks in a bookmark group be opened?

Status: RESOLVED WONTFIX

(SeaMonkey :: Tabbed Browser, defect)

Description

[Jason Bassford]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020724
BuildID:    2002072408

I am opening this meta bug to help track suggested alternative behaviour to what
happens currently when you click on a bookmark group.

Currently, there are 4 "camps":

At Present: Always append.
Bug 153016: Replace current, insert to right.
Bug 158365: Replace current, reuse to right.
Bug 159266: Reuse from leftmost on.

I have a few comments:

1. Behaviour of opening a group bookmark should / may be modified once / if they
are ever treated as hyperlinks.  In other words, allowing a user to Ctrl-click
on a bookmark rather than just do a regular left click.  Given such a future
scenario, the above 4 methods of group bookmark behaviour need not necessarily
be mutually exclusive.

2. It's seemingly apparent from the discussions going on in all the different
areas, that we will never reach consensus.  Nor, so it might appear, can we even
reach a simply majority (>50%) opinion on this matter.  That leaves a couple
alternatives that I can see:

a) Somehow "poll" everybody (exactly who and how I'm not sure) and implement the
solution with the greatest number of votes, despite the fact that the remaining
"against" majority will always be opposed to whatever this may be.

b) Implement some kind of per-user configuration / preference.

3. There should be NO discussion in this bug about which approach to handling
bookmark groups is better.  For evangelization of one method over another please
take it to the newsgroups or private email; for patches or technical discussion
pertaining to a particular method please take it up in the appropriate bug as
followed here (via dependencies).

4. Whatever is finally implemented, it should be as simple and unobtrusive to
the existing UI as possible.  I don't think that any of us wants to see a
context menu listing 20 different ways of opening a bookmark group.  I'd rather
not see ANY methods listed in a context menu or in the Preferences UI (hence bug
158365 comment 6) but that can be discussed here to some degree - although I'd
rather see "warring opinions" in the newsgroups rather than polluting this bug
so if you do post an opinion in this regard please do so ONLY IF it has not
already appeared in previous comments.

5. For various reasons listed above, please read through ALL of the comments in
this bug and think VERY CAREFULLY before posting anything new.

To repeat: Do not post any comment here to the effect of "tab groups should do
this, should do that, should behave like this other program," etc.  The only
comments that should go here are those relating to how we should best handle the
opposing bugs.  If it's thought that we should pick just one method, and not any
of the others, then DON'T say which method you think it should be.

Comment 1

[Jason Bassford]

Possible per-user option:

Add a setting to the tab group folder itself, such that it determines the tab
group's behaviour when its sub-tabs are loaded.  Just as we have keywords,
descriptions, and schedules / notify attributes assigned to individual tabs, tab
loading behaviour could be something that's settable in the Bookmark Manager for
each tab group folder.  At first I thought of context menus and keyboard
accelerators - but that would be WAY too much of a headache on top of an already
confusing array of options.  I also would not like to see yet another
Preferences addition.  But a simple setting in the BM shouldn't be that
difficult to accomplish and I don't think it would add any real UI complexity.  

Granted it WILL increase the complexity of the code but, if some kind of
preference is required to "peacefully" resolve the dispute, I think that, of all
the way of implementing a preference, this is the best.

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

Yay.  one more bug to track and get confused with of the same issue that I own
but didn't get assigned to me.  Taking, but if it gets out of hand, I'll dupe
all these bugs into one because essentially, they all are really the same "bug".
 This summary covers it pretty good.

Comment 3

[Jason Bassford]

Non-programmatic per-user option:

How about creating XPIs for each of the tab group behaviours?  That way we could
keep the default as it is, and anybody who wants one of the different behaviours
could just apply the XPI to their install.

This would allow for user customizability but would not impact anything about
Mozilla's base code or UI.  Those people regularly downloading nightly builds
shouldn't find it *too* onerous to click on a bookmark that would reinstall the
XPI each time - especially if what they get is, to them, "the correct" and much
better way of opening tab groups.

Comment 4

[Nick_Jenkins]

Your list excludes the main "camp" that I am aware of :

* Keep current, insert to right.

[I did have an very brief explanation of this, but I can't include it within the
constraints listed in the bug description, so stuff it]

Also, if you're going to poll people, you probably want to get them to rank
their preferences (5 points for 1st choice, 4 for second, and so forth), and use
the total of those points to decide. For me personally, the reuse options are
substantially worse than the other options - I would be reasonably happy to
compromise on the other options though if it avoided another preference/install
option/configuration option, and I would like to think that most people would be
mature enough to accept that if a consensus is going to be reached over
something that is a matter of taste, then there has to be some give and take. A
poll structured in such a way would provide this.

Comment 5

[Jason Bassford]

> * Keep current, insert to right.

I believe that would be a variation on bug 153016, and such behaviour could be
generated by some kind of modifier to its default behaviour of replace current.
 (It's too "minor" a difference for a whole other bug, IMHO.)

> if you're going to poll people, you probably want to get them to rank
> their preferences

Good idea - if polling actually becomes the method of resolving this.

Comment 6

[Alexander Dietrich]

I don't think a single method should be picked, since it would permanently ruin
bookmark groups for a large portion of users, as Jason observed. And we want
happy Mozilla users, don't we ?

I also don't think a per-group setting of behaviour would be a good idea, mostly
because it's going to cause confusion for the user. ("Now, did I set up this
group to replace or append ? Better open a new window anyway...")
Also, if you change your mind later in regards to "the one true way", you're
going to have a hell of a time modifying your bookmarked groups.

My vote is for a preference in "Tabbed Browsing" with:

1) Always Append (a safe default)
2) Replace All (the old method)
3) Replace Current, ??? (is it possible to agree on one of them ?)

Either way, a blank page/tab should not stick around when a bookmark group is
opened, this is totally useless. (Bug 159104 and also Bug 153016).

Comment 7

[Jason Bassford]

A new option with bug 203960 (currently the case with recent builds because of a
checkin) is to replace ALL tabs, regardless of how many there are - so if you
have 5 tabs open and open a tab group of 3 tabs, you'll end up with the 3 tabs
from the tab group open.  (Rather than those 3 tabs, plus the old 2.)

Comment 8

[Christopher Aillon (sabbatical, not receiving bugmail)]

->jag

Comment 9

[Frank Hellmann]

IMO this should not be handled through prefs. The default behavior needs to be
able to produce staisfactory behavior for everyone, meaning that with as little
as possible, as commonplace as possible actions each behavior needs to be able
to simulate.

Example:
Replace current replace to right.
Becomes:
Replace all: With simply "close all other tabs" before you open the tab group
Append: With simply Ctrl T beforehand.
Reuse to right: you have to close all to the right and then open.

Comment 10

[Jason Bassford]

> as commonplace as possible actions

While I agree that would be *ideal*, I still don't believe that it's possible to
actually determine what the majority opinion is on what should happen.  As
mentioned in comment 0, figuring that out is only possible with some kind of
poll, but I have no idea how to conduct something like that that would be
meaningful.

If it were able to be set via a preference, then a) everybody would be happy
once they'd set it the way they liked it, and b) we might *then* be able to get
Mozilla to send us feedback about how people are setting that preference so that
we can determine, from actual user statistics, what's being used most and then
set the appropriate defaults (if we cared about doing anything more with this at
that point).

Comment 11

[Gerrit Hannaert]

I think if Mozilla "overwrites" old tabs, as it now seems to do, a warning
similar to the one if you close a tabbed browser window should be displayed
before the existing tabs will be overwritten (unless the URLs are identical, I
would imagine). 
Although I'm more in favour of new tabs, a dialogue box would make me happy to
live with the current "overwrite" method.

Comment 12

[Prognathous]

(In reply to jag - comment #0, bug 203960)
> From a usability study we've learned that users find it confusing that bookmark
> groups open in additional tabs instead of replacing the existing set of tabs.

Such a usability study of could provide this meta bug with some actual numbers
to discuss. Unfortunately, despite many requests, jag never agreed to publicise
anything from this mysterious study - not the results, not the tests, not who
was behind it, not the methodology and not the analysis. Basically, the default
behavior changed, but without anything substantial and public to rely on.

Prog.

Comment 13

[Prognathous]

1. Please omit the "of" from the first sentence in my previous comment.
2. If it wasn't clear, I quoted the opening description (comment 0) of bug
203960 - not this one.

Sorry for the spam,

Prog.

Comment 14

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

[Philip Chee]

Bookmark groups are gone on trunk (SeaMonkey 2.1b2pre) Closing. If there are usability issues with opening bookmark folders please open a new bug.