Closed Bug 169489 Opened 22 years ago Closed 22 years ago

What Type Ahead and tabbing nav prefs should be exposed?

Categories

(SeaMonkey :: Find In Page, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: aaronlev, Assigned: aaronlev)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 4 obsolete files)

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?
Blocks: isearch
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?
*** Bug 169490 has been marked as a duplicate of this bug. ***
Right, that was an accidental dup. Just to clarify, I wasn't suggesting the actual wording - just what stuff we'd want to expose.
Blocks: 169045
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
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.
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.
Depends on: 175807
What about a (hidden?) pref about the highlight color?
Yes, the hidden pref for highlight color is listed in the typeaheadfind docs: http://www.mozilla.org/projects/ui/accessibility/typeaheadfind.html
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.
Depends on: 176296
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 ;^)
(*) SmARt caSe sensitive ( ) Always case sensitive ( ) Always case in-sensitive
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.
Depends on: 185489
No longer depends on: 175807
Attached image Screenshot of pref panel (obsolete) —
Attachment #110051 - Flags: superreview?(hewitt)
Attachment #110051 - Flags: review?(sgehani)
Attachment #110052 - Attachment is obsolete: true
Attachment #110051 - Attachment is obsolete: true
Attached image New improved screenshot
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!
Attachment #110425 - Flags: superreview?(hewitt)
Attachment #110425 - Flags: review?(sgehani)
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 '
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.
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.
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 :)
Component: Keyboard: Navigation → Keyboard: Find as you Type
Comment on attachment 110424 [details] New improved screenshot HAHAHAHA! This is a joke right?
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.
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".
Attachment #110425 - Attachment is obsolete: true
Attachment #110425 - Flags: superreview?(hewitt)
Attachment #110425 - Flags: review?(sgehani)
Attachment #110549 - Flags: superreview?(hewitt)
Attachment #110549 - Flags: review?(sgehani)
Depends on: 187508
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.
No longer depends on: 187508
Depends on: 187508
Keywords: nsbeta1
*** Bug 170871 has been marked as a duplicate of this bug. ***
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.
Attachment #110549 - Flags: superreview?(hewitt) → superreview?(jaggernaut)
Attachment #110051 - Flags: superreview?(hewitt)
Attachment #110051 - Flags: review?(sgehani)
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.
Attachment #110549 - Attachment is obsolete: true
Attachment #110549 - Flags: superreview?(jaggernaut)
Attachment #110549 - Flags: review?(sgehani)
Attachment #111122 - Flags: superreview?(jaggernaut)
Attachment #111122 - Flags: review?(sgehani)
Attachment #111122 - Flags: review?(sgehani) → review+
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.
> 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.
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.
> 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.
Summary: What Type Ahead prefs should be exposed (if any)? → What Type Ahead and tabbing nav prefs should be exposed?
>> 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. ;-)
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 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
Attachment #111122 - Flags: superreview?(jaggernaut)
Attachment #111122 - Flags: superreview+
Attachment #111122 - Flags: review?(jaggernaut)
Attachment #111122 - Flags: review+
Comment on attachment 111122 [details] [diff] [review] Modified with sgehani's feedback on IM r=jag on the radio.xml changes
Attachment #111122 - Flags: review?(jaggernaut) → review+
fixed
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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.
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.
vrfy'd fixed with recent comm trunk bits on mac 10.2.3, win2k and linux rh7.2/rh8.0.
Status: RESOLVED → VERIFIED
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
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: