169489 - What Type Ahead and tabbing nav prefs should be exposed?

Status: VERIFIED FIXED

(SeaMonkey :: Find In Page, defect)

Description

[Aaron Leventhal]

I realize we expose too many prefs already in our UI, but I feel that we should
expose at least these 2 prefs for Type Ahead Find:

[ ] Navigate to links only or all text
[ ] Beep on error

What do others think?

Comment 1

[Itamar]

Sounds good to me - I really wanted somthing like 
[ ] Navigate to links only or all text

BTW
bug 169490 is the same is this one right?

Comment 2

[Aaron Leventhal]

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

Comment 3

[Aaron Leventhal]

Right, that was an accidental dup.

Just to clarify, I wasn't suggesting the actual wording - just what stuff we'd
want to expose.

Comment 4

[Stefan Borggraefe]

Please add UI for the timeout setting. I think a line with a checkbox and a
textfield would be appropriate for this:

[ ] Timeout search after __ seconds

When the option is deselected this setting would correspond to
user_pref("accessibility.typeaheadfind.timeout", -1);

I believe a lot of people will prefer to turn off the timeout.

Stefan

Comment 5

[Aaron Leventhal]

I don't think we should expose the timeout pref -- we have to stop somewhere,
don't we? I'll never get the UI people to sign off on it if we ask for too much.

Comment 6

[Anthony DeRobertis]

The timeout pref is one of the most important, IMO. More so than if searching
links or everything is default (use the damn slash key) or if beeping should
occur (turn off sound if you need it quiet e.g., in a library)

People work at different speeds. People type at different speeds. So the timeout
needs to be different amounts for different people. Think of the difference
between a touch typist who knows exactly what he wants to type (and how to spell
it) and someone who is still doing finger-poking typing and can't spell at that.

Or someone who has a physical disability that limits his ability to type. This
is an accessability feature too, right?

Also, there is precedence to expose timeouts: Consider that even Mac OS exposes
the double-click timeout to the user.

Comment 7

[Corrado Berti]

What about a (hidden?) pref about the highlight color?

Comment 8

[Aaron Leventhal]

Yes, the hidden pref for highlight color is listed in the typeaheadfind docs:
http://www.mozilla.org/projects/ui/accessibility/typeaheadfind.html

Comment 9

[Adam Katz]

a bit more detail than comment 1...

  (*) require manual initiation of isearches
  ( ) always in isearch links mode
      __ begin isearch of links     __ begin reversed isearch of links
  ( ) always in isearch text mode
      __ begin isearch of all text  __ begin reversed isearch of text

  [color-selector] default highlight color

"( )" is a radio button, "__" is a single-character input box
defaults: require manual, ' links, " reverse links, / text, ? reverse text.

suggesting bug 176296 be marked as a dup of this bug.

Comment 10

[Adam Katz]

adjusted, including key combo init suggestion in bug 30088 comment 256:

[x] enable isearch
  (*) require manual initiation of isearches
  ( ) default isearch in links mode
  ( ) default isearch in text mode
  [ ] ctrl + [ ] alt + __  isearch (leave blank for always on), then...
      __ begin isearch of links      __ begin reversed isearch of links
      __ begin isearch of all text   __ begin reversed isearch of text
      note: above entries are CASE SENSITIVE
  [color-selector] default highlight color
  ___ seconds until timeout
  [selector:do nothing,beep,flash status bar] when nothing matches
  [x] disable backspace goes back in history

"( )" is a radio button, "[ ]" is a checkbox, and
"__" is a case-sensitive single-character input box, "___" is 2 chars

hope that's clear ;^)

Comment 11

[Adam Katz]

(*) SmARt caSe sensitive
( ) Always case sensitive
( ) Always case in-sensitive

Comment 12

[ChaTo]

On error:

(*) Disable for this page
( ) Do nothing
[ ] Beep [disabled by default] see bug 168574

I find typeahead really cool, except when there are forms, and I click-to-focus
on mozilla and the focus is lost from the first text field.

Comment 13

[Aaron Leventhal]

Attachment: Create Keyboard Navigation prefs panel, below "Tabbed browsing", but above "Downloads"

Comment 14

[Aaron Leventhal]

Attachment: Screenshot of pref panel

Comment 15

[Aaron Leventhal]

