This is a tracking bug for mockups of the new bookmark dialog in the location bar. Due to to the attachment size limit images will be hosted on people.mozilla.com. Check the most recent comment or URL for the latest iteration.

Iteration 7: http://people.mozilla.com/~faaborg/files/granParadisoUI/places_NewBookmarkDialog_i7.png Text from the mockup: --- This dialog is displayed when the user double clicks on the star, or clicks a second time. This dialog also replaces the new bookmarks dialog. --- The default location is based on how the UI was displayed: Double click on star: All Bookmarks Bookmarks Menu>Bookmark this Page: Bookmarks Menu Accel-D: Bookmarks Menu --- When nothing is entered in the tag field box the text "tag one, tag two, tag three," appears in a grey font: --- Both sections expanded: ---

note for i8: -Add "Page Bookmarked" at the top of the panel -remove done/ok/cancel, add small close button in the top left corner (right on mac)

With the current design, it is possible for the user to be surprised by the interface's behavior, twice: action -> "expected result" -> actual result: click star -> "dialog" -> star fills out click star again -> "clear star" -> dialog While the star itself only has two states, the difference in interaction between first click and second click, makes it feel like three states. in i8, I think we should simplify the interaction to this: click star -> dialog (but with details collapsed) click star agian -> dialog (details expanded) We didn't do this initially because we wanted clicking the star to be a very lightweight behavior. We assumed that displaying a dialog with various fields to fill out would cause the use to feel like they need to choose a name for the bookmark, and then choose a folder, and then type some tags. If the user feels this is too much work, they may continue to never bookmark a page. This is another hybrid approach, but it is closer to showing the full dialog. Now on the first star click, the user will see: ----------------| | |Page Bookmarked | |[v] details | ------------------- I'll try to post mockups of i8 soon.

I think it would be useful to add feeds to bookmarks so if you want both the page and the feed bookmarked you don't need two items on the toolbar (same with menu and sidebar). For bookmarks menu it could be like a normal bookmark but with the feed icon on the right and a submenu with the feeds and for the sidebar with the feed icon and a dropdown on the right.

How about using "Cancel" rather than "Delete"?

note for i8: try not to forget the new folder button in the expanded folders area this time.

