User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031215 Firebird/0.7+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031215 Firebird/0.7+ The Summary is pretty self explanatory. Now that we have the Tree view available in the "Add Bookmark" dialog, there needs to be a way so that Firebird remembers whether the user last had the tree view visible or not. (This idea is based on how IE does it.) This is useful for people who really like the tree view, so that they can always have it visible -- like me. I also suggest that we store this option in the profile so that the repeated updates to the browser (that are often necessary) will not erase this preference. Reproducible: Always Steps to Reproduce:

this essentially makes the "last folders" list rather less useful since you will rarely close the treeview again before saving a bookmark. The expectation is that normal users will use the tree view only rarely, and since it would require an extra step to hide this again, this is a less than ideal solution.

Mike, that doesn't make sense. The "last folders" list works fine when the tree is visible. Please reopen.

I second Mike on that, except that we could reopen this bug later. When the tree is collapsed, the user has a reason to expand it. But conversely, when it's expanded, he/she has no reason to collapse it. In fact, I didn't realized that the IE add bookmark dialog could be collapsed. I opened it once, and forgot about it. I always used it expanded. Now, if you agree that the add bookmark dialog will always stay expanded, then the user has the choice between selecting an item in the drop down or selecting it in the tree. First it's bad UI to present two possibilities, the user will think and waste time. But at last, since the tree is visible and the drop down is invisible (and doesn't contain fixed item except the bookmarks root and folder), I bet he/she will choose the tree. And the dropdown menu would not be used. At all. We are searching for the most ergonomic way to add a bookmark. Maybe our new way is wrong. Maybe it isn't, but I think it's too early to know it now. We need to gather User Experience, and 0.8 will be good for that. Meanwhile, if we realize that the drop down menu alone is not more efficient than the tree view, we'll reconsider the issue.

May I suggest a compromise instead? Instead of forcing it on the user (in other words remembering their last used view), add a checkbox that says something along the lines of: "Always show expanded view" or "Always show tree view" For users who only want to use the tree view, they could check this option. I really think the tree view is much better than the drop down, and I think we should offer it to people who want to use it exclusively. As for the "Create in" drop down causing confusion. I have found that it doesn't create any confusion for me. My eyes easily focus on the right spot. It simply duplicates whatever I click in the tree view, which is just what I would expect.

*** Bug 229768 has been marked as a duplicate of this bug. ***

*** Bug 230526 has been marked as a duplicate of this bug. ***

why is this wontfix? this is one of the worst bookmarks bugs

did you actually read the comments Pierre and I made or just see the bug, see the resolution, and comment?

(In reply to comment #8) > did you actually read the comments Pierre and I made or just see the bug, see > the resolution, and comment? I've thought about this bug every now and then. However, I wanted to give enough time for people to use the bookmark dialog in 0.8. Now that 0.8 has been out for a while, would it be ok with you if I went ahead and posted someting in the forums to gather people's thoughts on whether they see a need for this? I'm still not sure if enough time has elapsed (for people to fully check this out), so I thought I would ask first.

*** Bug 237150 has been marked as a duplicate of this bug. ***

Those watching this bug might be interested in bug 242626 - Ability to keep tree open in Add Bookmark dialog.

I made a forum post on Mozillazine to gather some feedback on this bug. From the thread, I was able to gather some feedback on this particular issue. In general, people had several reasons for wanting a permanent tree view. In the information below, I have attempted to list those reasons that people mentioned. >>1<< Duplicate Bookmark entries. Some people had folders in their boomarks with the same name. Thus, they did not know which one was in the dropdown. As a result, they have to use the tree view. Quote: "For example I have more than one 'Software' folder in different locations in my tree structure. When I now see 'Software' in the dropdown I don't know which 'Software' folder will be actually used when I select it from the dropdown without opening the tree view." >>2<< Many folders. Some people have a large amount of folders (like 40+) in their bookmarks, and the dropdown doesn't fit what they need in order to get to the right folder. >>3<< For a number of people , the dropdown doesn't contain the folder they want. As one person noted, this "makes the process longer." Quote: " The way it is at the moment, I always go into the trap to open the dropdown just to see that the folder I'm looking for isn't in there, so bookmarking for me means 1) Call the dialog 2) Open the dropdown 3) Open the tree anyway" >>4<< Some people don't remember names well; but, instead, remember visually. (Actually, it is probably true that everyone remembers better visually; only when you use the same names often, might text be easier.) Quote: " a) i don't always remember the exact name of the folder I want to put the bookmark in, but I do know approx. where it should go within the tree stucture b) i often haven't decided exactly *which* subfolder a bookmark is most appropriate in ("should it go in 'mozilla' or 'mozilla->bugs'?")" >>5<< Some people do not remember what folder they last bookmarked in. Quote: "c) even if i did know exactly which folder I would want a bookmark in, there's no way I'd remember whether that folder was one of the last 5 folders I had added to previously (unless I was adding a ton of bookmarks to similar locations in a very short period of time)" In addition, there were also some other points that people mentioned regarding the UI design of the bookmark dialog in general. >>A<< One person noted that having both in the window (the drop down and the tree view) causes "clutter." (Pierre noted this already in Comment #3) >>B<< Some people may not even know there is a tree view. Quote: "I feel a bit dumb for it, but until this thread, I didn't realize the tree view was even there..." [Based on that, the idea of using just a down arrow, may need to be reconsidered.] ================================ Conclusion ----------- I've tried to include most, or all, of the points that people mentioned on the issue. If anything, this information should be helpful in considering what (if any) changes need to be made. ================================ Some thoughts: ----------- From what Mike has told me personally, and from what I've read in this thread, there are several reasons for having the drop down always visible (but not the tree view): >>1<< Forcing the user to always use the treeview would be less intuitive. --the tree view requires "traversing more visual and mouse space" than the drop down. >>2<< for keyboard navigation the dropdown makes for quicker keyboard navigation (less key presses) >>3<< Clean UI (uncluttered) having the tree view always visible does make for a more cluttered UI Now... If were to combine these points with the issues brought up by users on Mozillazine, then the solution needs to be as follows: 1) Clean UI (uncluttered) 2a) Something simple, quick, and easy. 2b) Quick access to commonly used folders (some people don't like to bother with the tree view all the time) 3) Ability to skip the quick access and always use the tree view (some people can't use the quick access, for the reasons noted earlier) 4) Quick keyboard access As you can see, these goals are mutually exclusive. I can figure out a way to get 3 out of the 4, but not all 4 at the same time. -Having the tree view open all the time is more complicated and automatically implies a more cluttered UI. -On the other hand, having the drop down open all the time causes problems for people who always need the tree view.

I'm including one last thing... This was a suggestion someone in the thread made (as a solution). Basically, the ideas was to have common folders to the left side of the window (like in Windows' open dialog), and to have the tree view in the left. From my perspecpective, this solution would take care of issues 2b, 3, and 4. However, it would greatly clutter the UI. So, I'm not really sure if the idea can be used, but I thought I'd inlcude it anyways.

anything that's terrible UI and cluttered like that is incredibly unlikely to be implemented. :) Everything ultimately comes down to personal preference. Since this was implemented, there hasn't exactly been a huge outcry about the bookmark dialog. Other than a few scattered bugs and comments, I haven't seen real dissatisfaction with the interface as it is. There's certainly optimizations that can be done in how the shortlist is generated, but I haven't seen anything that has made me question the fundamental concept behind this UI. Ultimately, worst case, someone who wants the treeview has to click one button before picking their option from the treeview. Based on the four issues raised in comment 12, the current UI addresses all but #3. #3 is accessible via a single mouse click. Sure, that's an annoyance to those users, but that's it. I don't think that minor annoyance is worth the downside that comes with making that the default UI.

Would there be any harm in the following? Including a check-box option at the bottom of the "Add Bookmark" dialog that says: [ ] Always Show Tree View As far as I can tell, this would solve all of the issues. #1 The dialog would still have a clean UI (#1) as a default. When you expand the tree view, the dialog already has a lot of options, so adding one checkbox might would not be too much of an extension or too much additonal complexity. #2a The dialog would still be simple, quick, and easy by default. For those who chose to check the more complex option, the dialog would still be quick because it meets their needs. #2b In either mode people would still have quick access to commonly used folders. As a default the drop down would be all that's available, but once the option is checked, both would be available. I realize that Pierre noted that this might be bad UI design. However, people choosing to use the tree view all the time are in need of more options, and thus are willing to put up with more complexity. #3 This would provide people with the ability to skip the quick access and always use the tree view for those who can't use the drop down. This actually reduces complexity for those people who need the tree view. #4 Quick keyboard access would still be accessible in both modes. The drop down works works the same whether the tree view is visible or not.

*** Bug 255493 has been marked as a duplicate of this bug. ***

(In reply to Mike Connor, comment #14) > Sure, that's an annoyance to those users, but that's it. I don't think > that minor annoyance is worth the downside that comes with making that > the default UI. Who's asking to make the tree view the default UI? This bug talks about making Firefox *remember* the last view mode set by the user. That's a very good example of how a properly implemented spatial interface can serve the needs of different kinds of users - without them actually having to configure prefs. Firefox default for fresh profiles should be the compact view mode (ATTN Pierre: no discoverability issues). Then, if the user switches to tree mode, the browser should keep it until explicitly switched back to compact mode. Please re-open. Prog.

that was in response to the previous comment. What I said in comment 1 is still valid, as are pierre's comments in comment 3. Everything else was discussion on alternatives, not the original request. The WONTFIX stands.

*** Bug 268149 has been marked as a duplicate of this bug. ***

*** Bug 268379 has been marked as a duplicate of this bug. ***

*** Bug 268651 has been marked as a duplicate of this bug. ***

Please reopen. I have in excess of 4000 bookmarks in more than 600 categories with more than 50 "Misc" folders in different locations. Needless to say, "Create in:" drop down is a joke in my eyes. If you don't like the proposed feature let's just agree to bury it somewhere in about:config as an option. As opposed to WONTFIX.

What's wrong with this dialog is that the drop down box is called misleadingly. It should be called "Recent" instead of "Create in". "Create in" made sense years ago when that one combo box was used to select a folder in the whole tree.

(In reply to comment #23) > What's wrong with this dialog is that the drop down box is called misleadingly. > It should be called "Recent" instead of "Create in". > > "Create in" made sense years ago when that one combo box was used to select a > folder in the whole tree. Wrong. It still creates a bookmark in the place selected in the combo box. Nevertheless, I want this to be reopened too... (In reply to comment #1) >this essentially makes the "last folders" list rather less useful since > you will rarely close the treeview again before saving a bookmark. Sorry if the original implementor of the "last folders" feature is offended by my comment, but this feature is plain dumb as it's very unlikely that you have to add bookmarks consecutively in the same 5 folders you touched recently. The reality is, when you visit a page, it's likely that they belong to many different categories in a bookmarks folders as long as your bookmark holds more than 5 folders.

>> What's wrong with this dialog is that the drop down box is called >> misleadingly. It should be called "Recent" instead of "Create in". >> >> "Create in" made sense years ago when that one combo box was used >> to select a folder in the whole tree. > > Wrong. It still creates a bookmark in the place selected in the combo box. You've missed my point so i'll elaborate: In comment #3 Pierre complained that multiple choices might confuse users. And he is right (well, he is wrong, because the tree would be hidden by default until user summons it... but that's another story) as long as "Create in" is labelled the way it's labelled. If you change it to "Recent" (or "History" or something similar) the apparent superfluity vanishes. And i did not notice for quite some time that that's a recent folder list. I assumed it to be that ancient list of all the categories in the tree... when i actually opened it some day i decided that it's broken, because not all of the categories were there (as it used to be in the past) :-) Now, that's confusing! But i don't really care because for me the problem is elsewhere (see Summary).

Erm.. this is a valid bug, and the dropdown state should be remembered. I meant to get this for 1.0, but didn't get around to it.

Just an idea: What if we got rid of "Create in" box alltogeter, made tree view a permanent feature of the dialog, and made tree view's scrollbars to remember their state between dialog invocations?

What's the current plan for implementing this feature? A checkbox? Simply remembering in the profile - no checkbox? (In reply to comment #26) > Erm.. this is a valid bug, and the dropdown state should be remembered. I meant > to get this for 1.0, but didn't get around to it.

This one needs some discussion, vlad's on a very different page from the original design.

*** Bug 268655 has been marked as a duplicate of this bug. ***

*** Bug 301717 has been marked as a duplicate of this bug. ***

See this extension which adds such functionality: http://www.chuonthis.com/extensions/openbook.php

This UI change request is almost two years old. I think it has sufficiently aged that it warrants implementing. Existing IE users that have tried Firefox are switching back as evident by Firefox's shrinking market share. http://www.pcworld.com/resource/article/0,aid,122213,pg,1,RSS,RSS,00.asp The Firefox "OpenBook 1.3.1" extension is exactly the sort of UI change needed. http://www.chuonthis.com/extensions/openbook.php This plug-in is not a substitute for implementing this change request. Expecting the average user to search, locate, and install a plug-in simply to patch the UI is not an approach to help gain market share. The bookmarking UI is a core feature of a browser and Firefox deserves better.

*** Bug 326433 has been marked as a duplicate of this bug. ***

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

(In reply to Vladimir Vukicevic, comment #26) > I meant to get this for 1.0, but didn't get around to it. Well, here's a reminder ;-) Prog.

Not even close to a blocker, especially the day of freeze.

There are two different ways that this dialog can behave. 1) It keeps the expanded state that it previously had. 2) It does not keep the expanded state. In the case of 1), if the user ever clicks the dropdown (perhaps they are exploring or need it in a one-off matter), they are unlikely to collapse it. This is especially the case if they wait a couple days between expanding it and creating another bookmark, as they will be unlikely to remember that it is the non-default view as well as how to retract the area. Secondly, there are potentially two areas that can expand in our current Bookmarks popup. The Folder tree view and the Tags list can both get expanded. It wouldn't make sense to remember the expanded-state for only one of them, and remembering the expanded state for both can turn our bookmarks popup into a ridiculously oversized popup for people that don't need it to be that way. Thirdly, each bookmark that a user creates can have different intentions/reasoning behind the creation. One bookmark may be highly categorized and tagged, while others may be more ephemeral. If a user creates one highly categorized and tagged bookmark, they are not just as likely to create all their following bookmarks in the same manner. In the case of 2), if the user ever clicks the dropdown then they will have the opportunity to categorize and/or tag their bookmark with the high precision that they are looking for. This overhead of clicking the dropdown arrow isn't huge, and the lack of remembering the state guides our users towards the simpler and >80% use-case UI. With all that being said, I think that we can close out this bug and call the current behavior acceptable.

Please don't take this the wrong way Jared; maybe we can make this into a positive discussion. :) Nowadays, I don't get involved much in Firefox bugs like I used to, but I legitimately feel this bug needs to be be given some consideration after all this time. Long story short, even after all these years of using Firefox, I still find myself frustrated with the bookmark system because of the lack of tree view. Now, I had long forgotten about this bug report, but after seeing recent activity, I was reminded about how often this actually affects me. However, maybe this time around, we can come up with a better solution? :) You know, I wrote this post a very long time ago. So, if you all are willing, I would like to ignore the past and look at this with a fresh perspective. Here is my attempt: Before I start, I would like to establish a few things that maybe we can agree on? * It is my assumption that the Firefox developers want to keep the current "simple" non-tree style for basic users. * It is my assumption that the Firefox developers do not want these "basic users" to accidentally stumble into tree-view -- otherwise they will get confused. * However, at this point, I think our priorities diverge a little bit. I suggest to you that: 1) Tree-mode is not only useful, but extremely important, for advanced users. 2) Advanced users are a critical part of the Firefox userbase, so catering to them should be given some priority. 3) The current design is very frustating for people who use tree-view a lot. * The "solution" I originally offered in this bug report may not be the best solution; maybe we could consider alternatives? Since I am trying to convince you to see things from my perspective, let me walk you through a little about of my though processes so you can kind of understand why this issue is important for people like me. Background ... or ... "Why Do I even use Tree Mode in the first place?" :) 1. I often end up with a lot of bookmarks. I find organization the only way to keep this to a sane level sometimes. 2. It was suggested that tagging would offer the ultimate solution to this organization problem. However, after all this time, I still find tagging to be a lot less effective and, actually, more tedious to work with than a well organized tree. 3. Folders, on the other hand, mirror the way the file system works. This is something that has been around for decades and many people are familiar wiht it. So, as you can expect, I have grown quite good at using folders for organization. The natural result, is that I would like to use this same, effective, system for bookmarks. :) So, from that, I hope you can see why advanced users would want to use the folder system vs other methods of organizing bookmarks. Next... let me try and explain why the current Firefox design causes some frustation for people wanting to use the tree view. To do that, let me walk you the thought process of bookmarking (with the goal of organizing by folders). The process might go like this: 1. I try to bookmark something. 2. I see 3 fields, so I have to spend a split second figuring out which field is for the folder. This takes time, because all 3 fields look similar (they are the same size/width+height). 3. After figuring out the middle is the folder, I then have to spend time reading the name + more time deciding if it is the folder I want. 4. If if it is not the folder, I then have to make another decision: do I try the dropdown or expand into tree mode. 5. Sometimes I try the dropdown. However, often, I don't know where that folder is in the tree structure... and sometimes the folder I need is not even there. So, I have to take time to check through all the entries to see if I can tell for sure that it is the one I need. If I still am confused if my folder is in there or if it is simply missing, I then have to decide what to do. The logical next step is choosing tree mode. 6. I switch to tree mode and go to the folder I need. Now, perhaps you might be thinking, a few seconds is not so bad. However, when considering this from the perspective of whether this makes for a good user interface, it is a lot worse than it seems. When designing a user interface, you want the process to go as fast as possible so the end user does not get frustated. Every time a person has to look over many options or make a decision costs time and makes the user interface "feel" like it is badly designed. Although, the actual time it takes is very small in non-relative terms, the actual way it feels can be very bad to the end user. What I hope you can see is that the number of decisions and the number of items a person has to check in order to even get to tree mode is more costly than it needs to be in the current design (steps 2-5). By providing a way to automatically go straight to tree mode everytime, we can eliminate a lot of these steps and remove a lot of the frustating "feel." I am proposing that we find a way to eliminate steps 2-5 for people that use tree mode. However, perhaps just remembering the last bookmark is a bad solution. Perhaps we can consider other alternative solutions instead of just a basic "remember last state"? FINALLY, let me suggest some alternative solutions: Alternative solution 1: * Detect if a user use the tree view AND if they also put a bookmark inside a folder other than the main one. -- this means they actually used folders to organize something * If they use tree-view like this, then pop-up a message and ask if they always want treeview turned on. Alternative solution 2: * Basically, suggestion 1, but automatically show treeview the next time they bookmark without bothering to ask. Alternative solution 3: Next to the "New Folder" button, add a checkbox to "[ ] always show treeview" Other solutions? At this point, I'm not sure where to go with this. File a new report with one of these different solutions? Keep discussing it here and change the subject when the time comes? Discuss elsewhere or in private and then file a new report? But whatever route is taken, could I at least encourage the developers to at least consider that this really is an issue that matters for advanced users?

