Tools > Web Search is awkward UI

RESOLVED DUPLICATE of bug 235204

Status

()

RESOLVED DUPLICATE of bug 235204
15 years ago
6 years ago

People

(Reporter: gkn, Unassigned)

Tracking

({polish})

Trunk
polish
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8a) Gecko/20040506 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8a) Gecko/20040506 Firefox/0.8.0+

1. If the user doesn't have the web search box displayed, selecting Tools > Web
Search apparently* does nothing.

* I realise there is a cursor in the web search box, if one subsequently opens
the toolbar containing it, but that's quite irrelevant.

A solution to this would be that if the web search box isn't displayed, Tools >
Web Search brings up a dialogue box prompting for search terms, which are then
appended to the default search url (a la K-meleon). This isn't particularly slick.

Assuming the user has the web search box displayed, clicking the menu item
generates only a small cursor, possibly quite a distance from where the menu
item was clicked. I.e. the effect of the menu item may not be obvious, which
would confuse the user.

I agree with the desire to replicate toolbars' functionality in the menus, but
simply moving focus to a toolbar doesn't fully replicate the functionality.

Unless there would be a "Web Search for..." dialogue (in which case the menu
item should have a "..." suffix), the menu item should probably be removed.

Reproducible: Always
Steps to Reproduce:
A1. Ensure the web search box is displayed, and that the browser window is a
large size
A2. Tools > Web Search
A3. Try not to automatically look at the web search box because you know what's
coming - look at the mouse pointer as if to imitate a new and ignorant user

B1. Ensure the web search box is not displayed
B2. Tools > Web Search
Actual Results:  
A. You may notice a slight flicker to the right of your screen; nothing obvious
happens

B. Nothing happens

Expected Results:  
Something should happen. More specifically, a search dialogue should pop up.
(Reporter)

Updated

15 years ago
Keywords: polish

Comment 1

15 years ago
See also bug 235204, "Ctrl+K should go to search engine when search bar is
disabled".

Comment 2

15 years ago
I second the point about not being obvious when you click the "Tools -> Web
Search" button, and would propose the following (with associated Pref, maybe).

When the Search box and URL box are select from the Tools and Ctrl+L shortcuts
respectively, the user will expect a dialogue box (ala IE). To make it initially
obvious to new users that something has happened as a result of their action,
the relevent box should "flash", possibly ala the DOM Inspector "Flash" behavior.

This way, new users are guided to Firefox's streamlined interface, rather than
having to regress to an older way of working (dialog boxes). Currently however,
I would forgive all users who clicked "Tools -> Web Search" and presumed that it
didn't work. A bug like this could discourage use, since a "useful feature" that
would promote the Firefox browser would be seen as disfunctional by an
unassisted user.

Ideally, the text boxes would flash a system colour (the "Selected" colour
maybe?) to remain aesthetic with the user's system.

When clicking the boxes, flashing should not occur.
This behavior should probably be disablable after a time, since some users (when
they become accustomed to the behavior) would not want to be "flashed at" every
time, while others would. Perhaps on the 3rd or 5th occurance, the user could be
prompted with "Do you wish to disable the text box flashing when you click Web
Search?".

I would really support this as an enhancement for 1.0, as 1.0 marks the point
when a lot of less technical users will be 'encouraged' to try Firefox.

Should the point about flashing behavior for the URL bar be a new bug? Or is it
a valid extension to this one?

Comment 3

14 years ago
I can confirm with (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2)
Gecko/20040826 Firefox/0.9.1+) when the search bar is not on a toolbar going to
Tools->Web search does nothing at all...same with hitting CTRL+K nothing
happens. Also, I think that Websearch should be removed from the Tools context
menu...really no point of it being up there, just leave as a hotkey and
customizeable box for the toolbar.
(Reporter)

Comment 4

14 years ago
Since I filed the bug, the Find Toolbar has been invented. Perhaps if the web
search box is not visible, a quasi-Find Toolbar could appear. Find Next et al.
would be replaced by a single Find button.

Comment 5

14 years ago
Can this be a blocker since clicking 'Tools->Web' appears to do absolutley
nothing when the search bar is hidden. looks like a big bug to any user.
Flags: blocking-aviary1.0?

Comment 6

14 years ago
also this bug appears to be related to
https://bugzilla.mozilla.org/show_bug.cgi?id=242862
(Reporter)

Comment 7

14 years ago
(In reply to comment #6)
> also this bug appears to be related to
> https://bugzilla.mozilla.org/show_bug.cgi?id=242862

That *is* this bug. :)

Comment 8

14 years ago
wow i messed up in both bugs...lol sorry about that. I think this bug is a dup
of 235204 They both address the same issue.

Comment 9

14 years ago
if someone figures out what is appropriate, and comes up with a resonable patch,
might consider it for 1.0...  trying to get higher visability bugs first.
Flags: blocking-aviary1.0? → blocking-aviary1.0-

Comment 10

14 years ago
How about moving 'Web Search' from the Tools menu to the Go menu? Since
basically thats what it does when you click on 'Web Search' is goes to the
search bar...? 
(Reporter)

Comment 11

14 years ago
(In reply to comment #10)
> How about moving 'Web Search' from the Tools menu to the Go menu? Since
> basically thats what it does when you click on 'Web Search' is goes to the
> search bar...? 

In that case, I'd also move File > Open Location, as it's basically the same
thing; having said that, it's also the same thing as Open File.

...while we're at it, what has Work Offline got to do with a File menu? In fact,
if the menus' titles had any meaning, the entire first section of the File menu
(New Window...Close Tab) would be on the View menu.

Comment 12

14 years ago
I see what you saying and agree. But I still think something needs to be done,
like just removing the entry on the menu because right now it does nothing if
the search bar is not on the toolbar. Now if the search bar is on the toolbar,
clicking web search gives focus to the search bar, but why do that when you can
just click in the bar to give focus (donno if that the right word) to it...no
point in moving mouse up to the nagigation bar, clicking tools, clicking web
search and then typing in there.

I know that pretty much could go for anything though because of shortcut keys
but what I'm tryign to get at is that the Web search entry is pointless at the
time being...until a patch comes a long to fix the problem if the search bar is
not on any toolbars.
(Reporter)

Comment 13

14 years ago
We'll have a similar problem for Open Location once bug 247603 is fixed
(although I suppose it counts under that summary).

If the search bar contained "Enter search terms" by default (greyed out; I think
Asa suggested this in the notblog*), focusing it would cause that text to be
selected. It'd then be more obvious what had happened if the search bar was
visible, but no better if it was hidden.

The menu entry could just be disabled when the search bar isn't visible - it's
of no use at the moment anyway.

Comment 14

14 years ago
I totally agree. I like that solution and its got my vote for being a permanent fix.

Comment 15

14 years ago
I think Web search should be removed from menu. It has no funcinality, and it
occupies space, so when some extensions are added Tools menu becomes cluttered.

Imagine text processor with Type in Tools menu, so when you chose it cursor
moves to the white area allowing you to type.

It is ridicilous and unintuitive, see what user em_te said in
http://forums.mozillazine.org/viewtopic.php?t=139508&highlight= :

I actually don't have the search bar visible on my configuration because I
prefer to go directly to the Google site to search. And if I hadn't read this
thread, I would NEVER in the world have guessed what the "Web Search" menu was
for. I never bothered to ask anyone and just assumed that it was some "future"
feature that was not yet implemented yet! Well we learn something new everyday!!
The patch in bug 235204 addresses some of these concerns. I think that if that
patch lands, the only thing left to be done would be to somehow make the fact
that the searchbox is focused more apparent to the user. That could possibly be
done with the DOM Inspector-like flashing as suggested.

Updated

14 years ago
Depends on: 235204

Updated

13 years ago
Assignee: firefox → nobody
QA Contact: bugzilla → menus

Comment 17

13 years ago
*** Bug 314429 has been marked as a duplicate of this bug. ***

Comment 18

12 years ago
This bug hasn't been addressed in over 2 years. It's a bug and it's bad UI design.

Suggest removing "Tools > Web Search" from the menu entirely. That will solve the problem until such time as someone wants to write something better.

Current implementation is of no benefit to anyone, it is only negative.
(Reporter)

Comment 19

12 years ago
(In reply to comment #18)
> Current implementation is of no benefit to anyone, it is only negative.
> 

Well that's a lie. It exposes the keyboard shortcut combination. It's also useful for keyboard users who don't want to press Tab an indeterminate number of times in order to search.

Whatever was done to make focusing the Find (in this page) bar more noticeable would probably suit the Search bar as well.

(Someone should probably CC Beltzner once the whole "2.0" thing's been sorted out.)

Comment 20

10 years ago
Linux has been duplicated for this bug and I assume the same goes for Mac, marking for all.
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
Is this bug still applicable?

For me, using the keyboard shortcut or menu item with the search field hidden takes me to the Firefox start page (the Google search one), which seams like a reasonable action.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090410 Shiretoko/3.5b4pre ID:20090410035055

Same thing happens on Linux running 3.0.8

Comment 22

10 years ago
(In reply to comment #21)
> Is this bug still applicable?
> 
> For me, using the keyboard shortcut or menu item with the search field hidden
> takes me to the Firefox start page (the Google search one), which seams like a
> reasonable action.
> 
> Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre)
> Gecko/20090410 Shiretoko/3.5b4pre ID:20090410035055
> 
> Same thing happens on Linux running 3.0.8
Bug is more complex than that. It also states that it is meaningless that chosing menu item results in focusing on toolbar.

I think I have mentioned that above, but that is just like if you had in Word menu item 'Type' and after selecting it, it would focus the paper.

Some people might say that those that don't have search bar should have some access to search as reason to keep this menu item, but they can always type address of search engine, or eventually they might install add-on - they are minority and it is quite inline with Firefox policy
Not sure if this got mentioned earlier in the bug, but the main reasons we have this menu command (which are not immediately obvious) are:

1) supporting users who are visually impaired and are relying on a screen reader to interact with the browser
2) helping people discover the keyboard shortcut for performing a web search

So it's not that I don't also really want to simplify our menus, but any solution to the remove the command is going to need to also address those two aspects of the current design.

Comment 24

10 years ago
(In reply to comment #23)
> Not sure if this got mentioned earlier in the bug, but the main reasons we have
> this menu command (which are not immediately obvious) are:
I think reason no.1 was not mentioned and no.2 was
 
> 1) supporting users who are visually impaired and are relying on a screen
> reader to interact with the browser
This is really important issue, but as I have no knowledge on this topic, I can only guess that there should be some other way to do this (IE doesn't have this option and I think that it doesn't ignore visually impaired)

> 2) helping people discover the keyboard shortcut for performing a web search
My observation of human behavior tells that people will use shortcuts only if they already have the mental model that they should use shortcuts (and only very small precentage of people have it). So putting menu item for this is really not effective way to make change.

Otherwise, if you wanted the thing to be really discoverable, you could put in search bar instead of "Google" "Google (Ctrl+K)". Also you could use standard tooltip method and mention shortcut in the tooltip of search bar. But whatever method you use, I don't think that it will have some great impact.
(In reply to comment #24)
> > 1) supporting users who are visually impaired and are relying on a screen
> > reader to interact with the browser
> This is really important issue, but as I have no knowledge on this topic, I can
> only guess that there should be some other way to do this (IE doesn't have this
> option and I think that it doesn't ignore visually impaired)

David, what is your opinion about this given point?
Considered comment 16 hints that what is left to do is to hilight the focus, that based on the platform we do the common native hilighting (see the blue border on Win7 for example), and that now there is an action executed (opens the default search engine), this bug is basically a duplicate of bug 235204.
The requests to cleanup the menu removing the option clash against comment 23 and the fact the old menubar is rapidly being obsoleted by the appmenu button and Australis, and thus is pretty much a WONTFIX.
I think this bug reached a good solution so far, further improvements should be filed apart based on today's UI status.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 235204

Comment 27

6 years ago
> the old menubar is rapidly being obsoleted by the appmenu button and Australis

Not on Mac...

> this bug is basically a duplicate of bug 235204

For me, pressing Cmd+K navigates the current tab to google.com, which doesn't match the resolution of bug 235204...
You need to log in before you can comment on or make changes to this bug.