Attachment: New improved screenshot

Comment 16

[Aaron Leventhal]

Attachment: Patch for new improved design, also impl's radiogroup.selectedIndex getter and setter

When the checkbox "Find automatically when typing within a web page:" is
unchecked, the child radio buttons get disabled.

Unfortunately, I noticed that the tab navigation prefs aren't dynamically
changeable, you have to restart. Will file a bug on that. Also, if you select
textboxes only for focus, you can't tab to the location bar, or even hit
Accel+L to get there!

Comment 17

[Sander]

I'm no usability design expert (thank the Light) :) but from one of the things I
read about it something that made sense and is applicable here has stuck in my
mind: in the current screenshot, after you've selected either "Any text in the
page", or "Links only", how do you go back again to the "neither" option? (aka
the option where / or ' is always required to start type ahead find). 

I assume that it's by unchecking the "automatically" checkbox, and that this
contrasts with the tip about manually, but that isn't very clear, and right now
it seems that when you disable the checkbox, TAF won't be possible at all.

I'd suggest keeping the three radiobuttons from the first screenshot, although
the phrasing from this second version is a lot clearer.

Perhaps for these options something like:

Find As You Type within a web page:
 ( ) Any text in the page
 (*) Links only
 ( ) Any text only when you first type a / or links only when started by a '

Comment 18

[Aaron Leventhal]

I don't understand what's unclear.

The tip says you can manually start type ahead find using these keystrokes.
Those keystrokes will also be listed in the edit menu with menu options, to
reinforce that they will always work, no matter what the settings here are.

You can uncheck "automatic" if you don't want to have Find As You Type start
automatically.
If automatic is checked, the radio buttons are enabled, allowing you to select
what happens automatically.

Comment 19

[Sander]

What is unclear... This is hard to explain exactly, as I'm trying to look at
this like a user who doesn't know TAF would. 

The first is that in the screenshot neither of the radiobuttons is checked,
thereby creating a third "state", to which you can't go back once you've clicked
one of the two radiobuttons.

(Though perhaps this is only in the screenshot... comparing the xul from the
patch with that of some other preferences using radiobuttons, I think the "Any
text in the page" option will be checked if no preference is set, and if so that
concern vanishes.)

The second issue is the "automatically" versus "manually."
Most people coming to these preferences for the first time will only be aware of
the regular find dialog. No matter if / or ' is required or not, the entire
concept of finding text without going through a dialog will seem "automatic",
and they'll thus be hesitant to uncheck that checkbox (or expecting TAF to be
disabled completely when unchecking it), because the Tip doesn't directly
contrast it.

There are only three distinct states here, but by ordering them in two levels,
understanding that gets needlessly 'complex'.


Am I making sense? As far as the "power-user" me is concerned simply having the
options is all that's required, and having these preferences is certainly great,
but I'd like my mother to also easily grasp them.

Not trying to be annoying here or give you more work :) - simply trying to help;
because polish _does_ matter... *grins* Having given my input, I'll shut up now.

Comment 20

[Aaron Leventhal]

The first concern - that neither radio button is selected, is a quirk of the
screenshot. That won't happen in the real thing.

> The entire concept of finding text without going through a dialog will seem 
> "automatic", and they'll thus be hesitant to uncheck that checkbox 
Fair enough, perhaps we should reword that. Jatin?

> There are only three distinct states here, but by ordering them in two 
> levels, understanding that gets needlessly 'complex'.
When there were 3 radio buttons, I had 2 people in our usability group confused
by it, but not by this. So I suppose it's 2-1 them. :) 

In all the mockups I did, either the dialog got too wordy explaining what the 3
choices were, or it was too short it didn't explain the detail. These "two
levels" made the two kinds (automatic/manual start) easier to explain with less
text.

I think this panel has gone through a lot of thrashing and I'll really be glad
when we get this in. But, maybe someone else can weigh in on the issue. If I
hear from more people that don't like it, back to the drawing board I guess.

> Not trying to be annoying here or give you more work :) - simply trying 
> to help; because polish _does_ matter... *grins* Having given my input, I'll >
shut up now.
Feedback is welcome :)

Comment 21

[Hixie (not reading bugmail)]

Comment on attachment 110424 [details]
New improved screenshot

HAHAHAHA!

