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 ***

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.

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.

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