Closed Bug 32791 Opened 25 years ago Closed 24 years ago

Search button should not try to search URLs

Categories

(SeaMonkey :: Search, defect, P2)

Product:
SeaMonkey
Component:
Search
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: johng, Assigned: matt)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [nsbeta2-][nsbeta3-][PDTP4][rtm-])

Search button behavior is still not right. See beta1 bug 24582. Here is the behavior we want: *If the user has not changed anything in the URL bar* 1) Search button just goes to the default search engine's home page (as defined by pref, usually a redirect that goes to search.netscape.com) 2) Enter in the URL bar reloads that page. *If the user has entered something that looks like a URL or other web address* 1) Search button goes to that new URL or web address. 2) Enter goes to that new URL or web address. *If the user has entered something that is not a URL or other web address* 1) Search button does a search on that text 2) Enter sends that text to the keyword server Right now, tyrping a new URL and clicking search attempts a search of the URL itself - yuk. cc'ing valeski (since he wrote some logic code in the web shell) german and radha. Assigning to Matt.
Target Milestone: ---
On your second behavior. Type a URL and hit search You say that it should go to that URL Does that make sense to a user? It's says Search but acts like Enter. What about the integraty of the Search button? Shouldn't we be training people that Search really means Search? After they make on mistake they will quickly learn that the button really is a Search button. Maybe they don't like it but they will notice that is what the functionality is. Also if it actaully does a search on the URL string they might "discover" that they can type other things in that space and it will search for them. Here is my logic (long winded of course so skip it if you are an engineer) People think that the URL field if for typing URLs....not searches. I imagine that a lot of people will not notice the search button and just type a URL and hit search to go to that URL. The browser will do a search on that URL. They might not like like the behavior but they will notice what the functionality is which so the next time they need to do a search they will just type it in the URL field rather than hitting the search button and going to search.netscape.com What do the User Studies say?
Reassigning as per Don, who asks "what should be done with this" (assign back to him after deciding)
Assignee: matt → johng
The usability data and other feedback repeatedly indicates that most users do not differentiate between pressing "enter" and clicking the button. Therefore, the answer is to build something that will not surprise or confuse users as opposed to building something into the interface to "educate" the user that they *should* be acting in a different way. (We will use tooltips and other tactics to educate users on being able to search from the url-bar, but that is different then giving them a behavior they would view as "broken" in order to educate them on what we think is "correct" behavior.) Therefore, we have decided to make the button and enter work as much like each other as possible. For example, Netcenter is planning to design its keyword results pages (which you sometimes get with "enter") to look and act a lot like search results pages. The client behavior should work toward the same end. (We will keep some differences in the way they behave for various reasons that are only important to more advanced users.) So Matt, do you agree with this conclusion, with the behavior described at the beginning of this bug? Do you want to discuss more? If we are OK, let's implement as described above. Reassigning to Don.
Assignee: johng → don
Nominating nsbeta2 because search behaviors like this are so core to navigation as well as to our backend search service that we need to get feedback. Also, should be low risk since our code once worked this way.
Keywords: nsbeta2
radha, are you covering this stuff for matt now? I'd just reassign but I'm not sure. all, let me also add, woohoo! I have advocated this approach since Day 1, and put my full support(FWIW :-) behind it.
Not sure. Don should decide.
[nsbeta2-]
Whiteboard: [nsbeta2-]
M20
Target Milestone: --- → M20
nsbeta3 nominee
Keywords: nsbeta3
See also bug 28146 and bug 44455. I'm not surprised that `usability data and other feedback repeatedly indicates that most users do not differentiate between pressing "enter" and clicking the button'; that's what I warned of in bug 28146 (without the benefit of usability data). To make the Search button do a search in some cases and URL navigation in others would be to (a) make its behavior modal (yuk), and (b) make it impossible if you really really did want to search for an URL (how many pages mention my URL? etc).
nsbeta3+ reassigning to matt regression Critical to get this right: Searching is #1 activity in browser, and usability strongly supports a specific behavior. Matt, if you have questions, gable can clarify.
Assignee: don → matt
Keywords: regression
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
Who is gable and would he please clarify where the rest of the world can read? Search might be the number one feature. But I prefer google to this silly search approach. When I give google a url it tries to give me a cached page, which is much more useful than failing to load the missing page. Or maybe i really wanted to know what pages included ????.com [A friend who just died, and for which I wanted to find contact information]. If you really like the behavior described by johng then please give it some silly name like "go" instead of search. I'd just as soon request the button be banished. Make the default text for the box: <i>Enter something and press enter to load a page</i> Clicking into the box would remove the text allowing normal typing. Or make that a status hint.
> *If the user has not changed anything in the URL bar* Sometimes (e.g. with a framed site), loading the URL that is already shown in the urlbar makes sense. This mode is completely unconsistent to "*If the user has entered something that looks like a URL or other web address*", so please remove it. While I generally agree with the suggestion in this bug (I was about to file an RFE about it), mpt concerns are valid. An "URL" as in "what we recognize as and complete to an URL" can be something as ordinary as "m.tv" ("tv" is a top-level domain). Add that to the fact that users might get used to the search button and not know (instantly) how to search without it, and you have a problem.
assigning priority to comply with management.
Status: NEW → ASSIGNED
Priority: P3 → P2
Actually, I'm the famous Gable with all the controversial data. I'm the "evil" PM trying to bring all the data together and close on one decision so we can ship this baby. The stuff I've been adding is mostly based on usability data and user feedback, not my prefered ways of doing things. We are trying to design this for average users, intermediate users, not those of us who live and breathe this stuff. Some responses to above: Bucksch: Pressing "enter" and clicking the "search" button do not behave in exactly the same way. So Bucksch, I agree that "Sometimes (e.g. with a framed site), loading the URL that is already shown in the urlbar makes sense." You can do that by pressing enter - that is how we will protect that. If you click the "search" button, we presume that you do not intend to reload the current URL. Timeless: mpt is right - most users will not distinguish between "Search" and enter. Most users will click "Search" with the goal of "searching" for that web address they just typed in. Doing a search of that URL would be "the wrong thing to do" 95% of the time. The other 5% of the time can be handled by going to google or other search engine and doing your search from there - we do not have to solve every search problem from within the browser. We know this is not a perfect solution - but usability and feedback suggest that this is the best option. I understand the irratation of not being able to do a genuine search engine search for a URL from the location bar, we've talked alot about it here, but it is an edge case, and we think the "right thing to do" is to do it right 95% of the time.
> I'm the "evil" I can be pretty "evil", too :). > I agree that "Sometimes (e.g. with a framed > site), loading the URL that is already shown in the urlbar makes sense." You > can do that by pressing enter - that is how we will protect that. I do not want to use the keyboard, if I'm not entering alphanums anyway. BUt what is more important is the inconsistency. I just *expect* this case (no changed since last load) not to exist. > but usability and feedback suggest that this is the best option. Lake said, "usability tests" were used only to discover problems, not to prove something. > we think the "right thing to do" is to do it right 95% of the time. Who is "we"? If you mean "the people that build the browser suite", this includes me and Matthew. And *I* do *not* like "95%"-solutions, because these "5%" often turn out to be real pains in the long term. BTW: What means "URL" in this context? If I enter "localserver"ENTER, I get "http://localserver" (and correctly so). Same for "Ford".
Unless Matt really wants to, I can implement this if a decision is _ever_ reached (it doesn't look likely). Ben: it's understandable that you don't like 95% solutions (especially since you're in the 5% ;) But if you're going to take that stand, you need to present a 100% solution. It seems like you're advocating a 5% solution which is worse, as we'd rather satisfy 95% of users than 5%.
<plug class="shameless">The 100 % solution is in bug 28146 ...</plug> If I wanted to search for an URL, I would set the popup menu to `Search the Web for:', and then enter the URL; because I had manually selected an option, the URL auto-detection wouldn't kick in, and Mozilla would search for the URL instead of visiting it.
I think, you're still not getting me. I don't care about the case where a user wants to search for an URL. I care about the case where a user wants to do a normal search and our recognizer completes it to an URL.
PDT thinks this is a P5
Priority: P2 → P5
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta2-][nsbeta3+][PDTP5]
pdt: Usability strongly disagrees with you, and so do I. Today: type a URL, then click the button to the right to enter it, and you can *not* get the URL/ web address. This breaks basic browsing for many mouse happy beginner users. (These users see no difference in a Go button, a Search button, and clicking enter.) Just saw this since PDT's change took it off my radar. I'm changing to P1 to get it back on our radar (don't know how else to renominate).
Priority: P5 → P1
removing [PDTP5] from status to renominate
Whiteboard: [nsbeta2-][nsbeta3+][PDTP5] → [nsbeta2-][nsbeta3+]
johng: Isn't the "go" button for what you want? How do I search for a URI if when I click "search" after entering a URI it doesn't do a search of that URI???
The 'Go' button was surreptitiously inserted as a pref and isn't default so it might not gel completly with the previously established UI design. If they were both(Go and Search) visible all the time then maybe the search button's ideal design would be different, but that is not the case. If we do this right there is no need for a 'Go' button at all. To answer Ian's question: Searching for a URI that has a unique DNS match* has been established by useability data as an advanced user task. We would expect these advanced users to use one of the many available web search engines. Alternatively, they could use a key word/verb and type 'search www.anyurl.com' and that'll execute a netscapesearch for their URI or whatever they typed after the 'search' keyword. *note. If there is no unique DNS match you'll just be dumped into a search anyway. for the PDT: re request to reevaluate priority, useability has already shown us the way. Why do the tests and solicit feedback if we're not going to use the info we gain?
PDT: Two issues here, optimal UI design and severity relative to other P1 problems in the app. Now is the time to focus our efforts on things that make the app unusable, downgrading again. John, clearly you see this differently. PDT would welcome a visit if you simply cannot live with this answer.
Priority: P1 → P4
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta2-][nsbeta3+][PDTP4]
Priority: P4 → P2
returning to p4 since no supporting text was added. Before changing this again, please come explain the P2 impact to the pdt.
Priority: P2 → P4
Target Milestone: M20 → Future
OK, no go for beta. Does anyone wanna nominate this sucker for rtm? John?
Whiteboard: [nsbeta2-][nsbeta3+][PDTP4] → [nsbeta2-][nsbeta3-][PDTP4]
wow - missed this one. And it is unfortunately probably too late for rtm. This is one of those cases that since there is not concensus, we do the wrong thing for the average user but do the right thing for the mozilla and engineering geeks (which I'm frequently part of) who might actually want to do a search on "www.whatever.com". This is a problem for our targer users as we have learned from testing and looking at various scenarios. cc'ing tpringle and who can deal with this in the future. The big question is - if we have data that says we should do something a certain way, how can we make it happen even if there is not concensus? I'm obnoixously adding rtm keyword so Don and I will discuss it.
Keywords: rtm
> This is one of those cases that since there is not concensus No, it is not just disagreement. I really don't know how you want this to work. See my comments above.
The right thing to do is not search on URLs. But I don't think we can get this change in N6 RTM. Minus for now ...
Whiteboard: [nsbeta2-][nsbeta3-][PDTP4] → [nsbeta2-][nsbeta3-][PDTP4][rtm-]
Would anybody, *please*, care to define "URL" within this context? Because "URL" in the urlbar means much more than the spec says. "hello" is a valid "URL" in the urlbar (meaning the <http://hello/>).
BenB, clearly we can't guess what the user means when he types in "hello". But I'd guess the 99% case is that he wants to search for the word "hello", not visit "http://hello/" So I'd say we should only consider it an URL if it has a valid protocol...
> But I'd guess the 99% case is that he wants to search for the word "hello", > not visit "http://hello/" I would be careful about that. Many sites have a lot of internal webservers. I could agree, if you are only speaking about the search *button*, not hitting enter. This means that we have to have 2 different rule-sets about what is considered being an URL. (One for Enter and one for Search button.) This might make sense. > So I'd say we should only consider it an URL if it has a valid protocol... So, "home.netscape.com" + Search-button should search on Google for the hostname? "home.netscape.com" + Enter really should still go to <http://home.netscape.com>.
> So, "home.netscape.com" + Search-button should search on Google for the hostname? Well, I don't see how else we could determine "home.netscape.com" to be an URL without considering "hello." to be a search term...
Alright, what I just said really didn't make any sense. But there was a point hidden in there somewhere, really...I'll try this: I don't see a way to consider `home.netscape.com' an URL while considering `hello.' a search term. nap time...
Netscape nav triage team: as per Matt Fisher's pre-triage recommendation, this bug is nsbeta1-.
Keywords: nsbeta1-
I'm a bit confused. I thought we nsbeta1+ed this bug during triage. Did I miss something Matt? I tend to agree with Gable and Don here - when an average user takes the time to enter http://www.espn.com and then clicks search, they're almost certainly expecting to be taken to the ESPN site, not search results. I believe this behavior is vastly more common than searching on a URL. And to be more specific here, as URL seems to encompass a lot of things, I'm talking specifically about a situation where the end user types in the URL bar either: www.website.com or http://www.website.com or http://website.com In these cases, I strongly believe users are not expecting search results when they click the search button, but expect the page instead. We should fix this for beta1.
> either: > www.website.com or > http://www.website.com or > http://website.com Agreed. More generally: is either a full and valid URI (incl. scheme like "http" or "ftp", see RFC2396 and mozTXTToHTMLConv.cpp) or starts with "www." or "ftp.". Note that this is a new, additional definition of "URI" in the URLbar.
Blocks: 67414
Matt, I'd like to nominate nsbeta1 - what are your thoughts on fixing this?
The real problem seems to be defining what a URL is. If you consider anything with a '.' in it (which seems to be the current behaviour, as at 0.8.1) then any search with a '.' (such as 'someMusicIWant.mp3') will be considered a URL. This occurs even if the URL contains invalid URL characters (such as '"someMusicIWant.mp3"'). That just doesn't seem right. I can only imagine what would happen if some search engine decides to use '.' as part of the search syntax itself. I don't think catering to users who "don't know what's going on" (TM) is a good thing to start doing... when does it stop?
> If you consider anything > with a '.' in it (which seems to be the current behaviour, as at 0.8.1) then any > search with a '.' (such as 'someMusicIWant.mp3') will be considered a URL. That's braind^H^H^H^H^H^Hsuboptimal. Filed bug 73974.
German, bug 73974 would have been avoidable, if you posted a link to your spec <http://www.mozilla.org/projects/ui/communicator/browser/search/> here. You know about this bug, since you are cced since a long time. What I was discussing in this bug was exactly to avoid a bug like bug 73974. In hope of better collaboration in the future Ben
Suggested implementation: The best way to determine, what is a URL and what not, is to ask Gecko. This is what I use in the TXT->HTML converter (which is used by Mailnews), and it has proved to work well. I.e. complete the URL, if necessary, and then call NewURI with the string. If it succeeds, it's a valid URI that Mozilla can load. Look at the functions mozTXTToHTMLConv::CompleteAbbreviatedURL <http://lxr.mozilla.org/seamonkey/source/netwerk/streamconv/converters/mozTXTToHTMLConv.cpp#148> and the first part of mozTXTToHTMLConv::CheckURLAndCreateHTML <http://lxr.mozilla.org/seamonkey/source/netwerk/streamconv/converters/mozTXTToHTMLConv.cpp#351> (up to and including |if (NS_SUCCEEDED(rv) && uri)|. Maybe, you can use the actual functions in mozTXTToHTMLConv (after I separated the first and second part of CheckURLAndCreateHTML). This would lead to more consistency within the product. Tell me, if you want to. This basically implements my proposal from 2000-12-21 01:32. This will *not* catch all "URIs" that we can *process* in the urlbar (e.g. it won't catch "home.netscape.com", but only "http://home.netscape.com" and "www.netscape.com"), but IMO, that's OK. (See earlier discussion here for details.) Since it is a *search* button, we should err on the side of recognizing it as search term rather than URI. That's exactly the same that happens in Mailnews plaintext msgs.
German, I just checked .ui because of that, and I saw you posted your proposal there. So, a half-way "Sorry" for flaming you. Still, it would have been good to cite the document in the relevant bugs.
Keywords: nsbeta1- → nsbeta1
nav triage: this is a Netscape beta stopper. moving up to mozilll0.9.1 and bumping priority to P2.
Keywords: nsbeta1 → nsbeta1+
Priority: P4 → P2
Target Milestone: Future → mozilla0.9.1
fixed with bug fix 77261 Please not document http://mozilla.org/projects/ui/communicator/browser/search/ for clarification on search actions and reactions. If we need more we should have a newsgroup discussion.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I hope you meant: Please _note_ document
URL: http://mozilla.org/projects/ui/commun...
I'm sure there is more tweaking to be done but the basic point of this bug has been fixed. We're being a little smarter about what we call a url and no longer try to resolve mymusic.mp3 as a URL when the 'Search' button is clicked. Marking VERIFIED Fixed with 2001050304 builds. please let this bug die and never reopen it. New bugs can be filed that refer to specific failures against the specified behavior('da specs).
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.