This is a joke right?

Comment 22

[Hixie (not reading bugmail)]

Apparently it isn't a joke, so:

I strongly oppose this proposal. We already have WAY too many prefs. The HUGE
magority of our users couldn't care less: we should just pick the best set of
defaults for our users and go with that.

Our job as programmers is to write the browser. We shouldn't be making the user
make these decisions for us.

For the tiny minority of users that want to change this, we have extensions.

Comment 23

[Aaron Leventhal]

Attachment: Removed checkbox allowing textboxes to be removed from tab order and added "Note: text boxes are always part of the tabbing order."

Textboxes should always be tabbable.
We should file a bug to fix mac so that the system setting for what's tabbable
is adhered to. We should use that instead of the checkbox for "Buttons, radio
buttons, checkboxes, and lists".

Comment 24

[sairuh (rarely reading bugmail)]

filed bug 187508 for comment 23.

Comment 25

[Hixie (not reading bugmail)]

Similary the sound pref should be based on OS settings (e.g. sound schemes
control panel on Windows), "clear the current search after inactivity" should be
a hidden pref in milliseconds, "find automatically" should (and already is) a
hidden pref defaulting to enabled, and the remaining pref (the radio button to
pick the default behaviour) should be a hidden pref (as it already is)
defaulting to the option that a usability study says users use the most.

The hidden prefs can then be hooked up to a UI using an XPI extension, for the
rare users who actually want to tweak those things.

Comment 26

[sairuh (rarely reading bugmail)]

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

Comment 27

[Alex Bishop]

Personally, I think The only Type As You Find (or whatever it's called now)
prefs should be these:

+--Find As You Type------------------------------------------------------------+
|  When I start typing within a page:                                          |
|    (o) Search all page text                                                  |
|    ( ) Search links only                                                     |
|                                                                              |
|    Tip: To override the above setting, press / to search text or ' to search |
|    links, followed by the text you want to find.                             |
|                                                                              |
|  [x] Play a sound when no Find As You Type finds no matching text.           |
+------------------------------------------------------------------------------+

I can't see much point in having a pref to disable Type As You Find (it's not
like typing within a page did anything useful before). As for the timeout pref,
I think far more people will have no idea how to exit a search if it doesn't
time out than will be peeved that they have to retype a few letters if they
leave it too long.

Comment 28

[Aaron Leventhal]

One note on the radio.xml changes. That's implementing the selectedIndex
attribute in nsIDOMXULSelectControlElement. Some of those DOM XUL interfaces
Hyatt wrote were never fully implemented. I needed that attr in this bug, so I
filled out the impl for it.

Comment 29

[Aaron Leventhal]

Attachment: Modified with sgehani's feedback on IM

Comment 30

[Hixie (not reading bugmail)]

regarding comment 27: As I said above, the sound pref should be at the OS-level,
not in the Mozilla prefs panel. All GUIs now have extensible global sound
setting pref panels as far as I know.

As for the other pref, I really don't see the point. Why do we have to make the
user make this decision? Can't we just find the best solution and default to
that? Writing software is about making these decisions on behalf of the user,
not pushing our responsabilities on to them.

Comment 31

[Alex Bishop]

> regarding comment 27: As I said above, the sound pref should be at the
> OS-level, not in the Mozilla prefs panel. All GUIs now have extensible global
> sound setting pref panels as far as I know.

Fair point but it would spread out the Type As You Find prefs a little.

> As for the other pref, I really don't see the point. Why do we have to make
> the user make this decision? Can't we just find the best solution and default
> to that? Writing software is about making these decisions on behalf of the
> user, not pushing our responsabilities on to them.

In general, I agree but I think the two search modes of Type As You Find are
distinct enough to have separate uses. For example, I only ever use the feature
to search all text (and I prefix every search with a / because I'm too lazy to
edit my prefs.js file to change the default). I'm sure some people only ever use
it to search for links. I believe that both options should be available but
there should be a pref for the default mode.

While a lot of the unnecessary UI prefs are basically asking the user, "Which
behaviour is best, from a usability perspective?" (something no user should be
expected to know or care about), this pref is essentially saying, "Type As You
Find has two distinct uses, which do you use the most often?" (something a user
can more reasonably be expected to know).

