Closed Bug 993792 Opened 11 years ago Closed 10 years ago

[UX] new ctrl-k behavior with search bar hidden (open about:home) is sub-optimal

Categories

(Firefox :: Search, enhancement)

31 Branch
x86_64
Windows 7
enhancement
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
firefox31 --- affected

People

(Reporter: marcausl, Assigned: zfang)

References

Details

(Whiteboard: [ux] p=3 s=it-32c-31a-30b.3 [qa-])

bug 940685 changed the behavior of ctrl-k to open about:home if the search bar has been removed from the location toolbar.

the search provided in about:home is completely inferior to the google.com search page.

google.com provides live updates of tentative search results while typing, and provides type ahead guesses.

in addition, about:home is cluttered with content irrelevant to a search request.

thus, if this must be the default, provide a mechanism for specifying a url to be opened when about:home is entered, or a mechanism for specifying the url of ctrl-k with the default being about:home.
Summary: ability to customize about:home needed → ability to customize about:home or ctrl-k needed
Blocks: 940685
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: ability to customize about:home or ctrl-k needed → new ctrl-k behavior with search bar hidden (open about:home) is sub-optimal
Flags: firefox-backlog+
I think this is a UX bug.

This was the result of bug 940685. The rationale there, as I understand it, was that about:home provided a better (or at least more consistent?) search experience in this scenario than just loading the page specified by the engine's "searchForm" attribute  (which was generally the home page of the relevant search engine, e.g. https://www.google.com for Google).

Clearly some users think otherwise (or at the very least are disturbed by the change in behavior). I'm not sure that our rationale there is strong enough to merit this change.
Summary: new ctrl-k behavior with search bar hidden (open about:home) is sub-optimal → [UX] new ctrl-k behavior with search bar hidden (open about:home) is sub-optimal
Whiteboard: [ux] p=0
Whiteboard: [ux] p=0 → [ux] p=0 [qa-]
Assignee: nobody → zfang
Status: NEW → ASSIGNED
Whiteboard: [ux] p=0 [qa-] → [ux] p=3 s=it-32c-31a-30b.3 [qa-]
Summarizing the discussion with Bryan Clark & UX team here:

We think it's better to focus the URL bar on ctrl+k when the search bar is hidden. This behavior is more consistent and expected than opening the "searchForm" attribute, and a better search experience than about:home. Using a blank search to access the searchForm attribute is a pretty rare use case (without data to support this unfortunately), so we shouldn't optimize the behavior for this use case. And what a blank search should do is a separate issue covered in bug 940685.
I can't imaging why I'd want ctrl-k to do the same thing as ctrl-l.  And as I've said before, non of the built in search options are as good as the google search page.
(In reply to Marc Auslander from comment #4)
> I can't imaging why I'd want ctrl-k to do the same thing as ctrl-l.  And as
> I've said before, non of the built in search options are as good as the
> google search page.

This is a solution for an edge case: people who removed the search bar but still want to use ctrl+k. If people are looking for better search suggestions, I would argue that they would not remove the search bar in the first place or bookmark google.com (or other search engine)
Some of us still prefer a keyboard shortcut to a mouse operation for often used operations - like starting a search.  That's why ctrl-k exists, isn't it?

And the unremoved search bar is not as good as the google search page.  See the comparisons above.
Also, while the current ctrl+l highlights the url in the URL bar, ctrl+k (when search bar is hidden) should empty the url bar and focus it.
Why?  ctrl+l highlights and focuses.  If you start typing, the highlighted contents are replaced!
I apologize for getting sucked into a flame war.

My initial request was that ctrl-k behavior be customizable since there was no obvious right answer.  I'll stand by that and shut up.
(In reply to Marc Auslander from comment #8)
> Why?  ctrl+l highlights and focuses.  If you start typing, the highlighted
> contents are replaced!

The reason behind comment 7 is: when using ctrl+l to focus on the URL bar, user's intent could be to type something in the bar or edit current url, that's why we highlight the current URL; But when using ctrl+k, the user most likely want to perform a search that's not relevant to current url, that's why we should focus an emptied URL bar.

I think the ctrl+k behavior(when search bar is hidden) can be either focus on the URL bar or open about:home (since we have a plan to improve search in about:home) but I don't think we should open google.com.

And "unremoved search bar is not as good as the google search page" in comment 6 is a separate issue that shouldn't affect the decision here.
If we're going to do something with the URL bar on invocation of a "search" shortcut, should we do searchbar-style autocomplete from that textbox, rather than simply blanking things?  That's 100% possible.  We could also detect when we're re-querying and rather than blindly blank, restore those search terms for editing.  This would actually be a pretty solid win in a searchbar-free world (and we could use the same logic when on a search result page...)
Component: General → Search
Depends on: 612453
What exactly is the difference between pressing Ctrl-k, Ctrl-e, and Alt-Home? Why do they all exist if they all result in about:home?
I need at least one of them (why not ctrl-k?) to load a home page of the default search engine (in my case it is a slightly modded google.com because I'm outside the US and I don't want search results in the local language). Am I asking too much?
Ctrl+K is the default search shortcut across all platforms.
Ctrl+E is the IE search shortcut, which we added (on Windows only) to make it easier for IE users to migrate, but it wasn't the default because it was between two keys (W and R) that triggered actions that could result in dataloss.
Alt+Home loads your homepage (which defaults to about:home).  If you want a keyboard shortcut that loads an arbitrary URL, set that URL as your homepage.

And yes, if you don't change the homepage, and you hide the search bar completely, you potentially have three shortcuts that do the same thing. I'd suspect that's an edge case for most people.
(In reply to Mike Connor [:mconnor] from comment #12)
> If we're going to do something with the URL bar on invocation of a "search"
> shortcut, should we do searchbar-style autocomplete from that textbox,
> rather than simply blanking things?  That's 100% possible.  We could also
> detect when we're re-querying and rather than blindly blank, restore those
> search terms for editing.  This would actually be a pretty solid win in a
> searchbar-free world (and we could use the same logic when on a search
> result page...)

Yes those are good ideas of improvement for the URL bar. Do you think we should block this bug till we have a better search experience in URL bar? I lean towards land this (ctrl+k highlight the URL bar) and work on improving search at the same time. Bryan, is there a existing bug on improving search in general? I couldn't find one.
Flags: needinfo?(clarkbw)
The top level tracking bug for our recent search improvements is bug 973272.

If you wanted to restore the old behavior we have a new component that gets the correct URL for a search engine via bug 959576.  I personally would love to see search improvements all around but I also don't think sending people to google.com is a bad thing either.
Flags: needinfo?(clarkbw)
As the reporter of this, I've given up a long time ago.  You'll ship what you like and probably never know if it adds or subtracts from people happiness with firefox.

I'll continue to use keysnail to make ctrl-k (and any other key) behave the way I want.
Blocks: 1021288
Alright, I think from an UX perspective, I have a slight preference over highlighting the URL bar instead of opening about:home. But since we already fixed bug 940685, and are working on bug 612453, opening about:home is an equivalent good option. 

I'm filing Bug 1021288 so that we can prioritize this work.
No longer blocks: 1021288
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Closed, not tracking anymore.
Dang, this lack of ctrl-K just bit me with the 31 upgrade.
Perhaps the recalcitrance of the dev team to our (admittedly minor) plight might be resolved by allowing us to assign a hot-key to a bookmark.  That would be better.
You need to log in before you can comment on or make changes to this bug.