Closed Bug 410837 Opened 17 years ago Closed 14 years ago

save users from having to hit the down arrow, auto select the first autocomplete result.

Categories

(Firefox :: Address Bar, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 566489

People

(Reporter: moco, Unassigned)

References

Details

(Keywords: uiwanted)

Attachments

(1 file)

save users from having to hit the down arrow, auto select the first ac result. this suggestion comes from bret reckard. to paraphrase his request: "when I'm using the location bar, I always have to hit the down key once and then hit return. can't we autoselect the first item, so that return just works?" this seems like a good idea to me, given that touch typists know where return is but may have to look down and move their hands to find the down arrow (or use the mouse.) Or is this the intent of autofill? if so, this might be related to bug #408133: "browser.urlbar.autoFill should use the first result in the awesomebar". but, autofill is not enabled by default. beltzner/mconnor/faaborg, what do you think?
Flags: blocking-firefox3?
clarifying the summary. note, bret further clarified that he wanted to first "starred" item to be auto-selected. But, I think that part would be covered by #393578: "bookmarked results be weighted higher in the url bar autocomplete results". I'll let him elaborate.
Summary: save users from having to hit the down arrow, auto select the first ac result. → save users from having to hit the down arrow, auto select the first autocomplete result.
Sounds like a good idea, although this would mean that the user has to press Escape when she _doesn't want_ any of the autocomplete results (e.g. when navigating to a parent directory or when searching through the address bar). What about rethinking our keyboard shortcuts for the address bar and using e.g. Shift+Enter to go to the first autocomplete item (currently it'd add www. and .net)? Less discoverable, but less confusing and just as efficient...
Simon has a good point, and one concern is the action could be a bit confusing, but I feel the extra keystroke for Escape would be the minority case for most people. Though, the end result in terms of keystrokes and mouse interactions for the use case where auto-compete delivers the wrong result would be no different than the current implementation. I would say a more efficient method is for users to begin typing the URL (something they already do) until their desired selection autofills and then hit return (something easily learned/executed). "Starring" will only aid in process. I also agree that #393578: "bookmarked results be weighted higher in the url bar autocomplete results" covers my thoughts on raising the priority of "starred" items. Not sure if having the average user learn new keyboard shortcuts in the right path...
So if I understand this correctly, when I type cat in my location bar (I want a Google search for cat) followed by enter, it will go to "Bug List" (I will save you the long URL) instead, which is the first result in the list? :)
Hmm good point again, but that reminds me of my original thought. That the bar would auto fill only when a "starred" item were present in the results. So my search for cat would lead to my bookmarked page for Cat Fancy Magazine :), but your search would lead to the mighty Goog. Thoughts?
Ah no, for this is a starred URL.
Safari does this and I hate it. It completes something I don't want just before I press enter all the time.
ria points out that that we'd be breaking the google search feature of the url bar. I forgot about that. simon's suggestion of shift+enter would solve that problem, but it would not be very discoverable. (perhaps that is ok?) this is starting to feel more and more like autofill (see also bug #408133), but as jesse points out, this is not always a loved feature, which is probably why it is off by default. the google feature breakage alone makes this seem like a wontfix, but I'll wait for the ux people to weigh in. one of those ux gurus might have an alternative suggestion for how to save users that key stroke.
I Believe Safari attempts to ac based on most visited URL's. Sometimes you want them sometimes you don't. I'm suggesting only "starred" (Read: User Selected) URL's be sifted through before searching. Seth, wouldn't the Google search function be breaking url bar and not the other way around? Now, if this function breaks the Awesome bar, that's a different matter.
I think I was a little harsh here. Apologies to Seth, Ria and Jesse. Looking forward to hearing your thoughts? -Bret
Maybe a non-default option? A problem might also be that Firefox will not try anymore to do a DNS query as long as there is a starred item on top of the autocomplete. When I type mozillazine.org it won't go to http://mozillazine.org/ anymore but to one of three starred items that appear on top: http://forums.mozillazine.org/search.php?mode=results&sid=b4696590fe3e9051422bfcfdaa6991e6 , http://forums.mozillazine.org/viewforum.php?f=23 , or http://forums.mozillazine.org/viewforum.php?f=38
Well, this was a bad example :).
Seems it never tries to make an URL of an entered word when you just hit enter. This needs ctrl+enter. What I saw was probably an I'm feeling lucky search.
I'm all for saving every possible keystroke or mouse movement, but we've previously had a chance to consider this idea and found a pretty significant problem: novice users who don't know how to touch type will be looking at the keyboard to find the correct keys, and when they hit enter they will get a URL that is different from the keys they pressed e... b... a... y.. ... c... o.... m....[enter] will likely take them to whatever auction they view most. This disconnect between input and output may become very confusing since they are never looking at the location bar to even realize why this is occurring. This also impacts users who type incredibly quickly (Jesse's annoyance: forget to hit backspace to clear the selected autofill before hitting enter), and it has accessibility implications for user's with a screen reader. If you consider all three issues put together, it is probably worth forcing the extra keystroke (as much as I want to eliminate every possible keystroke).
For fun and to try out the alternative suggested in comment #2: This extension makes Shift+Enter go to the first autocompleted URL. (Warning: This quick hack will break as soon as you customize your toolbars.)
This is WONTFIX due for reasons listed in comment 8 and 14. Shift+Enter is already taken as a shortcut in the location bar, and not a really common metaphor (and not really that much of a savings).
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: blocking-firefox3? → blocking-firefox3-
Resolution: --- → WONTFIX
(In reply to comment #16) > (and not really that much of a savings). Been using it for two months now - and respectfully disagree. ;-)
(In reply to comment #14) > e... b... a... y.. ... c... o.... m....[enter] > will likely take them to whatever auction they view most. I thought about this problem and basically the logical answer to that is if the user hasn't entered a top-level domain (i.e. .com or .org. or .info etc) as part of their search then when the user hits enter, the first search result in the Location Bar should be loaded. example: youtube =>take the user to the first search suggested result as determined by the AwesomeBar If the user types a top-level domain in their query and then hits enter, have Firefox go to that page. example: youtube.com/feist =>take the user to Feist's YouTube Channel because .com was typed (In reply to comment #8) I disagree. Currently, typing a word into the Location Bar (without a top-level domain) and hitting enter results in a Google I'm Feeling Lucky search. Since the new Location Bar has gotten AwesomeBar features (search history and bookmarks and titles of sites) I never find myself using the Google I'm Feeling Lucky search anymore. If I want to Google something I just use the built-in search box to the right. However, many times I have found myself wanting to immediately go to the first result suggested by the AwesomeBar. Without thinking I hit enter right away and expect Firefox to take me to that result. Instead I get some seemingly random web page given to me by Google. To actually go to the first suggested result I have to press the down-arron-key and then enter. This is an unnecessary step. The AwesomeBar is all about personalization and ease-of-use. Having the Google I'm Feeling Lucky search just ruins this. Also, the AwesomeBar features will undoubtedly be used waaay more than Google I'm Feeling Lucky searches will. Because of these new reasons, I propose that the Google I'm Feeling Lucky search be replaced with the first suggested result of the AwesomeBar when querying the Location Bar. Thanks.
>I thought about this problem and basically the logical answer to that is if the >user hasn't entered a top-level domain (i.e. .com or .org. or .info etc) as >part of their search then when the user hits enter, the first search result in >the Location Bar should be loaded. That's an interesting idea, combined with increasing the value of places.frecency.typedVisitBonus we could potentially solve the user not looking at the screen problem. Unfortunately it is likely too late for this to make Firefox 3, but certainly something we should start to experiment with for the next release. Reopening the bug since this is no longer clearly a wontfix.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Ed's "Enter Selects" extension <https://addons.mozilla.org/en-US/firefox/addon/7423> works a treat and seems like the way to go if this goes into the browser.
Yeah, I am unhappy with the smart location bar without this extension / feature.
I've been giving this a lot of thought recently, and I'm going to propose a change in coordination with the other things we are starting to consider (http://blog.mozilla.com/faaborg/2009/03/25/integrating-ubiquity-into-firefox-ui-mockups/ ) I'll post more details and mockups to this bug once I have things a little more worked out, still focusing on 3.5 stuff at the moment.
Flags: wanted-firefox3.6?
Keywords: uiwanted
(Just as a point of order, if a bug has been WONTFIXed by a module owner or peer, REOPENing it is considered bad form without first checking with a module owner or peer which wasn't done here. Also, comment 22 and comment 25 aren't proper etiquette - bug comments aren't meant for advocacy, though your interest is appreciated.) I'd like to see a patch that implements this; I don't think we can make assertions about how it will feel and what the interaction will be like without trying this out. We also need to involve the ARIA/a11y guys, as I know one of the objections to bug 186136 had to do with a11y concerns. For my part, I'm still not sure that this is actually an optimization unless we can be 100% sure that it's what the user wants to do. That might mean making it more clear how to *not* select the first item in the list, or it might mean finding the perfect way of determining if the user wants to select that item.
Personally, I am really liking ChrisJF's (comment #20) idea. Safari has the autocomplete-url feature, but it takes too long to activate. After typing my location that I would like to visit, I end up seeing the dreaded blue of the autocomplete moments before I hit the return key, and I usually end up somewhere I did not want to go. Having the autocomplete feature only activate if a .com, .net, etc. extension was not present, would be awesome. The exception to this would be anything residing at localhost, or other places that have been specifically mapped to an IP (using your hosts file or through another method); it might be nice to have a place where advanced users could specify URLs that would not be autocompleted.
Status: REOPENED → NEW
Fixed in Firefox 6.0 Alpha
Firefox 6.0 Alpha has better behaviour. See bug https://bugzilla.mozilla.org/show_bug.cgi?id=566489 This bug should be closed.
Agreed, this is more or less a dup of bug 566489. We decided to only fill in one "part" of the URL at a time, to reduce the chance of going to the wrong URL. (But note that it has been backed out for Firefox 6.)
Status: NEW → RESOLVED
Closed: 17 years ago14 years ago
Resolution: --- → DUPLICATE
Flags: wanted-firefox3.6?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: