648398 - Visually unify search and bookmark keywords

Status: RESOLVED DUPLICATE of bug 1650874

(Firefox :: Bookmarks & History, defect, P3)

Description

[Steve Fink [:sfink] [:s:]]

I have recently stumbled across the search keyword feature, and I love it. But the management UI just feels weird. I don't understand why they're associated with bookmarks at all. I can see that they're sort of bookmark-like, but I really think of them as associated with the location bar, not any of the bookmark UI elements.

If I wanted to delete one of them, would I delete the bookmark? I'm not sure whether to expect that to work or not.

I use the bookmarks toolbar for *all* of my bookmarks, and had forgotten that anything else existed. I suppose if I ever went to the Bookmarks menu then I might feel differently?

I'm not sure where I would expect search keywords to be manipulated within the UI, but my first guess would be preferences.

Comment 1

[Marco Bonardo [:mak]]

Yes, keywords are a sort of annotation on a bookmark, since they have both the use of being quick-search-shortcuts or aliases for a uri.
To remove to keyword you remove the bookmark it's associated to or remove the keyword property from the bookmark (notice the same keyword can be associated to multiple bookmarks since locationbar allows to select the keyword to use after typing it)
The UI is probably confusing, most likely the initial decision to do so was to simplify internal management, ideally they should not be managed this way, and should be invisible to bookmarks lists, but that's a low priority right now.

Comment 2

[Wayne Mery (:wsmwk)]

Granted, it's not useable as a bookmark. But hard to imagine it not being managed like a bookmark, i.e. not managed in Places.

Comment 4

[Jesse Ruderman]

Search engines now have their own keywords UI. (The UX spec was in bug 1106055, and the implementation was in bug 1106559).

It seems silly to have both "bookmark %s keywords" and "search engine keywords" that do pretty much the same thing. We should probably drop the concept of bookmark keywords. This would mean changing the textbox context menu item (bug 261124), and converting existing bookmark keywords to search engines. Philipp, do you think we should do this?

Unfortunately, I couldn't find UI for creating a search engine from a URL pattern. I needed to do that in order to get some of my bookmark keywords correct, because they didn't correspond to search boxes on web sites. (Twitter search [all], Twitter username, subreddit name, unicode codepoint, DXR search with 'path:webidl').

Comment 5

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

First of all: Yes. The current situations where search keywords can exist as both search engines and bookmarks is very confusing and we should align them as soon as possible.

