Open Bug 648398 Opened 9 years ago Updated 2 months ago

Visually unify search and bookmark keywords

Categories

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

x86_64
Linux
defect

Tracking

()

People

(Reporter: sfink, Unassigned)

References

(Depends on 2 open bugs, Blocks 2 open bugs)

Details

(Whiteboard: [fxsearch][UX])

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.
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.
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.
Severity: normal → minor
Duplicate of this bug: 435954
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').
Flags: needinfo?(philipp)
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.
Flags: needinfo?(philipp)
Depends on: 1106626, 1106559, 261124
(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.
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.
Depends on: 444284
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.
(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.
(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 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>.
(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.
(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.
(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.
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
(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.
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?
(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.
(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.
Duplicate of this bug: 1135495
Whiteboard: [fxsearch]
Duplicate of this bug: 782562
we need to decide how we want this to work - and then can implement.  so adding UX to the title.
Severity: minor → normal
Rank: 40
Priority: -- → P4
Whiteboard: [fxsearch] → [fxsearch][UX]
Blocks: 236587
No longer depends on: 261124
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.
Summary: Search keywords (smart keywords?) should not be bookmarks → Visually unify search and bookmark keywords
(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).
(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).
I also suppose that restoring default search engines will lose all the custom added keywords?
(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.
(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.
(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.
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.
(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.
(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?
(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.
(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.
Blocks: 1226918
(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.
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?
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.
Priority: P4 → P3
See Also: → 1233810
Whatever will happen to keyworded bookmarks that aren't searches?
Blocks: 1314013
Duplicate of this bug: 1333013
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).
Depends on: 377736
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.
(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.
Duplicate of this bug: 1415101
Duplicate of this bug: 1483931
Quick Q, if I understand correctly the plan is to deprecated keywords right?
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.
You need to log in before you can comment on or make changes to this bug.