Of course, most users never alter the prefs so the default should be carefully
chosen. Personally, I think it should be to search all text, not just because
it's what I always use, but because I think it's the more understandable mode.
The first time I ever used Type Ahead Find (as it was then), I was confused as
to why it didn't seem to work; it was only later I realised that it defaults to
only searching links. If I had trouble getting to grips with the feature then I
fear for the average user.

Comment 32

[Sander]

For all that I couldn't live without Type Ahead Find anymore, I actually _want_
that third option of it not doing anything unless preceded by either a / or a '
It happens far too often for me that TAF is triggered when I don't want it to
(for example when switching to the location bar of a new tab and starting to
type before the focus has really registered (suddenly the previous tab has
scrolled to a position where I definitely didn't leave it; very annoying when
reading long texts), or simply because of stray touches to the keyboard).

Although I agree with the general idea that we shouldn't provide too many
preferences, I concur with comment 31: preferences like these _are_ important,
because they deal with the question of "how do you browse?" 
Which really is the only really relevant question we can be asking our users.

Comment 33

[Hixie (not reading bugmail)]

> Fair point but it would spread out the Type As You Find prefs a little.

I think that summarises the entire point rather well. We want to add more prefs
just because there is room? Please!

The type ahead find prefs, IF ANY, should be placed on an existing pref panel,
possibly at the expense of some existing prefs.

As to what the default should be: we need usability testing, or failing that an
unscientific poll or something, to find out what the most common use cas is.
THAT should be the default. The minority of users which use the other option can
use the prefix character, or, at a pinch, change the prefs.js.

Comment 34

[Alex Bishop]

>> Fair point but it would spread out the Type As You Find prefs a little.
>
> I think that summarises the entire point rather well. We want to add more
> prefs just because there is room? Please!

No, no, no, no, no! I meant that the different Type As You Find prefs would be
located in different dialogues (specifically, Mozilla's own Preferences dialogue
and in the OS's own sounds pref dialogue).

If I wanted to advocate adding more prefs just to fill up space, I'd be
inventing new options for the History and Downloads categories. ;-)

Comment 35

[Hixie (not reading bugmail)]

Well, no, it wouldn't be spread out: As far as I can tell there should only be
one pref, and it would be along with all the other sound-scheme prefs for the
entire system. When you want to change sounds you typically want to change just
sounds, not sounds and the default, etc. Just because prefs are used close
together in the code does not mean they belong together in the UI.

Comment 36

[Daniel Veditz [:dveditz]]

Comment on attachment 111122 [details] [diff] [review]
Modified with sgehani's feedback on IM

I mentioned a license change to one of the .xul files on IM, and I want jag's
r= for the radio.xml change. With that sr=dveditz

Comment 37

[jag (Peter Annema)]

Comment on attachment 111122 [details] [diff] [review]
Modified with sgehani's feedback on IM

r=jag on the radio.xml changes

Comment 38

[Aaron Leventhal]

fixed

Comment 39

[Hixie (not reading bugmail)]

Congratulations on completely ignoring my comments and making Mozilla and even
more complicated, hard to use, visually bloated mess than it was before.

I'm glad to know you care about our users.

And that goes to jag and dveditz too, who really should have known better than
to approve of this without addressing the concerns given above.

Comment 40

[James Graham]

There is very little that is more irritating for an application to do than set
up an OS-level preference for a application specific function. /In theory/ it
sounds good having all the sound preferences for all applications together, but
in practice it will lead users to believe that there is no way of disabling the
(annoying) sound. Certianly in other applications that add preferences to
completley seperate parts of the system, I don't realise the preferences exist
until I happen to use that dialog / whatever for a different purpose. Typically
I then forget again.

Unless of course you mean hooking up to some general OS exclaimation sound,
which might indeed be better.

This isn't to say that I agree with all of the UI here, but then I think the
whole prefs panel needs a ground up redesign.

OTOH no-one cares what I think, so sorry for the spam.

Comment 41

[sairuh (rarely reading bugmail)]

vrfy'd fixed with recent comm trunk bits on mac 10.2.3, win2k and linux rh7.2/rh8.0.

Comment 42

[Boris Zbarsky [:bzbarsky]]

As a note, the patch is incorrect in that it does not properly keep track of the
pref values when pref panels are switched.  See bug 193966 and bug 194412