In https://bugzilla.mozilla.org/show_bug.cgi?id=411261#c25 Dietrich wrote: >Thanks for the patch Andrew, but I don't think we should be extending that >dialog. Instead, we should be standardizing on the new bookmark properties >panel, and removing the old one. > >I think that the dialog should embed the new panel, like the library does. This >will reduce code and provide a consistent experience for users. > >I also don't like that there are two versions of bookmark properties UI >available via primary UI that are so radically different in appearance, but >that's an issue for another bug. To review all of the motivations here: 1) reuse code to reduce complexity 2) use a consistent interface so that users are not confused I think everyone is on board with both of those motivations, but I'm not sure how far we go with matching the bookmark contextual dialog (the thing that hangs off of the star in the location bar) in the other instances of the bookmark properties dialog. Here is the list Marco gave me on irc: 1. history sidebar, right click and choose Bookmark this link 2. places views (menu, toolbar) context menu New Bookmark, New Folder 3. subscribe a livemark 4. Add keyword for this search 5. add a sidebar panel clicking on a link or through js function addPanel 6. drop a bookmark over the bookmarks Library icon after customize toolbars 7. Bookmark all tabs 8. Context menu properties Also, I think: 9. Library window properties pane (?) 10. "Bookmark this Link" on the contextual menu of a hyperlink in the content area (screenshot in attachment). There might be more instances of creating / editing a bookmarks properties, but those are all of the ones I know about. In terms of Dietrich's comment: >I also don't like that there are two versions of bookmark properties UI >available via primary UI that are so radically different in appearance The bookmark contextual dialog is instant apply, and has a click outside to dismiss behavior (the click outside to dismiss behavior is conveyed visually by referencing other interfaces that are click outside to dismiss). Adapting the instant apply nature of the interface to other instances of the bookmarks property dialog is fine, but carrying over click outside to dismiss behavior doesn't make any sense in the other contexts. For instance, the "Bookmark this Link" interface isn't visually associated with anything that could recreate the interface (like the star in the location bar) and it is kind of awkward in the upper left hand corner of the content area. So I propose that we leverage some of the existing code, which means that they will become instant apply. However, they should really remain (including the "Bookmark this Link" instance) real modal dialog boxes, with Done / Cancel buttons. Also, the large star icon, title and "Remove bookmark" items don't need to appear in these other instances of the bookmarks property interfaces, since a contextual command already set the context of what the user is doing, and there was also a contextual delete command. I probably still need to clarify a bunch of stuff, but what do people think of that overall approach?

imho the hardest part is is mixing up in a sane way the need for a common UI with the user need of a dialog-like panel (as you said for example screen reader users, but i can tell for sure mostly Windows users prefer a classic panel to instant apply). I agree with the idea of a MODAL dialog with a border and Done/Cancel buttons so the user has to take a decision. Instant apply is quite easy and straight-forward for the edit case (so "properties"), it's already used when clicking the active star and in the Library pane. In the add case we will have to guess some data. Case 2 is maybe the most strange since we don't know anything about the bookmark (but probably the position where the user wants to create it, so we should create an about:blank bookmark with title New Bookmark, and let the user edit it, but we should present empty fields that are easier to fill).

Alex, one thing I noticed some days back is the complicated way how to chance the URL of an already saved bookmark. Currently we aren't able to do this via the contextual dialog. Users have to open the Library, navigating to the folder the bookmark resists in or doing a search within the Library. Afterwards they can change the URL in the details pane. But this is the only place. IMO this simple action is really complicated and needs a lot of user interaction until the aim can be achieved. At least the bookmark properties dialog shouldn't miss this field. It will make the life a lot easier for users who only want to update an outdated URL without the need of removing, re-adding, and retagging.

This because we are thinking about bookmarking being more like flagging an email, just a quick gesture to mark something interesting. If someone wants to change the URL of a bookmark, I would argue that what they really want to do is bookmark something else (just like you don't change the email of an existing flagged email, you flag some other email). Changing the folder, set of tags and name is extra work, but urls don't change all that often, and someone who sets all of this information will probably be familiar with the library window or sidebar to select "properties."

Alex any news here? I have a first working implementation (instant apply in a dialog) with following situation, hope this helps you telling what should be hidden and what should be changed here, after your first suggestions i would create a trybuild so you could suggest further refinements: 1. in history sidebar, right click on a visit and choose Bookmark this link Contents: name(filed), folder picker(bookmarks menu), Tags(empty) Title: "Add Bookmark" AcceptButton: "Add" 2. on Places views (menus, toolbars, trees) right click and choose New Bookmark contents: name("New Bookmark"), location("about:blank"), tags(empty), keyword(empty), description(empty), load in sidebar(unchecked) Title: "Add Bookmark" AcceptButton: "Add" 3. on Places views (menus, toolbars, trees) right click and choose New Folder contents: name("New Folder"), description(empty) Title: "Add Folder" AcceptButton: "Add" 4. go to a livemark, click subscribe using live bookmarks contents: name(filed), folder(bookmarks toolbar) Title: "Add Live Bookmark" AcceptButton: "Add" 5. right click on a search field, "Add keyword for this search" name, keyword, folder picker contents: name(empty), folder(bookmarks menu), tags(empty), keywords(empty) Title: "Add Bookmark" AcceptButton: "Add" 6. add a sidebar panel on http://www.google.com/mozilla/google-search.html contents: name(filed), folder(bookmarks menu), tags(empty) Title: "Add Bookmark" AcceptButton: "Add" 7. click on a panel Add link with rel="sidebar" (tested on http://tntluoma.com/sidebars/ Add links) contents: name(filed), folder(bookmarks menu), Tags(empty) Title: "Add Bookmark" AcceptButton: "Add" 8. add bookmarks button through customize toolbars, drag & drop a link upon it should show name (filled) and folder picker contents: name(filed), folder(bookmarks menu), Tags(empty) Title: "Add Bookmark" AcceptButton: "Add" 9. right click a bookmark and choose properties contents: name, location, folder, tags, keyword, description, load in sidebar Title: "Properties for "title"" AcceptButton: "Save Changes" 10. right click a livemark and choose properties contents: name, feed location, site location, folder, description Title: "Properties for "title"" AcceptButton: "Save Changes" 11. right click a folder and choose properties contents: name, folder, description Title: "Properties for "title"" AcceptButton: "Save Changes" 12. right click a smart bookmark and choose properties contents: name, folder, description Title: "Properties for "title"" AcceptButton: "Save Changes" 13. open 2 tabs, from bookmarks menu choose Bookmark all tabs contents: name("[Folder Name]"), folder(bookmarks menu) Title: "Bookmark All Tabs" AcceptButton: "Add Bookmarks" 14. "Bookmark this Link" in context menu of a hyperlink in the content area contents: name(filed), folder(bookmarks menu), Tags Title: "Add Bookmark" AcceptButton: "Add" 15. "Bookmark this Link" in context menu of an already bookmarked hyperlink in the content area contents: name, location, folder, tags, keyword, description, load in sidebar Title: "Properties for "title"" AcceptButton: "Save Changes"

also, i think we agree all dialogs should be modal since we instant apply, actually only complete dialogs are, while minimal ui is modal only on OS X, so for example if i choose "Bookmark All Tabs" the dialog on Windows is not modal, so the user could close the browser without closing the dialog, losing bookmarks.

Alex you can test with trybuilds in https://bugzilla.mozilla.org/show_bug.cgi?id=411261#c45, the final result is slightly different from comment 4, more similar to actual behaviour... so i think it would be easier for you trying the build and put comments over dialogs

I'll try to get to this soon, if I don't reply within 48 hours can you ping me again.

to help Alex i'm posting screenshots of the different dialogs

This isn't a huge deal, but a lot of the dialogs have different spacing between the fields. Ideally the spacing would be the same across the board. Also, the progressive disclosure controls should ideally be the same height as the text field so that it visually groups a little more, and just so things look aligned.

In terms of wording, I've been giving some thought to the window titles and commit buttons for each dialog. -I think we should alter the titles to be a little closer to the action the user just took -In cases where there is pre-populated information, I think the commit button should just be "Save" (not "Save Changes" or "Add"). This is because the dialogs are instant apply, and "Save Changes" implies the changes haven't been saved yet (they have), and "Add" implies it hasn't been added yet (it has). -In cases where there is no pre-populated information, I think the commit button should be "Add." This is intentionally inaccurate, the bookmark or folder has already been created, but I think it reads a little better and feels more natural. -In cases where the user is clicking a link to get a dialog box to add a new bookmark, the commit button should be "Add," since the pre-populated information is coming from a third party, and they might not have even expected to see a dialog when they clicked on the link. Here is all the suggested text in the form: user action > "window title text" > "commit button text" 1. history sidebar / bookmark this link > "New Bookmark" > "Save" 2. context menu / New Bookmark > "New Bookmark" > "Add" 3. context menu / New Folder > "New Folder" > "Add" 4. livemark subscribe > "Subscribe to Live Bookmark" > "Subscribe" 5. add keyword for this search > "New Bookmark" > "Save" 6. Add sidebar panel > "New Bookmark" > "Add" 7. bookmark a rel="sidebar" link > "New Bookmark" > "Add" 8. drop on Bookmarks in the toolbar > "New Bookmark" > "Save" 9. Properties of a bookmark > "Properties for [name]" > "Save" 10. properties of a livemark > "Properties for [name]" > "Save" 11. properties of a folder > "Properties for [name]" > "Save" 12. properties of a smart bookmark > "Properties for [name]" > "Save" 13. bookmark all tabs > "New Bookmarks" > "Add Bookmarks" 14. bookmark this link in content > "New Bookmark" > "Save" 13. bookmark this link in content when bookmark exists > "Properties for [name]" > "Save" I think for 6 and 7 we should show the URL (since hte user hasn't seen it yet), and we should show the check box "load this bookmark in the sidebar", with the box checked. How are 3 and 13 instant apply if they don't have a folder name yet?

(In reply to comment #24) > How are 3 and 13 instant apply if they don't have a folder name yet? I use the default folder name so also on IRC we ponted out that about:blank for a new bookmark should be hidden if possible. actually I could fix code and strings, and let further css refinements like spacing for a second pass after the string freeze

next nightly will contain changes, so feel free to add suggestions here (that are not part of known bug 413053)

(In reply to comment #24) > -In cases where there is no pre-populated information, I think the commit > button should be "Add." This is intentionally inaccurate, the bookmark or > folder has already been created, but I think it reads a little better and > feels more natural. This makes sense assuming that there is an associated "Cancel" button which destroys the newly created resource. That indeed seems to be the case as far as I can tell. Those strings all look much better, yes. > How are 3 and 13 instant apply if they don't have a folder name yet? Items I create using 3 don't seem to show up until I click "Add", fwiw. Or is that part of the change you're making? It's important that in those cases "Cancel" means "don't actually create the thing" as opposed to "don't rename the thing from the default name to what I just said".

(In reply to comment #27) > > How are 3 and 13 instant apply if they don't have a folder name yet? > > Items I create using 3 don't seem to show up until I click "Add", fwiw. Or is > that part of the change you're making? It's important that in those cases > "Cancel" means "don't actually create the thing" as opposed to "don't rename > the thing from the default name to what I just said". It should appear as New Folder, and if you click Cancel it should disappear. It's working like that for me.

Alex, what is left to do here from a UI perspective?

Unless Alex has something against this (in such a case feel free to reopen and elaborate on that), i'm going to mark this as WFM based on changes in bug 411261 and followers, further changes should have their own bug. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1pre) Gecko/20090619 Shiretoko/3.5pre

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