179065 - Bookmark inside toolbar make no sense.

Status: RESOLVED EXPIRED

(SeaMonkey :: Bookmarks & History, defect)

Description

[Yannick Koehler]

Saw this on Interface Hall of Shame.

Seems like Mozilla is doing the same mistake.

---

This particular design in Microsoft's Internet Explorer has prompted us to
consider adding another category to the site: Silly Designs. Whereas toolbars
are designed to provide rapid access to frequently used menu items, Microsoft's
designers chose to use the toolbar to display...menus.

Duplicitous designAs can be seen in the image of the Favorites menu, the
Favorites toolbar image merely replicates the menu. In so doing, the designers
have provided no additional usability benefit, and in fact, have decreased the
usablity of toolbar buttons by changing the control rules: toolbar buttons no
longer initiate an action, certain "special" toolbar buttons require the user to
distinguish among various types of toolbar buttons and may require a subsequent
action of the user. Since there is no benefit to the design, we regard it simply
as ... well, Silly.

Comment 1

[timeless]

.

Comment 2

[R.K.Aa.]

The sillyness, as i read it, is in the "Duplicitous design".
You don't find the equivalent in mozilla. Is it the functionality of the
personal toolbar you want to remove, or the bookmark menu? I use my personal
toolbnar all the time, but i nearly never use the bookmark dropdown menu, so if
you mean that should be removed - i'm all for it.

Comment 3

[Yannick Koehler]

I have a Bookmarks menu and a Bookmarks menu inside the bookmark toolbar.  So
there's duplication.

Comment 4

[Yannick Koehler]

Attachment: picture showing duplication.

Note, pressing the two Bookmarks does exactly the same thing, display a similar
menu.

Comment 5

[timeless]

there are two differences between the bookmarks button and the bookmarks menu:
you can't drag objects into the menubar version.
you need a mouse to use the toolbar version.

Comment 6

[Torben]

I cannot belive that there is not already a bug for this. Bug 92794 is related
though.

Comment 7

[Jason Bassford]

What is this bug actually asking for in terms of a resolution?  To delete the
Bookmark button from the Personal toolbar?  You already can just delete it - so
that would be WFM.  (I don't use my Personal toolbar, but I've whittled it down
so it only displays the Home button when I do View it.)  Or are you asking that
the Bookmark button shouldn't appear, by default, on the Personal toolbar?  Or
that it should be impossible for it to be put there at all?

As for duplication - why is that actually so terrible?  You can click on
Go->Back or you can click on the Back icon (or you can use Backspace or
Alt-Left).  Is it the duplication of the identical interface that's bothering you?

Comment 8

[Jason Bassford]

> i nearly never use the bookmark dropdown menu, so if
> you mean that should be removed - i'm all for it.

I have a passionate loathing for the Personal toolbar and never view it.  The
way in which I get to bookmarks is to use the Bookmarks menu.  So removing the
menu would be totally wrong in my mind.

Comment 9

[Torben]

I think the best solution would be to remove the bookmarks folder from the
personal folder. The menu item should be kept, both for accesibility reasons and
because not everyone uses the personal toolbar. 

If someone really wants to have a bookmarks folder on the personal  toolbar, 
they can easilly create it manually. I bet you even can add the add bookmarks
etc. functionality by using bookmarklets.

Comment 10

[Yannick Koehler]

I'm asking that the bookmark shouldn't appear by default on the personal 
toolbar.

A toolbar is for tools, not menu, that is a menubar, if you can't drag stuff 
on the menubar then make it draggable,  All stuff draw by Mozilla is non-OS 
centric and therefore there's no limitation nor difference between that menu 
and the one inside the toolbar.  There's nothing indicating that you drag 
stuff over a toolbar item either which is not user-friendly anyway.

Comment 11

[[e-mail]]

--- all.js
+++ all.js
@@ -112,7 +112,7 @@
 // 0 = Pictures Only, 1 = Text Only, 2 = Pictures and Text
 pref("browser.chrome.toolbar_style",        2);

-pref("browser.toolbars.showbutton.bookmarks", true);
+pref("browser.toolbars.showbutton.bookmarks", false);
 pref("browser.toolbars.showbutton.go",      false);
 pref("browser.toolbars.showbutton.home",    true);
 pref("browser.toolbars.showbutton.print",   true);

Comment 12

[Maarten Afman]

Duplicate bookmarks seems still the default in 1.3a.

Personal opinion: this duplication is worse than silly, it ads nothing for 99%
of the people, it only succeeds in cluttering the user interface and the screen,
uses memory and makes mozilla a less nice product in the end.  

Comment 13

[Peter Lairo]

I *do* use the Personal Toolbar (and the bookmarks folder _there_) a lot. I like
the bookmarks folder there because: (A) that's where i expect bookmarks to be,
next to my other bookmarks (not in the menu), (B) i can drag new bookmarks there
(can't do that in the menu). So at most, please only change the default setting.
That would solve ALL issues of this bug. 

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 15

[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

[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 17

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420