7930 - Find dialog improvements bug

Status: RESOLVED INVALID

(SeaMonkey :: UI Design, defect, P3)

Description

[cpratt]

build id: 1999060909
platform: windows nt

If you select Find On this page [sic] from the Search menu, the dialog that is
presented is horked.

- The text input control has an incomplete border, varying height, and visual
garbage over a couple of pixels.
- The option labelled 'Case Sensitive' should read 'Match Case'.
- Please discuss other UI stuff with German et al; 'Backwards' and 'Wrap' seem
unnecessary (ie it may be better to stick with Up and Down).
- Finally, the 'Find' button should theoretically be labelled 'Find Next' - I
think. Again, please confer with German et alii.

Comment 1

[Peter Trudelle]

These are not XPToolkit issues, reassigning to don for triage, although I think
you should break it up into separate bug reports, one defect per report.

Comment 2

[don]

German, you make the call.  No hurry.  Re-assign back to me with your comments.

Comment 3

[AriB]

bug #1 is my bug at #7974

Comment 4

[german]

Let's stick to the 4.5 interface unless there are any major objections. So up
and down as well as "Find Next" as button. Reassign to Don to check whether your
team has done/can do all the plumbing to the right JS functions, the  re-assign
to me so we can fine-tune the dialog later in terms of visual appearance.

Comment 5

[Simon Fraser [no longer active]]

Bill and I wrote the Find stuff. The current dialog is most like the Mac Find
dialog, which I was working from, and (IMHO) is better than the Windows Find
dialog.

If someone can give a good argument why the current implementation is worse than
the alternatives, I'll change it. If not, then let it be.

Comment 6

[cpratt]

The basic argument I'll make is this one:
- It's easiest for customers to deal with UIs they've seen before
- Given that most customers use Windows, if we have to choose, we should go with
the Windows conventions (ideally of course it would be tailored to each
platform)
As a QA engineer my job in this area is to make sure that dialogs &c. do not
differ from 4.x; if they do, it's good only if it's to conform to
platform-specific conventions (ie Options/Preferences, Quit/Exit, &c.).

Comment 7

[shuang (gone)]

move to later milestone for Ui polish process only.

Comment 8

[german]

<off-topic> I disagree with Chris's one-sided comments: This is not valid for
5.0. 5.0 will sport an new and look and feel that will put preference on a
platform independent web-inspired look and feel. As an aside I seriously hope
that you're not making being stagnant the guide of your work, as innovation is
at the heart of Netscape, and it sometimes means accepting risks as a way of
achieving innovation and taking the lead.</off-topic>
Yes bug stays open since this falls into a larger dialog cleanup effort for 5.0
past dog-food in this case.

Comment 9

[leger]

Moving UE/UI component bugs over to new User Interface: Design Feedback 
component.  UE/UI component will be deleted.

Comment 10

[Eli Goldberg]

QA Assigning to Sarah, who now owns this feature.

Comment 11

[Christopher Lam]

Moreover:

The Find dialog, pretty as it is, is pretty hopeless with the keyboard.  Use of 
keyboard is at best frustrating.

Another point is: can you program it so that the search string is positioned at 
the top of the browser window rather than at the bottom? I believe that would 
make so much more sense.

Comment 12

[shuang (gone)]

Move it onto a later milestone M18. The original reported problem seems already 
fixed but people would still like to discuss issues around this bug. Though I 
would not consider this one is a valid open bug anymore, I will leave it open 
for just discussion purpose till German wants to close it.

Comment 13

[german]

Most of the cosmetic suggestions have been fixed, agree with the original 
assement that we should still change these things to make the UI easier to use:
- Label button "Find Next" instead of "Find"
- Replace "Search backwards" and "Wrap around" check boxes with radio buttons 
that simply say "Up" and "Down"
cc'ing verah for wording feedback
nominating for nsbeta3

Comment 14

[verah (gone)]

The changes are fine with me.

Comment 15

[Simon Fraser [no longer active]]

I'm confused about how "Up" and "Down" radio buttons replace both "Wrap" and 
"Find backwards".

Comment 16

[verah (gone)]