(In reply to comment #5) > How about using "Cancel" rather than "Delete"? > I agree. This is confusing, since, to the user, no bookmark has been created yet.

(In reply to comment #8) > (In reply to comment #5) > > How about using "Cancel" rather than "Delete"? > > > > I agree. This is confusing, since, to the user, no bookmark has been created > yet. > It's not confusing if the user accepts that the bookmark is added immediately: When the user clicks Bookmarks > Bookmark this page..., the page IS bookmarked at that time. The Star properties menu appears at that moment to give the user an opportunity to edit the just added bookmark before they forget about or lose track of it. This is a much improved feature that will simply take users some getting used to.

(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #5) > > > How about using "Cancel" rather than "Delete"? > > > > > > > I agree. This is confusing, since, to the user, no bookmark has been created > > yet. > > > > It's not confusing if the user accepts that the bookmark is added immediately: > > When the user clicks Bookmarks > Bookmark this page..., the page IS bookmarked > at that time. The Star properties menu appears at that moment to give the user > an opportunity to edit the just added bookmark before they forget about or lose > track of it. > > This is a much improved feature that will simply take users some getting used > to. > > That is not normal behavior in any OS or app that I have seen. The first time you create anything, programs always ask you where you want to put it first, you then click ok, and it creates it. Now follow he here, don't just jump to conclusions. When you go to Bookmarks and click Create Bookmark, you are explicitly choosing to create a bookmark somewhere in a folder. So, we are partially there, because when clicking on Create Bookmark, it brings up the star dialog. However, in this case, it should not highlight the star yet, and there should be three buttons, Cancel, Delete, and Done. Delete will be grayed out. If you click Done, it should then highlight the star and place it wherever you choose. If you click Cancel, nothing is created. This same menu config would ALSO work when clicking on the star twice like how you guys want the starring system to work. When you click on the star once, it puts the page in Places (added to Recently starred pages and All Bookmarks) and no menu pops up. When you click it again, you either accidentally clicked it, and so you want to Cancel (yeah, I know you can just click away, but for usability reasons, you should still have a Cancel button there), you can delete it from Places by clicking Delete, or you can change the location of the bookmark or leave it where it is by clicking Done. This way, you make nothing confusing. The old way works, and the new way works.

>That is not normal behavior in any OS or app that I have seen. Instant apply interfaces do appear in a variety of operating systems and apps. The main point of confusion here is that we are transitioning what used to be a traditional pop-up dialog box to an instant apply interface to streamline the interaction. We are going to make the change clearer by: -telling the user exactly what just happened -changing the visual styling to clear indicate that is is not a traditional dialog (for instance, HUD window styling on OS X)

(In reply to comment #11) > >That is not normal behavior in any OS or app that I have seen. > > Instant apply interfaces do appear in a variety of operating systems and apps. > The main point of confusion here is that we are transitioning what used to be a > traditional pop-up dialog box to an instant apply interface to streamline the > interaction. > > We are going to make the change clearer by: > -telling the user exactly what just happened > -changing the visual styling to clear indicate that is is not a traditional > dialog (for instance, HUD window styling on OS X) > Ok. Fair enough, then what about being similar to other browsers for new users? This star interface is very useful, but it isn't something beginners are just going to easily understand. Those changes you mention would be helpful, but I still think it would be clearer to do what I said above in the 2nd and 3rd paragraphs, because then NO ONE would be confused, and it isn't like it would add any bloat, because there is even a spot in the interface for a cancel button! I really don't understand why recently that Mozilla devs can't come up with these type of "keep the old AND add the new" type of changes. I have run into this on two cases in the last week, and both times, even though there is a solution where both sides get what they want, the devs STILL want to be stubborn and not even consider a SOLUTION that isn't just a compromise.

>but I still think it would be clearer to do what I said above in the >2nd and 3rd paragraphs Having two different ways to do the same thing feels wrong, but I certainly see what you are getting at. I'll bring up your idea at the next user experience team meeting and see what everyone thinks.

(In reply to comment #13) > >but I still think it would be clearer to do what I said above in the > >2nd and 3rd paragraphs > > Having two different ways to do the same thing feels wrong, but I certainly see > what you are getting at. > > I'll bring up your idea at the next user experience team meeting and see what > everyone thinks. > I would agree with you on that, except that I really think that (as does the person who currently coded what we have with it right now) that when you click the star you AREN'T doing the same thing as when you are clicking Bookmarks -> Add Bookmark. Your intentions are different for each. Also, thank you for your kind consideration of what I wrote.

Can we please have a preference to open dialogues like this in expanded mode by default? I don't care if the preference is hidden behind about:config It's silly that I need to install an extension merely to get this boolean preference set, i.e. https://addons.mozilla.org/en-US/firefox/addon/42 http://www.chuonthis.com/extensions/openbook.php

(In reply to comment #15) I agree. Would be very useful for advanced users.

>Can we please have a preference to open dialogues like this in expanded mode by >default? I was thinking that the existing keyboard shortcut (command/control-D) should open this interface in the expanded mode.

The setup of the dialog made me make a change that I did not intend to make. I had a bookmarked site open and wanted to make changes to the tags so I clicked the star. By accident I deleted the name of the bookmark. But there's no way to cancel that change. The only options I had were to fix the name manually or delete the bookmark and have to redefine it again. Actually I found out I had to change the name manually after I hit escape and found that the old name was not restored. Instant apply changes really suck. People make mistakes and many times it's easier to cancel the mistake instead of fixing the mistake.

>Instant apply changes really suck. I agree, but I think the more comprehensive issue is that "instant apply changes that don't support undo suck." This problem will be addressed in the next iteration of the design.

Undo...Argh! I made bookmark of just any page. And I tried changing the name and then hit Ctrl-Z and the old name came back. I hit escape the previous time without even really thinking about it. I wonder if I was thinking that might do an undo instead of a cancel. But I'm not sure where I've come across where escape does an undo. Most of the time escape closes the dialog. (A few moments later) Oh that's right the address bar does that.

(In reply to comment #11) > The main point of confusion here is that we are transitioning what used to be a > traditional pop-up dialog box to an instant apply interface to streamline the > interaction. To what extent is the interaction really streamlined (for keyboard users)? On Firefox 2.0, the quickest way to add a bookmark was [Ctrl+D, Enter]. Now it's still [Ctrl+D, Enter]. No difference there. Having second thoughts OTOH was [Ctrl+D, Esc] and has now become [Ctrl+D, ???] (maybe Alt+D; see bug 409623) whereas [Ctrl+D, Esc] counter-intuitively is the very same as [Ctrl+D, Enter]. Sounds like a usability regression to me. Besides: The menu item currently reads "Bookmarks -> Bookmark This Page…" which implies the need for further input before performing the action (that's what the ellipsis is supposed to mean - see bug 255051). IMO keyboard users should thus continue to get the classic dialog while mouse users clicking the star should get the new popup (which won't display unless the page has already been bookmarked - thus allowing [Esc] to just mean "Close" instead of "Cancel").

I agree -- there's nothing streamlined about the new interface. It's actually a hindrance and irritant. To click outside the dialog to close it is NOT easier than to click OK or press Enter. In fact, in may actually be more difficult because you have to move the mouse cursor OUTSIDE the dialog whereas clicking OK button would allow the user to make shorter hand movements by staying within the dialog. Also, in addition to what's requested in comment #15, I'd like to be able to enter a description of a bookmark right when I am adding it. I don't want to do an extra step of launching the Library to do this. It's very inconvenient and wastes time, which is contrary to the goal of streamlining the UI. Have a More button or something to expand the dialog to display the description field (if you oppose to seeing it by default) and persist its state. I think the idea of instant change or streamlining the UI is dealing with an artificially created problem because pressing Ctrl+D and Enter or doing equivalent actions with the mouse is simple enough. If people don't bookmark pages as often as you want, I doubt they don't do it because the process is too difficult.

Roman, Control/Command-d is still available. The thing in your second paragraph is a feature request. If you wish to log it, please open a new issue here in bugzilla for it. Otherwise, it will be lost in this comment thread.

Al, I know that Ctrl+d is still available and don't know why you thought I didn't. As far as the feature request is concerned, I've already filed an issue for it but a got a standard reply: the design won't change. Since the developers seem to be more open now to listening to those who use fruits of their labor and this issue here is about discussing a new bookmark dialog, I thought I'd request this feature here.

>I thought I'd request this feature here. Yeah, requesting changes to the design in the tracking bug is fine. I'm the only ui designer working on places right now so I'll see the request either way. Any time you fail to add a feature to maintain simplicity people are going to complain that they use that particular feature. But if you try to make everyone happy you end up with a really bloated interface. To address your other points in comment #24 >To click outside the dialog to close it is NOT easier >than to click OK or press Enter. You're right, if your hands are starting on the keyboard and then you move a hand to the mouse to dismiss the dialog, that will take longer than hitting esc or enter. I think we should fix this by having both esc and enter dismiss the contextual overlay (what we are calling this kind of thing). >In fact, in may actually be more difficult >because you have to move the mouse cursor OUTSIDE the dialog We are going to give the dialogs a close button, which will be a short mouse movement from the star. However, since you are going to need to move your mouse to another target to continue interacting with the browser anyway, it will probably be more efficient in practice to dismiss the contextual dialog on your way to the next target. >I doubt they don't do it because the process is too >difficult. I wouldn't say too difficult, but rather too much expected effort. I think the user knows that that if they hit control-d in Firefox 2, Firefox is going to ask them what folder they want to put the bookmark in. They have to decide, and they have to click ok, the entire process is a lot of clicking and some amount of cognitive effort. Let's say I am bookmarking a product page for a new jacket, which folder should I create for it, winter wear, clothing, things to buy? It's easier just to remember what you need to google for to get back to the page. The new interface is a single click, and zero cognitive effort by default. Later you can retrieve the bookmark by searching in the location bar, which is faster than traditional browse-based interactions for bookmark retrieval.

(In reply to comment #27) [...] > I wouldn't say too difficult, but rather too much expected effort. I think the > user knows that that if they hit control-d in Firefox 2, Firefox is going to > ask them what folder they want to put the bookmark in. They have to decide, > and they have to click ok, the entire process is a lot of clicking and some > amount of cognitive effort. Let's say I am bookmarking a product page for a > new jacket, which folder should I create for it, winter wear, clothing, things > to buy? It's easier just to remember what you need to google for to get back > to the page. The new interface is a single click, and zero cognitive effort by > default. Later you can retrieve the bookmark by searching in the location bar, > which is faster than traditional browse-based interactions for bookmark > retrieval. > I disagree about what is more effort than what. Currently, I am using both Fx2 (BonEcho, 1.8.1 branch) and Sm2 (suiterunner, trunk). When I click "Bookmarks -> Bookmark this page", Fx puts up a dialog asking me where I want the bookmark to go, Sm doesn't. This means that in Sm I have to open the Bookmarks Manager and _then_ move the bookmark to where I want it to go, which is _more_ work than if a popup had come up when I saved the bookmark. Users who like the default location can always click OK on the popup without making any changes, and it serves them as a confirmation that the bookmark has indeed been saved.

(In reply to comment #24) > To click outside the dialog to close it is NOT easier > than to click OK I disagree, the page is a much larger target than a tiny close cross so it takes much more time to dismiss the pop-up. I think if a close button will be present, people will be more satisfied (because it belongs there) but very few will ever use it.

(In reply to comment #29) > I disagree, the page is a much larger target than a tiny close cross so it > takes much more time to dismiss the pop-up. I was talking about a regular OK button not "a tiny close cross".

I have been using the new bookmarking system for a while now and it works great. Formerly I never used the Add Bookmark dialog but I only "drag&dropped" but this feature was broken for at least 18 months now so I was forced to use it anyway. I think however that the transition from Firefox 2 to Firefox 3 should be made as easy as possible, so maybe an option in the Options window with a choice to show either a larger dialog with a description and keyword field etc. (like the dialog here: https://bugzilla.mozilla.org/attachment.cgi?id=282837 , or the (current) smaller one.

The problem with having an option is that (in my opinion) most people don't know that they can customize a program by exploring menus. However, if the option is displayed on the dialog (as a More button or something similar), it's more obvious and more easily accessible, which would be in line with the goal of streamlining UI.

I realize that there is a concern about ending up with a 'bloated interface' but I have to agree that it seems very strange that you can add a keyword and description after you have created a bookmark, but not at the time that you first create it.

This new dialog causes severe usability issues for me, as posted on m.d.p.firefox in thread "Bookmarks not even close to ready for prime-time": * Bad UI in Add bookmark o Why not a modal dialog? This is a *classic* case for it. I edited a web form, accidently hit Ctrl-D instead of Ctrl-C, and wondered why nothing in the form changes, until I noticed the bookmarks "dialog" in the upper right and took my input. o Clicked "Done" to get the dialog away. Later I wondered about a strange bookmark on the top level. I should have clicked "Delete" to Cancel the dialog. How unintuitive is that? Delete sounds destructive, it implies that I remove something that existed before I opened the dialog. "Nevermind" = "Get me out here and forget that I opened the dialog" is called "Cancel", not "Delete"! To actually create the bookmark already before the dialog opens is a violation of GUI principles ('no changes until OK'). o I have no way to create a folder when I add a bookmark! That's very essential for bookmark management and this missing feature alone makes FF3 unusable for me. o It does not remember the open/close state of the folder[view]. It's annoying enough that I have the tags field there (I'm not going to use it, but I understand why it was added), but why do I have to open the folder twisty *every time* I use the dialog? Every bookmark I file is going to go in a folder, I never add bookmarks at the top level, doing so is an error. It should also remember which folder was open

Note that the ellipsis in "Bookmark this page..." is wrong currently, as it bookmarks the page immediately.

Here's what the dialog should be: - no instant apply (keep this for users of special builds if needed) - the dialog is modal - OK and Cancel buttons - allow selection of a folder, and the selection should be persisted - allow entering keywords, tags, and description - some of the fields may be made hidden, but there has to be an easy to find way to show them, and this should be persisted. This is straightforward and easy to use. Use the time saved to implement something users really need such as the Library window (it's not ready either).

[comment #34] >Why not a modal dialog? This is a *classic* case for it. >violation of GUI principles ('no changes until OK') I agree that this is a classic case for a modal dialog, and that what we have currently designed violates the GUI principles of normal OK/Cancel dialogs. However, I also think that the new design is more efficient to use, understandable (albeit new), and it wraps into a lot of changes we have planned for redesigning notifications in Firefox 4, allowing us to later leverage internal consistency. GUI principles and human interface guidelines are important because they try to provide a set of best practices for people to follow. But that doesn't mean that the current set of design patterns is by any means ideal. These are just the best practices of what UI designers have come up with so far. Modal dialogs while a classic design pattern have a lot of problems. Modal dialogs interrupt flow, stealing your attention. Modal dialogs force you to answer questions that you may not actually want to bother to think about. Once you click OK or Cancel on a modal dialog box, there is no obvious way to bring it back if you suddenly change your mind about something. These are all issues that the new design for bookmarking is managing to address. >I have no way to create a folder when I add a bookmark! This was omitted by mistake and will be added back. >It does not remember the open/close state of the folder I agree that it should remember state, and also how the tree was expanded.

>Note that the ellipsis in "Bookmark this page..." is wrong currently, as it >bookmarks the page immediately. Nice catch, filed bug 412387

>Use the time saved to implement something users really need such as the Library >window (it's not ready either) The Places UI design is primarily about two things: -one click bookmarking (or never bookmarking) -searching with the location bar to quickly get back to a page you have been to before (some people call it the awesome bar) So one click bookmarking is a high priority for the places UI design (and higher than the library window). The reason this is such a high priority is because users are now much more likely to simply search google for whatever they want than they are to create and manage a complex hierarchy of bookmarks. Traditional bookmarking has failed to keep up with the simplicity and power of modern search engines. By creating an interface that is as simple as clicking a single star once, and then searching using the location bar, we are able to produce results that are both more customized that google, and faster to retrieve. We are of course still working on the library window, but it will likely only be used by a tiny percentage of users, compared to the bookmarking UI and location bar autocomplete.

> I also think that the new design is more efficient to use, > understandable (albeit new) Neither is true for me. > Modal dialogs interrupt flow, stealing your attention. This is what the dialog does, anyways, even now. On the newsgroups, I also mentioned a practical case: I was typing into a webform and accidently hit Ctrl-D (Add bookmark...) instead of Ctrl-X/C/V for clipboard. The dialog opened, but I didn't notice at first, and wondered where my keyboard entries went. I looked around and saw this little dialog in the upper right. It does interrupt anyways. Making this visually very apparent is good. > Modal dialogs force you to answer questions that you may not actually > want to bother to think about. You intentionally did "Add bookmark..". You do want to think about bookmarking. If you don't care about the details, you still *do* need to get the dialog away. Making this less obvious is contra-productive. I think a lot of people here have said that the instant-apply is very problematic technically, against expectations and has to go. Please follow this advise. The GUI rules have a *reason*. I an using FF3 since a few days only, and I've found myself already several times with unwanted bookmark entries in the top-level menu that I had to get rid of manually via bookmarks manager. Very much not flowing or cool.

> -one click bookmarking (or never bookmarking) Note that the new design does not achieve that. It opens a dialog, so that's at least 2 clicks, to get the dialog away. One-click bookmarking would mean that you take only page content for bookmarking, no user-supplied label (meaning the site puts it "... cheap prizes ..." in the label), no user-supplied organization, neither folders nor tags. I can imagine that for a "dumping-ground" folder, but not for general, organized bookmarking. If you only ever add stuff to your desk/house, you always have to fall back to searching to find anything. Some people like that, others don't.

>Note that the new design does not achieve that Sorry for the confusion, I'll be posting i8 shortly >If you only ever add stuff to your desk/house, you always have to >fall back to searching to find anything Being able to retrieve any item in my desk/house by typing in a few characters of any part of the name would be awesome. I know that some people like to organize stuff for later browsing, but we aren't making that harder. In Firefox 2 the process was Bookmarks > Bookmark this page > select folder (3 clicks) in Firefox 3 the process will be Star (in location bar) > Edit... > select folder (3 clicks).

Ok, here is the latest iteration of the design with changes aimed at: -providing better feedback -supporting undo -making it clear that this is an instant apply interface with by no longer having delete/done that sort of matched to ok/cancel, but not really -new folder button -visual tweaks http://people.mozilla.com/~faaborg/files/granParadisoUI/places_NewBookmarkDialog_i8.png Here is the text from the mockup: ==State 1: Not Bookmarked== User clicks the star, selects the "Bookmark This Page" menu item, or hits control-d Ideally the contextual dialog fades into view. ==State 2: Simple Bookmark Notification== Similar to the Identity Information contextual dialog, and the notification system that has been pushed back to Firefox 4, the 64x64 icon is used so that you can process the message using peripheral vision, and dismiss by clicking anywhere. Ideally when the contextual dialog dismisses it should fade out. --- Note that this is just one of many ways that we may decide to style the contextual dialog, which is covered in a separate mockup. Note that these contextual dialogs intentionally do not contain a close button, this is to force the user to learn to dismiss them by clicking anywhere out side of the dialog, which once learned is a very efficient interaction. --- User hits edit, or clicks the star on page that is bookmarked, or hits control-d on a page that is bookmarked (double click and control-d-d should also work) Ideally the panel should do an animated expand, with the new controls fading in ==State 3: Bookmark Details== In State 3, hitting enter or ESC now clears the dialog, saving changes. --- Name is pre-populated with the page title --- The user enters a new title and moves the focus to a different field --- The text that used to say "Page Bookmarked" now states the last action applied, and provides an undo button. When an undo option is available, control-z activates it. --- The user hits both progressive disclosure controls. --- There is now a new folder button in the contextual dialog. --- ==State 4: Removal Notification== This notification provides feedback and allows the user to undo the remove operation.

Where does the keyboard focus go when the "Bookmarked" dialog opens? If it stays where it was, not going to the flyout, then I can't use the keyboard to go to "Edit...", or it's exceedingly hard. If it goes to the dialog, it *is* interruptive, see my real-world scenario above. In essense, this *is* a normal dialog, and the new layout just tries to hide the fact that it is, making things *worse* (also see above).

>In essense, this *is* a normal dialog In that both this and normal dialogs grab keyboard focus. The key difference is that this dialog tells you "your done" while normal dialogs say "fill out this form." This dialog also maps to a control that can reproduce it. Your "it needs to be obvious" point is valid, perhaps we can achieve that with higher level of contrast, we are thinking about using HUD styling on OS X. >see my real-world scenario above. If you accidently hit control-d, you can either hit ESC or click undo, this is no different than what would happen if you accidentally hit control-d in Firefox 2. Thanks for thoroughly vetting the interface.

I quite like that new design however once the edit button is clicked, I think all UI should be expanded. That is the bookmarks folder selection section and tags definition section. Overall I think this design is very easy to use. The click outside instead of a close button is debatable because it's introducing an inconsistent UI interaction however if this is an iteration with a view towards consistency in Fx4, that's understandable. I've been flooded with email from this bug over the last few days. I haven't read much of it but there seems to be some concerns re keyboard interaction that seem like they have some merit. If these concerns can be addressed, I think the new design will be super. I'd like to congratulate Alex at this point for having the considerable patience and democratic attitude to engage with all the bug commentary over this feature.

in my above comment, #46, the first paragraph refers to concerns previously covered in comments #15, #16, #17. Alex your comment #17 appears to imply that all advanced users prefer predominantly keyboard interaction. I'm not sure this is true. Can we please have at least an about:config pref to set all sections of the new expanded dialog to expanded mode when clicking the Edit button? This would need to be documented somewhere so people can discover it.

>Can we please have at least an about:config pref to set all sections of the new >expanded dialog to expanded mode when clicking the Edit button? An about:config pref won't have very wide impact, perhaps persisting the state of the progressive disclosure controls is the best way to go.

Transparent 'remembering' of previous UI state? BRILLIANT! If only we could re-write the whole browser with that approach, I think it would make the usability of the browser improve incalculably.

> this ... grab keyboard focus Then it's a normal dialog for all intends and purposes and all the problems mentioned above apply. It *is* interrupting my work of e.g. filling out the form. > If you accidently hit control-d, you can either hit ESC or click undo, > this is no different than what would happen if you accidentally > hit control-d in Firefox 2. What's different is that I get a modal dialog in the middle of the screen in FF2, which I can hardly overlook (unless I stare at the keyboard), and which has clear OK and Cancel buttons, and I know I can press the Cancel keyboard button and it will mean Cancel. Here, there is no clear indication of how to get rid of it. You're saying that the Cancel key is like pressing Undo, but there's no indication in the UI for that - I would have assumed it simply closes the dialog, which would leave an unwanted bookmark. As said on the newsgroup, I don't see the advantage over using a simple, normal dialog.

> As said on the newsgroup Here's my proposal: http://groups.google.com/group/mozilla.dev.apps.firefox/msg/5908f92b8060329d

Feedback on your i8: Esc should NEVER result in saving changes. Pressing Esc undoes changes consistently across many pieces of software I've used from different vendors. There has to be a way to undo ALL changes during the current interaction with the dialog not just changes to a field that was last updated. Perhaps, add another button to undo changes to all fields. There must be a description field in the dialog. (In reply to comment #42) > Being able to retrieve any item in my desk/house by typing in a few characters > of any part of the name would be awesome. Users that are intimidated by the bookmarking process won't be able to remember what characters to type to get the full name. So, they won't see the awesomeness you hope to achieve. And more advanced users, who don't scared by a modal dialog when they requested it and are able to click OK button, should be fine with a regular modal dialog, which will make the UI more consistent with other pieces of software. I agree with Ben: I don't see the advantage over using a simple, normal dialog.

(In reply to comment #51) > Here's my proposal: > http://groups.google.com/group/mozilla.dev.apps.firefox/msg/5908f92b8060329d Ben's got some very good points there.

(In reply to comment #52) > Feedback on your i8: Esc should NEVER result in saving changes. Pressing Esc > undoes changes consistently across many pieces of software I've used from > different vendors. > > There has to be a way to undo ALL changes during the current interaction with > the dialog not just changes to a field that was last updated. Perhaps, add > another button to undo changes to all fields. I think hitting Esc once should undo the changes to the last edited or active field. Hitting Esc twice should undo all changes and close the dialog. > (In reply to comment #42) > > Being able to retrieve any item in my desk/house by typing in a few characters > > of any part of the name would be awesome. > > Users that are intimidated by the bookmarking process won't be able to remember > what characters to type to get the full name. I think that is completely false. At some point anyone surfing the web in an exploratory manner - where they are seeking information rather than just clicking link after link - needs to type. They have generally two options: type in the search bar or the location bar. If you cant spell or remember a few characters together, you are not going to get anywhere on the web, yet miraculously the web is a highly pervasive medium! I wonder how it became pervasive with all these people who cannot type a few characters Roman? > So, they won't see the awesomeness you hope to achieve. Anyone who ever types in any characters to the location bar *will* discover the awesomeness. To get anywhere on the web users need to type an address or search a search engine. Firefox covers both infinitely much better with version 3. The awesome bar is going to get so much publicity from those who love it, a lot of people who have not been very frequent location bar users will give it a go and probably keep using it. > > I agree with Ben: I don't see the advantage over using a simple, normal > dialog. > The positioning for one thing. Have the new 'dialog' positioned and styled so it related to the initial part of the UI that spawned it (the star icon), is highly beneficial to for usability IMHO. The user retains a sense of perspective. However I suppose this positioning could be done with a more modal, stylised dialog? If not, an styled element with modal dialog behaviour should be created. AFAIK apart from some quirks, it seems that is exactly what we're getting.

> The positioning for one thing. Have the new 'dialog' positioned and styled so > it related to the initial part of the UI that spawned it (the star icon), is > highly beneficial to for usability IMHO. The user retains a sense of > perspective. I agree with that. If the dialog is positioned so that the top right (not top left) corner touches the star, that makes sense and allows the user to correlate them. Maybe even an arrow pointing at the star. The dialog should be a standard dialog otherwise, though, including titlebar, OK/Cancel button etc.. The size should be large enough for the dialog to jump into the eye (it's currently far too small).

See bug 412027 comment#10 for three alternative suggestions for how to improve the situation for keyboard users WRT hitting Ctrl+D (which IMO is currently just regressing further). Another issue with the new design iteration: Ctrl+Z suddenly gets a double-meaning... Suppose I replace the bookmark's title with "BBookmark", hit [Home] and [Delete]. What happens on Ctrl+Z now? Will it revert the bookmark's title to the original (whatever that was) or will it just undo my deleting one letter (as every other textbox behaves!)?

(In reply to comment #54) > I think hitting Esc once should undo the changes to the last edited or active > field. > > Hitting Esc twice should undo all changes and close the dialog. I also think this would be better. It's customary for Esc to undo changes in an active text field. pd, I don't disagree that the new functionality is valuable, and I welcome it. I was talking about people who are intimidated by simple modal dialogs. I am sure they are too _______ to remember what characters to type to find a previous URL. Also, take a look at http://agency.governmentjobs.com/houstonair/default.cfm?action=viewclassspec&ClassSpecID=30838&Agency=773&ViewOnly=Yes. This page has no title, and relevant words aren't present in the URL. If I were to try to find it in the history, I would type "translator", which would lead me nowhere of value. Hence, being able to modify bookmarks' attributes would be very useful. In cases of pages like this, being *encouraged* to do so would be beneficial.

Due to time constraints I'm unfortunately going to have to keep comments brief, but I am reading all of the feedback. >perhaps persisting the state >of the progressive disclosure controls is the best way to go. mconnor vetoed this due to the interface becoming more complex over time, and people being too lazy to collapse things back down. >Esc should NEVER result in saving changes. Pressing Esc >undoes changes consistently across many pieces of software I've used from >different vendors. I agree, will be updated in i9 >There has to be a way to undo ALL changes during the current interaction with >the dialog not just changes to a field that was last updated. I agree, will be updated in i9 >discover the awesomeness. Kind of off topic, but discoverability of awesomeness is being addressed in bug 396816 >Ctrl+Z suddenly gets a double-meaning I agree (forgot it was active in text fields), I'll fix this in i9 >talking about people who are intimidated by simple modal dialogs It's not about being intimidated as much as users lacking the effort to deal with a complex interface while they are busy doing something else. For instance, I know a lot of very advanced users here at mozilla who while clearly smart enough to know they don't have to fill everything out with the Firefox 2 UI still end up bookmarking more pages in Firefox 3 because the new UI feels like a lightweight interaction.

(In reply to comment #58) > >perhaps persisting the state > >of the progressive disclosure controls is the best way to go. > > mconnor vetoed this due to the interface becoming more complex over time, and > people being too lazy to collapse things back down. So, what will it be? Are we going to have to expand the controls every time we want to change bookmark attributes? That's going to be very annoying. You haven't replied to the request to have the description field in the dialog. We need to be able to set all settable attributes during bookmarking. Going to the Library just to do this is too time consuming.

> >perhaps persisting the state > >of the progressive disclosure controls is the best way to go. > > mconnor vetoed this due to the interface becoming more complex over time, and > people being too lazy to collapse things back down. That's pathetic. In what sense does he mean the interface is more complex? For coders or for users? Can someone explain why one person has the right of veto in this case? Perhaps I don't really want to know. Bloody politics! If people are going to be too lazy to collapse things down, surely the opposite applies that they are either going to be too lazy to open them up or frustrated by having to continually do so and end up not using bookmarks at all because they are not going to add tags and a bookmark list without folder structure is less manageable. Alex can you at least make an about:config pref as I originally suggested. How dare we suggest anything more user-friendly! Now I'll just have to install yet another extension or manually tweak another setting to get a browser that doesn't hide powerful functions in the name of dumbing down the interface.

>You haven't replied to the request to have the description field in the dialog. Sorry for the delay in replying on that. We feel that adding the full set of properties that can be set will make the interface overly bloated and only a very small fraction of users actually want to set a description or keyword. This will obviously annoy that set of users, but we have to make decisions based on what we feel is best for Firefox's user base as whole. >In what sense does he mean the interface is more complex? Users won't go to the effort to collapse down the progressive disclosure controls when they no longer need the more advanced folder and tag options, and will end up with always having a UI that nearly fills the vertical height of their screen. I'm personally indifferent on the decision, because while I agree that this is not ideal I also understand that advanced users (like many of the people commenting in this bug) will be annoyed by having to repeatedly expand the controls. This issue came up with the progressive disclosure control in the bookmarking interface of Firefox 2, and apparently got wontfixed repeatedly. >right of veto in this case? As lead engineer of Firefox, he can approve or block changes. This structure is important because it reduces the design by committee effect, and given the success of Firefox, he has clearly made a lot of very good decisions in the past. >Alex can you at least make an about:config pref as I originally suggested. We are racing to get the required changes in before the freeze for beta 3, while we are not opposed to adding an about:config pref, we may not have time. >How dare we suggest anything more user-friendly! We all want to create an interface that is the most user friendly, but we have to keep in mind the demographics of our overall user base, and the fact that very few people create complex hierarchies. >I'll just have to install yet another extension On the bright side extensions do allow users to get exactly the functionality they personally want while maintaining a clean simplistic interface for mainstream users.

Alex, I am assuming that at least the Folder selector will stay open (and the open state of the folders remembered), as you said that before. Having to expand that Folder selector every time I want to bookmark something will drive me *nuts* and be completely unusable. Things like that are the reason why GNOME apps drive me nuts. While not many people create deep hierarchies, I hope that most people at least create some folders and put all their bookmarks in there. In other words, I think that most users will need the folder selection. And that we should encourage that. I understand and fully agree with the desire to make the app easy to use, also for novice users, and I support that. You must not alienate the average or more advanced users in the process, though. There's a line of how far you can go, and making folder selection hard (including hiding the selector) is definitely crossing the line by *far*.

(In reply to comment #62) > While not many people create deep hierarchies, I hope that most people at least > create some folders and put all their bookmarks in there. In other words, I > think that most users will need the folder selection. And that we should > encourage that. > The idea is to actually not encourage that. The "Star" is there to encourage users to "one click" add bookmarks and never worry about creating and maintaining a folder hierarchy. Just use the location bar to find stuff you've marked as notable. Most people anymore just Google and Google again to find things. Tagging is for power users of Places. Folders is old school. The folder functionality remains for those who can't let go of the old ways. But you are right, since it's there, it shouldn't suck.

I agree that using tags can be better than using folders. Tags provide what folders do and more (although, I wouldn't bet my life on it). But then the dialog will have to display the list of all tags available for selection. Will it? I'd like to. Alex, you could have the description displayed when an option is set. I am sure this is very easy to add and will make lives of those who want to use this much easier. I often add bookmarks for further study in the future, but without a description it's hard to know why exactly I bookmarked something several months ago. And it's very annoying to have to open another window to add a description for a bookmark I am adding right now. I can't count on existence of an extension that would add this trivial feature. As far as judging correctness of actions of the lead engineer of Firefox by success of Firefox is concerned, I'd like to say that it's unknown whether Firefox would have not been much more successful had it not been for some of his actions.

(In reply to comment #63) > (In reply to comment #62) > > > While not many people create deep hierarchies, I hope that most people at least > > create some folders and put all their bookmarks in there. In other words, I > > think that most users will need the folder selection. And that we should > > encourage that. > > > > The idea is to actually not encourage that. The "Star" is there to encourage > users to "one click" add bookmarks and never worry about creating and > maintaining a folder hierarchy. Just use the location bar to find stuff > you've marked as notable. Most people anymore just Google and Google again to > find things. > > Tagging is for power users of Places. Folders is old school. The folder > functionality remains for those who can't let go of the old ways. But you are > right, since it's there, it shouldn't suck. > I think the star system cannot fundamentally replace folder organization. They each serve a different purpose. What you are talking about for how to use the star system is having the user create for themselves a database of interesting links that they can then go back and search through at a later time to find that stuff again. That is fine and dandy. The problem in your thinking is trying to make that synonymous or superseding the idea of creating subject folders of bookmarks that one visits on a DAILY or WEEKLY basis. The star system does not keep one from doing this, you are right, but it does not facilitate this type of user behavior, either. To do this properly, you must have a folder system. (or as was said above, a very in depth tagging system where tags can be traversed or selected like folders) I personally organize my Bookmarks Toolbar into folders, one of them being called "Daily", on which I daily middle click on it and that opens up all my daily site bookmarks into tabs. I also have other folders for other topics that I access frequently that sit there on my bookmarks toolbar as needed. I don't have to go and "search" for these at all, because I have proactively, over time, placed them into a hierarchy that I intuitively know where to look.

(In reply to comment #63) > (In reply to comment #62) > > > While not many people create deep hierarchies, I hope that most people at least > > create some folders and put all their bookmarks in there. In other words, I > > think that most users will need the folder selection. And that we should > > encourage that. > > > > The idea is to actually not encourage that. The "Star" is there to encourage > users to "one click" add bookmarks and never worry about creating and > maintaining a folder hierarchy. Just use the location bar to find stuff > you've marked as notable. Most people anymore just Google and Google again to > find things. > > Tagging is for power users of Places. Folders is old school. The folder > functionality remains for those who can't let go of the old ways. But you are > right, since it's there, it shouldn't suck. > I believe it isn't as simple as that. Compare with a book, a good reference book. It will have a table of contents, organized in volumes, chapters, sub-chapters and sections. It will also have an alphabetical index going linearly from A to Z. Both are necessary (or it isn't a "good" reference book) and both should be easy to use. Organizing bookmarks into folders and subfolders is akin to building a table of contents. Using URL autocompletion is akin to using the alphabetical index. Both are useful at different times. By encouraging people to create a linear bookmarks structure with no folders, you are discouraging the creation of a _useful_ table of contents. For 5 or 10 bookmarks, such a TOC can indeed be regarded as superfluous, I won't challenge that. But as the number of bookmarks increases with time (and I believe it always will, even if slowly), sooner or later the user will get to the point where the sheer number of bookmarks makes a flat folderless structure unmanageable. Folders and subfolders (chapters and subchapters) will, from then on, become indispensable to that user. If he cannot decide, at bookmark creation time, at which point of his bookmark folder tree (his bookmarks TOC) the new entry shall fall, he will grumble about how troublesome and unusable his browser is. He might even leave for a different browser, if he can find one where the bookmark creation dialog makes the bookmark folder hierarchy immediately accessible without the need to repeat the same "disclosure" actions again and again every time, and of course without the need to open the Bookmarks Manager immediately after every creation of a new bookmark.

>you are discouraging the creation of a _useful_ table of contents In the next iteration the menu command "bookmark this page" and the keyboard command control-d will both take the user directly to what we are calling state 2, this will be no more discouraging of creating folder hierarchies than Firefox 2 was. We are also promoting tagging for the use case of creating a table of contents, although instead of a one dimensional hierarchy that is designed for printing on paper the creation is more of a massive venn diagram designed for facetted browsing and hybrid search/browse interactions.

In reply to comment #67 I am not disparaging tags; the reason I didn't mention them is that I haven't yet been actively using a user where bookmarks have them: let's say I was "reserving judgment" concerning them. At the moment, I assume that they will form a new way to look for bookmarks, complementary with both a folder hierarchy and a "frecency"-ordered autocomplete process, but that in the long run none of the three can be expected to push any of the other two from common use. What I mostly reacted to in comment #66 was the statement in comment #63, "The idea is to actually not encourage [the creation of bookmark folder hierarchies]." I personally believe that such hierarchies, even deep ones, become increasingly useful as the number of bookmarks increase, and that they should not be "discouraged". Also, I believe that once the number of bookmarks has reached the point where a hierarchical system will be a necessity, that hierarchy should be accessible immediately, without the need to repeat the "disclose the folder list" action for every new bookmark. IMHO, there *must* be a way to have that list remain in "expanded" state, be it by persisting user expand/collapse actions (which has been vetoed from on high) or by an about:config pref (which I hear will be thought of, but the decision whether or not to implement it will probably be for later than release 3). Well, let's hope it will be 3.0.1 rather than 4.0 or later, because for me such a "permanent folder list" is a necessity. I hear you saying that both "Bookmarks -> Bookmark this page" and the Ctrl-D shortcut will, in the next iteration, open the dialog with the folderlist (and, I think, the tag list) expanded. This makes me feel a little better. Of course, I'll still be watchfully monitoring this bug, and I may even speak up again if I think that there is a risk of "taking the wrong path". But I'll try to "behave" and not unnecessarily spam the bug. :-)

>for me such a "permanent folder list" is a necessity. What about opening the bookmarks sidebar and dragging the favicon to the folder you want? This gives you the full vertical height for the hierarchy, and after the drag operation you can right click to set the properties (including description and keywords).

(In reply to comment #69) > >for me such a "permanent folder list" is a necessity. > > What about opening the bookmarks sidebar and dragging the favicon to the folder > you want? This gives you the full vertical height for the hierarchy, and after > the drag operation you can right click to set the properties (including > description and keywords). > Sure, but any sidebar makes the main page narrower (and, if I have many tabs, may push some of them out of sight), so I prefer other methods when possible.

Historically, I've been an avid creator of folder hierarchies but I've been tying my best to use Firefox3's new tagging system. I find the one-click bookmarking is a great feature for pages that I *might* want to return to later. However, for those pages that are very important to me (tools of my trade, a web-developer, like one of several colour palette sites or reference material) I like the folder system. Perusing a visible tree of folders helps guide me to the bookmark I want. I don't have to remember the tags names I used. Finding a particular bookmark is as easy as following the breadcrumbs, regardless of how infrequently I might use a site. Tags just don't do that for me. I've tried but I get frustrated trying to remember the tags I need. Combine that with Ff3's current behaviour of OR-ing tags rather than AND-ing them and finding that particular bookmark can be quite frustrating.

Folders are not "old school" nor a subset of tags, nor inferior to keyword search, they are a different way of thinking. Some people think in a highly structured way: computers - internet - security - check - NMAP. If I don't remember the name of the software NMAP, I can't find it using bookmark search, but I can find it using the hierarchy. It's provable that hierarchies (esp. if multiple parents are allowed) are superior to tags and keywords. But that's not the subject here. The point is that even if it's not "Web 2.0"-"social networking"-hip, there are very good reasons to use folders, and to *always* use them, and it should not be hard, nor frowned upon or discouraged.

(In reply to comment #69) > >for me such a "permanent folder list" is a necessity. > > What about opening the bookmarks sidebar and dragging the favicon to the folder > you want? This gives you the full vertical height for the hierarchy, and after > the drag operation you can right click to set the properties (including > description and keywords). I thought we were trying to simplify the process of creating bookmarks, not make it more complicated that it already is. Ctrl+B - two keystrokes Click anddrag - one click Right-click to edit - one click Click to focus appropriate field - one click Click OK to confirm - one click Ctrl+B - two keystrokes That's a grand total of 8 keystrokes or clicks. I'm sure your new design with expanded folder section is much more efficient than that Alex.

(In reply to comment #61) > > >In what sense does he mean the interface is more complex? > > Users won't go to the effort to collapse down the progressive disclosure > controls when they no longer need the more advanced folder and tag options, This is opinion or fact? How much user testing does MoFoCo do? Or are design issues directed by a chat around the office, as was alluded to earlier? > and will end up with always having a UI that nearly fills the vertical height > of their screen. I think that's a design flaw in your new UI. I see no reason why the 'dialog' is almost completely vertically oriented when most of the time the UI will be displayed in at least a 4:3 (wider than taller) aspect. I see no functional reason why the assignment of folders and tags sections cannot be side by side > I'm personally indifferent on the decision, because while I > agree that this is not ideal I also understand that advanced users (like many > of the people commenting in this bug) will be annoyed by having to repeatedly > expand the controls. This issue came up with the progressive disclosure > control in the bookmarking interface of Firefox 2, and apparently got wontfixed > repeatedly. I know this comment will generate a "not appropriate place to raise ..." but I disagree ... When will Firefox stop dumbing down the user interface so much? Or perhaps this ongoing issue for advanced users is not necessarily best addressed by fobbing us off with the 'go get a bunch of extensions' line, but by looking at a new suite of features that can be enable in one foul swoop? I understand balancing the needs of different users is a nightmare. However something other than the current methodology is worth considering. I'll save the rest of this for another time/place. > >right of veto in this case? 2> > As lead engineer of Firefox, he can approve or block changes. This structure > is important because it reduces the design by committee effect, and given the > success of Firefox, he has clearly made a lot of very good decisions in the > past. I think that's a very tenuous statement. I wont go into detail but Firefox's market share has not moved significantly for a long time. Arguably it's current market is still niche in comparison to IE and it could easily be argued that IE's ridiculously long time on virtual death row was the biggest reason why Firefox has gained it's stagnant share. Nevermind ... > > >Alex can you at least make an about:config pref as I originally suggested. > > We are racing to get the required changes in before the freeze for beta 3, > while we are not opposed to adding an about:config pref, we may not have time. I was asking for at least an about:config pref because I thought it was necessary for the updating of an extension like OpenBook. If not, not worries. I understand Fx3 is quite late and you are all no doubt trying to get it out the door. > >How dare we suggest anything more user-friendly! > > We all want to create an interface that is the most user friendly, but we have > to keep in mind the demographics of our overall user base, and the fact that > very few people create complex hierarchies. I think as above, there is room for a 'Power User' Firefox. At the moment it's called Opera. There's no reason why a set of extensions cannot be bundled together in a Labs project more meaningful to hardcore users than that toolbar background thing that last came out of Labs. > >I'll just have to install yet another extension > > On the bright side extensions do allow users to get exactly the functionality > they personally want while maintaining a clean simplistic interface for > mainstream users. Extensions are cool if someone has the ability to write them. Not every potentially loyal power user has XUL+JS skills. There are smart people out there who could become fiercely loyal Firefox champions that simply don't have the coding skills to write extensions. Even IT people don't necessarily have XUL+JS skills. Network techs, Excel macro maniacs, etc.

Bookmarks, including folders, is core browser functionality. I'm not going to install an extension to be able to bookmark properly. (Apart from that, most extensions don't work with Firefox trunk builds.) There's a line of how much you can dumb things down, and this is going too far. Aside from that, it's a matter of following user's orders. If I tell the folder view to open, I want it to *stay* open. Closing it every time is saying that you know better what I want than I do.

With the full set of milestone 2 windows icons arriving today I'm afraid I don't have time to reply in much detail to comments. Also, it would in general be better to keep this bug focused on specific design discussion, and move higher level topics like the adoption rate of Firefox, changes in market share, or our overall strategy for user testing to a more public forum like dev.apps.firefox so that everyone can participate in the discussion. A few quick replies: >This is opinion or fact? How much user testing does MoFoCo do? Or are design >issues directed by a chat around the office, as was alluded to earlier? We don't commonly do usability testing in a controlled environment (one way mirrors and all that) in favor of ethnographic interviews, observing users in context, watching feedback that comes in from mainstream users through systems like hendrix, etc. This isn't to say that we wouldn't love to have way more data than we currently have when making decisions. >There's a line of how much you can dumb things down, and this is going too far. Everyone is welcome to continue to request this feature, but I'm personally indifferent (due to the fact that it will create a persistently complex interface), and Mike Connor is clearly against it (which is consistent with his position on the same topic nearly four years ago, in bug 242626).

Here is the latest iteration, i9: http://people.mozilla.com/~faaborg/files/granParadisoUI/places_NewBookmarkDialog_i9.png -the contextual dialog is still instant apply, and you can still close it by clicking outside of the dialog, but a Done button lets you have a target to close, and a Cancel button lets you undo all changes (the Gmail-ish undo queue in i8 wasn't working out) -ESC will undo the initial bookmark, and works as cancel when in the full edit mode -Control-D now opens directly to full edit mode -Added a choose option to the recently used folder menu to improve discoverability of the full folder list -Some styling changes: smaller star icon, tab-like overlay appearance for the dialog itself I'm pretty sure that is all the changes in this last round. If people have feedback try to get it in soon because Mano is about to start implementing the new design.

> ESC will undo the initial bookmark, and works as cancel when in the full edit mode Usually, Esc stops an operation from proceeding, but in Firefox it will work differently -- will undo an operation that's completed. :( I consider i9 a lesser of several versions of evil we've been offered. Please add the description field. That shouldn't be hard. If you (or "the man") think(s) this is a scary field for many to see, display it when an option is set. You could call the option something like this: bookmarks.moreUsefulAddDialog and set it to false by default. Or bookmarks.addDialogForDummies and set it to true by default.

Alex, what do you think of grouping folder options, tag options better so they are clearly separated? the dialog fully opened is looking a bit crowded, is not visually clear that new folder is referring to its upper dialog and not to lower one, a border around foolder picker|bucket|new folder and tag editor would make that more like "this is the section to choose your folder/tag". Or maybe simply moving new folder to the right would make more clear the separation between folder "editor" and tag editor, or a little more space between them.

I have to say that for all my misgivings about the usability of the 'dialog', aesthetically it is very beautiful. I particularly like the latest iteration's 'tab-like overlay appearance' which I assume to mean the 'raised' effect using extra padding and a drop shadow around the star. Aesthetically, very nice work Alex. Congratulations.

What about having CTRL-D open the bookmark dialog with the progressive disclosure controls expanded? After all, I suspect many people who want the state to be remembered might often use CTRL-D to bookmark things instead of clicking.

(In reply to comment #77) > -ESC will undo the initial bookmark, and works as cancel when in the full edit > mode This is completely counter-intuitive because pressing Esc will be expected to close the dialog with all changes that may have been made being discarded, but it will not be expected to undo adding the bookmark. To make the dialog semicorrect, you'll need to enable Ctrl-z for the undo operation. Esc should just close the dialog without any changes -- leaving the bookmark intact. Computer novices are easily confused already, having hard time remembering where to single-click and where to double-click, where to left-click and where to right-click. Don't add more confusion! Now we'll have to teach them that in all application (at least, on Windows) Esc cancels a dialog discarding all changes that may have been made in it, but Firefox acts differently -- it also undoes a previous operation. Or maybe this is a moot argument because novices won't even know or care about Firefox and will be fine with the default browser (IE). Firefox is for geeks, it seems.

AndrewM, Alex wrote this in comment #77: "Control-D now opens directly to full edit mode". I think this means that the progressive disclosure controls will be expanded. I hope it does.

(In reply to comment #84) > AndrewM, Alex wrote this in comment #77: "Control-D now opens directly to full > edit mode". I think this means that the progressive disclosure controls will be > expanded. I hope it does. Yes, I did see that, but as I understand it Alex was meaning that in the latest design, hitting CTRL-D opens directly to State 3 (but with the progressive disclosure controls unexpanded) rather than State 2. What I am proposing is that CTRL-D would open it to State 3, but with both progressive disclosure controls expanded (which might resolve the concerns about the state not being remembered :) Incidentally, it looks like the latest mockup doesn't quite reflect that "Control-D now opens directly to full edit mode", because the text bubble next to State 1 says "User clicks the star, selects the "Bookmark This Page" menu item, or hits control-d" with an arrow pointing to State 2. Also, in State 2, 'always' is misspelled as 'allways' :)

(In reply to comment #83) > (In reply to comment #77) > > -ESC will undo the initial bookmark, and works as cancel when in the full edit > > mode > > This is completely counter-intuitive because pressing Esc will be expected to > close the dialog with all changes that may have been made being discarded, but > it will not be expected to undo adding the bookmark. To make the dialog > semicorrect, you'll need to enable Ctrl-z for the undo operation. Esc should > just close the dialog without any changes -- leaving the bookmark intact. > > Computer novices are easily confused already, having hard time remembering > where to single-click and where to double-click, where to left-click and where > to right-click. Don't add more confusion! Now we'll have to teach them that in > all application (at least, on Windows) Esc cancels a dialog discarding all > changes that may have been made in it, but Firefox acts differently -- it also > undoes a previous operation. Or maybe this is a moot argument because novices > won't even know or care about Firefox and will be fine with the default browser > (IE). Firefox is for geeks, it seems. Roman, I think you may be misunderstanding the mockup (assuming I'm understanding it correctly, that is ;) To me, it looks like ESC *will* "close the dialog with all changes that may have been made being discarded" when it is in State 3 ('Bookmark Details'), thus functioning as you would expect. However, when you have just added a bookmark without editing the details (State 2), it seems very intuitive to me that hitting ESC would undo the action of adding the bookmark, because there are no changes that you can make in the dialog itself.

One more question for Alex: When you click 'Remove Bookmark' (or hit ESC) in State 2, shouldn't it go to State 4 and show 'Bookmark Removed', with the option to undo, rather than to go straight back to State 1? It seems confusing to me to have the 'Remove Bookmark' button behave differently in State 2 than in State 3.

If you hit Ctrl-D, the star or Add bookmark... in the menu, and and you get a dialog allowing you to change the title, it is very untuitive and standard to be able to hit ESC or click Cancel and it forgets about the title/folder change and about the fact that you did Add Bookmark... . The latter means that no bookmark is added. But it also means that if I added a bookmark for this site 3 months ago, that it not deleted or changed either.

BTW: The goal is to make it easy, right? One base rule for GUIs it to not have modes. Because modes confuse users (esp. if they are not visible, but even if they are, they are confusing). In your design, you have no less than 3 different modes ("states") of the bookmark dialog. I would suggest that you redice the number of modes by having a single dialog that appears when I click on the star, Ctrl-D or Add Bookmark... It has the folder, tag, description stuff closed by default, and I can open it via twisties. The open state is remembered, to not annoy advanced users. (I know what mconner thinks, but it's bad for users.) Furthermore, the bookmark should not be added until the dialog is closed*. This fulfills the requirement of making it easy for novice users and for advanced users. It is consistent with other apps and dialogs and avoids several states in the dialog/UI. * Instant-apply here is a merely technical difference, there's no real difference in how the UI works, because I can't see the effects of apply anyways, but the current solution does not work properly, because e.g. my folder selection is ignored the first time and the second click takes 3 seconds(!) to appear. I hear my hard drive rattling hard, on dialog open and on changes in the dialog, much more than even Add Bookmark OK button in FF2.

(In reply to comment #86) > However, when you have just added a bookmark without editing the details (State > 2), it seems very intuitive to me that hitting ESC would undo the action of > adding the bookmark, because there are no changes that you can make in the > dialog itself. It does to me too; however, when the Add Bookmark dialog appears, the bookmark has already been added (the dialog says so). Since Esc usually prevents changes from occurring, the proposed behavior is different from the norm because it undoes what has happened instead of preventing it from happening. What Ben suggested (if I understood him correctly) is good -- hide the dirty fact that the bookmark has been created. This will create an appearance that things are working normally. However, if the browser crashes (which happens too often) before you had time to click Esc, the bookmark will remain in DB even though you intended to prevent that. I actually don't see the benefit of having the bookmark added to DB by the time the dialog appears. Since the confirmation dialog is displayed in anyway, the bookmark could be persisted after the dialog is cleared. If this is done, then pressing Esc would correctly cancel creation of the bookmark, and clearing the dialog in any other way would accept the bookmark.

Comment on attachment 300239 [details] [diff] [review] a patch >- editBookmarkPanelShown: >- function PCH__doShowEditBookmarkPanel() { >- var namePicker = document.getElementById("editBMPanel_namePicker"); >- namePicker.focus(); >- namePicker.editor.selectAll(); >+ panelShown: >+ function SU__doShowEditBookmarkPanel(aEvent) { nit: method name wrong r=me

Comment on attachment 300239 [details] [diff] [review] a patch drivers: high-risk high-impact UI/UE/late-10n/unpolished change.

Comment on attachment 300239 [details] [diff] [review] a patch a=beltzner We need to make sure that a future interaction fix (unless you can do this on checkin) is to add an "OK" button or other explicit close UI when the dialog is in the "Bookmark Removed" stage, but we can do that as a follow-up.

mozilla/browser/base/content/browser-places.js 1.85 mozilla/browser/locales/en-US/chrome/browser/browser.dtd 1.98 mozilla/browser/base/content/browser-places.js 1.86 mozilla/browser/base/content/browser.xul 1.415 mozilla/browser/components/places/content/editBookmarkOverlay.js 1.19 mozilla/browser/components/places/content/editBookmarkOverlay.xul 1.11 mozilla/browser/components/places/public/nsIPlacesTransactionsService.idl 1.10 mozilla/browser/components/places/src/nsPlacesTransactionsService.js 1.13 mozilla/browser/components/places/tests/unit/test_placesTxn.js 1.14 mozilla/browser/locales/en-US/chrome/browser/browser.properties 1.64 mozilla/browser/locales/en-US/chrome/browser/places/editBookmarkOverlay.dtd 1.7 mozilla/browser/themes/gnomestripe/browser/browser.css 1.165 mozilla/browser/themes/gnomestripe/browser/jar.mn 1.68 mozilla/browser/themes/pinstripe/browser/browser.css 1.117 mozilla/browser/themes/pinstripe/browser/jar.mn 1.72 mozilla/browser/themes/winstripe/browser/browser.css 1.159 mozilla/browser/themes/winstripe/browser/jar.mn 1.67

Possible cause of broken bookmarking, bug 414776

Unlikely. That was only checked in at 8:43 PM, not quite two hours ago. The build was made earlier than that.

Fixed now.

The text 'Minefield will always remember this page for you.' is not quite correct. 1. 'will always remember' sounds like a love promise to me... (I will always love mozilla...) 2. 'always' is a bit strong, as Firefox/Minefield still sometimes do loses its bookmarks..., also as soon as I delete the bookmark, I hope that it is really deleted... 3. Just make it shorter.

what about: "Minefield will now remember this page for you."

Much better, if not perfect!

I know some Mozilla guys really like the click-once-and-forget-it idea, but it's obvious a number of users (including myself) prefer or even have need of different behavior. I also know we want to avoid bloat. That said, for the sake of both streamlining and flexibility, I'd like to suggest a Bookmarks preference pane (whether its own or a subset of Advanced) which would contain only a few simple options: --Bookmarking---------------------------------- | When I bookmark a page: | (*) Show a confirmation | ( ) Save bookmark to: |_All Bookmarks_| [Choose...] | ( ) Let me edit details before saving ----------------------------------------------- "Show a confirmation" would display State 2, and would be the default behavior on first launch. I'd then propose changing state 2 in this way: ---------------------------/\--- Page Bookmarked [Undo] [Edit...] [OK] [ ] Show this next time -------------------------------- By default, "Show this next time" would not be selected, so if a user didn't choose it, from then on Firefox would switch to saving the bookmark to All Bookmarks without any dialog (2nd option in Preferences). If it were selected, the 1st option in Preferences would remain set. And yes, I included an "OK" option, because I think a visual method of acceptance is much more intuitive than clicking outside the dialog. Also, it would make it obvious that you could use Enter to dismiss. Regardless, after the first bookmarking, FF3 could display a notification that, once you've bookmarked a page, you can always click the star again to edit details. We've already covered Option 2 (“Save bookmark to:”) indirectly, and it's pretty self-explanatory anyhow, so I'll move on to Option 3, “Let me edit before saving”. Since this is a less common, more power-user option, I'd suggest it would only be accessible via Preferences. If selected, it would display a dialog every time you bookmark a page. I might suggest, additionally, that this dialog not create the bookmark until after it's been confirmed; that is, Escaping out of it could cancel the bookmarking process. In that case, it could be basically the same as the Edit dialog, but with two minor changes: ---------------------------/\--- Bookmark This Page (no Remove button here) Blah blah blah... [Cancel] [OK] -------------------------------- I'm not familiar with the dialog code, but I imagine you could even use the same dialog as Step 3, with the contextual changes made via if/else behavior? I had the thought that this Preference pane could also set the behavior of Ctrl-D, giving us the benefit of consistent bookmarking behavior. People who want to bookmark without any dialog could do so via click OR keyboard, while still being able to edit details later. People who always want to see the confirmation dialog could do so either way; same for people who want to edit by default. It seems to me that inconsistency between click and Ctrl-D would become unnecessary, best left to Add-On territory if someone really wants it. But of course all that's up for debate. I also had another small idea for the Preference pane: --Editing-------------------------------------- | When I edit a bookmark: | [ ] Always expand the Folder list | [ ] Always expand the Tags list ----------------------------------------------- (or, more simply) --Editing-------------------------------------- | [ ] Remember if lists are expanded ----------------------------------------------- A third option is to make this an about:config preference instead. I think this Preference pane idea would shield the average user from complexity, ushering them quietly into the new default behavior, while elegantly retaining more flexibility for those of us who want it. In the end, the changes wouldn't be terribly significant, but they'd make all the usability difference in the world.

This "Undo" feature on the star menu is taking it overboard and is an annoyance. I love that they finally added the Cancel button and the Delete Bookmark button, but this Undo thing just adds one click too many. It is extremely easy to re-click the star and just re-add the bookmark if you really really didn't mean to delete it. Furthermore, the simplified menu that pops up when you click the star is completely unneeded. The same menu that pops up when you go and bookmark the link the old way that is still there, and is also the one that appears when you click the "Edit" button, should be the one that still pops up here. No matter whether you hit Ctrl-D, whether you go to the Bookmark menu and click Add Bookmark, or if you just click the star, it should be the same menu. I do like the fact that when you do it the old way it defaults to the Bookmarks folder, and the new way defaults to the Unfiled folder, though. That can stay. But having to click "Edit' after you click the star is extremely annoying if the menu that follows could just as well have popped up there in the first place with no confusion. I understand that they are trying to make the point to people that they don't have to file the bookmark, and that they can just click away, but I think that would still be completely obvious if they had the more detailed menu just pop up in the first place. It would show that the bookmark now resides in the Unfiled folder, and if the user is cool with that, he could just click away. If not, he changes the location of it. No need to have this Edit button on a super simplified menu mess.

I couldn't read all the comments, but as search on "info bar" and "infobar" leads to zero results, I think that no one mentioned this: It is in the spirit of Firefox to display infobar in situation where there might be some important information for the user and the user action may not be necessary (but is possible). What I want to say is that when one clicks star, he should see the infobar instead of the dialog proposed in the first step of mockup. Personally, I wasn't aware of the need to inform the user about possibility to edit bookmark (though it is a neat idea), but current dialog really bothers me. Infobar would be nice.

The first dialog (Page Bookmarked, called state 1 in the i9 Mockup), is a nice example of something that looked like it might be a good idea in a mockup, and is really annoying when you actually interact with it a lot. The bug to remove it is 414933.

I just had a chance to interact with the dialog that appears when I press Ctrl+D. It's as illogical as I thought it would be when it was being designed. The dialog said, "Page Bookmarked", and offered me to edit the page. I clicked the Cancel button (or pressed Esc) because I didn't want to edit the bookmark, and later found out that the page was NOT bookmarked. That's the first problem -- misleading the user. Also, because adding the bookmark to the database takes time (at least, it does Firefox), sometimes I thought FF didn't notice my command and pressed Ctrl+D twice. After the second time, I was presented with a dialog giving me the option to remove the bookmark (that I thought I hadn't added yet). I think folks at Microsoft and other competitors are laughing their asses off seeing this. It would've been amusing to me too if I didn't use FF.

OK guys, please calm down! :-) There is a simple solution I think. Prior to fix for bug 415105, Accessibility used a different label for the dialog, which says "Bookmark this page". I filed bug 415439 in which I recommend a course of action to take for the current status the Add Bookmark dialog is in.

The new approach to bookmarks is a big change. I didn't really understand what was going on until I read this thread - and I consider myself an advanced user. I'm still on FF3b2, but it looks like the recent changes are going a long way to helping ease the transition for new (to FF3) users. Most of the complaints I had seem to be addressed. Despite folders being an 'anachronism' (something I disagree with :), people are going to stubbornly stick with them, so I think you still need to consider these users. To whit: Gripe#1. I have around twenty top-level folders. Manipulating the folder hierarchy through the current keyhole (size=8 in b2) is a pain. It is going to be much more annoying if it reduces in size as shown in the last mockup (#19). I really think the folder selector widget needs to be resizable (and remembered) to accommodate users (like me) who prefer to folder their bookmarks. Gripe#2. Even when using folders I still have a lot of bookmarks that are unsorted. The 'Bookmarks' menu is large and unwieldy to scroll as it is. If the idea - like Alex says - is that folders are pointless/discouraged then that menu is going to be even worse. It almost seems pointless to display them in the Bookmarks menu at all. A scrolling list of hundreds of unsorted bookmarks is plain silly IMO. Perhaps by default bookmarks should go into an 'Unsorted bookmarks' folder rather than the top level 'All bookmarks' folder.

To add my five cents: 1. The two different 'states': 'FF will always remember' and 'Page Bookmarked' are confusing. The first is not needed. 2. Re. Gripe#1: I agree bookmark folder mgmt is diff. through these panels. May be add a 'Manage Bookmarks' button to the 'PageBookmarked' panel to access the real bookmark manager? 3. Re. Gripe#2: I agree here also. Some options: provide sort options. Use tags as 'folders' (ie show in the Bookmarks menu the list of tags (gmail also uses tags to do 'folders'). 4. Drag & drop from urlbar in to the bookmark menu's is not working as it did in FF2.

Alfred, why would you want to go the bookmark manager from the Add Bookmark dialog? If the dialog is made convinient enough to add a bookmark in the right place and with desired attributes (title, tags, description), then there will be no need to go the bookmark manager.

Just because people find it difficult to find the bookmark manager (like the comment above #110, where one tries to resize the panel to manage the folders).

mozilla/browser/base/content/browser-places.js 1.93

(In reply to comment #114) > Created an attachment (id=301315) [details] > disable both the initial notifcation and th undo-remove-ui See bug 414933 comment 22 for more information; this checkin fixes bug 414933.

I think that, in Gnome at least, the Remove Bookmark button should be at the bottom left: it's very unusual for “do something and dismiss” buttons to be at the top of a dialogue (I'm aware that this isn't technically a dialogue, but still). Should I file a new bug for this? (There's no dependent bug about styling this dialogue on Gnome.)

Bug 415780?

>“do something and dismiss” buttons to be at the top of a dialogue It is also odd for the button to be "delete and dismiss" we are concerned about accidental dataloss when the use clicks what they expect to be either OK or cancel without looking carefully and end up hitting delete. Also three buttons on the bottom of the dialog is a little more confusing than two, and the remove command has a direct association with the title phrase "page bookmarked." The interface is a little funky, but those are the reasons I think it works better with the remove button on the top.

(In reply to comment #119) > the remove > command has a direct association with the title phrase "page bookmarked." The > interface is a little funky, but those are the reasons I think it works better > with the remove button on the top. Maybe it would look less funky if we would group the button better with the title phrase. I'll attach a screenshot.

(In reply to comment #119) > It is also odd for the button to be "delete and dismiss" we are concerned > about accidental dataloss when the use clicks what they expect to be either > OK or cancel without looking carefully and end up hitting delete. OK and Cancel are never at the left of a dialogue in Gnome, so I don't think that sort of confusion would arise. To be clear: in Gnome, Cancel and Done are right-aligned (here and in general). > Also three buttons on the bottom of the dialog is a little more confusing > than two, Having one set of buttons in the bottom-right and one button in the top-middle seems pretty confusing to me (or at least untidy). It's platform convention to keep such buttons at the bottom of the dialogue; and there are two sets of buttons that aren't aligned either vertically or horizontally. > and the remove command has a direct association with the title phrase "page > bookmarked." That's a fair point. Equally, though, the whole dialogue is about the page being bookmarked. Remove Bookmark doesn't seem out of place at the bottom (to me). Moreover, I've used Gnome for more than a year and I *instinctively* went to the bottom-left assuming the button would be there. > The interface is a little funky, but those are the reasons I think it works > better with the remove button on the top. I disagree; well, I agree that's it's a little funky :) I think it'd be better to have them all at the bottom, but with Remove Bookmark clearly separated from the other two with some extra space and by being left-aligned – see the attached mock-up. This would entail making the overlay a little wider (which would afford more space for the bookmark's name and tags), but it would also end up less tall and there'd be more room around the main heading. This is the same layout as Firefox's “you're closing multiple tabs; do you want to save the session?” dialogue: “Cancel” and “Save & Close” are on the right; “Quit” is at the far left. (Incidentally, I noted while making this mock-up that the Remove Bookmark button is two pixels taller than the other two.)

To add to current discussion: When I first saw this dialog, I was looking for Remove Bookmark at the bottom of it, and was confused when I didn't find it. Actually, I kept looking for it at the bottom for it several times after. And even now when I know where I should look for it, it takes more time to focus it and click it than if it was at the bottom. I clearly agree that there could be wrong clicks, but shouldn't there be dialog "are you sure that you want to delete bookmark?". Or you should add trash folder for bookmarks. That is usual way to prevent data loss. Some more points on current dialog: 1. Done and Cancel seems to be wrongly ordered on Windows. Shouldn't Done be right? 2. Rethink the dialog so that it could be useful when accessed from keyboard. If the dialog is frequently used for editing tags, isn't it strange that it is easier to select that field with mouse than to tab through dialog? Moving Folders to the bottom seem logical to me, as it is expected to be edited with mouse, so people won't care so much about order. I would also rethink about putting Title to second place, as I guess it is more likely for one to edit tags than title.

(In reply to comment #123) > To add to current discussion: > > When I first saw this dialog, I was looking for Remove Bookmark at the bottom > of it, and was confused when I didn't find it. Actually, I kept looking for it > at the bottom for it several times after. And even now when I know where I > should look for it, it takes more time to focus it and click it than if it was > at the bottom. > > I clearly agree that there could be wrong clicks, but shouldn't there be dialog > "are you sure that you want to delete bookmark?". Or you should add trash > folder for bookmarks. That is usual way to prevent data loss. > > Some more points on current dialog: > > 1. Done and Cancel seems to be wrongly ordered on Windows. Shouldn't Done be > right? I agree, Done should be right

(In reply to comment #123) > To add to current discussion: > > When I first saw this dialog, I was looking for Remove Bookmark at the bottom > of it, and was confused when I didn't find it. Actually, I kept looking for it > at the bottom for it several times after. And even now when I know where I > should look for it, it takes more time to focus it and click it than if it was > at the bottom. I agree.

Done should NOT be on the right. Standard order of windows buttons is "Yes" "No" "Cancel". So Done should be leftmost, and cancel rightmost. As for other to quote myself :) In fact here's what I think star behavior should look like - one click on blank star - add bookmark - one click on yellow star - remove bookmark (if a dialog is absolute must, then yes no confirmation) - doubleclick on any star - full bookmark dialog

(In reply to comment #126) > Done should NOT be on the right. > Standard order of windows buttons is "Yes" "No" "Cancel". So Done should be > leftmost, and cancel rightmost. On GNU/Linux (at least on GNOME), it should be on the right. Preferences/Options menu item is in different places for the same reason. > As for other to quote myself :) > In fact here's what I think star behavior should look like > - one click on blank star - add bookmark > - one click on yellow star - remove bookmark (if a dialog is absolute must, > then yes no confirmation) > - doubleclick on any star - full bookmark dialog Please, no unnecessary double-clicks, and please, no tag removal without confirmation.

(In reply to comment #126) > Done should NOT be on the right. > Standard order of windows buttons is "Yes" "No" "Cancel". So Done should be > leftmost, and cancel rightmost. My bad wording. But I was complaining because it is not like that.

The folder view the panel provides when expanded is much too small: it's neither wide enough nor tall enough to navigate a detailed folder hierarchy without an onerous amount of scrolling. It just feels really cramped. Previous "add bookmark" panels were always resizable and I believe this new one should be, too.

The size bothers mee too. The title field in the original dialog is too small to really edit it before saving the bookmark (a lot of scrolling). I often remove common terms from the title and add tag-like items to the title to improve search results. I have given up on folders on the other hand. I haven't used tags at all so far as editing the title is usually quicker and usually only one or two keywords are missing. I also miss the ability to add keyword entries- those are really important to me. I access most of my bookmarks this way. The change to instant-apply also bothers me. https://bugzilla.mozilla.org/attachment.cgi?id=282837 looks fine to me. Maybe a simple/full view with expand button that remembers the expand choice?

I think that this bug is getting large and unwieldy, and oin nowhere. Please file bugs on individual issues as followups and nominate for blocking as appropriate.

>I think that this bug is getting large and unwieldy, and oin nowhere. Please >file bugs on individual issues as followups and nominate for blocking as >appropriate. This is a UI design tracking bug for discussion of each iteration of mockups, I'm not sure how it ended up blocking. Setting back to ? so that the drivers can remove the blocking flag (unless there was a reason I'm not aware of).

Is there any chance of getting the Remove Bookmark button moved to the bottom-left before the final release? (bug 415780) Although Faaborg objects (comment 119), I responded to (and hopefully resolved) those concerns in comment 122. There've also been several other (albeit less influential) people who agree that the bottom-left is a more intuitive and consistent place for this button on Gnome.

Currently, in tonight's build at least (Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008032204 Minefield/3.0b5pre FireShot/0.32) double clicking on a bookmarked page's star opens the dialog and makes the "remove bookmark" button disappear. To reproduce: 1. Bookmark a page with a single click on the star 2. Wait a few seconds 3. Double click (fast enough for it to be a double click on your system) on the star. What you will see is the dialog appearing on first click and the "remove bookmark" button disappearing on second click. Maybe this should be filed under a new bug? Regarding comment 119 about the button to remove being at the top making sense, well, it does make as much sense as making a click on the highlighted star to automatically remove the bookmark. Meaning that it's something users will learn pretty immediately and hence it is ok to change expectations. Though, having said that, the web is already littered with voting stars that are turned on/off this way, so it makes it even an easier choice to make it work as such. The double click could then open the dialog. Considering one click on a highlighted star being data loss has no merit. If it did, the close button in a tab would have to be considered data loss as well. In the case of the tab, more so, because knowing how to get that back is not apparent as it is when a star that was yellow turns white... "click again?" "ah, there is the yellow back, nice!"... Pretty straight forward, and all it took a newbie to learn this. And if someone still believes that a click to remove a bookmark is akin to data loss, I have an idea for their next plugin: make a list of the pages that had their bookmark removed, keeping all metadata, so if you go to that list and decide to restore an ex-bookmark, it will be a complete restoration. Oh, an in the menu, under Bookmarks, add an entry called "Recently Removed Bookmarks >". That's were you go to see the lost bookmarks. Keep the list to survive between restarts of the application and you'll be safe.

(In reply to comment #134) > Currently, in tonight's build at least (Mozilla/5.0 (Windows; U; Windows NT > 6.0; en-US; rv:1.9b5pre) Gecko/2008032204 Minefield/3.0b5pre FireShot/0.32) > double clicking on a bookmarked page's star opens the dialog and makes the > "remove bookmark" button disappear. > > To reproduce: > > 1. Bookmark a page with a single click on the star > 2. Wait a few seconds > 3. Double click (fast enough for it to be a double click on your system) on the > star. > > What you will see is the dialog appearing on first click and the "remove > bookmark" button disappearing on second click. > > Maybe this should be filed under a new bug? > I am glad you aren't referring to double clicking to add a bookmark, as that would have been horrible if something changed there. Yeah, it looks like a bug if you double click on a yellow star. Unless there is some separate functionality that we are missing, I think a double click on a yellow star should do the same thing as two spaced out clicks on a yellow star, which is to have the menu go away. > Regarding comment 119 about the button to remove being at the top making sense, > well, it does make as much sense as making a click on the highlighted star to > automatically remove the bookmark. Meaning that it's something users will learn > pretty immediately and hence it is ok to change expectations. Though, having > said that, the web is already littered with voting stars that are turned on/off > this way, so it makes it even an easier choice to make it work as such. The > double click could then open the dialog. > > Considering one click on a highlighted star being data loss has no merit. If it > did, the close button in a tab would have to be considered data loss as well. > In the case of the tab, more so, because knowing how to get that back is not > apparent as it is when a star that was yellow turns white... "click again?" > "ah, there is the yellow back, nice!"... Pretty straight forward, and all it > took a newbie to learn this. > > And if someone still believes that a click to remove a bookmark is akin to data > loss, I have an idea for their next plugin: make a list of the pages that had > their bookmark removed, keeping all metadata, so if you go to that list and > decide to restore an ex-bookmark, it will be a complete restoration. Oh, an in > the menu, under Bookmarks, add an entry called "Recently Removed Bookmarks >". > That's were you go to see the lost bookmarks. Keep the list to survive between > restarts of the application and you'll be safe. > The data loss occurs if you have actually filed the bookmark into a folder. There is no dataloss if it is unfiled, because you can just click the star again, but if it has been filed, then you have lost knowing the folder where the bookmark was originally filed.

> The data loss occurs if you have actually filed the bookmark into a folder. > There is no dataloss if it is unfiled, because you can just click the star > again, but if it has been filed, then you have lost knowing the folder where > the bookmark was originally filed. > In other words, you have removed a bookmark somewhere in your Bookmarks Library, accidentally, and you now don't know where you had it placed. You may have also lost the specific position where you had it placed within that folder.

(In reply to comment #136) > > The data loss occurs if you have actually filed the bookmark into a folder. > > There is no dataloss if it is unfiled, because you can just click the star > > again, but if it has been filed, then you have lost knowing the folder where > > the bookmark was originally filed. > > > > In other words, you have removed a bookmark somewhere in your Bookmarks > Library, accidentally, and you now don't know where you had it placed. You may > have also lost the specific position where you had it placed within that > folder. Then, so that we can have the nice, easy to understand behavior in both situations, code it so that if you remove the star from a bookmarked page and then add it again, the place, ordering, tags, etc. of the original are remembered. Do that as long as you are in the session. Now that that's done, a click on a white star makes it yellow and bookmarks the page. A click on a yellow star turns it white and removes it from bookmarks. If the latter was a mistake, click it again and you are done. The fact that it was already filed under a not so easy to find folder is a non-issue. The system kept track of it on your behalf.

(In reply to comment #134) > Currently, in tonight's build at least (Mozilla/5.0 (Windows; U; Windows NT > 6.0; en-US; rv:1.9b5pre) Gecko/2008032204 Minefield/3.0b5pre FireShot/0.32) > double clicking on a bookmarked page's star opens the dialog and makes the > "remove bookmark" button disappear. Bug 415932 (listed in this bug's dependencies)

(In reply to comment #137) > (In reply to comment #136) > > > The data loss occurs if you have actually filed the bookmark into a folder. > > > There is no dataloss if it is unfiled, because you can just click the star > > > again, but if it has been filed, then you have lost knowing the folder where > > > the bookmark was originally filed. > > > > > > > In other words, you have removed a bookmark somewhere in your Bookmarks > > Library, accidentally, and you now don't know where you had it placed. You may > > have also lost the specific position where you had it placed within that > > folder. > > Then, so that we can have the nice, easy to understand behavior in both > situations, code it so that if you remove the star from a bookmarked page and > then add it again, the place, ordering, tags, etc. of the original are > remembered. Do that as long as you are in the session. Now that that's done, a > click on a white star makes it yellow and bookmarks the page. A click on a > yellow star turns it white and removes it from bookmarks. If the latter was a > mistake, click it again and you are done. The fact that it was already filed > under a not so easy to find folder is a non-issue. The system kept track of it > on your behalf. > I like that idea in theory for data integrity purposes, but the problem is that implementing that behavior would remove the "Edit this bookmark" menu capability that we currently have when clicking on a yellow star, which I find very useful. All I can think of that would serve everyone's purposes would be to have what the left click behavior strictly activate or deactivate the star like you are saying, and have the "Edit this bookmark" menu come up immediately on a right click (not a context menu, but the actual menu that currently comes up on left click). If it is currently white, a right click would bookmark it into unfiled and bring up the "Edit this bookmark" menu, as if you clicked on the "Bookmark this page" option in the Bookmark menu. If you right click a yellow star, it brings up the "Edit this bookmark" menu the way currently a left click does. That would be very intuitive, and neither camps would have to make an extra click to get what they want to happen. The left click would be for newbies and minimalists, and the right click would be for power users. Now, more generally speaking, I would also have no problem with having the data integrity behavior you mentioned implemented for all accidental removal cases. Say, for the current trunk, when you left click on the yellow star, and then somehow you accidentally click on the "Remove Bookmark" button when you didn't want to, clicking on the white star again will bring it back to the way it was before the bookmark was removed. That would be useful no matter the case.

Sorry, a typo above, What I meant to say was, "All I can think of that would serve everyone's purposes would be to have the left click behavior be for strictly activating or deactivating the star, and have the "Edit this bookmark" menu come up only on a right click (not have a context menu pop up, but the actual current "edit this bookmark" menu that we have come up on left click in the trunk)" I think that would make a lot of intuitive sense, and would cover everyone's needs here who have been going back and forth about it.

Oh, and make sure to leave the behavior how it currently stands regarding when you select "Bookmark this page" from the Bookmark menu, or "Ctrl+D", as those were done on purpose to not leave people out in the cold who were used to the old bookmarking behavior. What I am proposing would, that way, completely cover all bases.

Regarding the data loss, it's really not that hard to prevent it. Something along the line of (mockup): IF "tag is present" OR "folder is other than unfiled folder" THEN "confirmation dialog". It is really simple, so I'll join others and repeat my pledge to revert to one click "bookmark/remove bookmark".

(In reply to comment #142) > Regarding the data loss, it's really not that hard to prevent it. > > Something along the line of (mockup): > > IF "tag is present" OR "folder is other than unfiled folder" THEN "confirmation > dialog". The only problem with this option is that it does two different things depending on something else for a given action. This is akin to the drag and drop of files in Windows Explorer. If you are dragging and dropping in the same disk drive, it "moves" the files, but if you are dragging and dropping to a different drive, it "copies" the files. In the end, it's an action you can't rely on. I rather we kept track of it in the background and made the action standard.

Maybe we should discuss this in the forums instead of the bug :) I don't think there's a realistic chance of implementing tracking for every bookmark ever made. Database would just bloat and slowdown bookmark access as it would check against more and more old bookmarks. Besides, there would surely be people to frown upon keeping deleted bookmark data as it's an obvious privacy issue.

(In reply to comment #144) > Maybe we should discuss this in the forums instead of the bug :) Ok, just last comment to yours, though. > I don't think there's a realistic chance of implementing tracking for every > bookmark ever made. It would be session based, as is the case with "Recently Closed Tabs >" > Database would just bloat and slowdown bookmark access as > it would check against more and more old bookmarks. Just those changed within your current session. > Besides, there would surely > be people to frown upon keeping deleted bookmark data as it's an obvious > privacy issue. As long as it was kept only for the duration of the session, it would have no impact, or as much as you can say of the "Recently Closed Tabs" feature.

Just an idea I just had... Would it make sense, when adding a bookmark, to populate the Tags field with the contents of the page's <meta name="keywords"> field?

(In reply to comment #146) > Just an idea I just had... > > Would it make sense, when adding a bookmark, to populate the Tags field with > the contents of the page's <meta name="keywords"> field? That's bug 404129.

This was a tracking bug for Firefox 3 development, resolving.

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv