current state: Add current page: not easy to file bookmarks to a specific location, no feedback that bookmark got added. Not easy to change the name of the bookmark. As we will not have drag-in and mini-management functionality for the first release on the toolbar we need a way to make filing bookmarks easier. Right now users have to launch manage bookmarks to do any sorting or renaming. This is one of the most often heard request in recent rounds of Netscape-internal user testing.(This gets worth if we are adding to much junk in terms of imported and pre-filled bookmarks for NS6!) recommendation: Add a dialog (see IE) that has one popup menu with the folder to which the bookmark is saved (opening the menu will open the bm folder tree like file in mail) and one edit field with the proposed name for that bookmark selected. That way users can click OK if pre-filled props are OK. Also helps with getting a confirmation that it has been filed.

Great. Now adding a bookmark, something you'll probably want to do often, has become a two-step process. We _could_ have drag-in toolbar functionality if the Bookmarks button were back on the personal toolbar. I'm not saying in any way that I support its old positioning there, but just a comment...

At this point I have no option but to refer you to the Aphrodite menu spec ... Bookmarks menu -------------- A_dd Bookmark Ctrl+D Add Bookmark _As ... Ctrl+Shift+D ------------------------------------ Open _Bookmarks List Ctrl+B ------------------------------------ {bookmarks} This allows you to quickly add a bookmark immediately (which, as Blake said, is a PITA if you use IE), and also to quickly add a bookmark with modified title/keyword/update options/whatever (which, as German said, is a PITA if you use Mozilla). In addition, these two menu items work in a very similar way to the `Save' and `Save As ...' items in the `File' menu of most apps. For the dialog, modify the the Bookmark Properties dialog to take a parameter of whether it's modifying an existing bookmark or creating a new one. If it's creating a new one (in this case), insert an extra tree widget for selecting the folder which the bookmark should go into. (This means, incidentally, that the `Ok' and `Cancel' buttons should be in the top right corner of the dialog, rather than the bottom, so that they have consistent position in both cases.)

nav triage team: would love to see this improved, but this is a new feature and it is too late for that now. keyword helpwanted. Also, we need more clarity on what the fix should be. QA claudius to note a dupe.

Matt's suggestion from Aphrodite is a good compromise between speed and usability.

this is a dupe of bug 41888 *** This bug has been marked as a duplicate of 41888 ***

VERIFIED Dupe

Reopening. Bug 41888 is currently destined to add a `File Bookmark' submenu system to the Bookmarks menu. That would not solve all, or even most, of the problems German described: * it would allow folder-specific control over where the bookmark went, but many users may want more specific control than that (I'd be one of them); * it would not allow the user to edit the title of the bookmark at time of addition; * it would not allow the user to enter a keyword for the bookmark at time of addition; * it would not allow the user to edit, at time of addition, any other properties which may be added to bookmarks in the future (such as subscription state).

Keeping this bug open is good since we do want to improve bookmarks management in the future. This missed the train for the next release, but I'm hoping we will nsbeta3+ bug 41888 which gets us part way, or at least catches us up to 4.x. reassigning to german

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

dup of bug 19922?

No.

I have about 75% of an implementation of a fix done for this but I'd like feedback on the UI as I have it at the moment. http://www.objective2k.co.uk/addbookmark.jpg

I've got a proposed implementation of this at http://www.objective2k.co.uk/addbookmark.zip It allows the renaming of the bookmarked page or link and creation of new folders. Faults at the moment that I know of is that the Save|Cancel Buttons are centred within their box (really an Ok|Cancel box, so that their right hand edge doesn't line up with the Folder button. Creating a new folder depends upon selecting an existing item in a folder, which is the same as the sidebar context menu, The treeview shows bookmarks as well as folders, that's really only because there is no placeholder for either root or a position within the folder, that I'm aware of anyway. It does the basic job though. Adding a properties button to enable editing any of the regular bookmark properties is certainly possible but to reuse the current properties dialog (writing a new one for this would be a Bad Idea), means saving the bookmark and finding its ID before editing. Alternatively the bm-prop.xul should be generalised to work off a temporary file as well as an existing bookmark. Comments and testing welcomed.

Good work. Obvious problems: -<!ENTITY bookmarkPageCmd.label "Bookmark this Page"> +<!ENTITY bookmarkPageCmd.label "Bookmark this Page..."> See my 2000-08-07 comment, and German's 2000-08-10 comment. The `Add Current Page As ...' item needs to be *in addition to* `Add Current Page', not instead of. Otherwise people will get annoyed (see Blake's 2000-08-04 comment.) + The Original Code is Objective 2000 Ltd. + + The Initial Developer of the Original Code is Netscape + Communications Corporation. This can't be right. Surely it should be `The Original Code is Mozilla Communicator code ... The Initial Developer of the Original Code is Objective 2000 Ltd.' As for the UI ... I started making a list of suggestions, but decided to just do a mockup instead because it was quicker. +---------------------------------------------+ | Add Bookmark :::::::::::::::::::::::::::::::| +---------------------------------------------+ | / Location \/ Updates \____________________ | || `""""""""""""""""""""""""""""""|| || _Name of bookmark: || || [Bugzilla QuickSearch ] || || || || _Address: || || [http://ags.uni-sb.de/~afranke/mozilla/q] || || || || _Position: || || +-------------------------------------+-+ || || | ,' UI specs |A| || || |>[] Reference tools |:| || || |_,'_Bugzilla_________________________|:| || || | ,' Macintosh HIGs |:| || || | ,' Windows UI Guidelines |:| || || |>[] Linguistics links |V| || || +-------------------------------------+-+ || || ( New _Folder ... ) || |+-------------------------------------------+| | ( Cancel ) (( Add )) | +---------------------------------------------+ (What I said earlier about having `Add' and `Cancel' at the top right was wrong, since bookmark properties should be a window not a dialog and therefore won't have `Ok' and `Cancel' buttons at all.) Reassigning to Simon and moving to Bookmarks, since German has approved the idea and since he isn't going to do the coding.

Thanks for the comments >-<!ENTITY bookmarkPageCmd.label "Bookmark this Page"> >+<!ENTITY bookmarkPageCmd.label "Bookmark this Page..."> > >See my 2000-08-07 comment, and German's 2000-08-10 comment. The `Add Current >Page >As ...' item needs to be *in addition to* `Add Current Page', not instead of. >Otherwise people will get annoyed (see Blake's 2000-08-04 comment.) I've only changed the Context menu so far. Agreed some will want to add Bookmarks as quickly as possible but As... always sparks the question As What? A Rhinocerous? some other kind of Bookmark? I think the two options need to be worded so that people don't click on the wrong one by accident, thereby irritating them even further. As to what they should be..., Add Bookmark Now Add/Edit Bookmark... ? I'm not convinced by that either :-) >+ The Original Code is Objective 2000 Ltd. >+ >+ The Initial Developer of the Original Code is Netscape >+ Communications Corporation. >This can't be right. Surely it should be `The Original Code is Mozilla >Communicator code ... The Initial Developer of the Original Code is Objective ?2000 Ltd.' Well something like that, depends which file it is, I'll fix it up either way. >As for the UI ... I started making a list of suggestions, but decided to just do >a mockup instead because it was quicker. >+---------------------------------------------+ >| Add Bookmark :::::::::::::::::::::::::::::::| >+---------------------------------------------+ >| / Location \/ Updates \____________________ | >|| `""""""""""""""""""""""""""""""|| >|| _Name of bookmark: || >|| [Bugzilla QuickSearch ] || >|| || >|| _Address: || >|| [http://ags.uni-sb.de/~afranke/mozilla/q] || >|| || >|| _Position: || >|| +-------------------------------------+-+ || >|| | ,' UI specs |A| || >|| |>[] Reference tools |:| || >|| |_,'_Bugzilla_________________________|:| || >|| | ,' Macintosh HIGs |:| || >|| | ,' Windows UI Guidelines |:| || >|| |>[] Linguistics links |V| || >|| +-------------------------------------+-+ || >|| ( New _Folder ... ) || >|+-------------------------------------------+| >| ( Cancel ) (( Add )) | >+---------------------------------------------+ > >(What I said earlier about having `Add' and `Cancel' at the top right was wrong, >since bookmark properties should be a window not a dialog and therefore won't >have `Ok' and `Cancel' buttons at all.) I'm against having too much in this dialog otherwise it is only likely to put people off from using it. The most likely thing people will want to do is find the folder to add it in and maybe give it a reasonable name. Adding new folders then becomes desirable. The Folders button is at the same level as the tree as that is the element its editing, placing it below disconnects the sense. Cancel, I think, should always be the rightmost button in a group, I thought of labelling the confirm button 'Add' but as the dialog is called 'Add' and there is an editable field 'Save' seemed more accurate though its true it also implies the dialog is going to stay around, I can live with Add if there's a better argument for it. As for the additional fields, editing the URL in this dialog would stretch it beyond reasonable width for the rest of the content, having a shortish URL box when its likely people want to trim a lot of **** off the end would make it awkward to manipulate. I think all the other fields should be edited in the properties dialog which is changed to allow either edit existing properties or those about to be. I'll make some changes and repost, along with a new image of the dialog for those unable to build it. Simon

Source: I didn't get it to work. I applied the patch, but the context menu item "Bookmark this Page..." doesn't trigger a dialog, but just adds it right away (old behaviour). No errors on the console. > Cancel, I think, should always be the rightmost button in a group This is platform-dependant. See the XPToolkit dialog stuff. You could use the askSendFormatDialog in Mailnews Compose as example. > having a shortish URL box when its likely people want to trim a lot of crap off > the end would make it awkward to manipulate. Better than having to go to the Manager. Tree: Personally, I usually don't arrange bookmarks within one folder, but use (deep) folders instead. So, I would much prefer to hide all bookmark items and just show folders in the tree view. Maybe have a checkbox in the dialog "Show folders only"?

> I've only changed the Context menu so far. I don't think this feature belongs in the context menu at all. > As... always sparks the question As What? If you want to deviate from the industry-standard wording for `Save' and `Save As ...' (from which I'm borrowing users' knowledge, so they understand what the two items are for), please wait until Mozilla is more widely used than any other GUI app on the planet before doing so. Thanks. :-) > The Folders button is at the same level as the tree as that is the element its > editing, placing it below disconnects the sense. No, creating a new folder is what the user does *after* they realize that the current folder hierarchy has no good place for their bookmark. > Cancel, I think, should always be the rightmost button in a group Except on platforms other than Windows. And except on Windows when there isn't a `Cancel' button, just an `OK' button, whereupon `OK' is the rightmost. Which is why you never get quick at choosing one or the other, which is why Windows' button ordering wastes a few seconds of your time every day. However, that's controlled by a platform-specific XUL overlay, so it's a non-issue. > 'Save' seemed more accurate [...] I can live with Add if there's a > better argument for it. The action button should reflect what the user is doing in the dialog. They're not saving a bookmark, that's what `File' > `Save' is for. they're adding a bookmark. > having a shortish URL box when its likely people want to trim a lot of crap off > the end would make it awkward to manipulate. Not when bug 28583 is fixed, whereupon it would just be Tab, Right Arrow. > I think all the other fields should be edited in the properties dialog Except for the `Position' tree (and the `Add' and `Cancel' buttons), this dialog should be identical to the properties window. Firstly so users can reuse their knowledge of one in the other; and secondly because going to the trouble of using this dialog (rather than just `Add Current Page') in the first place, and *then* having to go into the properties window because the dialog didn't allow specification of all fields, would be *incredibly* annoying. PS: When commenting in Bugzilla, please keep quoted text to an absolute minimum.

Matthew, we obviously see different purposes for this dialog box, you'd better reassign the bug because your view doesn't make any sense to me at all, but then I've only ever added Bookmarks from the Context menu. I can see why you'd expect a full blown all fields dialog in an out of context menu option but it doesn't make very much sense as an in context item. As for implementing all of Properties just to add a bookmark that I think would just put the average user off...'You mean I have to enter all this junk to add a bookmark?' Ben: On the Cancel position, I used the standard OkCancel button as I made the assumption that that was fixed for XP, if it wasn't warranted then the point of XP confuses me :-). I'll check the patch for the context menu.

My fault I think I probably trimmed my original diff of the context change

`Add Bookmark' in the context menu would add the bookmark to the root folder (or the user-specified folder for new bookmarks) normally, just as it always has done. This advanced feature would only be in the Bookmarks menu. Sorry for the confusion. As regards putting users off -- they would come into this dialog *on purpose* (by selecting the item from the Bookmarks menu), and (unless they clicked on the `Updates' tab) they would see only three fields -- Name, Address, and Position. How could that put anyone off?

Matthew, other than your opinion is there a specification that says that? If there is I'll let someone else implement it. It seems truly absurd to me.

> Position: My Toolbar - V Position: + ----- + | .... | + ----- + use a twisty ;)

The position tree should be much larger than the one mpt drew, except maybe on Mac, where users are used to file dialogs that only show a few items at a time. One possible way to free up space in the dialog is to put the "name" and "url" textboxes on the same line as their labels. mpt wrote: >`Add Bookmark' in the context menu would add the bookmark to the root folder >(or the user-specified folder for new bookmarks) normally, just as it always >has done. This advanced feature would only be in the Bookmarks menu. Sorry for >the confusion. Bringing up the dialog should be the default method for adding a bookmark, to encourage users to keep their bookmarks organized from the beginning (which is considerably easier than organizing them later). What do you mean by calling filing a bookmark an "advanced feature"? Simon wrote: >As for implementing all of Properties just to add a bookmark that I think >would just put the average user off...'You mean I have to enter all this junk >to add a bookmark?' How about making a tab in the dialog (window?) with the extra options? I would like the ability to add a keyword as I'm adding a bookmark, but I don't do that very often.

> This advanced feature would only be in the Bookmarks menu. mpt, this is exactly the arrogant style you critize at some Netscape employees. 1. This is completely arguable. I happen to agree with Jesse. Reorganizing bookmarks later makes not much sense in most cases. If you encourage filing in the main bookmarks menu, you encourage menus with 200 entries. I thought, these were supposed to not exist? 2. Please be more polite with voluntar coders. They do this for fun, and it is not fun do be commanded around. The problem with reusing the properties dialog is, as I understood Simon, also a coding problem. the existing code is not written in a way that it could be easily reused for this feature, a major rework would be necessary. I agree that this would be desirable, but having basic feature at all is vastly more important IMO.

Jesse wrote: >How about making a tab in the dialog (window?) with the extra options? I would >like the ability to add a keyword as I'm adding a bookmark, but I don't do that >very often. The only thing I have against a tab is the same as rewriting the properties, it gives more than one UI to change the same fields which I think should be avoided if at all possible. Up to now I've thought a button under <New Folder..> for <Properties...> to get to a single unified properties dialog would be the best solution. I've found two other behaviour bugs which I need to raise on this because it affects usability. The first is http://bugzilla.mozilla.org/show_bug.cgi?id=65966 unable to create folders within a folder unless it already has an item in it. The second is http://bugzilla.mozilla.org/show_bug.cgi?id=65967 unable to exclude IE Favourites from the tree.

Feel free to implement this however you like, all I'm doing is making UI suggestions (since I can't contribute code). If I have problems with the UI of your implementation, that's no big deal, I'll file them as separate bugs which might get wontfixed. I'm sorry if anything I said seemed rude. If you have particular examples, please discuss them by e-mail. Jesse: My mockups are usually smaller (e.g. trees contain fewer rows) than their real-life counterparts, just because that takes less time to draw. :-) The dialog could be resizable, so you could make the tree whatever size you wanted.

Matthew: No offence ever taken, robust argument is encouraged, by me anyway.

I see an item "Always ask me to choose a title and folder when adding a new bookmark". I think, this is a bad idea. This is not a preference, it depends on the situation. Usually, I want to specify a folder, but sometimes, I have no time. Also, the pref has no effect. Who checked that in and why???

Agreed, its a pointless preference and only makes it more complicated.

Let's wait for bug 67884 to be addressed. I think the current default behaviour ("Always ask" enabled) is correct, an option to de-activate it is trivial but not completely useless. The proposed alternative, i.e. a second option for saving a bookmark in the Bookmarks menu (besides the "Add current page") would be a really bad idea.

The original request in this bug description is fixed via BenG's new bookmark manager. How about resolving this now?

I'm not sure that it is. At the moment the context menu seems to be broken and the Add a Page dialog doesn't include the title or the URL to edit.

My two euro-cents : "Add Current Page" now brings up a dialog called "Add Bookmark" in which you can specify the Name and the Location (url) of the Bookmark. There is also a button "Create In" that expands the dialog to allow you to chose in which folder to file the bookmark. You can also create a new folder. The "use default" button does not work yet, but there is a bug reported about that. So far so good, this solves all the problems here. Context menu on the page : "Bookmark this page" bookmarks the page silently. This is a bug imho and should be filed in a new bug. All the usability problems are fixed afaic.

Oh, I know what's wrong: The pref (in Navigator|Bookmarks) has the exact opposite effect of what you choose. Duh! I need to press a button to be able to choose a folder. That's a no-option, since this is the reason why I (and lots of others, I assume) need the dialog at all. One extra click each time is too much. Since this has been checked in without notice here, and noone took responsibility so far, I'll assume it's OK to just modify the current implementation as suggested (remove pref in favor of extra menu item, remove "dialog expander"). If there are any objections, raise them now.

Ben, sorry for repeating myself here but where is the need to have one more choice in the Bookmarks menu (add without dialog box) while in most cases we have to modify the title? I think this will clutter the menu with a rarely useful option. Current implementation is already a big step ahead of what old Navigator was. Why to complicate it? Imho, at the moment of creation, an average user modifies the title only, later he massively categorises the new bookmarks folders (if he ever does this).

This bug is starting to get messy, so I'm going to start trying to split up the remaining issues. Killing "dialog expander" or making it persistent -> bug 68629. Changing when the dialog is shown (removing the pref, adding a menu item, etc) is still this bug for now, but I think it would be good for a new bug to be created for that so this bug can be resolved as fixed. If anyone thinks the following things are important, please file new bugs so they don't get lost: - positions/names of the buttons that are currently OK/Cancel and at the bottom- right of the window on Windows (mpt 2001-01-18 03:45) - position of "New Folder..." button (mpt 2001-01-18 05:30) - making the dialog resizable (jesse and mpt)

> in most cases we have to modify the title? I rarely edit titles. I usually want to specify another *folder*. > I think this will clutter the menu with a rarely useful option. I completely disagree. 4.x had both options (file instantly, file in folder), too. I need a way to instantly, quickly bookmark a page. Sometimes, I have lots of windows open and suddenly have to close the browser for any reason (e.g. instability or shutting down the OS). No time to hit a menu item *plus* OK (for the dialog) for each windown (there migh be dozens). This was just one example. I'm sure other people have other reasons why they sometimes what to add a bookmark instantly. I assume that almost everybody sometimes wants to edit a bookmark (title/URL/folder) while adding it. So IMO, the pref is pointless, because I cannot see any significant amount of people having this "preference". > [...] an average user[...] I disagree with that assertion, but it currently doesn't matter.

FYI: The "anonymous" coder is Ben Goodger, r=blake, a=hyatt. Checkins at Jan 22, Jan 31 and Feb 4. Very bad habits to not even mention it here.

it's very hard to know about all of nearly 70000 bugs. imo this bug is fixed, and any remaining issues should be spun off. w32 2/9-4

> it's very hard to know about all of nearly 70000 bugs. There are only 201 open Bookmarks bugs. The module owner should know them. > imo this bug is fixed but left a major regression IMO. > and any remaining issues should be spun off. Bug 68654 for no dialog.

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

mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31. if you think this particular bug is not fixed, please make sure of the following before reopening: a. retest with a *recent* trunk build. b. query bugzilla to see if there's an existing, open bug (new, reopened, assigned) that covers your issue. c. if this does need to be reopened, make sure there are specific steps to reproduce (unless already provided and up-to-date). thanks! [set your search string in mail to "AmbassadorKoshNaranek" to filter out these messages.]