28146 - [RFE] [search ui] Popup menu on location bar, for `Location:', `Search for:', etc

Status: RESOLVED INVALID

(SeaMonkey :: Search, enhancement)

Description

[Matthew T (active 1999-2002)]

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).

Comment 1

[german]

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

Comment 2

[Matthew T (active 1999-2002)]

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

[Ben Ruppel]

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.

Comment 4

[shuang (gone)]

Move to M18.

Comment 5

[johng]

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".

Comment 6

[Ben Bucksch (:BenB)]

> 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.

Comment 7

[Matthew T (active 1999-2002)]

> 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

[Blake Ross]

reopening and marking future, updating QA contact

Comment 9

[Marcia Knous [:marcia]]

Netscape nav triage team: as per Matt Fisher's pre-triage recommendation, this 
bug is nsbeta1-.

Comment 10

[Raphael Wegmann]

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

[Martin Lucina]

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

[Stephen Compall]

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.

Comment 13

[Asa Dotzler [:asa]]

reassigning.

Comment 14

[Samir Gehani]

Search UI spec change request; over to Marlon.

Comment 15

[marlon bishop]

this one has too much baggage to consider for the next release.  marking future

Comment 16

[Matthew T (active 1999-2002)]

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.

Comment 17

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.