Closed Bug 214880 Opened 21 years ago Closed 20 years ago

Replace the radio buttons of "Find in this page" with action buttons.

Categories

(Firefox :: General, enhancement, P2)

Product:
Firefox
Component:
General
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: hakon_, Assigned: bugzilla)

Details

(Keywords: fixed-aviary1.0) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030802 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030802 Mozilla Firebird/0.6.1

Replace the radio buttons in the "Find in this page" with two buttons that
actually perorms one step further or back when you click on it.
That would be more user friendly and faster to switch direction.
Maybe they should look something like this rather than just left/right.
 .            ______.
/|\                 |
 |______           \|/
                    '

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
I like this idea a lot.  When I want to "find backwards", it's always because I
overshot while finding forwards.  It takes too many clicks to switch direction
with the radio buttons.

How about "Find next" and "Find previous" as button labels?

See also bug 164683, same bug for Seamonkey.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
QA Contact: asa
There are problems with this.  Here's my understanding of the request.

+-------------------------------------------------+
| Find what: [                ] { Find Previous } |
| [ ] Match case                {{  Find Next  }} |
| [x] Wrap                      {    Cancel     } |
+-------------------------------------------------+

I think you would have to put "Find Previous" above "Find Next" because on
normally-flowing websites, previous means up (It means up/left for almost all
websites), but then "Find Previous" is right next to the search field.  People
will hit "Find Previous" on accident, and go the wrong way.  With wrap on by
default, they will end up at the bottom of the document.

Then, you have to worrry about the default button.  Obviously, you want "Find
Next" as the default, and if you figure out a way to get around the first
problem, you now have the issue of changing a simple dialog to perform *two*
functions.  Search this page for a single letter.  You can keep hitting enter to
continue the search in your desired direction.  With the proposed double-action
find dialog, does hitting enter perform the default button's action ("Find
Next"), or does it perform the action of the last button?  It becomes
not-so-clear to the user, *even if* we define a standard action.  Couple the
fact that the user doesn't know which way they are going, with the wrap being
auto-on, and a user could get their whole world thrown upside down very easily.

Does overshooting (which happens) really call for this change?  When you
overshoot, you have to click once to change the pref, and once more to search. 
(I'd like better keyboard access, but that's another bug.)  With this change,
you just have to click a different button, but now we've gone and compounded the
dialog by adding another function.  

It's just one extra click.

Oh, and the "everyone else is doing it, so it's intuitive" argument is supposed
to go here too.
> I think you would have to put "Find Previous" above "Find Next"...

No, you wouldn't.

> With wrap on by default, they will end up at the bottom of the document.

First, that can happen just as easily with radio buttons, so it's not an
argument against switching to buttons.  Second, find should tell you when it
wraps (instead of wrapping silently) anyway.  See bug 91520 comment 10.

> With the proposed double-action find dialog, does hitting enter perform the 
> default button's action ("Find Next"), or does it perform the action of the 
> last button?

It would work just like in every other dialog.  (If the textbox is focused,
Enter would be "Find next".  On Windows, if the "find previous" button is
focused, pressing Enter would find previous instead.)

I think users are unlikely to hit Enter after clicking a button with the mouse.

> [Clicking the "up" radio button] is just one extra click.

Currently, it's 2-4 extra clicks.  One to select "up", then one to select "down"
the next time you try to use the "find" feature.  If you forget that you
selected "up", you waste about two more clicks.

> Does overshooting (which happens) really call for this change?

Overshooting isn't the only reason you might want to search up.  In *any* case
where you would use the radio buttons now, using a "find previous" button would
take fewer clicks.

> With this change, you just have to click a different button, but now we've 
> gone and compounded the dialog by adding another function.  

I don't understand why you think having two buttons is more complicated than
having a button and a pair of radio buttons.
> find should tell you when it wraps (instead of wrapping silently) anyway

Oops, it does tell you when it wraps.  Which makes me wonder why there's a
"Wrap" checkbox at all.
Bug 234048 may relate to this slightly (not sure whether there are
blocks/dependencies involved so didn't want to add any.

Also, I think that the dialog could be layed out as follows, with the 'previous
/ next' side by side. I have also shown below the 'messages' section which again
is in relation to bug 234048.

+-------------------------------------------------+
| Find what: [                ]        Find:      |
| [ ] Match case                {Previous}{{Next}}|
| [x] Wrap                      {    Cancel     } |
|                                                 |
|        <-----  Messages here ----->             |
+-------------------------------------------------+

What does everyone think?
Find Next is default and logical action in Find dialog, so its button have to be
first, so your dialog should look something like this:

+--------------------------------------+
| Find what: [                      ]  |
|  [ ] Match case                      |
|  [x] Wrap                            |                                       
|                                      |
| (Find Next) (Find Previous) (Cancel) |                                       
     |                                      |
|    <-----  Messages here ----->      |
+--------------------------------------+

Also keep in the mind, that texts like "Match case" will be translated and 
could be longer. For example "Match case" is translated as "Rozlisovat
mala/velka pismena" in czech.
Adam, that's a good point. However, i think the buttons should be above the 
checkboxes, as follows... and ordered differently. 'Previous' should be left 
of 'next', as back is associated with left-side and forward is associated with 
right-side.

As follows:


+--------------------------------------+
| Find what: [                      ]  |
|                                      |
| (Cancel)(Find Previous)((Find Next)) |
|                                      |
|  [ ] Match case                      |
|  [x] Wrap                            |    
|                                      |
|    <-----  Messages here ----->      |
+--------------------------------------+

metz2000: AFAIK default action should be first in direction of reading, Cancel
should be last. I'm not GUI expert, but your proposal button order looks bad for me.
Ok, I see what you mean.

In that case I feel that the following solution would be best:

+--------------------------------------+
| Find what: [                      ]  |
|                                      |
| ((Find Next))(Find Previous)(Cancel) |
|                                      |
|  [ ] Match case                      |
|  [x] Wrap                            |
|                                      |
|    <-----  Messages here ----->      |
+--------------------------------------+
Flags: blocking1.0?
We probably need something here. The dialog, while system like, is still a
little cumbersome and the apparent only line of defense for the large set of
people that don't know about find as you type.
Flags: blocking1.0? → blocking1.0+
Flags: blocking-aviary1.0RC1+
No longer a problem in the new find bar.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
setting fixed-aviary1.0 for bugfixes checked into branch, for searching purposes.
Keywords: fixed-aviary1.0
You need to log in before you can comment on or make changes to this bug.