Closed Bug 261175 Opened 20 years ago Closed 6 years ago

Keyword search should not require a name to be created

Categories

(Firefox :: Bookmarks & History, defect)

2.0 Branch
defect
Not set
normal

Tracking

()

RESOLVED INACTIVE

People

(Reporter: ian, Unassigned)

Details

(Keywords: helpwanted)

STEPS TO REPRODUCE
1. Go to http://imdb.com/
2. Right click the field at the top left.
3. Choose "Add a Keyword for this Search".
4. Type a keyword.
5. Click Add.
6. Use your keyword search.

EXPECTED RESULTS
The above steps should work.

ACTUAL RESULTS
The above breaks at step 4. You are actually requested for _three_ pieces of
information, even though as a user you only care about the keyword. (You are
asked for the bookmark name and bookmark location, implementation details that
merely show that the magic of keywords is implemented by bookmarks.)

PROPOSAL
The title should be prefilled to "%s Quicksearch (%s)" where the first %s is the
domain name or <title> of the page if it was very short, or the start of the
title up to the first "-", or some such, and the second %s is the keyword the
user entered.
The "Create In" field should default to the folder with the most quick searches
already created (since that is most likely the user's quicksearch folder).
In my opinion, the fact that quicksearch is implementated using bookmarks should
be hidden from the user completley. The quicksearch "bookmarks" are not useful,
and confusing, if you try to use them the way you use bookmarks (select them
from the Bookmarks menu). And if you want to edit your quicksearches, looking
for them in the bookmarks menu, right-clicking, and selecting "properties" is
not the most intuitive interface. 

So, in addition to what Hixie suggests, I would suggest not to display
quicksearches in the "Bookmarks" menu at all, and instead have a "Quicksearch
manager", which will be accessable from the "Tools" menu.
OS: Windows 2000 → All
Assignee: vladimir → vladimir+bm
Assignee: vladimir+bm → nobody
Flags: blocking-firefox2?
Not a blocker, but it'd be nice to add to the growing Places coolness.
Component: Bookmarks → Places
Flags: blocking-firefox2? → blocking-firefox2-
Keywords: helpwanted
QA Contact: mconnor → places
This will use a different back end for Firefox 2.0. 
Component: Places → Search
Component: Search → Bookmarks
No longer depends on: 317107
QA Contact: places → bookmarks
Hardware: PC → All
Version: 1.0 Branch → 2.0 Branch
(In reply to comment #1)

Whatever you call them keyword shortcuts, quickbookmarks, keyword searches, smart bookmarks, they are all the same and whether you use them to address a specific url (without an operand), extend/modify nodes on a url, include a filename, use as a bookmarklet, or add operands such as for use in a search it is all the same and is a *user* interface -- certainly not something to be hidden from a user, and they are meant to be used from the location bar (address bar).  Forcing a user to go through the Tool bar would not be intuitive, would make the Tools menu useless by the great number of additions of those used even only for search.

Would vote NO on this bug's proposal.

The reason more people don't use keyword shortcuts is because all of the bookmark properties are not being exposed when creating a bookmark.  Solve that problem and bookmarks would be used a lot more powerfully by a lot more users.   

Meant to be a user interface, please keep it as a user interface in using bookmarks. 

By using two spaces after the keyword (alias), you effectively have nullified the optional argument.  Hiding the fact that is there would make it harder for users to work with and modify.  I frequently type in just the keyword to see see what is generated or to modify other parts of it within the location bar, so essentially I would already have used it before I create a derivative keyword bookmark.  
This bug's current summary (Keyword search should not require a name to be created) isn't very clear, and doesn't reflect the proposals made in comment #0 well. 

As per its summary, this bug should be resolved duplicate of  Bug 404279 -  (Suggest automatic filling of 'name' field after selecting "add a keyword for this search" from context menu), which covers the first and main proposal of this bug (in the case of "add a keyword for this search", pre-populate the name field of the add-bookmark-dialogue with a useful name).

The second proposal of this bug is that the Create-in: [bookmark-folder]-Field should default to the bookmark folder which contains the most "quick searches" (i. e. bookmarks with keywords set). I assume that when the bug was posted, the Create-in: [bookmark-folder] field didn't default to anything, it does now (I think it defaults to the [bookmark menu]-folder, but not sure). So the first half of the second proposal is also addressed. Hixie, if you feel that the create-in: field should default to something else, please check if there is a bug for that and you could post a new bug if there isn't.

Imho Uri's proposal of comment #1 doesn't have much of a chance ("not to display
quicksearches in the "Bookmarks" menu at all, and instead have a "Quicksearch
manager", which will be accessable from the "Tools" menu). Especially the first part is quite impossible, because the user can always add a keyword to any bookmark anywhere in his bookmark folders, and as David rightly points out in comment #4, the keyword UI as a way of shortcut-accessing bookmarks deserves to be *more* visible and accessible rather than hiding it even more.
However, I agree with comment #1 in that currently there is no efficient way to manage the bookmarks subset of bookmarks with keywords. But that's a different matter which deserves its own bug, if there isn't one already. (How about having a virtual folder labelled "Quick searches" that filters for all bookmarks with keywords, like we now have virtual folders for "most recently bookmarked pages", "most frequently visited pages" etc.)
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.