267770 - Add Bookmark dialog has inconsistent UI depending on whether there are other tabs

Status: RESOLVED EXPIRED

(Firefox :: Bookmarks & History, defect)

Description

[Nik Makepeace]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1

When you bookmark a page and there are multiple open tabs, there is a checkbox
option to bookmark all tabs in a folder. If you bookmark a page with no other
tabs visible, the dialog doesn't show the checkbox. It should show the checkbox,
but disabled with a tooltip or some other explanation.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Mike Connor [:mconnor]]

Care to explain why you think this is necessary?  I don't know of any HIG rule
etc that would require this.

Comment 2

[Nik Makepeace]

I can't find the source for this, but I'm 100% sure I've read this or been
taught this before: consistency and explorability in UI is more important than
cleanliness. In this case, the two modal dialogs do exactly the same basic thing
in each situation - make a bookmark of your current browsing environment -  but
when there is more than one tab open, you can do it in to a different degree.

I think it would make sense if the UI was consistent in each case, but with the
small redundant part simply disabled when not needed. We're not looking at
something likely to be overloaded with disabled items like a context menu, just
a simple dialog.

But I'm not passionate about this :)

Comment 3

[Ben Fowler]

Nik, although you have put forward a good argument, the current taste in
HI design is to not use 'greyed out' items as an interface feature.

This is most relevant to menu items, and may not apply in full measure
to your Report.

The reason for this is subtle, but runs deep, and is along the lines
that the application knows why something is greyed out, but hasn't
told the user. This was a good thing at Xerox Parc and back in 1984,
when applications and interfaces were small, but is a bad thing in
large or complex applications.

I suspect that that there would be a huge majority amongst developers 
of Firefox for avoiding the 'greying out' feature except where there
was a necessity (where there is a no page to go forward to, the Forward
menuitem of the Go menu is greyed out).

I am certinly not saying that you are altogether wrong, and you have
made an excellent case - put it this way: Suppose that the Cmd-D item
at the top of the menu were to change between "Bookmark This Page" and
"Bookmark Pages" according to whether there were more than one page
available to bookmark, you would need to specify in the latter case
whether to bookmark one or all pages, but in the former case, does it
need to be mentioned again? Greyed out? Needing tooltip help?

Based on commet 1 this should be WONTFIX .

Comment 4

[nrlz]

Attachment: alignment screenshot

I also think that the, "bookmark all tabs in a folder", feature is not very
discoverable. In my opinion it is because the alignment of the checkbox,
combined with the default text in the "name" field, doesn't suggest something
that is radically different than the general behavior of just bookmarking 1
URL. In fact when I first saw it, I thought it was some sort of metadata or
additional properties to store with the current bookmark and I chose not to
read it since I was ready to accept its default setting, whatever that may be.

I think the fact that it's aligned with the "data" column and that it doesn't
contain its own row header, suggests to me that it belongs to the "Create in"
field which caused me not to read it since I had no interest in changing. If
instead, the checkbox was aligned with the other headers ("name/create in"), I
would have given it more status as a separate entity.

I also found a screenshot of a bookmarks property window (see attachment) to
show what a checkbox looks like if it is aligned with the headings instead of
the data column.

Comment 5

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 7

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change