There are a couple of layers to this:
- Right Click + Add as search engine should create a new search engine and place it in the button tray of the search field
- Existing bookmark keywords should be converted to search engines (perhaps unchecked by default so that people who had many bookmark keywords don't end up with an insanely cluttered list)
- We should do our best to make the option to add a search engine more discoverable. We already have the green plus icon over the magnifying glass when a site offers open search. We could do the same if a site has a search field. We'd need to figure out a good heuristic for what to promote here though, because the »Add search keyword« context menu entry currently appears on ALL textboxes.
- A UI to manually set the pattern is another matter. I think that belongs more into add-on land.

Comment 6

[Lily Kim]

(In reply to Philipp Sackl [:phlsa] please use needinfo to make me respond from comment #5)
"- A UI to manually set the pattern is another matter. I think that belongs more into add-on land."

Just making sure I understand correctly.
So to manually make a search term like "TEST %s" you'd need an addon with this change?
That to me seems fairly backwards, and would without doubt anger the power-users who already use that feature.

Comment 7

[Matthew N. [:MattN]]

I don't think we should remove the bookmark search keywords until we sync the custom engines along with their keywords otherwise it's a step backwards for power users. I have around 40 search keyword bookmarks and I wouldn't want to manually set them up on a new computer.

Comment 8

[nortexoid]

It seems to me that bookmark keywords are more flexible than search engine keywords, and should remain even if they duplicate some of the functionality that search engine keywords do. For one, it's more convenient to right-click in a search field and add the search engine as a bookmark, than to go do an add-on site and add the search engine as an add-on. Second, bookmarks (and their keywords I presume) are synced just like bookmarks are, and search engine keywords are not presently synced (though I see there are plans to do this). Third, the latest version of FF (35.0) removed the ability to associate keywords with search engines, so this functionality is totally missing (without going into hidden settings) from the UI.

Comment 9

[Florian Quèze [:florian]]

(In reply to nortexoid from comment #8)

> Third, the latest version of FF (35.0) removed the ability to
> associate keywords with search engines, so this functionality is totally
> missing (without going into hidden settings) from the UI.

This was missing in 34 and readded in 35 in bug 1106559.

Comment 10

[nortexoid]

(In reply to Florian Quèze [:florian] [:flo] from comment #9)
> (In reply to nortexoid from comment #8)
> 
> > Third, the latest version of FF (35.0) removed the ability to
> > associate keywords with search engines, so this functionality is totally
> > missing (without going into hidden settings) from the UI.
> 
> This was missing in 34 and readded in 35 in bug 1106559.

Don't see the option to change keywords from the search settings or the extensions settings. I'm using FF for linux (from the Ubuntu distro).

Comment 11

[Florian Quèze [:florian]]

(In reply to nortexoid from comment #10)
> (In reply to Florian Quèze [:florian] [:flo] from comment #9)
> > (In reply to nortexoid from comment #8)
> > 
> > > Third, the latest version of FF (35.0) removed the ability to
> > > associate keywords with search engines, so this functionality is totally
> > > missing (without going into hidden settings) from the UI.
> > 
> > This was missing in 34 and readded in 35 in bug 1106559.
> 
> Don't see the option to change keywords from the search settings or the
> extensions settings. I'm using FF for linux (from the Ubuntu distro).

In the search preferences, double click in the "keyword" column. If you prefer to use the keyboard, select the row of an engine, and press <enter>.

Comment 12

[nortexoid]

(In reply to Florian Quèze [:florian] [:flo] from comment #11)
> (In reply to nortexoid from comment #10)
> > (In reply to Florian Quèze [:florian] [:flo] from comment #9)
> > > (In reply to nortexoid from comment #8)
> > > 
> > > > Third, the latest version of FF (35.0) removed the ability to
> > > > associate keywords with search engines, so this functionality is totally
> > > > missing (without going into hidden settings) from the UI.
> > > 
> > > This was missing in 34 and readded in 35 in bug 1106559.
> > 
> > Don't see the option to change keywords from the search settings or the
> > extensions settings. I'm using FF for linux (from the Ubuntu distro).
> 
> In the search preferences, double click in the "keyword" column. If you
> prefer to use the keyboard, select the row of an engine, and press <enter>.

Highly NON-discoverable, but thanks.

Comment 13

[Florian Quèze [:florian]]

(In reply to nortexoid from comment #12)
> (In reply to Florian Quèze [:florian] [:flo] from comment #11)

> > In the search preferences, double click in the "keyword" column. If you
> > prefer to use the keyboard, select the row of an engine, and press <enter>.
> 
> Highly NON-discoverable, but thanks.

If you think we should improve discoverability, please file a new bug for it and cc me.

Comment 14

[Marco Bonardo [:mak]]

(In reply to nortexoid from comment #8)
> For one, it's more convenient to right-click
> in a search field and add the search engine as a bookmark, than to go do an
> add-on site and add the search engine as an add-on.

I think the UI could stay the same.

> Second, bookmarks (and
> their keywords I presume) are synced just like bookmarks are, and search
> engine keywords are not presently synced (though I see there are plans to do
> this).

Should be done apart, I agree.

fwiw, I was commenting just to notify that in Places we are starting moving keywords out of bookmarks to their own API and table, this is a first step in the right direction. I agree longer term they should converge to the search service.
From a UI point of view there won't be changes, but should be easier in future to decouple the thing and offhand management to a different component.

Comment 15

[Matthew N. [:MattN]]

There are a few ways that bookmark keywords don't really fit as search engine keywords:
A) They don't require a search term e.g. I can have fb always load https://www.facebook.com/ without specifying a search term. It really is just defining a keyword for the page in this case.
B) Even with a substituted argument they aren't always for "search". Three examples I use:
  * Translation: nl2en => https://translate.google.com/#nl/en/%s (and the opposite for en2nl)
  * Utility websites: ip => http://ip-lookup.net/?ip=%s (lookup an ip address)
  * Load an MDN template: mdntemp => https://developer.mozilla.org/en-US/docs/Template:%s
  * Load a URL in Google's document viewer (more useful before pdj.js): gdoc => https://docs.google.com/gview?url=%s

Comment 16

[Marco Bonardo [:mak]]

(In reply to Matthew N. [:MattN] from comment #15)
> A) They don't require a search term e.g. I can have fb always load
> https://www.facebook.com/ without specifying a search term. It really is
> just defining a keyword for the page in this case.

While this is true, this use-case was created when we didn't have adaptive autocomplete and complete-to-domain. The likely to need that functionality is very low today.

> B) Even with a substituted argument they aren't always for "search". Three
> examples I use:
>   * Translation: nl2en => https://translate.google.com/#nl/en/%s (and the
> opposite for en2nl)
>   * Utility websites: ip => http://ip-lookup.net/?ip=%s (lookup an ip
> address)
>   * Load an MDN template: mdntemp =>
> https://developer.mozilla.org/en-US/docs/Template:%s
>   * Load a URL in Google's document viewer (more useful before pdj.js): gdoc
> => https://docs.google.com/gview?url=%s

They are functionally equivalent. Honestly, we could create a keywords component and make it manage both bookmarks and search keywords. It doesn't have to be part of one of the 2 components.

Comment 17

[Akkana Peck]

I have (had) a ton of bookmarks with keywords, often without a search term, for example, typing "blog" loads my blog, typing "mozbug 123456" goes to https://bugzilla.mozilla.org/show_bug.cgi?id=123456 and so forth. As of firefox 35 none of them work any more, and typing "blog" goes to some random URL I may have visited several months ago that the awesomebar happens to like for some reason, not the one I have bookmarked. The Search preference panel doesn't seem to offer a way of adding back all my keywords, or even adding the search that used to be my default search (keyword.URL), which was google but with some custom settings. All the support.mozilla.org or mozillazine pages I've found are pre-35 and claim that the features still work; I haven't found any documentation pages that have been updated to explain how to get the old functionality back in firefox 35.

Is there documentation somewhere (maybe google just isn't finding it yet) explaining how to get the old functionality back in the firefox 35 world?

Comment 18

[Marco Bonardo [:mak]]

(In reply to Akkana Peck from comment #17)
> Is there documentation somewhere (maybe google just isn't finding it yet)
> explaining how to get the old functionality back in the firefox 35 world?

nothing should have changed regarding bookmark keywords, looks like you might have some wrongly set preference or an add-on conflicting. Try contacting support.

Comment 19

[Matthew N. [:MattN]]

(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #16)
> They are functionally equivalent. Honestly, we could create a keywords
> component and make it manage both bookmarks and search keywords. It doesn't
> have to be part of one of the 2 components.

My reply was about the UX that was proposed in comment 5 which would convert bookmark keywords to search engines even though users don't think of them as search engines.

Comment 22

[:shell escalante]

we need to decide how we want this to work - and then can implement.  so adding UX to the title.

Comment 23

[Marco Bonardo [:mak]]

Clarifying the scope here, I don't think it's realistic to think we can make things what they aren't (so transform bookmark keywords into search engines) with few resources.
But visually we can have a single UI in Preferences to manage both kind of keywords and the user doesn't need to know the implementation details, at a maximum they should be able to distinguish the ones related to a search engine to the ones related to specific urls.
The current Preferences UI could be adapted with a few label changes and a New URL Keyword button.

Comment 24

[Florian Quèze [:florian]]

(In reply to Marco Bonardo [::mak] from comment #23)
> Clarifying the scope here, I don't think it's realistic to think we can make
> things what they aren't (so transform bookmark keywords into search engines)
> with few resources.

What's the problem with that?

Showing bookmarks as one-off buttons in the search UI seems more difficult to me than generating search engines from the bookmarks (especially since the engines are now just data stored in a JSON file).

Before thinking about converting existing bookmarks, we could start by making the "Add a Keyword for this Search…" context menu item generate a search engine.

> The current Preferences UI could be adapted with a few label changes and a
> New URL Keyword button.

The Preferences UI already supports setting aliases on engines (which is the same thing as keywords for bookmarks).

Comment 25

[Marco Bonardo [:mak]]

(In reply to Florian Quèze [:florian] [:flo] from comment #24)
> (In reply to Marco Bonardo [::mak] from comment #23)
> > Clarifying the scope here, I don't think it's realistic to think we can make
> > things what they aren't (so transform bookmark keywords into search engines)
> > with few resources.
> 
> What's the problem with that?

Search engines require various data that bookmark keywords don't have, like search forms.
Plus we could not convert any keyword that is just an alias to an url (not doing a search).

Comment 26

[Marco Bonardo [:mak]]

I also suppose that restoring default search engines will lose all the custom added keywords?

Comment 27

[Florian Quèze [:florian]]

(In reply to Marco Bonardo [::mak] from comment #25)
> (In reply to Florian Quèze [:florian] [:flo] from comment #24)
> > (In reply to Marco Bonardo [::mak] from comment #23)
> > > Clarifying the scope here, I don't think it's realistic to think we can make
> > > things what they aren't (so transform bookmark keywords into search engines)
> > > with few resources.
> > 
> > What's the problem with that?
> 
> Search engines require various data that bookmark keywords don't have, like
> search forms.

I think search forms is optional. If not, we can make it so.

> Plus we could not convert any keyword that is just an alias to an url (not
> doing a search).

Is this use case common? I don't see a reason to expose that case in the search preferences.

(In reply to Marco Bonardo [::mak] from comment #26)
> I also suppose that restoring default search engines will lose all the
> custom added keywords?

Restoring default search engines just un-hides the default engines that were removed by the user; it doesn't remove any user-installed engine.

Comment 28

[Stephan Sokolow]

(In reply to Florian Quèze [:florian] [:flo] from comment #27)
> Is this use case common? I don't see a reason to expose that case in the
> search preferences.

I don't know about common, but I use it for things like defining "mb" as shorthand for the current year's Mythbusters episode list on Wikipedia.

Comment 29

[Marco Bonardo [:mak]]

(In reply to Florian Quèze [:florian] [:flo] from comment #27)
> > Plus we could not convert any keyword that is just an alias to an url (not
> > doing a search).
> 
> Is this use case common? I don't see a reason to expose that case in the
> search preferences.

The usage is very low (95% of telemetry users have no keywords), the population is most likely technical users and developers, and thus it may be used to improve productivity in some of these cases.
I think it would be easy to create a simple add-on that allows to create and manage non-searching aliases, if we convert all the other searching keywords to search engines. This may be a valid migration plan.

Comment 30

[Florens Verschelde :fvsch]

Another option would be to change the "Add a keyword for this search" feature, so that it creates a search engine rather than a bookmark-with-keyword.

Then when advanced users create custom search engines, they would be added in the search engines, used with a keyword (if the user enters one), used from the search input dropdowns, and synced to Firefox on Android or iOS.

As a result:

- For users new to custom search engines/keywords, the fragmentation between the two features effectively ends.
- For users who already have bookmarks-with-keywords, this offers a manual migration path: manually recreate their search bookmarks as search engines (if they want the added bonus of better UI integration, setting as default search engine, syncing to mobile).
- Advanced users can still create bookmarks-with-keywords if they want to (no forced migration).

Of course a community add-on could help users migrate their search bookmarks if they want to.

Comment 31

[Marco Bonardo [:mak]]

(In reply to Florent Verschelde from comment #30)
> Another option would be to change the "Add a keyword for this search"
> feature, so that it creates a search engine rather than a
> bookmark-with-keyword.

That's the plan expressed above indeed.
The problem was figuring out what to do with keywords not executing searches.

Comment 32

[Matthew N. [:MattN]]

(In reply to Marco Bonardo [::mak] from comment #31)
> (In reply to Florent Verschelde from comment #30)
> > Another option would be to change the "Add a keyword for this search"
> > feature, so that it creates a search engine rather than a
> > bookmark-with-keyword.
> 
> That's the plan expressed above indeed.
> The problem was figuring out what to do with keywords not executing searches.

I don't see the problem. They can be like the bookmark ones are now and just not have a substitution/replacement token ({searchTerms}), can't they? Or do we enforce that somewhere?

Comment 33

[Marco Bonardo [:mak]]

(In reply to Matthew N. [:MattN] from comment #32)
> > That's the plan expressed above indeed.
> > The problem was figuring out what to do with keywords not executing searches.
> 
> I don't see the problem. They can be like the bookmark ones are now and just
> not have a substitution/replacement token ({searchTerms}), can't they? Or do
> we enforce that somewhere?

I fear that special casing some engines would add complication to the search service and would be error-prone. How would such an engine work in the search bar or in one-off buttons? What if someone sets it as a default, even by mistake? It will look like search is broken.

There's another "problem" too, we discussed of "Add keyword for this search" as the only way to add a keyword in future, this excludes 2 use-cases we should evaluate:
- manually add a search url (the current ui doesn't allow that, should we add a button for it?), may be useful to technical users
- edit a search url, to remove some params or slightly modify a prefilled search, again it's something for technical users

For these I only see 2 solutions so far:
- unify the manager in prefs, better distinguishing search-origin keywords from url-origin keywords (url is editable and new ones can be added), still manage them separately (engines in search, urls in Places)
- Keep url-origin keywords as an hidden feature in Places, allow to manage them through an add-on

The fact add keywords for this search adds an engine is orthogonal to the above issue and I think it would be nice to do regardless.

Comment 34

[Florian Quèze [:florian]]

(In reply to Marco Bonardo [::mak] from comment #33)
> (In reply to Matthew N. [:MattN] from comment #32)
> > > That's the plan expressed above indeed.
> > > The problem was figuring out what to do with keywords not executing searches.
> > 
> > I don't see the problem. They can be like the bookmark ones are now and just
> > not have a substitution/replacement token ({searchTerms}), can't they? Or do
> > we enforce that somewhere?
> 
> I fear that special casing some engines would add complication to the search
> service and would be error-prone. How would such an engine work in the
> search bar or in one-off buttons? What if someone sets it as a default, even
> by mistake? It will look like search is broken.

I agree, it will seem broken if it can happen by accident. I don't think we should allow creating search engines that don't take search terms.

> There's another "problem" too, we discussed of "Add keyword for this search"
> as the only way to add a keyword in future, this excludes 2 use-cases we
> should evaluate:
> - manually add a search url (the current ui doesn't allow that, should we
> add a button for it?), may be useful to technical users
> - edit a search url, to remove some params or slightly modify a prefilled
> search, again it's something for technical users

We've had requests (eg bug 1195005) to make the URL editable for search engines, including the engines we ship. Chrome supports this. I'm not sure if we want to do it, but it's a possibility on the table.

Comment 35

[Scott R]

(In reply to Matthew N. [:MattN] from comment #19)
> (In reply to Marco Bonardo [::mak] (needinfo? me) from comment #16)
> > They are functionally equivalent. Honestly, we could create a keywords
> > component and make it manage both bookmarks and search keywords. It doesn't
> > have to be part of one of the 2 components.
> 
> My reply was about the UX that was proposed in comment 5 which would convert
> bookmark keywords to search engines even though users don't think of them as
> search engines.

This is not logical to classify something like a keyword example "fb" as a "search engine" that is more confusing that what we have now. The keywords in bookmarks should be left alone even if telemetry shows low usage outside tech users it maintains upward compatibility. A search engine  needs to be for URL pages where you do searching by keywords cluttering them up with the bookmark aliases (keywords) is not useful.

Comment 36

[Scott R]

This was raised as an issue that "keywords" in bookmarks and the "keywords" in search engine are confusing. I suggest there are very few "confused" users out there as mentioned by low telemetry. If you are using "keywords" in bookmarks to create basic search engines then yes there can be confusion but surely you must be aware of that if you were smart enough to figure out that "%s" can be used in URL string and are aware of that "about:preferences#search" is the preferred way of doing it. If not why would that be - and is this not just an education issue?

The "keywords" in bookmarks are aliases for URLs in your bookmarks (think of cases where "%s" is not in bookmark URL). Although you can use it for simple search URLs that is a subset of aliasing. As an aliasing feature I like it and it should stay as is. I was very disappointed that bug 1145063 dropped the keyword column making yet another "surprise" when the browser updated.  

Aliases do not belong mixed in to search engines just because you could manage them in a future "about:preferences#search" interface does not make this a sound way of doing it. The confused user population is small, so what is it intent here to remove confusion by removal of bookmark aliasing (keyword field completely) or removal of just the "%s" feature in bookmarks or something else?

Why is it necessary to change "keywords" in bookmarks if confusion is negligible issue?

Comment 37

[Marco Bonardo [:mak]]

again, the current UI is broken, keywords have no relation to bookmarks but the UI shows a relation and maintaining it is hard and complicate. Indeed it's currently malfunctioning exactly due to that complication.
We need a way out of that, and separating keywords used as searches and keywords used as aliases makes a lot of sense.
I don't think the functionality will change, but the UI to set and manage keywords should change.

Comment 38

[avada]

Whatever will happen to keyworded bookmarks that aren't searches?

Comment 40

[vleet]

A question about these major changes with search-mookmark-keywords: is it or will it be possible to use two or more keywords for the same search url? Because current changes in Firefox took this option away from users (a regression).
It especially affects users with 2 or more keyboard layouts, see more details in Bug 1362325 (in fact it's not fixed).

Comment 41

[Eric Shepherd [:sheppy]]

It's been ages since the search keyword column was removed from the Library window, yet this bug has not yet been handled to restore the ability to see them in a new UX. Is there any plan to make headway on this? It's a little hard to manage search keywords properly right now when I can't see the keywords.

Comment 42

[avada]

(In reply to Eric Shepherd [:sheppy] from comment #41)
> It's been ages since the search keyword column was removed from the Library
> window, yet this bug has not yet been handled to restore the ability to see
> them in a new UX. Is there any plan to make headway on this? It's a little
> hard to manage search keywords properly right now when I can't see the
> keywords.

There's an addon for that from "Alice0775 White" ( https://addons.mozilla.org/hu/firefox/user/white-alice0775/ ) made quite a while ago that still works on FF56, but he decided to to remove all of his addons. Maybe you can dig it up somewhere.
But it won't work on FF57+, so it's only an interim solution, if you plan to jump on the ff57 train.

Comment 44

[Martijn]

I should remind everyone that Opera has had this problem nailed at least 10 or 15 years ago (until they decided to ditch their browser and copypaste Chrome, that is). They had implemented exactly this: add a search by entering title, keywords, and url with %s as the search terms placeholder. Couldn't be simpler.

I personally don't see why this needs to involve such a long discussion.

Comment 46

[Danny Colin [:sdk]]

Quick Q, if I understand correctly the plan is to deprecated keywords right?

Comment 47

[Marco Bonardo [:mak]]

nope, there's no plan to deprecate keywords as a way to search, the plan is to unify 2 features that in practice are doing the same thing.

Comment 48

[remirampin]

It seems that bookmark keywords were remove from Firefox Android. Thanks for the heads up people, I really feel respected as a user.

Comment 49

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 6 duplicates.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 50

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.