Date: Sun, 28 Nov 2004 20:48:11 -0500 From: Josh DiMauro jdimauro@gmail.com
That's pretty much it... but the advantage is less the shorter find string, and more the ability to fine tune by either narrowing or widening the search with a couple keystrokes, without having to reopen a dialog box. The difference is subtle, but (I feel) important.
Incremental search seems to be one of those things that makes a subtle difference in reducing resistance to use. It's not so much that I need it to do all my searching. It's more that, when I don't have it available, I search less, and that makes me less efficient.
Incremental search changes the way you do searching. Using Firefox or Mozilla, on a web page I can just type '/' and then the thing I'm looking for. cmd-f and filling in a dialog box is requires much more cognitive effort because of the two context switches required (into the dialog box and back). Many times I've wanted to type '/something' and then realized I needed to do cmd-f etc... and decided just to page-up or page-down instead. May I suggest cmd-/ for incremental search?
Carl
Incremental search changes the way you do searching. Using Firefox or Mozilla, on a web page I can just type '/' and then the thing I'm looking for.
I agree, incremental searching is great. I like the highlighting feature in firefox. I can see it be a great help when searching for all the times a function is being called in your program. I really like the way Firefox has implemented the interface as a strip at the bottom.
May I suggest cmd-/ for incremental search?
This may be going out on a limb, but why not just make it cmd+f and change the find dialog to a strip like firefox. While on the subject of finding why not combine the the find in project and current find dialog into one. This way you can use the same replace selected feature on single documents and not just projects.
- Juan
On Nov 28, 2004, at 9:37 PM, Juan Anorga wrote:
This may be going out on a limb, but why not just make it cmd+f and change the find dialog to a strip like firefox. While on the subject of finding why not combine the the find in project and current find dialog into one. This way you can use the same replace selected feature on single documents and not just projects.
Description of Firefox's incremental search UI w/pics:
http://www.squarefree.com/burningedge/archives/000494.html
Chris
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.
On Mon, 29 Nov 2004 12:12:48 +0100, Allan Odgaard allan@macromates.com wrote:
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).
The problem with your argument is that the issue here is not whether the "context" is predictable. There is little difference between the context of a search dialog box and the floating window of i-search. What is different is that error correction and feedback occur as you type, which allows search to be used as a navigation aid.
Allow me to give a common example: I have a very large text file (my todo.txt list) which has subsections with headers that I often navigate through. It's just simply faster to hit:
^-S## @HO[DEL][DEL]IN[DEL][DEL]TO[ESC]
in order to browse my list, than it is to issue repeated search commands and repeat the "## @" portion that designates the beginning of each section. Searching for that string and using [CMD]-G is a poor substitute, as I am not interested in the order these segments appear in, in the textfile. I'm interested in getting to them in the order I think of them.
Search as navigation is a function that is poorly served by the standard search dialog box.
As to the command key: please, let's keep it ^-s. It's consistent across multiple applications, and I'm already having to learn too many new commands as it is, thanks.
On Nov 29, 2004, at 17:45, Josh DiMauro wrote:
[...] 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).
The problem with your argument is that the issue here is not whether the "context" is predictable. There is little difference between the context of a search dialog box and the floating window of i-search.
I'm referring here to the mental context (i.e. the state of mind) -- when I hit cmd-f, enter "foo (" and press return I know (in my mind) that "foo (" will be selected in the declaration of the foo function and I can continue to work from this point w/o having to visually verify it.
I.e. I ignore the external context of actually seeing the find window or verifying that the search went okay -- the action to take after the search follows naturally and there is no "break", e.g. if I were to copy the line declaring the prototype I'd do option-l, cmd-c with the pause between return and ( to start the search, and between return and option-l probably being very similar.
This of course only when searching is used for navigational purposes -- but this is probably what would make sense to optimize for.
So if the argument were that i-search is faster because I would in this case only have to type 'fo' to get to where I wanted, this argument is very much flawed because it looks only at the physical work and not on the thought process, which is often what slows us down (most of us can probably type >50 words pr. minute, but we don't, because other things are slowing us down).
I know this wasn't your argument -- I just wanted to clarify my own, which was in response to the 'i-search is faster'.
Allow me to give a common example: I have a very large text file (my todo.txt list) which has subsections with headers that I often navigate through. It's just simply faster to hit:
^-S## @HO[DEL][DEL]IN[DEL][DEL]TO[ESC] [...] I'm interested in getting to them in the order I think of them.
This is interesting -- I'd argue that you are actually getting new functionality out of the i-search, because you turn the search string into a way to move the caret by issuing the proper commands.
And I'd imagine that this process is very much geared toward automation/no cognitive overhead other than thinking of the actions you want to perform.
Search as navigation is a function that is poorly served by the standard search dialog box.
Agree :)
As to the command key: please, let's keep it ^-s.
I was thinking I'd just name my function the same as the iSearch-plugin's, so those who have bound keys to this function will just see it also work in TM.
People who want it on cmd-/ can always change the default bindings.
On Mon, 29 Nov 2004 18:49:46 +0100, Allan Odgaard allan@macromates.com wrote:
I know this wasn't your argument -- I just wanted to clarify my own, which was in response to the 'i-search is faster'.
Just to add my perspective--I find a regular search somewhat annoying in the cases where:
- There's very many matches, and I keep guessing wrong as to how much substring I need to type to find the match I want. (Poor example: "text" finds "textedit"; re-entered search of "textmate" finds "textmate"; re-entered search of "textmate users" finds textmate users mailing list.)
- I've actually opened the wrong document, and have typed in a long search string (to disambiguate) only to discover that there's no matches at all. (Most annoying when I'm searching the wrong document, but happens with the "right" document too.)
- I've made typo in the search string, and I don't notice until the search has been run. (Or worse, I don't notice at all, and think that there's no match at all.)
Basically, I guess isearch has advantages over search for me in cases where, given a particular search string, that search string matches either no lines, or a lot of lines.
--M.
On 29. nov 2004, at 17:45, Josh DiMauro wrote:
[i-search...] As to the command key: please, let's keep it ^-s. It's consistent across multiple applications, and I'm already having to learn too many new commands as it is, thanks.
But of course this doesn't work on keymaps where ^ is dead, such as danish :-/.
On 29. nov 2004, at 5:51, Carl Forde wrote:
[...] May I suggest cmd-/ for incremental search?
Too many and too far apart keys for us with danish keymaps :-p.
-
Allan Odgaard -
Carl Forde -
Chris Thomas -
Josh DiMauro -
Juan Anorga -
Michael Stillwell -
Sune Foldager