Perhaps there is no "wrap." Anyone?

Comment 17

[cpratt]

As far as I'm concerned "wrap" is obviated by the use of "up" and "down", which 
imply a circular motion (up to the top of the page and then up starting at the 
bottom of the page). "Wrap" really doesn't need to be there - sure, it may 
provide a tad of additional functionality by distinguishing between stopping at 
the top/bottom of the page and not stopping, but the confusion it may create for 
end users is not worth the extra functionality.

Comment 18

[verah (gone)]

I think people are used to seeing a "wrap around" option in search dialogs. By 
not having one, we're communicating that our search stops when it reaches the 
bottom (or top). That's okay, if that's what we want to communicate.

Comment 19

[Matthew T (active 1999-2002)]

The way `Up' and `Down' replaces wrap is by also having an `All' option, like MS 
Word has. I'm squeamish about using the words `up' and `down' at all, given that 
(with the wonders of CSS) text which is found `Down'wards may be hundreds of 
pixels *higher* than the starting position (and vice versa). Perhaps `forwards' 
and `backwards' would make more sense?

Anyhow ...

  +---------------------------------------------------------+              5.0
  |[] Find in This Page ::::::::::::::::::::::::::::::::::::|               |
  +---------------------------------------------------------+               |
  | _Find what: [_________________________] (( Find Next )) |               |
  | _Search:    ( ) Up  (*) Down  ( ) All                   |               V
  |                       ,-----------------------------------------------------
  | [ ] Exact _case      /        [ ] Find whole words only |(bug 14871)  future
------------------------'         [ ] Use wildcards         |(bug 32641) versions
  | [ ] Exact _diacritics         [ ] Allow spelling errors |               |
  | [ ] Exact _alef hamza         {... future non-charset-  |               |
  | {... future charset-specific  -specific options go here}|               |
  | options go here}                                        |               V
  +---------------------------------------------------------+

Explanations:
* Position of `Find Next' button: obviousness for someone who just wants to do a
  simple search, and forwards compatibility with muscle memory for the `Find
  Next' button when we add more options to the bottom of the dialog in future
  versions.
* Text of `Find Next' button: It would be really cool if the text of this button
  changed to `Find First', `Find Next', or `Find Previous' depending on the
  situation, but just `Find Next' will do for now.
* `Cancel' button replaced by a close box: this isn't a modal dialog, so we
  shouldn't confuse people by making it look like one (and it's not as if you can
  un-find text once you've found it, anyway, so `Cancel' makes absolutely no
  sense).
* Order of radio buttons ({Up, Down, All} rather than {All, Up, Down}): so that
  when the radio buttons have focus, from `Down' (the default) I can get to
  either of the other two options with only one keypress.
* Position of charset-specific vs. non-charset-specific options: aesthetics and
  economy of movement. There are probably always going to be more
  charset-specific options than non-charset-specific options, so charset-specific
  options go on the left for visual balance. And normally, users are more likely
  to use non-charset-specific options than charset-specific options, so they
  should be closer to the `Find Next' button to minimize mouse effort.
* Wording of `Exact case' checkbox: obviousness, and future compatibility.
  Already when I see `Match case', I wonder for a moment: `does that mean it will
  match *any* case, or only the case I enter?'. I can work it out after a couple
  of seconds, but that's a couple of seconds I could have spent doing something
  else. And IMO, that's just going to get worse with future charset-specific
  options unless the wording is changed.

BTW German, you really should get into the habit of reassigning bugs to 
programmers once you're done with them. :-)

Comment 20

[hangas]

Marking nsbeta3-, but that should be removed when assigned back to an engineer.

Comment 21

[german]

I am fine with the short-term changes suggested by Mat., guessing these are
easier to understand than 'wrap-around', while providing nearly the same
functiuonality. assigning to Don's team to see whether we can implement this for
rtm. Keyword rtm.

Comment 22

[don]

Hmmmm, that IS a nicer design.  But I don't want to take it for Netscape 6 at
this time.  Let's see if we can get it into a possible Mozilla release or
Netscape 6.1.

Comment 23

[Blake Ross]

cc'ing me in case i want to do this on a rainy day

