Closed
Bug 28146
Opened 25 years ago
Closed 22 years ago
[RFE] [search ui] Popup menu on location bar, for `Location:', `Search for:', etc
Categories
(SeaMonkey :: Search, enhancement)
SeaMonkey
Search
Tracking
(Not tracked)
RESOLVED
INVALID
Future
People
(Reporter: mpt, Assigned: marlon.bishop)
Details
Build: 2000021608, MacOS 8.6 The current design for the location bar includes a `Search' button at the right end of the bar. This design has a major drawback: many, many users will think that `Search' in Mozilla means the same as `Go' in IE, and they will click on `Search' whenever they enter an URL in the location bar. This problem will be particularly bad for users migrating to Mozilla from other browsers sporting `Go' buttons (IE 5, for example). Presumably the Search button as implemented would have a fall-back to detect URLs and redirect to the URL instead of the search results, but this would have three problems: * the user might never realize that they were doing things the slow way; * the user might never realize the original purpose of the search button; * if the URL-detection and redirection was done by the search engine, rather than the browser, the extra redirection step would give the impression that the browser was slower than it actually was. That's why I'm reporting this as a bug rather than an RFE. SOLUTION A suggestion I made in n.p.m.ui was unanimously endorsed by those who responded. That is, for a popup menu to be placed to the left of the location bar. This popup menu would contain the following items: * Location: * Search the Web: * Search Usenet: * What's related to: etc. (Hint: Extending this menu with sponsored items such as `Stock symbol:', `Shop for:', `Show map of:', and so on, would be a nice little money-earner for popular Mozilla distributions.) The current item in the menu would dynamically change between `Location:' and `Search the Web for:', depending on whether the currently-entered text did or did not look like an URL -- but only if the menu was at `Location:' when the user started entering text in the location bar. (This would prevent the menu from annoyingly reverting to the wrong choice if I wanted to [Search Usenet for:][http://mypage.org/] or whatever.) In summary, this design would: * remove the problem of users mistakenly clicking `Search' when they should press Enter; * give users a clearer idea of what pressing Enter will do for the current contents of the location bar; * make the location bar more useful; * be a money-spinner for Netscape (and other commercial Mozilla distributors).
We have discussed this idea previously as one of about 7-8 possible UI layouts. What we've come is very similar to what you suggest, some of which you will start seeing after beta1. The current setup is actually by design. In a nutshell: - we expect search and smartbrowsing to become the preferred ways of navigating the web in the short to mid-term -We want to be backward compatible in terms of behavior with 4.x: ENTER=smart browsing SEARCH=searching - furthermore it designed to make the search capability in the URL very discoverable and obvious which I think you rdesign would fail to do as it's relying on a popup which has shown to be near invisible on other occasions with 4.x especially for beginners. from a usability perspective we determined for a bunch of reasons to seperate pressing Enter behavior (works like smart browsing in 4.x) from 'pressing the search button' behavior which does do a search. To distinguish these two things is important from a user perspective This comes into play when you type in a strong tradmark (unique website) such as 'mcsonalds' or 'ford explorer', pressing enter in those cases does what 4.x does, it uses Smartbrowsing to resolve the reuest. Pressing search instead does perform a search on those terms. This again is similar to 4.x except, but improved, since now I can actually run search directly from my URL barwithout being at a search website. Hence the better visualization of this behavior seemed to be to leave them seperated in enough to underscore the difference between the two behaviors. Yet we have them in close proximity the URL field to suggest to the user that they now have a portable search engine. We will have some usability on this item in order to get internal in addition to user feedback on beta 1. But this will be what we are going with for beta 1. One of the things we'll watch out carefully for is the search vs enter behavior as you mention below. After beta one we are actually planning on adding an integrated popup button on the left of the toolbar that features both popular key verbs as well as the MRU type in history, which is very similar to what you indicate (minus the location). but that's after beta1. Setting to m16 for now as we we are expected to get beta end user feedback during beta 1. Expect resolution before beta 2. Setting component to search
Status: NEW → ASSIGNED
Component: Browser-General → Search
Summary: Popup menu on location bar, for `Location:', `Search for:', etc → [search ui] Popup menu on location bar, for `Location:', `Search for:', etc
Target Milestone: M16
Reporter | ||
Comment 2•25 years ago
|
||
To address your points in order: * There's very little difference in effectiveness between the result of Smart Browsing and the results of searching in your favorite search engine. (Try it: search for `McDonalds' or `Ford Explorer' on Google, Lycos, AltaVista, or Hotbot.) I appreciate that Netscape will want Smart Browsing in their own Mozilla distro, so perhaps the Netscape version could flip between `Location:' and `SmartBrowse:' based on the URL/non-URL contents of the location bar, while vanilla Mozilla flips between `Location:' and `Search:'. This difference would be trivial to maintain. * The visibility of the popup menu would be enhanced by its dynamic changing for URL/non-URL location bar contents -- the fact it changed from one option to another would signal to the user that there were other options available. * `ENTER=smart browsing SEARCH=searching' is *not* `backward compatible in terms of behavior with 4.x'. Try it and see. Enter a few words in the Location bar in 4.7, and then click the Search button (this is exactly what a friend of mine did in her first use of Navigator 4.x a couple of days ago). People have a right to expect that the button to the right of a text field will perform the same action as pressing Enter in that text field, no matter how large the gap between the text field and the button, because that is how every single Web search engine works. And you want the chrome to act just like the Web, remember? * Combining verbs and MRU URLs in the menu was one of my earlier ideas, but I rejected it because it would be internally inconsistent -- the menu would be acting half as a popup menu (selecting an option, and awaiting further user input), and half as a pull-down menu (performing an action, without any further input). MRU URLs would be best kept in a separate menu. * You will get beta end user feedback during beta 1, but you will not get public feedback from beginning users -- those most likely to suffer from the inconsistency between pressing Enter and clicking the Search button -- because beginning users don't tend to download beta versions. Please keep that in mind.
Comment 3•24 years ago
|
||
I think it would be interesting to look at what the competition has done. Specifically, IE 5 for the mac. What happens there is, when you start typing, a dropdown menu similar to Netscapes recently typed urls list automatically appears. At the bottom is an option to search for whatever has just been typed. Different? yes. Weird? yes. Neccessarily bad because of this? no. Time it took me to figure out how its works: three clicks and two page loads and I am enlightened.
Marking [RFE] Looks like we are not planning on implenting this feature any time soon, instead will see how users like or don't like the current Search UI, so marking "Later".
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → LATER
Summary: [search ui] Popup menu on location bar, for `Location:', `Search for:', etc → [RFE] [search ui] Popup menu on location bar, for `Location:', `Search for:', etc
Comment 6•24 years ago
|
||
> The current item in the menu would dynamically change between `Location:' and > `Search the Web for:', depending on whether the currently-entered text did or > did not look like an URL When do you want to change the dropdown content? When do you have enough input to judge if the user is going to enter or did enter a URL or not? Example: The user typed "h". Will this end in "http://www.mozilla.org" or "how do i hack my browser?"? The current implementation waits for an explicit user action (hitting enter) to run the recognition/completion.
Reporter | ||
Comment 7•24 years ago
|
||
> When do you want to change the dropdown content?
After each character is typed. So yes, it would read `Search the Web:' (or
whatever the user's default search function was) during the start of typing
`http://', but I don't think that would matter.
Comment 8•24 years ago
|
||
reopening and marking future, updating QA contact
Status: RESOLVED → REOPENED
QA Contact: asa → claudius
Resolution: LATER → ---
Target Milestone: M18 → Future
Comment 9•24 years ago
|
||
Netscape nav triage team: as per Matt Fisher's pre-triage recommendation, this bug is nsbeta1-.
Keywords: nsbeta1-
Comment 10•23 years ago
|
||
I would like to see a "clear url field" button like in konquerer. If you copy an url under X and find out, that you would like to change it, before loading it in the Browser, you have nowadays 2 bad solutions: A: you select the url in the browser, delete the current url. then select the url from the other app (i.e. an xterm) again (because the selection is gone) and paste it to the location lield. now you can edit it there an press enter. B: you click into the location field without selecting anything. Delete the current url by pressing <del> or <bs> for a while (this can take a long time for long urls), then paste it by pressing the middle button and finally make the editing to the new url both of those procedures are very ugly and could be easily made much faster by adding a <clear url field> button. Should I open a new RFE/Bug for that?
Comment 11•23 years ago
|
||
I see that this has been (possibly partially) implemented post 0.9; when I type into the Location Bar, Search XXX for "YYY" drops down from it. A couple of points regarding the current builds: * Is there a way to turn this off? Some of us like our location bar to be just a text entry field for entering URLs. * The current implementation seems to be rather buggy. When using build 2001052411, with the "Search" toolbar button turned off, typing into the Location Bar will drop down the Search XXX for "YYY" sometimes, but not always. * Since this functionality appeared there has been a noticeable lag between typing in the Location Bar and characters actually appearing. This may or may not be related to the above. I can file separate bugs for these points if that is the right thing to do.
Comment 12•23 years ago
|
||
As a user and observer of other users, I would like to add that there is not a single person in the universe who uses the "Go" button to send the URL (speaking in terms of messages between objects). Also, I have overheard this at a RadioShack: [context: an employee is on the phone, directing other end to http:// www.radioshack.com] Emp: "Just go to our website." ... Emp: "Type radioshack dot com into any search engine." I think the implication is clear (other than the fact that he has no idea how to use a web browser). Furthermore, the search feature as it is, is much more convenient than setting up the Google sidebar, opening the sidebar, waiting for loading, searching. Plus, for some reason, the referrer-mozilla Google search has no ads, not even text, evidently. Smart Browsing never works anyway; and I rely extensively on the descriptions! Get rid of it.
Updated•23 years ago
|
Assignee: german → sgehani
Status: REOPENED → NEW
Priority: P3 → --
Target Milestone: Future → ---
Comment 13•23 years ago
|
||
reassigning.
Assignee | ||
Comment 15•23 years ago
|
||
this one has too much baggage to consider for the next release. marking future
Target Milestone: --- → Future
Reporter | ||
Comment 16•22 years ago
|
||
As the reporter of this RFE, I am withdrawing it. Of course being the reporter doesn't ordain me with full control over the bug report, so if anyone thinks this proposal would be absolutely wonderful, they can reopen it, but I would advise them not to. The problem I described in comment 0 still stands, and is a severe shortcoming in Mozilla's interface. I think it is costing Netscape a substantial amount of market share as novice browser users give up after a few minutes of the Search button not doing what they thought it would do. However, the solution I proposed was rather wacky, suitable perhaps for Sherlock but not for a browser. In my defence, I was very very young at the time.
Status: NEW → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → INVALID
Comment 17•22 years ago
|
||
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.
Severity: normal → enhancement
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•