Closed Bug 229768 Opened 21 years ago Closed 21 years ago

Remove "Create in" from Add Bookmark dialog

Categories

(Firefox :: Bookmarks & History, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: lunchtimemama, Assigned: p_ch)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031230 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031230 Firebird/0.7+

Now that we have that handy expandable arrow in the Add Bookmark dialog which
gives us a tree view of our bookmark folders, we have a redundancy problem. The
"Create in" box gives us a space efficient method of choosing the folder, but a
less intuitive interface. The "Arrow" gives us a nice visual representation of
our folders, but it makes the "Add Bookmark" window much larger. Also to
consider;  as it stands now, the presence of the “Create in” box hinders the
effectiveness of the “Arrow’s” easy interface.

Let us assume that you are adding a new bookmark into a different folder. For
the “Create in” method you must click the drop-down and click the folder (2
clicks.) For the “Arrow,” you must click The Arrow and click the folder (2
clicks also.) The only difference is The Arrow offers a more visually
comprehensive interface.

Now let us assume that the window is changed to remove the “Create in” and make
the tree view front and center, sans Arrow. This time you need only click the
folder (1 click.) You have also opted for the ease-of-use interface (2 benefits.)

The 1 drawback is the dialog size. The “Add Bookmark” window becomes much larger
when you replace a slim drop-down box with a full blown tree view. This should
not become a problem, however, because of the following reason. 
When you are adding a bookmark:
1. You are not taking more than a few seconds
2. You are not working in/looking at the browser during those few seconds
There is, therefore, no reason to be conservative with screen space.

I suppose one could suggest that a tree view could be a visually complex
interface for your average user, but I could then suggest that the tree view is
one that is a common element of both Windows and Mac OS interfaces. It is also
one that is obvious and self-explanatory (unlike the “Create in” box.) So to
conclude, I can’t believe you read all the way to the end.

Reproducible: Always

Steps to Reproduce:
1. Bookmarks > Add to Boomarks   or   Ctrl D
2. Check out that weird drop-down box
3. Check out that cool tree view (by clicking The Arrow)
4. Notice the problem?
bug 228582 addresses the view that the tree view should persist or replace the
Create In box.  It is currently marked WONTFIX, but will be re-evaluated during
the 0.9 cycle.  Duping against that bug since this adds nothing new to that
discussion.

*** This bug has been marked as a duplicate of 228582 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Mr. Conner,
This bug is similar to 228582, but they are in fact two different proposals.
Addressing bug 22852 does not resolve this bug therefore, they are not
duplicates. I received you fine e-mail regarding your views on my proposal.
Thank you for your feedback. I invite you to share those views with the entire
community in the space below.

This is not a duplicate of bug 228582. I am reopening this bug.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
really, the other bug summary is not identical, but the focus of that bug did
change, although not all of that is apparent from the comments within the bug. 
If we revisit that bug, we'll be dropping the Create In entirely, as persisting
the treeview is only useful if you drop the create in aspect of the dialog.

however, if its NOT the same bug, then WONTFIX, here is the reasons I gave in
the email, besides the fact that this is intended behaviour as decided by the
module peers for Firebird.

> as it stands now, the presence of the “Create in” box hinders the
> effectiveness of the “Arrow’s” easy interface.

The "Create in" is intended and expected to be the primary method for users
adding bookmarks.  The tree-view is viewed as a complement to the primary interface.

> Let us assume that you are adding a new bookmark into a different folder. For
> the “Create in” method you must click the drop-down and click the folder (2
> clicks.) For the “Arrow,” you must click The Arrow and click the folder (2
> clicks also.) The only difference is The Arrow offers a more visually
> comprehensive interface.

Actually, this is assuming you don't have nested folders.  In a large array of
bookmarks you will likely see a more complex and nested treeview, which would
necessitate clicking to expand/contract/scroll.  For a user that follows "typical"
behaviour, even with nesting they only commonly use four or five folders, making
the treeview rather irrelevant 90% of the time or more.

> Now let us assume that the window is changed to remove the “Create in” and make
> the tree view front and center, sans Arrow. This time you need only click the
> folder (1 click.) You have also opted for the ease-of-use interface (2 benefits.)

See argument above about ease of use with larger numbers of folders not being a
one-click operation.

> There is, therefore, no reason to be conservative with screen space.

Large dialogs take more time to visually absorb, if you actually look at the
dialogs,
so by expanding the size of the dialog you are slowing the user down.  Part of
usability
is reducing the amount of time spent understanding UI elements.

> I suppose one could suggest that a tree view could be a visually complex
> interface for your average user, but I could then suggest that the tree view is
> one that is a common element of both Windows and Mac OS interfaces.

Just because something is common does not mean its simple.  The idea is to
present a simple, streamlined interface, with the flexibility to choose uncommon
or new folders in which to add the bookmark.  We believe the current dialog
succeeds in this, far more
than a tree-based dialog would ever be.  However, as I noted in the bug comment,
this will be considered based on user feedback from the 0.8 release.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → WONTFIX
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
You need to log in before you can comment on or make changes to this bug.