Find bar dismissal
Peter Kasting
currently have with the find bar and how it is dismissed. I've filed
bug 337192 ( https://bugzilla.mozilla.org/show_bug.cgi?id=337192 )
on implementing the results of this. (Changing things here is easy as
I've been working with this code a lot recently and know where I need to
go.)
Specifically, ctrl-f invocation of the find bar doesn't dismiss the bar
the same way / invocation does. We don't set an auto-dismiss timer; we
don't dismiss when users click in the page; we don't dismiss when users
hit TAB after a successful search. (Note that I'm not saying we don't
dismiss "when focus changes"; the existing code is very explicit about
how it deal with different clicks/keystrokes, so I'm enumerating exactly
the cases I'm concerned with here.)
To me,
(1) Dismissing the find bar when users click in the page seems like a
no-brainer. I don't see why
we explicitly don't do it for the ctrl-f case now, and I think that
should be made consistent among all three find modes.
(2) Dismissing the find bar when users click tab after a successful
search seems like a good idea for consistency's sake. In / or ' mode,
the find bar will treat tab/shift-tab as requests to dismiss the find
bar and then move focus one element forward or backward from the current
search result. In ctrl-f mode, hitting tab just moves focus to whatever
is "next" after the find input field, which is NOT the next control on
the find bar (most of which are not in the tab order), but is instead
the "Match case" button. This behavior doesn't seem particularly
intuitive. (Note: this is also the behavior in / or ' mode, if there is
NOT a successful search.) If, for some accessibility reason, we believe
that tab should navigate through the find bar controls instead of
dismissing the bar, then the other controls on the bar should be able to
be tabbed to.
(3) Auto-dismissing the find bar also seems useful for the sake of
consistency, "I've stopped searching, why is that dumb bar still there",
"the bar lost focus and escape won't close it", etc. To me this is the
most arguable point of the three. brettw suggests that perhaps
autodismissal on a longer timeout would make sense here; / and ' use
five second timeouts, perhaps this could use fifteen (so it would be
unlikely to trigger except in the
you-really-didn't-want-to-use-the-bar-anymore case). If this is a
better idea than five seconds, it might be worth considering whether to
move the other two modes to the same timeout interval as well.
The motivation behind all these is the amazingly irritating tendency for
the find bar to get "stuck" open when you didn't want it to. This is
generally caused by using ctrl-f to find, then clicking on the page.
Since there's no auto-dismiss timeout, the bar won't go away until I ask
it to, and since it no longer has focus, escape doesn't work. Points
(1) and (3) above are the key points to fix in this use case. Point (2)
is more of a consistency-with-other-find-modes point. (There are
numerous tiny ways that / and ctrl-f differ besides these, which is very
confusing since there's no obvious indicator of this to users. I'm not
sure all of these can or should be fixed, but some seem silly.)
PK
Gijs Kruitbosch ("Hannibal")
> To me,
> (1) Dismissing the find bar when users click in the page seems like a
> no-brainer. I don't see why
> we explicitly don't do it for the ctrl-f case now, and I think that
> should be made consistent among all three find modes.
I would rather like middle-clicking links and interacting with AJAX on
the page to not close the find bar I opened (current behaviour). I
opened that bar for a reason, not to have it go away the moment I make a
wrong move.
> (2) Dismissing the find bar when users click tab after a successful
> search seems like a good idea for consistency's sake. In / or ' mode,
> the find bar will treat tab/shift-tab as requests to dismiss the find
> bar and then move focus one element forward or backward from the current
> search result. In ctrl-f mode, hitting tab just moves focus to whatever
> is "next" after the find input field, which is NOT the next control on
> the find bar (most of which are not in the tab order), but is instead
> the "Match case" button. This behavior doesn't seem particularly
> intuitive. (Note: this is also the behavior in / or ' mode, if there is
> NOT a successful search.) If, for some accessibility reason, we believe
> that tab should navigate through the find bar controls instead of
> dismissing the bar, then the other controls on the bar should be able to
> be tabbed to.
That seems reasonable to me.
> (3) Auto-dismissing the find bar also seems useful for the sake of
> consistency, "I've stopped searching, why is that dumb bar still there",
> "the bar lost focus and escape won't close it", etc. To me this is the
> most arguable point of the three. brettw suggests that perhaps
> autodismissal on a longer timeout would make sense here; / and ' use
> five second timeouts, perhaps this could use fifteen (so it would be
> unlikely to trigger except in the
> you-really-didn't-want-to-use-the-bar-anymore case). If this is a
> better idea than five seconds, it might be worth considering whether to
> move the other two modes to the same timeout interval as well.
Please don't! This is even worse than making it go away on clicking.
"Hey, I wanted to search for something, why is the Find bar not there?"
is just as valid a concern as the one you mentioned. If you do this,
it'll make it impossible, for example, to scroll through and read some
stuff while keeping the bar open (if you don't implement (1) - if you
did then that'd only make this case worse).
Lastly, I personally feel the bug you filed should be severity:
enhancement, since I don't see why the current perceived 'inconsistency'
is a 'bug' as such. I also vote for WONTFIX on (1) and (3) above, but
that decision is not up to me.
Also, my argument for the 'inconsistency' is that if you use / or ',
you're doing it to quickly find something and then continue browsing. If
you use Ctrl+F (is a 'real' shortcut and therefore, to me anyway,
indicates a stronger purpose from the user if it's used) you want to
search the page (carefully), maybe for multiple things.
You asked for opinions, so I'm hoping I gave mine this way, without
sounding too harsh.
-- Gijs
Peter Kasting
> I would rather like middle-clicking links and interacting with AJAX on
> the page to not close the find bar I opened (current behaviour). I
> opened that bar for a reason, not to have it go away the moment I make
> a wrong move.
same thing. I'm trying to distinguish the various possible use cases
here so I can get a good idea of why this would bother you. In the case
where you're intentionally interacting with the page, do you frequently
intermix uses of the find bar with clicking on the page in such a way
that the bar disappearing is a hassle/annoyance? What sort of scenario
is this? And is the problem with the bar disappearing that you actually
needed to use it more, or that it becomes unclear that ctrl-g will still
search for more matches?
> "Hey, I wanted to search for something, why is the Find bar not
> there?" is just as valid a concern as the one you mentioned.
Here is why I don't agree: you can ALWAYS get the find bar up, wherever
you are, with ctrl-f. If it disappears a single keycombo brings it
back. However, if the find bar is up and you want it to go away, it is
NOT always the case that a single keycombo can dismiss the bar. In the
cases I'm trying to "fix" in particular this isn't the case. If hitting
escape from my page always dismissed the find bar no matter who has
focus, then I wouldn't think these annoyances were so large, but it
doesn't, and I'm not convinced it should either. I suppose that's an
alternate proposition people can discuss if someone thinks it's a better
fix.
In short, bringing the find bar back when it goes away is much easier
than making it go away when you don't want it there, AND find still
works even when the bar is invisible. So it seems clear that if we
don't have compelling use cases that mandate a certain behavior, we
should err on the side of dismissing the bar. However, I'm willing to
accept that such use cases exist, which is why I'm asking for more detail :)
PK
scratch
> Gijs Kruitbosch ("Hannibal") wrote:
>> I would rather like middle-clicking links and interacting with AJAX on
>> the page to not close the find bar I opened (current behaviour). I
>> opened that bar for a reason, not to have it go away the moment I make
>> a wrong move.
> I'm not sure "interacting with page" and "made a wrong move" are the
> same thing. I'm trying to distinguish the various possible use cases
> here so I can get a good idea of why this would bother you. In the case
> where you're intentionally interacting with the page, do you frequently
> intermix uses of the find bar with clicking on the page in such a way
> that the bar disappearing is a hassle/annoyance? What sort of scenario
> is this? And is the problem with the bar disappearing that you actually
> needed to use it more, or that it becomes unclear that ctrl-g will still
> search for more matches?
many times i will do a search (using type-ahead find), scroll a bit to
read text following the match, determine it's not what i was looking
for, go to click "next match" since my hand is now on the mouse from
scrolling, and find that the find bar has auto-dismissed itself. this
is a major annoyance.
>> "Hey, I wanted to search for something, why is the Find bar not
>> there?" is just as valid a concern as the one you mentioned.
>
> Here is why I don't agree: you can ALWAYS get the find bar up, wherever
> you are, with ctrl-f. If it disappears a single keycombo brings it
> back. However, if the find bar is up and you want it to go away, it is
> NOT always the case that a single keycombo can dismiss the bar. In the
> cases I'm trying to "fix" in particular this isn't the case. If hitting
> escape from my page always dismissed the find bar no matter who has
> focus, then I wouldn't think these annoyances were so large, but it
> doesn't, and I'm not convinced it should either. I suppose that's an
> alternate proposition people can discuss if someone thinks it's a better
> fix.
but having the find bar there when you don't specifically want it isn't
a usability problem nor an annoyance. not having the find bar when you
want it is both.
> In short, bringing the find bar back when it goes away is much easier
> than making it go away when you don't want it there, AND find still
> works even when the bar is invisible. So it seems clear that if we
> don't have compelling use cases that mandate a certain behavior, we
> should err on the side of dismissing the bar. However, I'm willing to
> accept that such use cases exist, which is why I'm asking for more detail :)
it may be much easier to bring it back than to dismiss it, but it's more
important that it be there when you want it than it not be there when
you don't want it. i think you are certainly erring on the wrong side.
-scratch
Mike Beltzner
> (1) Dismissing the find bar when users click in the page seems like a
> no-brainer. I don't see why
> we explicitly don't do it for the ctrl-f case now, and I think that
> should be made consistent among all three find modes.
I don't know if it's so much of a no-brainer, actually. For FAYT, it
makes sense, since that's an inline action looking to jump your cursor
to a spot and/or quickly detect the presence (or absence) of a string
in the page. The Find Bar, however, is a UI layer which is requested
by the user.
The question is: what are the use cases for having the find bar there?
By my estimation, and listed in expected frequency ..:
C1: User is looking for a term on a single page.
C2: User is looking for a term on a set of pages.*
C3: User is looking for many terms on a single page.
C4: User is looking for many terms on a set of pages.*
(* this could be across several tabs, or within a single tab)
C1 and C3 are the open-and-shut case that your auto-dismissal
heuristics seem to be optimizing for, where the user is just looking
for a single term on the page and wants to go from there. But what if
the user is trying to find something and doesn't know the exact page
it's on? That user might surf around, and leave the Find Bar open.
I know that the Find Bar is easily recalled using Accel-F, but if the
user didn't *ask* for it to be removed, and if we can't be absolutely
sure that they *want* it to be removed, then removing it will be more
annoying than not removing it (especially since it's quite innocuous).
Consider:
- press Accel-F
- enter find term
- yay, you found it, continue surfing
- oh, my find bar still there
- click to close find bar
vs.
- press Accel-F
- enter find term
- poop, not there
- click link to a different page
- hey, where'd the search bar go?
- press Accel-F
In the first case, the UI responded to user action. In the second, the
UI misinterpreted a user action to mean "I'm done finding" when
really, that user wasn't at all done.
All in all, I think it's *more* annoying to continually have to press
Accel-F to get the Find Bar back unless I've told it to go away in the
first place. I'd rather be wrong by under-interpreting user actions
than be wrong by over-interpreting them.
> NOT a successful search.) If, for some accessibility reason, we believe
> that tab should navigate through the find bar controls instead of
> dismissing the bar, then the other controls on the bar should be able to
> be tabbed to.
Yes, we believe that TAB navigation should cycle through the find bar
controls for accessibility reasons, so this is what we should be
doing. Using tab to move between search results confuses that
metaphor, and makes it hard for users with screen readers to
understand what TAB will do.
> (3) Auto-dismissing the find bar also seems useful for the sake of
> consistency, "I've stopped searching, why is that dumb bar still there",
> "the bar lost focus and escape won't close it", etc. To me this is the
> most arguable point of the three. brettw suggests that perhaps
And argue I shall! Changing the UI in the absence of any direct user
action is always a tricky game, since it requires a thorough
understanding of all use cases and less tolerance for edge cases. The
maxim goes that the user owns the screen, and the application is just
there by invitation. Auto dismissing after some timeout would go
against this maxim, taking something away without giving the user any
idea as to why it vanished.
> The motivation behind all these is the amazingly irritating tendency for
> the find bar to get "stuck" open when you didn't want it to. This is
Is this really amazingly irritating? It's a little bar at the bottom
of the page. I'm not sure that this is as widespread a problem as you
seem to think it is, especially since it was a direct user action that
revealed the bar in the first place.
Would a keyboard shortcut to hide it again be enough here?
cheers,
mike
--
/ mike beltzner / user experience lead / mozilla corporation /
Jeff Schiller
"amazingly irritating".
In those situations where the Find bar is up and pressing Escape
doesn't hide it, I simply press ctrl+f or / again to refocus it and
then press Escape. I haven't come across a scenario where this doesn't
work...
Jeff Schiller
Find bar gone. Press ctrl+f and then click in the page - Find bar
stays.
I actually think things should work consistently in the ctrl+f way, not
in the / or ' way. That is, only dismiss the bar when I click the 'x'
or I press Escape with the Find bar in focus.
Brett Wilson
for '/' vs. Ctrl+F.
This leads people to think that it's broken, and is "amazingly
irritating". I thought it was just buggy because it didn't always go
away. I have heard people at work also complain that their find bar is
broken because it doesn't go away. Now I know it's because I used Ctrl+F.
The problem with not going away is that we've given the user the
expectation that it does go away. We need to make this consistent. Even
advanced users like me are confused by the current behavior.
After thinking about it, the least wrong thing to do for most people is
to always keep it up. I wonder if it's worth a little button on the far
right of the find bar that causes it to auto-hide (defaulted to off). I
would use this option, I prefer my bar to auto-hide.
Brett
Peter Kasting
I encourage anyone interested in this to play around with the patch on
bug 337192 and see how it feels to them. Just on the basis of that
patch, I'm already inclined to remove/lengthen the auto-dismiss timeout
in ctrl-f mode (probably remove).
Mike Beltzner wrote:
> For FAYT, it
> makes sense, since that's an inline action looking to jump your cursor
> to a spot and/or quickly detect the presence (or absence) of a string
> in the page. The Find Bar, however, is a UI layer which is requested
> by the user.
Perhaps this is part of my problem. Mentally, I want the / behavior all
the time. I interpret the find bar as a way to hook up ctrl-f to the /
behavior, and I randomly intermix the two shortcut keys to start
finding, depending on what other program I'm coming from and what
mechanic it uses (/ for FAYT in "less", and ctrl-f for FAYT in my text
editor). So the inconsistency between the two drives me crazy. This is
almost certainly not the case for typical users.
I do suspect that there are users of / who occasionally hit ctrl-f and
meant it to act like /. I doubt there are many folks the other way
(users of ctrl-f who hit / and meant it to act like ctrl-f). ctrl-f
seems like the accessible shortcut for common users; / is a "power-user"
function.
My whole problem might go away if there was a visual indicator of any
kind of modality. I can't remember whether I started the bar with / or
ctrl-f because they look exactly the same, but they don't behave the same.
> The question is: what are the use cases for having the find bar there?
> By my estimation, and listed in expected frequency ..:
>
> C1: User is looking for a term on a single page.
> C2: User is looking for a term on a set of pages.*
> C3: User is looking for many terms on a single page.
> C4: User is looking for many terms on a set of pages.*
>
> (* this could be across several tabs, or within a single tab)
>
> C1 and C3 are the open-and-shut case that your auto-dismissal
> heuristics seem to be optimizing for, where the user is just looking
> for a single term on the page and wants to go from there. But what if
> the user is trying to find something and doesn't know the exact page
> it's on? That user might surf around, and leave the Find Bar open.
This is a good point. I hadn't really considered the C2/C4 use cases.
I don't tend to have multiple pages open that I would want to search
across (because I either know what they are, or I check what they are
before finding). So in my personal use, C1/C3 would have been the
primary find bar usaages. If C2 is a common use case, that's certainly
worth keeping in mind.
> removing it will be more
> annoying than not removing it (especially since it's quite innocuous).
I suppose I should explain my extreme animosity toward having the find
bar around when I don't want to use it, since several people have either
asserted it's harmless or questioned why it irritates me.
Least importantly, the find bar takes up space in my browser, which I'm
obsessive enough about to have collapsed every browser control into a
single small bar at the top.
More importantly, having the find bar onscreen is part of my mental
context that "I'm finding right now". Mentally, "finding" and
"browsing/reading/doing something else" are very different actions for
me: I "find" to get to the point on the page I want to interact with,
then I interact with it. Having the find bar dismiss indicates that the
browser and I are in sync about what I'm doing. Having the find bar NOT
dismiss is distracting and confusing to me, because I can't remember if
I'm done finding, or if I meant to keep looking for something else.
Most importantly, when I finally realize I don't care about the bar and
hit escape, it won't go away. Tied in with my second point, finding is
something of a "modal" function to me, even if the dialog is no longer
modal. I expect the dialog to have focus as long as it's visible. When
I give focus to something else, that's my conscious desire to dismiss
the bar. When I see it still present, my brain expects it to be
focused. Hitting "escape" should therefore dismiss it, but it doesn't.
The obvious workaround someone suggested is to simply hit ctrl-f again
to focus the bar, THEN escape. But I never think of this, because
ctrl-f means "I want to start finding", not "I want to focus the find
bar". In this case I explicitly DON'T want to start finding, I wanted
to STOP finding and the browser didn't obey me.
For these reasons, probably the ideal solution _for me_ would be that
the find bar ALWAYS catches the escape key and dismisses. What I don't
know is whether that would break browser interaction in some other way.
My gut feeling is that it does. And besides, the solution _for me_ was
that when I click on the page I always intend that as a desire for the
find bar to disappear, so clearly optimizing for me is not necessarily
correct :)
> Consider:
>
> - press Accel-F
> - enter find term
> - yay, you found it, continue surfing
> - oh, my find bar still there
> - click to close find bar
It's the "click" part of this that's annoying.
> All in all, I think it's *more* annoying to continually have to press
> Accel-F to get the Find Bar back unless I've told it to go away in the
> first place. I'd rather be wrong by under-interpreting user actions
> than be wrong by over-interpreting them.
This seems like a correct statement as long as use case C2 (trying to
find across multiple pages) is actually common, and therefore people
WOULD have to continually get the bar back. Do we have any data about
how people use find and whether they have any kinds of problems with it
right now?
> Yes, we believe that TAB navigation should cycle through the find bar
> controls for accessibility reasons, so this is what we should be
> doing. Using tab to move between search results confuses that
> metaphor, and makes it hard for users with screen readers to
> understand what TAB will do.
That makes sense to me. I don't understand why only the "Match Case"
control on the find bar can be tabbed to, not the other buttons. I
would be perfectly happy with putting those in the tab order.
One irritation of tabbing to these is that, as-is, if your focus is on
the checkbox, hitting escape doesn't close the find bar. Changing that
is one fix my aforementioned patch makes that maybe we really can agree on?
Once again, thanks very much for your responses. I remain unconvinced
on the click-in-page issue, but I'd be happy to retract my desire for
auto-dismissal and modify my request for tab-behavior-consistency to
"all the find bar controls should be in the tab order, assuming hitting
escape on any still closes the find bar". Feedback on the "if Find is
up, escape anywhere in the page dismisses Find" idea welcome.
PK
Peter Kasting
> many times i will do a search (using type-ahead find), scroll a bit to
> read text following the match, determine it's not what i was looking
> for, go to click "next match" since my hand is now on the mouse from
> scrolling, and find that the find bar has auto-dismissed itself. this
> is a major annoyance.
It seems like in this case you're asking for / mode to behave like
ctrl-f mode. Why not just turn off
accessibility.typeaheadfind.enabletimeout in about:config?
Or perhaps we should make enabletimeout affect all modes (as I suggested
before) but disable it by default, so as not to dismiss the UI without
explicit user action? This seems like a reasonable idea, although I
wonder if all the / users (like me) would howl.
PK
Peter Kasting
though exposing the enabletimeout pref via UI was something I hadn't
thought of. I'm not sure how I'd make this intuitive and usable without
being irritating or confusing, but it's worth considering.
I think your summary perfectly expresses why the current behavior
frustrates me. What it DOESN'T cover is how we make the
click-to-dismiss behavior consistent, because once again, we've given at
least some people the expectation that clicking in the page DOES dismiss
the bar. Should we also default to "click in page doesn't dismiss" and
enable clicking to dismiss via the same UI that the auto-hide stuff
uses? I certainly wish it were consistent either way.
PK
Jeff Schiller
Peter Kasting wrote:
> More importantly, having the find bar onscreen is part of my mental
> context that "I'm finding right now". Mentally, "finding" and
> "browsing/reading/doing something else" are very different actions for
> me: I "find" to get to the point on the page I want to interact with,
> then I interact with it. Having the find bar dismiss indicates that the
> browser and I are in sync about what I'm doing. Having the find bar NOT
> dismiss is distracting and confusing to me, because I can't remember if
> I'm done finding, or if I meant to keep looking for something else.
First, let me state that I get what you mean. Obviously this is
because you've been trained to think this way. You obviously don't
have a problem with the Address or Web Search bar, whose purposes are
different than "reading the page". The presence of those bars in the
window don't bother you in the same way. Can't you "change your mind"
about the Find Bar? ;)
> The obvious workaround someone suggested is to simply hit ctrl-f again
> to focus the bar, THEN escape. But I never think of this, because
> ctrl-f means "I want to start finding", not "I want to focus the find
> bar".
Actually, from my point of view:
- ctrl+L/alt+D means "focus the location bar"
- ctrl+K means "focus the web search bar"
- ctrl+F means "focus the find bar"
These are "low-level primitives" in my head. i.e. standard keyboard
shortcut means of focusing a control in a window in order to do
something at a higher level. There's another layer of processing that
goes on in my head that is automatic because I've used computers so
long.
So "I want to close the Find Bar" is processed in my head as:
if(Find Bar Not Focused) {
Focus Find Bar => "Press ctrl+F"
}
Close Find Bar => "Press Escape"
I process it this way because in most cases I'd rather use the keyboard
then have to move my hand away and interact with the mouse. But other
people may translate the "I want to close the Find Bar" differently:
- Move mouse pointer over red 'x' on Find Bar.
- Press the left mouse button.
Let me just state that I don't think the current Find Bar functionality
is superior to the proposal, it's just how my brain adapted to the way
the software works. It doesn't mean I can't change this behavior if
the code changes, it's just get harder as I age ;) For instance,
moving the Feed button from the bottom right to the Address Bar caused
me some pain for the first week or two...
Peter Kasting
> You obviously don't
> have a problem with the Address or Web Search bar, whose purposes are
> different than "reading the page". The presence of those bars in the
> window don't bother you in the same way. Can't you "change your mind"
> about the Find Bar? ;)
>
is why the first thing I do when I get a new profile is remove the web
search box and set the keyword.URL to do a standard Google search. Then
the address bar is no longer an address bar but a "go somewhere" bar.
If I type in an address it goes to that address, and if I type in
something else, it tries to help me find where I wanted to go. That is
a long and separate discussion that I'm not prepared to fight right now
:), I mention it merely to indicate that your interpretation of my
motives may not be correct.
From a UI perspective, I would actually probably be OK with the address
bar vanishing and then appearing when I hit a shortcut like ctrl-L
(reminds me somewhat of "fullscreen mode" browsing). The only reason
the current behavior doesn't bother me is because I use that bar so
constantly (not only to type in, but to copy from and to see "where am
I") that having to call it up each time would be somewhat taxing. My
usage of the find bar is not one, but probably two orders of magnitude
less frequent than my use of the address bar. I wonder if "ordinary
users" are much more even or even reversed, because they do things like
navigate to their bookmarked common pages, and surf from page to page
via links, instead of constantly typing in URLs like I do. I kind of
wonder what an auto-hideable address bar would work like... maybe it'd
turn out to be nice (if you could choose to lock it in place, and if
locked open was the default). Then the address bar and find bar would
work very similarly :)
> - ctrl+F means "focus the find bar"
>
> These are "low-level primitives" in my head. i.e. standard keyboard
> shortcut means of focusing a control in a window in order to do
> something at a higher level. There's another layer of processing that
> goes on in my head that is automatic because I've used computers so
> long.
>
Sadly, I use many software programs that don't work this way. As I
mentioned, for example, my text editor of choice uses ctrl-f to begin a
FAYT/incremental search (and ctrl-f again to repeat the search, unlike
Firefox' usage of ctrl-g). Other programs I use use ctrl-f to begin a
modal (old-style) find. In general, most people use ctrl-f to mean
something like "start finding", although that looks different on each
platform. "focus the find bar" is very Firefox-specific.
However, I think all this is getting somewhat off-topic. Brett's post
that our different behavior sets up misleading expectations is more what
I want to get at. I want to set consistent and correct user
expectations of how things work, which is why I titled my bug the way I
did. Even making / work more like ctrl-f (and possibly allowing users
to change what this behavior is) seems better to me than the current
inconsistent sort of behavior. The differing behavior made more sense
when ctrl-f and FAYT were more separate, as the UI was clearly
completely different. The current situation feels more like someone
intended to combine the two but didn't go all the way, or did it
buggily, or something.
PK
scratch
> scratch wrote:
>> many times i will do a search (using type-ahead find), scroll a bit to
>> read text following the match, determine it's not what i was looking
>> for, go to click "next match" since my hand is now on the mouse from
>> scrolling, and find that the find bar has auto-dismissed itself. this
>> is a major annoyance.
>
> It seems like in this case you're asking for / mode to behave like
> ctrl-f mode. Why not just turn off
> accessibility.typeaheadfind.enabletimeout in about:config?
I didn't realize it existed. I will do so now and hopefully it will
help my frustrations.
> Or perhaps we should make enabletimeout affect all modes (as I suggested
> before) but disable it by default, so as not to dismiss the UI without
> explicit user action? This seems like a reasonable idea, although I
> wonder if all the / users (like me) would howl.
Sounds reasonable to me, but as you said, others may complain.
-scratch
scratch
> Actually, the presence of the web search box bothers me very much, which
> is why the first thing I do when I get a new profile is remove the web
> search box and set the keyword.URL to do a standard Google search. Then
> the address bar is no longer an address bar but a "go somewhere" bar.
> If I type in an address it goes to that address, and if I type in
> something else, it tries to help me find where I wanted to go. That is
> a long and separate discussion that I'm not prepared to fight right now
> :), I mention it merely to indicate that your interpretation of my
> motives may not be correct.
I agree with you 100% on this one, as I do the exact same thing, and I
advocate combining the two into one bar.
-scratch
Tuukka Tolvanen
box about this, the reason it didn't get posted yet is, well, it's still
a rant :) Basically:
- both '/ and ctrl-F suck in default behavior at different extremes
- their modes of suckage mean you can't always just use one of them
- ...at which point the inconsistency between the two bites you
A case in point is where you start searching using '/ mode because
ctrl-F is horribly sticky, but while you're reading context to matches
to refine the search, the timer dismissal hits you. Then you have to use
ctrl-F instead of '/ to refine the search because '/ clears the search
term instead of retaining it with select all for type-over like ctrl-F
-- unless you want to re-type the search term, of course. (bug 264651,
bug 297369)
Peter Kasting wrote:
> bug 337192 ( https://bugzilla.mozilla.org/show_bug.cgi?id=337192 )
> (2) Dismissing the find bar when users click tab after a successful
> search seems like a good idea for consistency's sake. In / or ' mode,
> the find bar will treat tab/shift-tab as requests to dismiss the find
> bar and then move focus one element forward or backward from the current
> search result. In ctrl-f mode, hitting tab just moves focus to whatever
> is "next" after the find input field, which is NOT the next control on
> the find bar (most of which are not in the tab order), but is instead
> the "Match case" button. This behavior doesn't seem particularly
> intuitive. (Note: this is also the behavior in / or ' mode, if there is
> NOT a successful search.) If, for some accessibility reason, we believe
> that tab should navigate through the find bar controls instead of
> dismissing the bar, then the other controls on the bar should be able to
> be tabbed to.
This little perversion probably stems from the timer dismissal -- if it
weren't for this tab behavior mod, pressing tab would do a different
thing in '/ mode depending on when you press it, in a fairly short time
span after typing your search.
> (3) Auto-dismissing the find bar also seems useful for the sake of
> consistency, "I've stopped searching, why is that dumb bar still there",
> "the bar lost focus and escape won't close it", etc. To me this is the
> most arguable point of the three. brettw suggests that perhaps
> autodismissal on a longer timeout would make sense here; / and ' use
> five second timeouts, perhaps this could use fifteen (so it would be
> unlikely to trigger except in the
> you-really-didn't-want-to-use-the-bar-anymore case). If this is a
> better idea than five seconds, it might be worth considering whether to
> move the other two modes to the same timeout interval as well.
I think timer dismissal of any length is a bad idea, it makes reading a
bit of search hit context and then refining the search term further a
rather more stressful than necessary race against the clock. On the one
hand, provided the search bar is as easily dismissable as it is in '/
mode currently, I'm unconvinced that timer dismissal ever does the right
thing for anyone to any substantially useful extent. On the other hand,
the less prone the find bar is to dismissal by user action, the more out
of place a dismissal by timer becomes.
't.
Peter Kasting
>> In / or ' mode, the find bar will treat tab/shift-tab as requests to
>> dismiss the find bar and then move focus one element forward or
>> backward from the current search result.
>
> it weren't for this tab behavior mod, pressing tab would do a
> different thing in '/ mode depending on when you press it, in a fairly
> short time span after typing your search.
Actually I believe this stems from the history of FAYT, where there
didn't used to BE a bar with controls. When the bar was added, the
function of tab was not changed so that people used to the old behavior
were not upset. Since that behavior seems to make less sense given the
new controls, it's possible that should be revisited. Perhaps the
number of "old" users of / is now dwarfed by the number of people for
whom the current behavior is confusing or inaccessible.
> I think timer dismissal of any length is a bad idea, it makes reading
> a bit of search hit context and then refining the search term further
> a rather more stressful than necessary race against the clock. On the
> one hand, provided the search bar is as easily dismissable as it is in
> '/ mode currently, I'm unconvinced that timer dismissal ever does the
> right thing for anyone to any substantially useful extent.
It sounds like your suggestion would be that by default there should not
be an autodismiss timer and a click-in-page would dismiss the bar in
both modes.
PK
Mike Connor
On 9-May-06, at 11:23 AM, Brett Wilson wrote:
> I think the problem with the find bar is that it doesn't behave the
> same for '/' vs. Ctrl+F.
I don't know if I believe that this is a problem, especially as it
differs for more than just auto-hide. Take, for example, the
behaviour when hitting enter. / is invoking FAYT, and hitting enter
when you find a link navigates to that link. For Ctrl-F, the
behaviour for Enter is "Find Again" which is expected and consistent
with pretty much every windows app I have ever used, minus the .
(I'll accept that Linux apps are less consistent about how find
invocation/behaviour is broken out, of course, but Linux on the
desktop is bad at that.)
The two shortcuts have different histories, and different use cases.
FAYT (autostart or via /) was added as a navigation tool for a11y,
which is why Enter invokes a link if that is what is found. Ctrl-F
is the find in this page shortcut, soon to work properly across all
text on the page, regardless of whether its in a textarea. If people
are using / as an alternate shortcut for Ctrl+F, they're probably
frequently falling back to Ctrl+F because of where / can't work, and
that's where the confusion would come in.
I rather would disable / by default than start changing the Ctrl+F
defaults, if that's what it came down to, but I don't think that
there is any evidence based on usability studies or acceptance tests
that will support any assertion that this behaviour is creating a
negative experience for the average user. If users are used to / as
a search invocation, I am almost certain that a 30 second blurb on
the support site would make them not only understand, but appreciate
the behaviour differences.
> This leads people to think that it's broken, and is "amazingly
> irritating". I thought it was just buggy because it didn't always
> go away. I have heard people at work also complain that their find
> bar is broken because it doesn't go away. Now I know it's because I
> used Ctrl+F.
>
> The problem with not going away is that we've given the user the
> expectation that it does go away. We need to make this consistent.
> Even advanced users like me are confused by the current behavior.
>
I'm going to challenge this assumption, because it's based on
assuming that users know there are other ways of finding in the page
aside from Ctrl+F. Advanced users like you are probably the majority
of people who have discovered that / invokes a findbar, and use that
behaviour.
> After thinking about it, the least wrong thing to do for most
> people is to always keep it up. I wonder if it's worth a little
> button on the far right of the find bar that causes it to auto-hide
> (defaulted to off). I would use this option, I prefer my bar to
> auto-hide.
I'd rather not add UI to the findbar itself, since I have yet to see
a large amount of feedback about the inconsistency (which makes me
suspicious of any attempts to change the user experience). If
anything, once the difference is better-understood, it can be a
highly useful behaviour, since / can be used for link navigation, and
Ctrl-F can be used for find (regardless of where focus is). That's
how I use the shortcuts, and it is pretty useful, and powerful, to
have it behave that way.
-- Mike
Mike Connor
On 9-May-06, at 5:25 PM, Peter Kasting wrote:
> Jeff Schiller wrote:
>> You obviously don't
>> have a problem with the Address or Web Search bar, whose purposes are
>> different than "reading the page". The presence of those bars in the
>> window don't bother you in the same way. Can't you "change your
>> mind"
>> about the Find Bar? ;)
>>
> Actually, the presence of the web search box bothers me very much,
> which is why the first thing I do when I get a new profile is
> remove the web search box and set the keyword.URL to do a standard
> Google search. Then the address bar is no longer an address bar
> but a "go somewhere" bar. If I type in an address it goes to that
> address, and if I type in something else, it tries to help me find
> where I wanted to go. That is a long and separate discussion that
> I'm not prepared to fight right now :), I mention it merely to
> indicate that your interpretation of my motives may not be correct.
You might as well not fight it. The separate search bar has lowered
the bar to search, and when I talk to end users who use the app, its
consistently something they mention as an important feature to them.
"This is a URL and will behave like this" and "This is not a URL and
will behave like that" is an abstraction that requires the user to
understand what a URL is, and I don't think you can argue
successfully that such a thing is understood widely enough. This is
leaving out how cool the suggest-as-you-type feature is turning out
to be, and the general move from all browsers to push search terms
into equal prominence as the URL bar
> From a UI perspective, I would actually probably be OK with the
> address bar vanishing and then appearing when I hit a shortcut like
> ctrl-L (reminds me somewhat of "fullscreen mode" browsing). The
> only reason the current behavior doesn't bother me is because I use
> that bar so constantly (not only to type in, but to copy from and
> to see "where am I") that having to call it up each time would be
> somewhat taxing. My usage of the find bar is not one, but probably
> two orders of magnitude less frequent than my use of the address
> bar. I wonder if "ordinary users" are much more even or even
> reversed, because they do things like navigate to their bookmarked
> common pages, and surf from page to page via links, instead of
> constantly typing in URLs like I do. I kind of wonder what an auto-
> hideable address bar would work like... maybe it'd turn out to be
> nice (if you could choose to lock it in place, and if locked open
> was the default). Then the address bar and find bar would work
> very similarly :)
You can auto-hide the dock in OS X, and the taskbar in Windows, but
how many users do that and like it? Auto-hide is great for screen
real estate, but it adds complexity to something which isn't by
definition tied to a screen edge (click in a field and type, instead
of open the field, click in it, and type).
> However, I think all this is getting somewhat off-topic. Brett's
> post that our different behavior sets up misleading expectations is
> more what I want to get at. I want to set consistent and correct
> user expectations of how things work, which is why I titled my bug
> the way I did. Even making / work more like ctrl-f (and possibly
> allowing users to change what this behavior is) seems better to me
> than the current inconsistent sort of behavior. The differing
> behavior made more sense when ctrl-f and FAYT were more separate,
> as the UI was clearly completely different. The current situation
> feels more like someone intended to combine the two but didn't go
> all the way, or did it buggily, or something.
There was a long discussion (bugzilla and IRC) about the
inconsistency a while back, early in 2005, and the rough conclusion
was "the difference in function is useful enough to justify the
possible perception of inconsistency." / serves a different purpose
than Ctrl-F from a design perspective, which I find useful coming
from my own Windows-driven background. Is breaking that distinction
better for users than explaining the difference? I remain unconvinced!
-- Mike
Mike Connor
On 9-May-06, at 1:33 PM, Peter Kasting wrote:
> I think your summary perfectly expresses why the current behavior
> frustrates me. What it DOESN'T cover is how we make the click-to-
> dismiss behavior consistent, because once again, we've given at
> least some people the expectation that clicking in the page DOES
> dismiss the bar. Should we also default to "click in page doesn't
> dismiss" and enable clicking to dismiss via the same UI that the
> auto-hide stuff uses? I certainly wish it were consistent either way.
If we do click-to-dismiss, why not go back to a dialog? The entire
point of doing the findbar was to allow the findbar to remain open
but unobtrusive. I certainly end up with it left open a lot of the
time, but it's rarely harmful (I don't really notice it), and often
incredibly useful. If you're highly keyboard-oriented (which from
your arguments thus far, it certainly appears that you are) then its
presence isn't really a win. But that makes you a minority in our
market, since most users surf with a mouse, using the keyboard only
when they need to type something. If I search Google for "ben
goodger goat teleporter" I'll get about 17 million results, but a lot
of those pages have a lot of info on them, and I need to find in the
page to get to what I'm looking for. With click to dismiss, every
time I go back and go to another result, I need to hit Ctrl-F to find
again, or Edit->Find in this Page, instead of just clicking Find
Next. This is part of why we added the find toolbar in the first
place, so that users didn't have to keep invoking the find UI, it was
just there when they needed it. I haven't seen a reason to break
this for the vast majority of users that only use/are aware of Ctrl+F
to find, in all of this thread.
I think I remain totally unconvinced that this UI is either a) a
distraction or b) taking up valuable space that we need to reclaim
aggressively. Try turning off the timeout for / and see, after a
week, whether you notice the findbar hanging around the bottom of the
page, and how much it hurts to have it there? I thought it was in my
way when it first landed, and then I ended up not noticing it after a
while, even on my 12" powerbook I still forget about it. Having two
equally valuable find behaviours, accessible by different shortcuts,
and with subtle but important differences, seems like a big win for
power users. It does represent a bit of a learning/awareness curve,
which I will absolutely admit can have some pointy edges, but is
flattening that curve worth sacrificing the flexibility the current
overlap provides?
-- Mike
Brett Wilson
> I don't know if I believe that this is a problem, especially as it
> differs for more than just auto-hide. Take, for example, the behaviour
> when hitting enter. / is invoking FAYT, and hitting enter when you find
> a link navigates to that link. For Ctrl-F, the behaviour for Enter is
> "Find Again" which is expected and consistent with pretty much every
> windows app I have ever used, minus the . (I'll accept that Linux apps
> are less consistent about how find invocation/behaviour is broken out,
> of course, but Linux on the desktop is bad at that.)
I always press enter after my searches and end up navigating to the
link, which drives me crazy.
> The two shortcuts have different histories, and different use cases.
> FAYT (autostart or via /) was added as a navigation tool for a11y, which
> is why Enter invokes a link if that is what is found. Ctrl-F is the
> find in this page shortcut, soon to work properly across all text on the
> page, regardless of whether its in a textarea. If people are using / as
> an alternate shortcut for Ctrl+F, they're probably frequently falling
> back to Ctrl+F because of where / can't work, and that's where the
> confusion would come in.
The basis of everything you say here depends on the assumption that
people that use '/' know it is different form Ctrl+F. I think this is
wrong. Nobody around me knew this difference until this discussion
started, I didn't know the difference. You can't "fall back" on
something you don't know is different.
If we are trying to support more than one use case, the current approach
has manifestly failed. If we want to continue to support two cases, it
needs to be totally rethought. In the absence of that, unifying Ctrl+F
and '/' is far better than the current failed approach.
> I rather would disable / by default than start changing the Ctrl+F
> defaults, if that's what it came down to, but I don't think that there
> is any evidence based on usability studies or acceptance tests that will
> support any assertion that this behaviour is creating a negative
> experience for the average user. If users are used to / as a search
> invocation, I am almost certain that a 30 second blurb on the support
> site would make them not only understand, but appreciate the behaviour
> differences.
Who reads the support sites? Advanced users especially won't read it. I
would never read it. I would continue to think it's broken.
> I'm going to challenge this assumption, because it's based on assuming
> that users know there are other ways of finding in the page aside from
> Ctrl+F. Advanced users like you are probably the majority of people who
> have discovered that / invokes a findbar, and use that behaviour.
/ looks like it works like Ctrl+F. The people that have discovered it
like me and everybody that sits around me therefore think that it works
the same. If we support two different behaviors, it needs to be OBVIOUS
that they're different, and not have several very subtle differences.
Brett
Tuukka Tolvanen
> Tuukka Tolvanen wrote:
>>> In / or ' mode, the find bar will treat tab/shift-tab as requests to
>>> dismiss the find bar and then move focus one element forward or
>>> backward from the current search result.
>>
>> This little perversion probably stems from the timer dismissal -- if
>> it weren't for this tab behavior mod, pressing tab would do a
>> different thing in '/ mode depending on when you press it, in a fairly
>> short time span after typing your search.
>
> Actually I believe this stems from the history of FAYT, where there
> didn't used to BE a bar with controls. When the bar was added, the
Oh, yeah, that's more accurate :) What I really meant to say was
something along the lines of what would make it a necessary behavior
given current ui, history notwithstanding.
>> I think timer dismissal of any length is a bad idea, it makes reading
>> a bit of search hit context and then refining the search term further
>> a rather more stressful than necessary race against the clock. On the
>> one hand, provided the search bar is as easily dismissable as it is in
>> '/ mode currently, I'm unconvinced that timer dismissal ever does the
>> right thing for anyone to any substantially useful extent.
>
> It sounds like your suggestion would be that by default there should not
> be an autodismiss timer and a click-in-page would dismiss the bar in
> both modes.
I think that would serve me quite nicely, yes. I think in
keyboard-oriented use of the find bar there is no essential
functionality lost by hiding the bar in this way ("Highlight all"
excepted), as find next/prev and focusing the find bar work the same
regardless of whether the bar was visible, so beltzner's C1 through C4
are served ok.
Beltzner's post suggests to me though that more mouse-based users are in
a different situation -- if you navigate after finding and want to apply
e.g. Find Next/Previous or focus the text entry to edit it using the
mouse, having the find bar gone into hiding would be no fun at all. That
seems to call for explicit hiding only.
Perhaps a "pin" sticky toggle of the kind brettw suggested, defaulting
to on, would be reasonable -- there's some precedent for such toggles I
believe, though I'm unsure about the consistency of their semantics with
this case.
One might argue that choosing between / and ctrl-F is the thing to do
rather than to make ctrl-F behavior guifully customizable, but I think
the latter might have more value due to better discoverability, provided
it doesn't complicate the ui too much. Also, the latter reduces
potential change resistance by allowing to leave '/ behavior as-is if
necessary ;)
't.
Peter Kasting
> The basis of everything you say here depends on the assumption that
> people that use '/' know it is different form Ctrl+F. I think this is
> wrong. Nobody around me knew this difference until this discussion
> started, I didn't know the difference. You can't "fall back" on
> something you don't know is different.
>
> If we are trying to support more than one use case, the current
> approach has manifestly failed. If we want to continue to support two
> cases, it needs to be totally rethought. In the absence of that,
> unifying Ctrl+F and '/' is far better than the current failed approach.
>
> like me and everybody that sits around me therefore think that it
> works the same. If we support two different behaviors, it needs to be
> OBVIOUS that they're different, and not have several very subtle
> differences.
like me who DO know the modes are different, I continually don't want
the DISMISSAL to be different (and sometimes I don't want other things
to be different, either). However, I'm not going to get into the
question of what the enter key should do or the other differences
between the modes or other things; I'm just concerned with dismissal.
beltzner and mconnor suggest that not dismissing on delay OR click is
the better thing to do for most users, so let's just do that by
default. We already have prefs to control a lot of this stuff if people
really want their find bar to automatically go away. Let's add one for
click-to-dismiss or else remove that feature entirely, then make these
prefs control all modes of the find bar, not just some. What do people
think of that suggestion? From what I've heard so far I'd predict this
would be largely amenable.
That still leaves the question of whether, when the find bar is up but
not focused, it should grab the escape key and dismiss on that, as I
suggested earlier. If I could get that behavior, I don't think I'd even
need to turn on the click-to-dismiss pref, because I could hit a single
key to make the bar go away if I wanted it to. But that seems possibly
dangerous; I don't know what else listens for the escape key and how
this would interact with other things or confuse user expectations.
If I have time at some point, perhaps I'll modify my patch on the bug to
do the things I've suggested above, so people can play with this behavior.
PK
Brett Wilson
> That still leaves the question of whether, when the find bar is up but
> not focused, it should grab the escape key and dismiss on that, as I
> suggested earlier. If I could get that behavior, I don't think I'd even
> need to turn on the click-to-dismiss pref, because I could hit a single
> key to make the bar go away if I wanted it to. But that seems possibly
> dangerous; I don't know what else listens for the escape key and how
> this would interact with other things or confuse user expectations.
I don't think this would be a good idea. Escape cancels page loading,
so it becomes ambiguous. Even if you REALLY wanted to do this and
could convince other people, it sounds too scary for branch right now.
Brett
Mike Connor
> If we are trying to support more than one use case, the current
> approach has manifestly failed. If we want to continue to support
> two cases, it needs to be totally rethought. In the absence of
> that, unifying Ctrl+F and '/' is far better than the current failed
> approach.
"Tear it down and try something different" is the wrong approach
here, and in 95% of cases. We have learned that the hard way in this
project, and we need to avoid this mindset like the plague. Rewrite
and iterate in place is the fastest path forward, and involves the
least pain on upgrade for new users, because you're starting from the
same place as they are. There are exceptions, but a lack of visual
distinctiveness is not one, IMO.
If a small inconsistency is causing problems for people who have
stumbled across /, and decided to use / instead of Ctrl+F (how do you
adopt a new shortcut if it doesn't work the way you want it to?) then
we need to figure out how to clearly indicate the find mode that is
active. If you are using FAYT, the UI for the findbar can, and
probably should, be visually different (i.e. we could skip the
buttons, since you're using the keyboard to navigate, but that's just
a modification of the original approach).
If visual distinction is not enough to avoid confusion, although the
reasoning seems to be "I can't tell the difference," then we need to
just disable / by default, and enable FAYT behaviour via a pref.
Making / not work like FAYT will break the original intent of the
feature, which was better keyboard navigation, not "add a different
search shortcut."
>> I rather would disable / by default than start changing the Ctrl+F
>> defaults, if that's what it came down to, but I don't think that
>> there is any evidence based on usability studies or acceptance
>> tests that will support any assertion that this behaviour is
>> creating a negative experience for the average user. If users are
>> used to / as a search invocation, I am almost certain that a 30
>> second blurb on the support site would make them not only
>> understand, but appreciate the behaviour differences.
>
> Who reads the support sites? Advanced users especially won't read
> it. I would never read it. I would continue to think it's broken.
Maybe I'm unique in assuming that if two different shortcut actions
work differently, there's a reason and not a glaring bug. I'm
certainly not above checking a support site if something doesn't make
sense, but some people just won't RTFM!
>> I'm going to challenge this assumption, because it's based on
>> assuming that users know there are other ways of finding in the
>> page aside from Ctrl+F. Advanced users like you are probably the
>> majority of people who have discovered that / invokes a findbar,
>> and use that behaviour.
>
> / looks like it works like Ctrl+F. The people that have discovered
> it like me and everybody that sits around me therefore think that
> it works the same. If we support two different behaviors, it needs
> to be OBVIOUS that they're different, and not have several very
> subtle differences.
Right, that's totally different from "scrap this and rethink it from
scratch." That's "make different things look different" which is a
clear way forward. I'm curious about how people discover this
shortcut, and why, but that's not of importance in fixing this part.
-- Mike
Peter Kasting
> Peter Kasting wrote:
>> That still leaves the question of whether, when the find bar is up
>> but not focused, it should grab the escape key and dismiss on that,
>> as I suggested earlier.
>
> so it becomes ambiguous. Even if you REALLY wanted to do this and
> could convince other people, it sounds too scary for branch right now.
I think that's a good enough reason for me to withdraw the request,
unless others think this wouldn't be ambiguous. Consider me to be back
at the "don't dismiss by default, make prefs affect all modes" case.
PK
Mike Connor
For this exact reason, we can't ever do this. If having two keys do
two similar but different functions is this bad, how would one key
for two completely unrelated actions work better? :)
-- Mike
Tuukka Tolvanen
> On 5/8/06, Peter Kasting <pkas...@google.com> wrote:
>> (1) Dismissing the find bar when users click in the page seems like a
> I know that the Find Bar is easily recalled using Accel-F, but if the
> user didn't *ask* for it to be removed, and if we can't be absolutely
> sure that they *want* it to be removed, then removing it will be more
> annoying than not removing it (especially since it's quite innocuous).
> Consider:
>
> - press Accel-F
> - enter find term
> - yay, you found it, continue surfing
> - oh, my find bar still there
> - click to close find bar
Click?! What is that ;)
>> The motivation behind all these is the amazingly irritating tendency for
>> the find bar to get "stuck" open when you didn't want it to. This is
>
> Is this really amazingly irritating? It's a little bar at the bottom
> of the page. I'm not sure that this is as widespread a problem as you
> seem to think it is, especially since it was a direct user action that
> revealed the bar in the first place.
Regardless of the backwardness of having to start another search in
order to be able to esc out the find bar, that's practically speaking
not that complicated to do, and yeah, it's not that big... Perhaps some
of the annoyance with the find bar sticking around after you're done
comes from the feeling that you made an error; what you should have done
is press esc as soon as you were done finding, but that darn find
feature distracted you by displaying find matches in content and you
lacked the self-control to keep your mind on the find ui instead of
jumping on the content and matches that are relevant to what you're
actually after. Then the find bar sits there basically saying "NO!
WRONG!" until you placate it with a dismissal dance.
I can certainly see though how clicking on the Find Next button would be
made difficult by a focus change or such making the find bar go away... :)
't.
Mike Connor
> Brett Wilson wrote:
>> The basis of everything you say here depends on the assumption
>> that people that use '/' know it is different form Ctrl+F. I think
>> this is wrong. Nobody around me knew this difference until this
>> discussion started, I didn't know the difference. You can't "fall
>> back" on something you don't know is different.
>>
>> If we are trying to support more than one use case, the current
>> approach has manifestly failed. If we want to continue to support
>> two cases, it needs to be totally rethought. In the absence of
>> that, unifying Ctrl+F and '/' is far better than the current
>> failed approach.
>>
>> / looks like it works like Ctrl+F. The people that have discovered
>> it like me and everybody that sits around me therefore think that
>> it works the same. If we support two different behaviors, it needs
>> to be OBVIOUS that they're different, and not have several very
>> subtle differences.
> Not only do I entirely agree with this, but I add that even for
> people like me who DO know the modes are different, I continually
> don't want the DISMISSAL to be different (and sometimes I don't
> want other things to be different, either). However, I'm not going
> to get into the question of what the enter key should do or the
> other differences between the modes or other things; I'm just
> concerned with dismissal.
Ah, but that is important here. Different actions should really have
distinct UI, and if its distinct UI, we can do the right thing for
each case. If enter to click and autohide are right for FAYT's
intended use cases, and enter to find again and esc/closebutton to
dismiss are right for Ctrl+F, we should ensure that the best thing
happens in each case, and that we highlight visually that the find
modes are different. Design and discussion of individual bits of a
feature need to happen in the larger context of the feature, not in
isolation.
I'm really still curious why closing the find bar is important to
you. Aside from taking up a little bit of the least interesting
section of the content pane, is there another downside to forgetting
to dismiss it?
-- Mike
Hasse
fir...@lists.mozilla.org>, Mike Connor wrote...
> If a small inconsistency is causing problems for people who have
> stumbled across /, and decided to use / instead of Ctrl+F (how do you
> adopt a new shortcut if it doesn't work the way you want it to?) then
> we need to figure out how to clearly indicate the find mode that is
> active. If you are using FAYT, the UI for the findbar can, and
> probably should, be visually different (i.e. we could skip the
> buttons, since you're using the keyboard to navigate, but that's just
> a modification of the original approach).
How about not showing the find bar for FAYT? Having the find bar pop up
when you are using the keyboard to focus and "click" a link is, IMO,
amazingly irritating.
--
Hasse
sv-SE l10n team
Peter Kasting
> How about not showing the find bar for FAYT? Having the find bar pop up
> when you are using the keyboard to focus and "click" a link is, IMO,
> amazingly irritating.
At lunch today brettw suggested perhaps changing the / interface to be a
small box with only a textfield that pops up in the corner of the
screen, instead of the full find bar. This would distinguish the two
modes and perhaps better serve / users, without making the function as
undiscoverable as it used to be when text was displayed in the status bar.
PK
Peter Kasting
> Different actions should really have distinct UI, and if its distinct
> UI, we can do the right thing for each case. If enter to click and
> autohide are right for FAYT's intended use cases, and enter to find
> again and esc/closebutton to dismiss are right for Ctrl+F, we should
> ensure that the best thing happens in each case, and that we highlight
> visually that the find modes are different. Design and discussion of
> individual bits of a feature need to happen in the larger context of
> the feature, not in isolation.
I am completely on board with that in a general sense. My concern is
that the current interface melding of the search modes seems to be more
historically oriented rather than designed-for-specific-use-cases, and
that therefore we haven't done a ton of thinking about exactly how we
want this all to work. That sort of thinking and design takes some time
to get right. I am interested in making a minimal set of changes to get
at least the branch working "better", even if we wish to make larger
changes in the future. There are far too many bugs in bugzilla that
languish for want of the perfect design/implementation. I'm seeking an
immediate improvement without wishing to compromise future, larger
improvements. I don't think that making dismissal more consistent,
given that the UI looks similar now, is a step backwards, or that it
makes it harder to do good, separate UI in the future (or, as you also
proposed, to simply remove the / functionality).
To be more selfish about things, I'm currently in the process of
refactoring/rewriting much of the FAYT code, to fix a few different bugs
and to "take ownership" of the code since it currently has no true
owner. Now is the time when I'm motivated to fix annoyances like this
and when I'm looking at all the code. I'm also new enough that doing
major UI changes is beyond my level of knowledge. If doing a simple fix
like changing dismissal doesn't happen due to a desire to wait for a
"better" design, I'm concerned that it won't happen at all.
> I'm really still curious why closing the find bar is important to
> you. Aside from taking up a little bit of the least interesting
> section of the content pane, is there another downside to forgetting
> to dismiss it?
I already posted my thoughts on this in detail in reply to a much
earlier mail from beltzner. In short, finding for me is an entire
mental mode, not a function like scrolling through the page. Having the
find bar in the browser not match my "mode" is distracting, confusing,
and makes me feel that the browser isn't doing what I want it to be
doing, and doesn't know what I want it to do.
PK
Tuukka Tolvanen
This sounds a lot like how FAYT appears in the gtk filepicker and
nautilus 2.13.
't.
scratch
> On 9-May-06, at 11:23 AM, Brett Wilson wrote:
>
>> I think the problem with the find bar is that it doesn't behave the
>> same for '/' vs. Ctrl+F.
>
> I don't know if I believe that this is a problem, especially as it
> differs for more than just auto-hide. Take, for example, the
> behaviour when hitting enter. / is invoking FAYT, and hitting enter
> when you find a link navigates to that link. For Ctrl-F, the
> behaviour for Enter is "Find Again" which is expected and consistent
> with pretty much every windows app I have ever used, minus the .
> (I'll accept that Linux apps are less consistent about how find
> invocation/behaviour is broken out, of course, but Linux on the
> desktop is bad at that.)
I'd argue that given its nonstandard GUI, this is not expected. I
haven't tried it as I rarely use ctrl-f anymore, but I would be
surprised if it ever happened.
-scratch
Mike Connor
If the right thing for FAYT is autohide (which it does seem to be) then
taking a decision on current state based on expedience means that we're
churning too much, since we'll then fix the appearance stuff and have to
flip the behaviour back. I am not at all advocating for perfect design,
I am advocating for only making change if that change is on the path to
the right thing. If we don't know what the right thing is, change is
potentially more harmful than the short-term gain the churn provides.
> To be more selfish about things, I'm currently in the process of
> refactoring/rewriting much of the FAYT code, to fix a few different
> bugs and to "take ownership" of the code since it currently has no
> true owner. Now is the time when I'm motivated to fix annoyances like
> this and when I'm looking at all the code. I'm also new enough that
> doing major UI changes is beyond my level of knowledge. If doing a
> simple fix like changing dismissal doesn't happen due to a desire to
> wait for a "better" design, I'm concerned that it won't happen at all.
>
Is there a bug here, and an idea of what this major rewrite/refactoring
is about and how you're approaching it? While I haven't fixed a whole
bunch of stuff lately, I'm the owner of record for that area, so please
do share (and post for comment) your plans here as a new thread. Big
rewrites are bad, incremental rewrite-in-place is good, as we've had
slammed into our face rather forcefully recently with Places, so if
something like this is happening, I want to be in that loop!
>> I'm really still curious why closing the find bar is important to
>> you. Aside from taking up a little bit of the least interesting
>> section of the content pane, is there another downside to forgetting
>> to dismiss it?
>
> I already posted my thoughts on this in detail in reply to a much
> earlier mail from beltzner. In short, finding for me is an entire
> mental mode, not a function like scrolling through the page. Having
> the find bar in the browser not match my "mode" is distracting,
> confusing, and makes me feel that the browser isn't doing what I want
> it to be doing, and doesn't know what I want it to do.
I would love to dig deeper into what mental models are most typical,
since find-as-mode-not-function is interesting, but I don't believe it
to be the majority model.
-- Mike
Peter Kasting
> If the right thing for FAYT is autohide (which it does seem to be)
> then taking a decision on current state based on expedience means that
> we're churning too much, since we'll then fix the appearance stuff and
> have to flip the behaviour back. I am not at all advocating for
> perfect design, I am advocating for only making change if that change
> is on the path to the right thing. If we don't know what the right
> thing is, change is potentially more harmful than the short-term gain
> the churn provides.
>
I don't see any way in which the change I advocated is harmful or
lengthens/damages the "path to the right thing". For one, codewise it's
incredibly easy to flip the change either way, so there's no significant
extra work being added here. For another, no one has agreed on what
nebulous future UI this stuff should all have, but I have heard
widespread sentiment on and off this mailing list that the current
behavior is at the very least odd. I'm much more interested in fixing
an obvious and real issue that may or may not end up being "short term"
than delaying that with the fear that I am somehow not proceeding the
optimal path toward nirvana. Finally, the proposed future UI I _have_
heard, from brettw, is that perhaps FAYT could be in a small box in the
screen corner. If that IS the way things go, then at the time when we
make that UI change, it would be easy to change the dismiss behavior
without breaking user expectations, because the different UI clearly
indicates the mode is different.
I think you're much more convinced of the clarity and utility of having
two almost-identical-but-not-quite find modes that use the exact same UI
than I am, or indeed than most people I've talked to are. Thus it seems
like, while you're interested in what an even better UI might look like
in the future, you don't really believe the _current_ UI is broken. I do.
>
>> To be more selfish about things, I'm currently in the process of
>> refactoring/rewriting much of the FAYT code
>>
>
> Is there a bug here, and an idea of what this major
> rewrite/refactoring is about and how you're approaching it? While I
> haven't fixed a whole bunch of stuff lately, I'm the owner of record
> for that area, so please do share (and post for comment) your plans
> here as a new thread. Big rewrites are bad, incremental
> rewrite-in-place is good, as we've had slammed into our face rather
> forcefully recently with Places, so if something like this is
> happening, I want to be in that loop!
There's no "big rewrite" going on. I'm slowly working toward fixing bug
263683, which will require ripping the highlighting code out of
findBar.js and separating the "find" portion of
nsTypeAheadFind::FindItNow() from the "update selections" portion.
Along the way, I'm also going through every function in that file and
commenting everything, cleaning up things that seem noticeably stupid,
etc. I purposefully didn't say "major" rewrite. It's going to touch
most of the file, but the code isn't actually going to be new, for the
most part.
I _have_ been repeatedly told that nsTypeAheadFind.cpp is not the
recipient of the love and care it could use, and that the two people
strongly connected to it are Blake Ross (gone) and Aaron Leventhal
(overloaded and, to paraphrase him, no longer keeping up with this
code). Hence my interest in going ahead and doing
cleanup/clarity/ownership work on this code.
PK
Mike Connor
Code isn't the concern here. I believe the inconsistency is bad (and
it is bad) primarily because of the visually identical UI, and we
need to fix that before we can determine what is obvious or not
obvious to change about how those distinct but not clearly distinct
enough modes work. Obviously I'm not making it clear enough that
fixing the visual presentation is important and should happen as soon
as possible, i.e. for b1. Not sure if there's a bug, but one of us
should file that bug and get it on the b1 list.
> I think you're much more convinced of the clarity and utility of
> having two almost-identical-but-not-quite find modes that use the
> exact same UI than I am, or indeed than most people I've talked to
> are. Thus it seems like, while you're interested in what an even
> better UI might look like in the future, you don't really believe
> the _current_ UI is broken. I do.
Er, that is not at all what I'm saying. I am saying that the visual
differentiation is the biggest priority, and once its obvious that
they're not the same thing, we can determine what the right thing for
each mode is. If visually distinct find modes wasn't doable for
Fx2, sure, we could take a stopgap. Even dropping the next/prev
buttons and the closebutton, along with a label change, would go a
long way here, IMO.
>>
>>> To be more selfish about things, I'm currently in the process of
>>> refactoring/rewriting much of the FAYT code
>>>
>>
>> Is there a bug here, and an idea of what this major rewrite/
>> refactoring is about and how you're approaching it? While I
>> haven't fixed a whole bunch of stuff lately, I'm the owner of
>> record for that area, so please do share (and post for comment)
>> your plans here as a new thread. Big rewrites are bad,
>> incremental rewrite-in-place is good, as we've had slammed into
>> our face rather forcefully recently with Places, so if something
>> like this is happening, I want to be in that loop!
>
> There's no "big rewrite" going on. I'm slowly working toward
> fixing bug 263683, which will require ripping the highlighting code
> out of findBar.js and separating the "find" portion of
> nsTypeAheadFind::FindItNow() from the "update selections" portion.
> Along the way, I'm also going through every function in that file
> and commenting everything, cleaning up things that seem noticeably
> stupid, etc. I purposefully didn't say "major" rewrite. It's
> going to touch most of the file, but the code isn't actually going
> to be new, for the most part.
If I say I'm rewriting/refactoring much of the code, I usually mean
I'm doing major surgery, not doing cleanup and commenting. Most
rewrite-and-refactor jobs that happen around here are more
substantial than what you're describing. Its still a lot of change
though, and should be done incrementally where possible. Is there a
bug where the plan is laid out?
> I _have_ been repeatedly told that nsTypeAheadFind.cpp is not the
> recipient of the love and care it could use, and that the two
> people strongly connected to it are Blake Ross (gone) and Aaron
> Leventhal (overloaded and, to paraphrase him, no longer keeping up
> with this code). Hence my interest in going ahead and doing
> cleanup/clarity/ownership work on this code.
Help is always welcome, but if there's an existing and active owner,
you should be coordinating/discussing your plans and goals with that
owner (owner being more module-level than individual source-file-level).
-- Mike
Peter Kasting
> Obviously I'm not making it clear enough that fixing the visual
> presentation is important and should happen as soon as possible, i.e.
> for b1. Not sure if there's a bug, but one of us should file that bug
> and get it on the b1 list.
No, that hadn't been clear to me at all. Is someone going to be able to
do the work on this? I don't think I'm prepared to make the changes
required here in that timeframe.
As for bugs, the bug I'd filed on dismissal differences seems like the
closest current one. Either that can morph or someone can file a new
bug. Since I don't know how much change you're interested in getting
into the b1 timeframe, could you go ahead and file what you'd like to
see happen?
> If visually distinct find modes wasn't doable for Fx2, sure, we could
> take a stopgap.
That was exactly the impression I had been working under. If things can
be made distinct for Fx2, then changing the dismiss behavior now isn't
important.
> If I say I'm rewriting/refactoring much of the code, I usually mean
> I'm doing major surgery, not doing cleanup and commenting. Most
> rewrite-and-refactor jobs that happen around here are more substantial
> than what you're describing. Its still a lot of change though, and
> should be done incrementally where possible. Is there a bug where the
> plan is laid out?
No, partly because there isn't a "plan" per se right now. I'm working
my way through the code trying to learn as I go. I'm too new and too
ignorant to be able to plan even something this small yet.
> Help is always welcome, but if there's an existing and active owner,
> you should be coordinating/discussing your plans and goals with that
> owner (owner being more module-level than individual source-file-level).
It's not really clear to me what "module" means. TypeAheadFind has its
own subdirectory inside toolkit/components. At what level are things
broken into "modules" here? And if the level is larger than "the
TypeAheadFind" directory, it seems the ownership is broad enough that
more fine-grained ownership below the "module" level is useful and
desirable.
I had been talking plans over with darin/bryner, since they're easily
available and since they hadn't told me there was someone else I would
need to clear things with.
PK
Mike Connor
On 11-May-06, at 1:48 PM, Peter Kasting wrote:
> Mike Connor wrote:
>> Obviously I'm not making it clear enough that fixing the visual
>> presentation is important and should happen as soon as possible,
>> i.e. for b1. Not sure if there's a bug, but one of us should file
>> that bug and get it on the b1 list.
>
> No, that hadn't been clear to me at all. Is someone going to be
> able to do the work on this? I don't think I'm prepared to make
> the changes required here in that timeframe.
We'll find someone. The stopgap different (hide buttons/closebutton
and change the label) are actually pretty trivial to implement, due
to the joy of XUL+CSS.
> As for bugs, the bug I'd filed on dismissal differences seems like
> the closest current one. Either that can morph or someone can file
> a new bug. Since I don't know how much change you're interested in
> getting into the b1 timeframe, could you go ahead and file what
> you'd like to see happen?
>
>> If visually distinct find modes wasn't doable for Fx2, sure, we
>> could take a stopgap.
>
> That was exactly the impression I had been working under. If
> things can be made distinct for Fx2, then changing the dismiss
> behavior now isn't important.
I think you've highlighted a pretty bad oversight, which was based on
"no one discovers / by accident" as an obviously false assumption.
>> If I say I'm rewriting/refactoring much of the code, I usually
>> mean I'm doing major surgery, not doing cleanup and commenting.
>> Most rewrite-and-refactor jobs that happen around here are more
>> substantial than what you're describing. Its still a lot of
>> change though, and should be done incrementally where possible.
>> Is there a bug where the plan is laid out?
>
> No, partly because there isn't a "plan" per se right now. I'm
> working my way through the code trying to learn as I go. I'm too
> new and too ignorant to be able to plan even something this small yet.
That's why we split up the ownership better, very recently, so that
there would be people to guide and discuss this type of thing with!
Darin and bryner are good guides, of course!
>> Help is always welcome, but if there's an existing and active
>> owner, you should be coordinating/discussing your plans and goals
>> with that owner (owner being more module-level than individual
>> source-file-level).
>
> It's not really clear to me what "module" means. TypeAheadFind has
> its own subdirectory inside toolkit/components. At what level are
> things broken into "modules" here? And if the level is larger than
> "the TypeAheadFind" directory, it seems the ownership is broad
> enough that more fine-grained ownership below the "module" level is
> useful and desirable.
>
Right, typeaheadfind is really a sub-module of toolkit. see http://
www.mozilla.org/projects/toolkit/review.html for details on how we
split this up.
-- Mike
Mike Connor
That could work, yeah, though definitely more time-consuming to
implement on a short turnaround, and I'm wondering about how the
problems that hit the Places popup would affect this.
Still, boy, we need to get something done!
-- Mike
Peter Kasting
> We'll find someone. The stopgap different (hide buttons/closebutton
> and change the label) are actually pretty trivial to implement, due to
> the joy of XUL+CSS.
OK, I'll file this in a bit unless you get to it first. Hopefully I'll
do something sensible w.r.t. getting it targeted at b1. The difference
between "milestone" and "blocking?" is not terribly clear to me...
> Right, typeaheadfind is really a sub-module of toolkit. see
> http://www.mozilla.org/projects/toolkit/review.html for details on how
> we split this up.
I was about to ask for this to be linked off the module owners page when
I saw that it already was, and I was just too dumb to have clicked it
before :(. Thanks for the link, that's quite helpful.
PK
Mike Beltzner
> My whole problem might go away if there was a visual indicator of any
> kind of modality. I can't remember whether I started the bar with / or
> ctrl-f because they look exactly the same, but they don't behave the
Huh. This got me thinking "what kind of visual indicator" which led me
back to "well, what's the difference in task?" and that got me to
realize that "/" seems to be a quick "jump me to the next instance of
this text in the page" whereas "Accel-F" is a more robust "find..."
action.
Perhaps the bar could be rendered slightly differently (and more
sleekly) for the "/" case:
-------------------------------------------------------------
Jump to: (O._foo___________________)
-------------------------------------------------------------
The only way to get rid of this is to click in page or to let it
timeout. If the user presses Ctrl+F, then the dialog turns into a find
dialog. "Jump to" was the first label I could think of that wouldn't
be confusing en lieu of "Find", other possibilities include: "Quick
search", "Look for", "Show me".
(Turns out mconnor was having very similar thoughts to this, which is
usually an indication that we're on the right track :)
cheers,
mike
--
/ mike beltzner / user experience lead / mozilla corporation /
Peter Kasting
> The only way to get rid of this is to click in page or to let it
> timeout. If the user presses Ctrl+F, then the dialog turns into a find
> dialog. "Jump to" was the first label I could think of that wouldn't
> be confusing en lieu of "Find", other possibilities include: "Quick
> search", "Look for", "Show me".
especially "quick search" -- that's the closest description I can think
of to what the dialog actually does. It's a stripped-down version of
search, for finding things quickly without worrying about the other
buttons/controls.
I'd request that "escape" continue to dismiss this dialog as it
currently does. It might be nice to not remove the close button either,
unless we manage to create the small-box interface that feels better to
me than just a find-bar-sans-controls (but is supposedly harder to do?).
Long-term, it might be nice to continue thinking about exactly how these
modes should behave, such as the enter button difference, the difference
in clearing the search field on activation, the tab button difference,
etc. Short term, just making them visually distinct seems like the
high-priority item.
PK
Mike Shaver
> I'm not very sure of "jump to", but the other three seem better to me,
> especially "quick search" -- that's the closest description I can think
> of to what the dialog actually does. It's a stripped-down version of
> search, for finding things quickly without worrying about the other
> buttons/controls.
I think "search" there would make things a little confusing WRT the
other search UI (the top-right engine input field). I like "Look
For", or even "Quick Find" perhaps -- it really is a slimmed down
version of the "Find" experience, so that doesn't seem unreasonable to
call out.
Mike
Peter Kasting
> I think "search" there would make things a little confusing WRT the
> other search UI (the top-right engine input field). I like "Look
> For", or even "Quick Find" perhaps -- it really is a slimmed down
> version of the "Find" experience, so that doesn't seem unreasonable to
> call out.
Ah. Yes. Quick Find, that's closer to what I was thinking anyway. (I
merge "find" and "search" mentally because I get rid of the search box,
so I thought of the find functionality here when I said "search").
Quick Find seems like a very good label.
PK