FastFind: A toolbar merging the find dialog and type-ahead-find

VERIFIED DUPLICATE of bug 250231

Status

()

Firefox
Toolbars and Customization
--
enhancement
VERIFIED DUPLICATE of bug 250231
14 years ago
7 years ago

People

(Reporter: dbaron, Assigned: Ben Goodger (use ben at mozilla dot org for email))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

This proposal came from a discussion a bunch of us (asa, ben, brendan,
bryner, chofmann, dbaron, mscott) had at the Foundation, but I've filled
in a some additional details that we didn't discuss, but also left a bunch of
questions.  The goal is to combine the efficiency of TAF with the
discoverability of the Find dialog and make the whole thing easier to
use.
                                                                                
The basic proposal is that type-ahead-find would occur in a new toolbar
that would drop down (logically in the style of a Mac OS X sheet, but
visually just the bottommost browser toolbar).  When the toolbar is
shown, it is always the thing in the browser window that has focus --
anything that would cause it to lose focus to anything else in the
browser window other than a menu should cause it to go away.  This
toolbar would show roughly what TAF currently shows in the status bar,
along with some buttons (probably with hotkey labels, although that
seems a bit awkward).  Regular TAF (the no-"/" version) could continue
to exist for links only as an accessibility feature.
                                                                                
This toolbar would appear, with the textfield blank, and take focus,
when any of the following things occur:
 * The user presses "/" (perhaps to be discontinued after a bit)
 * The user presses Modifier-F (Modifier == Appropriate platform modifier)
 * The user selects Edit | Find in this page...
                                                                                
It would appear, with the textfield filled in with the previous
search and simultaneously find the next occurence of the previous
search, when any of the following things occur:
 * The user presses Modifier-G.
 * The user selects Edit | Find again
(ISSUE: Is this really what we want "Find again" to do?  Do we still
want the menuitem?)
                                                                                
While the toolbar is shown and contains text (when it is shown, it is
always the thing in the browser window with focus), any of the following
will also cause a "Find Again":
 * The user presses Modifier-G.
 * The user selects Edit | Find again
 * The user presses Enter for more than the first time (unless we use
   Enter to dismiss the toolbar).
 
As the user types in the toolbar, the text would appear in the toolbar's
text field and roughly the current typeahead find behavior would occur
in the browser, highlighting the first occurrence of the matched text as
a secondary selection.  However, characters typed that do not match
should appear in the toolbar (unlike now), along with a beep indicating
there is no match (as now).  This allows the user to delete typos
without becoming confused.
 
  Future enhancement (hard): highlight the matching part of the text
  typed in the FastFind toolbar's text input (but don't highlight the
  non-matching characters that we would, in this proposal, allow the
  user to type).
 
  Question: Should TAF's concept of selection be merged with the real
  selection?  That might be a little less confusing for users, but it
  actually doesn't seem all that useful and might get in the way.
 
  Future enhancement (hard): Highlight all occurrences of the string (in
  a different highlight color) once the user stops typing for a certain
  interval or presses Enter (unless we use Enter to dismiss the toolbar)
 
When the user presses "Esc" or clicks on the page, the toolbar goes away,
destroying the selection.
 
  Question:  Or would there be an advantage to have two different ways of
  making it go away?  I doubt the advantage would outweight the confusion,
  at least for the ways I can think of.  (Current TAF uses "Enter" to mean
  "go away but make the TAF selection the real selection".  However, I'd
  prefer it to mean "I'm done typing" and then "Find again", as above.)
 
  Question:  If the user starts typing after pressing Enter, should the
  typing replace or append to the current text being searched?
 
Where should the find start?  Ideally, until the user uses the "Find
Next" feature, the search should highlight (and, if needed, move the
viewport to) the the first occurrence of the text whose location is
below the top of the viewport.  (Note that this might require restoring
the original viewport position, e.g., if user enters "abcdef" and
there's text "abc" in the sidebar, below the viewport, but text "abcdef"
in the main part of the page (later in the content tree).  Scrolling to
see the "abc" shouldn't put the "abcdef" out of range because it's above
the new top of the viewport.)

Comment 1

14 years ago
Great. I'm all for merging the two kinds of find and making FAYT more discoverable.

1. The F3 key is also a way to "find next" on some platforms.

2. The Enter key currently means follow the current link. I would only want
Enter to mean "find next" if FAYT for text was being used, as opposed to FAYT
for links.

3. Would the toolbar show up for FAYT for links?

4. If we get rid of the "find in page" dialog we should make sure the important
features it supports are available in FAYT. Currently find in page is still a
useful compliment to find as you type, because:
- you can paste into it. It would be great if paste worked with FAYT.
- you can do a case sensitive search. We have a case sensitive search checkbox
in the toolbar, or base it on when the user types mixed-case text.
- you can turn wrap around off. Maybe not so important.
- you can search textfields and textarea. We had turned this off for FAYT
because the green selection wasn't working and no one had the time to fix it.
Otherwise it just had a caret so it looked like data entry was happening.

5. FAYT was originally designed as an accessibility feature and putting in some
of these great new ideas for mainstream users may cause some problems, perhaps
for screen readers. Let's remember FAYT's roots as we do this and not make find
any less accessible than it is now, if anything improve it. 
- The current "find in page" dialog is totally accessible with screen readers.
We'd have to test to make sure the new design's putting the focus in this
toolbar, and highlighting the correct part of the patch didn't cause any
funkiness with screen readers. 
- Screen magnifiers normally jump to the area of the screen where the selection
goes. However, now they will stay at the toolbar near the bottom of the screen
rather than showing the user what they've found. That's not a good thing. The
only ways I can think of fixing this problem is to have the toolbar be something
that can be turned off, or to hack in the screen magnifier to ignore the
toolbar's caret/focus.

>   Question: Should TAF's concept of selection be merged with the real
>   selection?  That might be a little less confusing for users, but it
> actually doesn't seem all that useful and might get in the way.
It does use the real selection now, we just color it green when FAYT is active.

>  Future enhancement (hard): Highlight all occurrences of the string (in
>  a different highlight color) once the user stops typing for a certain
>  interval or presses Enter (unless we use Enter to dismiss the toolbar)
This would be really useful and a killer feature that people would notice in
reviews.
Note that this can be optimized by doing a couple of things. First, don't do it
if they've just typed a single character or if there are more than 200 matches.
Second, can we do the visible area of the screen first, then the rest of the doc
as a background task? This will give the user the feeling that it happened
instantly.

Comment 2

14 years ago
I like this idea.

"Any of the following will also cause a 'Find Again': ... The user presses Enter
for more than the first time."

So the first time someone hits Enter, nothing will happen?  That doesn't sound
good for discoverability.

It's going to be tricky to decide what Enter should do.  It could follow a found
link (like Esc+Enter), stop Find (like Esc), or act as Find Again (like Ctrl+G).
 I'd prefer if Enter's behavior did not change based on whether you're
restricting Find to links or searching through all text.

"When the user presses 'Esc' or clicks on the page, the toolbar goes away,
destroying the selection."

I think it would be better if Esc left the text selected, like Esc in the
current Find dialog does.  Leaving the text selected would make it clearer that
you can tab from it to nearby links or form controls, press Ctrl+G to Find
Again, etc.

Comment 3

14 years ago

*** This bug has been marked as a duplicate of 250231 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED

Updated

12 years ago
QA Contact: bugzilla → toolbars
You need to log in before you can comment on or make changes to this bug.