Follow-up... Jared, you did a pretty good job explaining the concerns behind the current bookmark behavior. So... I agree that a simple "remember last state" is not a good solution. However, I attempted to help explain why we do still need a solution (even if it is a little bit different). Hopefully, I did a good enough job helping you see my/our perspective as you did explaining your perspective. So... since you have a good grasp of this issue, let me ask you this: Would any of these solutions provide an acceptable compromise that would benefit both advanced and basic users? * Add a checkbox next to the "New Folder" button: "[ ] always show treeview" I imagine making this text slightly greyed out so it does not stand out so much (and overly vie for user attention / clutter the interface). Something like 80% opacity on the text and checkbox... or making the text show up as "disabled" when unchecked and then dimmed when checked. This option, only shows up, when you are in tree-view, of course. Internally, this might trigger an about:config option; however, I am very keen that we do NOT want to make this some buried option -- it needs to be an obvious choice in the user interface. Pros: * solves most of the basic user problems - they are much less likely to accidentally turn on tree mode * keeps tree-view permanently on for people who use it a lot (which is actually the preferred way) and keeps it turned off for people who used mixed-mode Cons: * a little bit more clutter in the interface - but if people are advanced enough to use tree view in the first place, I think they can handle an extra option showing up.

(In reply to Kevin Ar18 from comment #40) > Alternative solution 1: > * Detect if a user use the tree view AND if they also put a bookmark inside > a folder other than the main one. -- this means they actually used folders > to organize something > * If they use tree-view like this, then pop-up a message and ask if they > always want treeview turned on. I think this sounds reasonable, minus the pop-up message, but it still doesn't cover the different types (ephemeral/read-it-later bookmarks vs. highly specific, never-want-to-forget-this-site bookmarks).

> I think this sounds reasonable, minus the pop-up message, but it still doesn't > cover the different types (ephemeral/read-it-later bookmarks vs. highly > specific, never-want-to-forget-this-site bookmarks). Leaving out the pop-up is fine. :) Anyways, if I understand correctly... you are saying you think people who use tree-view will not *always* want it turned on? Personal Answer: Personally, I would like to keep it permanently on. I found switching back and forth between the simple and tree mode was actually the source of a lot of my frustration. General Answer: You might have a point in that it would be nice if the bookmark dialog always showed as much information as you need and no more. However, the current style of having to *manually* decide between tree or simple mode every time can also be frustrating. However, like you, I can't really see a solution can "adapt" dynamically every single time. In this unfortunate situation, the only option I can think of it to let the user choose which mode is less problematic for them. --------------------- In short, may I suggest to you the following? Let us assume that the current bookmark dialog, as it is right now, addresses most of the concerns you have regarding one-off vs more in-depth bookmarks. So... by adding the checkbox to make the tree-view permanent, we are not removing the current design/mode, but just adding another mode that makes tree-view permanent. Some people might chose to stick with the current mode, some might chose to stick with the permanent tree mode (like me). The key point is that both modes have cons..., but the user gets to choose which mode will have the least negative side effects for them. Granted, this is not the perfect solution we are looking for. A mode that can adapt and present the minimal interface every single time would be nice. but I can't think of any good way to accomplish that every single time. :( :( Anyways, if you want to let this simmer for a few days and see if any good ideas (or problems) come to mind.... P.S. I'll try to send you an email you about something related to this issue (but maybe off-topic)

>> Alternative solution 1: > I think this sounds reasonable, minus the pop-up message Sorry, pretty bad mistake on my part. I assumed you were talking about suggestion 1 in Comment 41. So my reply was about the checkbox suggestion. :( Strangely enough, almost everything I said in the other post still applies. :) However, one note about auto-enabling tree view... I wonder, would this be too risky? Someone might start wondering how it "magically" turned itself on and how they can disabled it. Although a checkbox adds clutter, I figured it might be a little bit "safer" > but it still doesn't cover the different types (ephemeral/read-it-later > bookmarks vs. highly specific, never-want-to-forget-this-site bookmarks). To be honest, I don't think there is a reasonable solution to this. I considered something similar a long ago. However, there's just no way to tell what the person really wants... and we can never guess accurately enough. Thus, the simplest solution I could think of was having either tree mode always on for people that use that the most or always off for people who don't use tree view. (aka, each person uses the mode that has the least cons for that person)

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.