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)
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).
Comment 1•20 years ago
|
||
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.
Updated•20 years ago
|
OS: Windows 2000 → All
Assignee: vladimir → vladimir+bm
Assignee: vladimir+bm → nobody
Updated•19 years ago
|
Flags: blocking-firefox2?
Comment 2•18 years ago
|
||
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
Comment 3•18 years ago
|
||
This will use a different back end for Firefox 2.0.
Component: Places → Search
Updated•18 years ago
|
Component: Search → Bookmarks
No longer depends on: 317107
QA Contact: places → bookmarks
Hardware: PC → All
Version: 1.0 Branch → 2.0 Branch
Comment 4•16 years ago
|
||
(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.
Comment 5•15 years ago
|
||
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.)
Comment 6•6 years ago
|
||
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.
Description
•