On Nov 29, 2004, at 2:05, Wayne Larsen wrote:
[...] "Ctrl-S + Partial search string" is always going to be faster than "Apple-F + Full Search String + Enter" [...]
On Nov 29, 2004, at 5:51, Carl Forde wrote:
[...] cmd-f and filling in a dialog box is requires much more cognitive effort because of the two context switches required
While I have yet to try out i-search, I do think you guys are wrong. To maximize your workflow you need to make the process rely as little as possible on external input (e.g. the need to visually recognize something throughout the process) and remove as many conscious decisions from the process as possible (i.e. the need to decide next “action” based on present non-predictable (by the mind) context).
While with enough use I imagine you'll condition yourself to incorporate the visual feedback from the i-search into the decision process (as in associative learning), and less conscious thought will be required -- personally though, I generally do not realize I've miscalculated something before a few actions after the point of disagreement between my mental model and the real world, meaning that any process where visual feedback is optional, I'll perform faster w/o the visual feedback, often even if it requires more physical work (as in typing the full function name followed by " (" to find the declaration of a function, rather than iterative typing and visually monitoring when I've actually found the function).
I think the Firefox example as supportive evidence of the usefulness of this kind of search in a text editor is wrong for a few reasons:
1) searching in a browser is generally trying to obtain information not easily available, so the task at hand is to find new information, so (mental) automation is not even on the table -- in a text editor OTOH we may often use search simply as a navigation aid, and thus some degree of automation is possible and IMHO very much desired.
2) the text in a browser is generally unknown and thus unambiguous search strings are not easily created. If you'd written all the text yourself this would be easier and you may even have a system to disambiguate different elements of the text (e.g. a function call from a function prototype/declaration).
3) as I understand it, Firefox highlights all matches in one go, adding new functionality -- the iSearch plugin doesn't, but I understood another letter as saying Emacs does do this!?! then however I'm not sure how to proceed after the i-search (if the search hasn't been narrowed down to a single match).
All this said, I do intend to implement the i-search functionality, if for no other reason than to (dis)verify my own belief ;)
My argument is btw not that standard search is faster than i-search, only that given the right circumstances (i.e. a user who can blind type, is inclined to associative learning and having a workflow that relies little on decision making (as navigating in structured text shouldn't do)), the i-search is not going to be faster, and I'd even say it caters to the wrong (if the goal is automation) type of implicit learning.
A thing to remember is that each time an automated action is repeated, the person becomes faster at doing this action (there's a logarithmic speedup over time) -- so if we have two methods to achieve the same goal and only one caters for automation, then even if this is initially the slower way of doing things, it may over time be the faster one.