(warning: it might have to be very rainy to get me to do this)

Comment 24

[Matthew T (active 1999-2002)]

*** Bug 65539 has been marked as a duplicate of this bug. ***

Comment 25

[Håkan Waara]

I am working on this dialog now..

Comment 26

[Zach Lipton [:zach]]

Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...

Comment 27

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Just a personal point of view : I have never understood how works "All" in MS
Find features. From a user's perspective, how can the direction be "up" *and*
"down" at the same time ?...

I think that "wrap" or "repeat" makes more sense and shouldn't be in same
radiogroup.

Comment 28

[Håkan Waara]

Attachment: 2001/03/03 - Find dialog right now

Comment 29

[Håkan Waara]

Ok, the latest attachment is how it looks right now.

Known issues:
* Find Next button is clipped at the right side

Most of what I've done was from the beginning to follow mpt's spec from
2000-08-23 20:29. But I've not fulfilled it to 100%, why?

* Exact case isn't used in any other app, so I used "Case sensitive" so the user
won't be confused.

* Instead of "Up", "Down" and "All" I did "Next" and "Previous". Sometimes there
are several matches at the same line, so Up and Down ain't really appropriate.

 "All" makes no sense either, it's just confusing "Up, down or all? How can it
search both up and down at the same time?". So for that reason I'm sticking with
"Wrap around".

I think I implemented the rest of what the spec asked for. Now there's much
space over in the bottom-left corner that's used for nothing.. That looks kinda
weird. Another thing is that I don't know whether the checkboxes looks best
vertically or horizontally aligned.

Please give feedback now, if you have a really good reason then perhaps I can
implement it! If you have good reasons and ideas about how the find dialog can
be further improved then please post them here. And please only post good,
complete comments - not several small comments. Thanks!

PS.
Law hasn't touched this bug in 2 years, so I'm taking it. Law: please let me
know if this is a problem.

Comment 30

[Jesse Ruderman]

How about having "find next" and "find previous" buttons instead of a pair of 
radio buttons and a button?  The "find next" button would be the default 
button, and it would be next to the text field.  Perhaps shift+enter when the 
text field has focus could do "find previous".

I think the dialog should have a cancel button, simply because it's easier to 
bonk a cancel button with the mouse than it is to bonk a close box.  See bug 
60618 and bug 64489 for more discussion about cancel buttons and the escape key.

Comment 31

[Jesse Ruderman]

Instead of having a "wrap around" checkbox, we could ding at the top/bottom of 
the document, and bring up a second dialog saying "You've reached the end of 
the document.  Click Find Next again to continue searching from the beginning."

Very recently I heard someone suggest replacing the dialog-on-dialog with an 
area for "status" text in the Find dialog.  I like this idea because it means 
the user would be able to just click once (Find Next to wrap around, or Cancel 
to bail out) if the text isn't found.  I don't remember whose idea this was.

Comment 32

[Jesse Ruderman]

Ahh, that was Jeffrey Baker in bug 70771.

Comment 33

[Håkan Waara]

Ok. Any comments on the actual UI that the screenshot showed?

Comment 34

[Håkan Waara]

cc'ing German who was involved with this some time ago...

Comment 35

[Håkan Waara]

Correction: the attachment shows how it looks right now after my improvements, 
not how it looks right now for users of Mozilla.

Comment 36

[timeless]

in NetBeans source editor (http://editor.netbeans.org/) find can result in a 
highlight search, which is how a find All option can be used.  an example of 
how this is useful can be seen in google cache searches, eg. 
http://www.google.com/search?q=cache:www.google.com/+google&hl=en
which highlights google in yellow [which is the same color that netbeans uses].

i'm not sure how hard/easy it would be to add a css selector :-moz-find-match

Comment 37

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

See :contains() pseudo-class in CSS 3 Selectors working draft :

http://www.w3.org/TR/css3-selectors/#content-selectors

Comment 38

[Matthew T (active 1999-2002)]

> Exact case isn't used in any other app, so I used "Case sensitive" so the user
> won't be confused.

Principle of consistency of the closest aspects: Consistency within the app is 
more important than consistency with other apps. So, consistency of the `Exact 
case' checkbox with the eventual `Exact diacritics', `Exact alef hamza', etc 
checkboxes is more important than consistency with `Case sensitive' checkboxes in 
other apps. And, IMO, Find windows/dialogs aren't used often enough generally for 
consistency with other apps to be worth the (IMO) decreased obviousness of what 
the checkbox does.

> Instead of "Up", "Down" and "All" I did "Next" and "Previous". Sometimes there
> are several matches at the same line, so Up and Down ain't really appropriate.

See the first paragraph of my 2000-08-23 comment.

> "All" makes no sense either, it's just confusing "Up, down or all? How can it
> search both up and down at the same time?". So for that reason I'm sticking
> with "Wrap around".

`All' is not the same thing as wrap around. `All' starts from the beginning and 
goes towards the end. `Wrap around' goes up/down, just like vanilla Up/Down, but 
continues from the end/beginning of the document once you've reached the 
beginning/end. I think `All' is much more likely to be useful than `Wrap around' 
is -- you're more likely to want to begin a search from the beginning of the 
document, than to (seemingly arbitrarily) search the document in two chunks based 
on the position of a (usually) invisible caret.

How about
|
| Search: (*) Whole document  ( ) Forwards  ( ) Backwards
|
-- but that would take more space.

> Now there's much space over in the bottom-[right] corner that's used for
> nothing.. That looks kinda weird.

So, implement a few of bugs listed in my 2000-08-23 comment. :-)

> I think the dialog should have a cancel button, simply because it's easier to
> bonk a cancel button with the mouse than it is to bonk a close box.

Yes, my preferred option is for the Find window to become a dialog (rather than a 
window)
|
| +-----------------------------------------------------+
| | Find :::::::::::::::::::::::::::::::::::::::::::::::|
| +-----------------------------------------------------+
| | _Find what: [_________________________] (( Find  )) |
| | _Search:    (*) All  ( ) Down  ( ) Up   ( Cancel  ) |
| |                                                     |
| | [ ] Exact _case         [ ] Find whole _words only  |
| | [ ] Exact _diacritics   [ ] _Use wildcards          |
| | [ ] Exact _alef hamza   [ ] Allow spelling _errors  |
| |                                                     |
| +-----------------------------------------------------+
|,
which (when you click Find) minimizes itself into a Find toolbar at the top of 
the content area. The toolbar would have a close box, and buttons labelled `Find 
Next', `Find Previous', `Find ...' (to reopen the dialog), and maybe even 
`Highlight All' (as Timeless suggested).

But for now, it's a window, rather than a dialog. And just as dialogs shouldn't 
have close boxes to do exactly the same thing as one of the buttons inside them, 
windows shouldn't have buttons inside them which do exactly the same thing as the 
close box. It's the law. (See also bug 66456.)

Comment 39

[timeless]

Exact alef hamza sounds really wierd

/- Match --------\
| [x] Case       |
| [ ] diacritics |
| [ ] Alef Hamza |
+----------------+
you could even do:
/- Match ---------------------------\
| [x] Case         [ ] whole words  |
| [ ] diacritics   [ ] wildcards    |
| [ ] Alef Hamza   [ ] misspellings |
+-----------------------------------+

Comment 40

[german]

too me this looks incredibly complex. The bug originally started out by
streamlining things, and making them easier to understand. 
Now I wonder whether there is still a way to use progressive disclosure here,
and only expose the 90% case upfront, but then have some control that expands
the dialog to also show wildcards and all the other stuff consumers are not
expected to use...

Comment 41

[Simon Fraser [no longer active]]

A comment on the screenshot: you should line the checkboxes up with the left edge 
of the text field, not have them flush left in the dialog.

Comment 42

[Håkan Waara]

I don't have enough time to promise I'll fix this, thus I'm reassigning to the
default owner of this component. Who knows, maybe I'll get around and fix it
after all - but I can't promise it. Sorry :(

Comment 43

[Gervase Markham [:gerv]]

Hakan: If you are ditching this bug, please attach your patches :-)

Gerv

Comment 44

[Håkan Waara]

One reason I stopped with this was because I lost them, along with the rest of
the fixes in my tree :(

Comment 45

[Matthew T (active 1999-2002)]

--> mozilla0.9.2. This is #4 on my list of things-to-spec (after Page Info, the 
XP filepicker, and Bookmarks). Though if anyone wants to implement my
2001-03-04 design, that would certainly be an improvement over the current 
version.

Currently I'm thinking of replacing `Up', `Down', and `All' with (a) a `Start 
at Top' checkbox in the dialog, and (b) `Find Next' and `Find Previous' items 
in the `Edit' menu rather than in the dialog itself.

Comment 46

[Steve Meredith (gone)]

This dialog can be greatly simplified by removing the up, down, and wrap
options. It would always search down, and automatically wrap (perhaps with a
notification that the end of the document has been reached.)

At a very minimum, keyboard shortcuts should be added to the current options.

Comment 47

[Gervase Markham [:gerv]]

I use "search up" frequently. Normally when I've gone one too far 
searching down. However, you could make a case for auto-wrap.

Gerv

Comment 48

[cpratt]

"This dialog can be greatly simplified by removing the up, down, and wrap
options."

Yes, that would make it simpler. That would also make it incredibly lame. Don't 
forget, we do compete with Microsoft Internet Explorer; given that we already 
are lacking dozens of IE-comparable features in Mozilla, why make matters worse 
by removing even more functionality?

Come on, people, this bug has been open for 1 year, 10 months, and two weeks at 
this point. Talk about 'stagnation'.

Comment 49

[Håkan Waara]

Cpratt, we aren't `competing' with Internet Explorer of the number of visible
options and features are we?

We are striving to make a good browser, and good is not always to provide as
much *visible* functionality as possible - but sometimes to hide it for the
user, to make another certain feature easier to use, in this case the Find Dialog.

Comment 50

[cpratt]

Håkan - you're right; I stand corrected. I agree that Mozilla remains 
uncompetitive with IE.

The problem is simple: once users come to expect certain functionality in a 
software application (e.g. Up and Down buttons in the find dialog), it's very 
difficult for them to migrate to an app with reduced functionality. Given that 
(approximately) 90% of the world is using IE, and most of the rest of the world 
is using Communicator 4.x (both of which have Up and Down buttons in their Find 
dialogs), the lack of these buttons in Mozilla would IMHO be problematic.

Comment 51

[Håkan Waara]

No, we are competetive with IE if we provide a better UI than it does. 

I'm not 100% certain that is the cause within this suggestion, about removing
the radiobuttons. But generally, hidden functionality without too much visible
UI/prefs gives a better UI experience.

I would like to hear MPT or German's thoughts here (re: Up and Down).

Comment 52

[Simon Fraser [no longer active]]

My thoughts re: Up/Down and Wrap:

If you start searching from the middle of the document (i.e. that's where your 
selection is), then, so search the entire document, you have to do it in two 
stages: search Up to the top, then Down to the bottom. This can be ameliorated by 
a checkbox to start searching at the top, but then, why not add another checkbox 
to start searching at the bottom (for backwards search?). Having a single 'Wrap' 
checkbox avoids these issues.

Another thing to think about here is searching behaviour in framesets, which is 
soon to get get checked in (see bugs 63241 and 68307). Note that this may require 
the addition of a 'Search all frames' checkbox.

Comment 53

[Gervase Markham [:gerv]]

mpt: Does the fact that you say you are going to re-spec this mean that the 
current spec in this bug no longer reflects your thinking?

Otherwise we can just go ahead and implement that...

Gerv

Comment 54

[Asa Dotzler [:asa]]

pushing out. 0.9.2 is done. (querying for this string will get you the list of
the 0.9.2 bugs I moved to 0.9.3)

Comment 55

[Gervase Markham [:gerv]]

mpt: if you spec this, someone with Patch Maker could fix the UI part pretty
quickly. If it requires back end changes, that's harder.

Gerv

Comment 56

[Colin Phillips]

Is there anything left to do on this bug?

Comment 57

[Jonas Jørgensen]

.

Comment 58

[Blake Ross]

This bug isn't useful.