Author Topic: FARR version 2 - discuss the best way to handle 'actions' (Read 57821 times)

jgpaiva · « **Reply #50 on:** February 03, 2006, 05:55 PM »

I am now reading about regexes. It's quite powerfull, and associated with what we are discussing here, it might lead us to very good results, i think.

From what i understand, a regex like this:

[Select]

(["][A-Z0-9. ]*["] ){0,1}edit( ["][A-Z0-9. ]*["]){0,1}

would accept entries like this:
"jgpaiva.txt" edit OR edit "jgpaiva.txt" OR "jgpaiva.txt" edit "donationcoder.txt"
And farr already does this. (the testing box in farr's alias group editing is really useful

)
The inconvinience with the version that farr has now, is that there is no way to ease the entry of the file names. So, to edit something, you'd have to do:
"C:\documents and settings\joao\my documents\jgpaiva.txt" edit to edit that file.

Which doesn't make sense when you have such a great power of search already included in farr.

So, my proposition to implement this, is to have farr work like this:
You search for anything, and when you press tab, that anything is replaced internally by it's result.

Meaning, when i search for jgpaiva.txt and press tab, the line to be executed by farr would be "C:\documents and settings\joao\my documents\jgpaiva.txt" . Then, the search field searches for possible aliases, since the first thing i selected was a file.
I type edit and my group edit is selected (important: here, farr adds a space to the end of the expression to be evaluated after the word edit, or the following won't work).
Now, if i press enter, the regex is evaluated, and jgpaiva.txt is opened in the editor i had selected.
If i press tab again, my regex specifies that afted "edit " can come anything, and so, the search alows anything to be used. I search for donationcoder.txt, press enter, it's path is quotated, added to the end of the regex, the regex is evaluated and my editor is launched with both documents.

I think that the only problem with this, is that the searches wouldn't be only by the string typed, but also using the rules defined by the last regular expresion selected.
What do you think, mouser? Any problems with this solution?

PS: The regex i presented is highly incomplete, as it doesn't contain the search for only text files, nor it allows fullpaths to be specified. I only presented it like that, for the sake of understandment, since the whole regex would have about 3 or 4 lines

Of course, this kind of "basic action" regexes would come with farr v2, so as the user doesn't have to configure them.

PS2: as this post was very tiring, i'm going to bed.

(g!, regexes are confusing

)

mouser · « **Reply #51 on:** February 04, 2006, 05:22 AM »

to clarify what i was saying from before, i was saying we cant insist that the filename comes first,
because sometimes there is no filename, for example when you want to send an email.

there is always an action however, so it is possible to insist the user always starts out specifying an action.

or it is possible to start out allowing both, as we do now.

Amadawn · « **Reply #52 on:** February 04, 2006, 04:29 PM »

OK. I really think that allowing both would be better, as it works for most cases (when you are searching for a program or file). I also think that we should allow more complex actions (like filename email address or filename copy foldername, etc).

Man, this is becoming a very ambitious project, mouser!!!

allen · « **Reply #53 on:** February 04, 2006, 07:40 PM »

to clarify what i was saying from before, i was saying we cant insist that the filename comes first,
because sometimes there is no filename, for example when you want to send an email.
-mouser (February 04, 2006, 05:22 AM)

Essentially, wouldn't the email address or contact name be the "file" -- Without additional parameters, it's not an action, just a launch.

Rover · « **Reply #54 on:** February 05, 2006, 12:23 AM »

@mouser: This might be another discussion, but I'll start it here; you may already be doing/thinking this.

Does it make sense to extract the User Interface and Presentation from the core functions of the FARR code? eg. do you really care how the user asks to you execute the find_files function part of your code so long as you return an array or list of files?

It's sort of like skinning the whole UI. The logic of FARR would become a glorified API and you could have a couple of UI's that access it: a keyboard based or a mouse based or whatever.

I'm just thinking out loud here... it's certainly not a fully baked solution. I'm not sure it makes sense in this case since I haven't seen your code. I can see some issues either way.

Thoughts?

jdmarch · « **Reply #55 on:** February 06, 2006, 01:02 AM »

How to distinguish between the 95% case (simple file launch), and the 5% case (search for verb then search for object), with minimum keystroke count for the 95% case, and without requiring that FARR/MR be a mind-reader because of ambiguities in the name space? What we want is the best of both worlds. We don't want the user to have to type a verb in the 95% case, but we always want the command to begin with a verb to keep the parsing clean. So...

When FARR opens (after the user presses the <BREAK> key) , the user entry line is pre-filled with the "OPEN" (or "LAUNCH" or "RUN" if you prefer) verb followed by a space, so the user starts typing the object immediately after this verb and everything works exactly as it does now.

But if, instead of typing following the OPEN verb -- if, rather, the user presses the <ESCAPE> key, then the OPEN verb is cleared from the user entry line and the user is presented with a FARR-style selection list of possible verbs (or search modifiers), filtered down as the user begins to type the desired verb. The first verb on the default list is still Launch, so if the user changes her mind and wants to do a simple launch after all, she can just press <ENTER> or <TAB><ENTER> and be back where she started, getting ready to type the object.

Also, I have been wavering about whether the verb and the object should be in the same input field or separate input fields. I now think that they should be in separate input fields on the same horizontal line, where the first field is strictly limited to defined verbs (and as just described is pre-filled with OPEN in the basic launch case).

Mouser, the command could still be typed sentence-like, so that when a space (or any whitespace terminator) is typed after the verb, then the cursor moves from the verb field to the object field. In contrast, the object field can contain spaces if desired (unless we're going to support nested verbs, which I have grave doubts about, see next post; but even that could be implemented as an extension of this model).

This also makes it easier to figure out how Enter and other selection keys (e.g. numbers) work. When we are choosing a verb, all the selection keys have the effect of finalizing the choice of a verb and moving the cursor to the object field. Whereas when we are choosing an object (whether the verb is OPEN or something else), they will finalize the command and set the desired action in motion.

To conclude with an example, to enter the command "KILL C:\MY DATA\MY FILE.TMP" the user would type:
<BREAK><ESCAPE>K<ENTER>
At this point, the command says "KILL ". The user goes on to type:
.TMP<TAB><7><ENTER>
(for example).

jdmarch · « **Reply #56 on:** February 06, 2006, 01:04 AM »

Lots of great ideas in this thread, but for me, there are only 2 enhancements to FARR/MR which I'm really waiting anxiously for:

1. Switching to an already running task -- whether it's in the taskbar, or in the tray, or sequestered by a tray-manager utility -- using the same sort of partial matching methods as are used to launch files.

2. Mouser's "search modifiers" where an initial keyword alters the scoring rules.

These both seem like natural enhancements of FARR's existing strength. I'm dubious about everything else: good ideas in theory, but risking feature-itis for small productivity gains. I really don't expect to be doing file maintenance, or sending emails from FARR/MR, any time soon. And I don't need to kill tasks so often that I mind having to do it with task manager. But task switching? I do it hundreds of times every day and it's wearing out my wrist tendons.

So I really hope that the early releases of FARR2/MR will not be delayed by trying to figure out the perfect universe of multiple verbs and complex subordinate clauses! For example, is it really important that the MP3 enqueue command be implemented as a 2-level verb rather than as a single verb "MP3enqueue", one of several easily found 1-level verbs which all begin with the characters "MP3"?

mouser · « **Reply #57 on:** February 06, 2006, 01:09 AM »

jd can you talk a little bit more about what you think the ideal way would be to tell farr to switch tasks?

jdmarch · « **Reply #58 on:** February 06, 2006, 09:59 AM »

I want to be able to switch to a task the same way that I would start one. After the (default) OPEN/RUN/LAUNCH verb, the selection list would show running tasks along with, but by default above, launchable files. So the following keystrokes would switch to firefox if it is running, else start it:
BREAK - to invoke FARR/MR
fire (or maybe ffx depending what you decide to do about noncontiguous search strings)
ENTER
Since different tasks use different interfaces (single click, double-click, right-click-Open, right-click-Restore,...) to allow restoration from the system tray, some task-specific customizing of the task switching mechanism might be required.

In keeping with my interface proposal of last night, the following keystrokes would kill a running firefox task:
BREAK - to invoke FARR/MR
ESCAPE - to clear the initial verb entry field
k
ENTER - assuming that the KILL verb is the first one which matches "k"
fire
ENTER

mouser · « **Reply #59 on:** February 06, 2006, 10:02 AM »

right this makes sense - basically you are saying, if you type the name of a program already running, switch to it instead of launching a new copy. ill add this or an option for this.

i could also add an option to use a special command called "switch" if people did not want this behavior by default.

jdmarch · « **Reply #60 on:** February 06, 2006, 10:19 AM »

Just to be clear: both the running task and the file would appear on the selection list. The running task would appear first, so pressing Enter would switch to it, but if the user wanted to launch a new instance (for programs which permit this), she could select and launch the file instead of the task.

I agree, there would be no reason not to support a SWITCH verb, which would be one of the wonderful universe of search modifier verbs, this one restricted only to running tasks.

jdmarch · « **Reply #61 on:** February 06, 2006, 10:21 AM »

While multiple verbs are not a top priority for me, I do think that they could eventually be very useful.

The number and function of entry fields, as well as the contents of the drop-down selection list, would vary depending on the preceding verbs or objects selected. So I agree with the proposal for an initial FIND verb followed by an arbitrary object, followed by an object-dependent secondary verb.
For example:
FIND <taskname> KILL
FIND <taskname> SWITCH
FIND <file name> DELETE
FIND <tunename> ENQUEUE

The first of these could be entered as
<BREAK>
<ESCAPE>
F
<ENTER> (or TAB #, or TAB arrow arrow arrow ENTER, etc, just as now)
taskname
K
<ENTER>

This would also be useful after search modifier verbs, which restrict the object selection list, which in turn restricts the secondary verb selection list:
MP3 <tunename> ENQUEUE
TASK <taskname> KILL

Amadawn · « **Reply #62 on:** February 06, 2006, 11:37 AM »

If the main problem shown by this thread is how to distinguish between the "main case" where FARR must do a regular search and the "5%" case, in which we must provide FARR with a "verb" (or command), why can't you just select a "escape character" that must be used for commands?

For instance, maybe we could use ">" which is not allowed in any Windows filename. If ">" is the first character on the command line, assume that it is followed by a command (like "define", for instance). Otherwise, assume that we are in "normal" mode.

Of course, while in normal mode, you could still be able to stack "commands" as it has been discussed above (QuickSilver style).

Does this make sense?

Amadawn

jdmarch · « **Reply #63 on:** February 06, 2006, 12:26 PM »

Amadawn, the keystroke count of your suggestion is the same as mine (both require pressing an escape key to move from launch-only mode to multiple-verb-choice mode, although actually ">" requires holding down the shift key).

But to me, the multiple-field model is more friendly, especially to newbies, than the single-command-line model.

First, the use of any special-purpose characters (e.g.">" here, or "|" in the results field of the group edit dialog) makes a command line look forbidding and potentially confusing.

Second, the visible presence of a default OPEN/LAUNCH/RUN verb, in the first entry field, provides a visual clue that other verbs are possible. And the number of available entry fields gives a clue as to the desired syntax (e.g. after OPEN, there is just one more visible field, but after FIND, there are at least 2 more visible fields, the exact number depending on subsequent choices). So, at least in theory, this model holds the hand of the inexperienced user without inconveniencing the experienced user.

I expect that most of us having this conversation are very comfortable with multi-part command lines, but I'm trying to think what would work better for others. Maybe I'm wrong about this: it would take some usability testing with inexperienced users to be sure.

jgpaiva · « **Reply #64 on:** February 06, 2006, 12:38 PM »

jdmarch:
I think that the possible ambiguities in the Farr engine, can only come from the way we define the aliases.
I mean, using the great stack-pile method that Jan-S proposed, i think that Farr only has to do what he does now.
The only difference is that when we select something, it's name gets replaced by it's full path.
The only hard thing is define the aliases, but even that, i don't consider very hard. I've seen that there is much people that are "experts" in aliases, and others willing to learn (like myself

)

Another thing you mentioned is selecting with SPACE. I think this has been referenced before, and can't be done, since one of the most asked-for feature was "f f" finding firefox. (i myself would like to select with space too, maybe it could be an option?)

I love the way you said that the switch tasks- function could work, and i think it's perfect. And it even doesn't need to have the option to disable it, if Farr will have the adaptive scoring like it is predicted will have, if you usually don't use the "switch to" option, it won't come first, and ENTER will just open a new instance.

Mouser's "search modifiers", that's a great idea! it has happened too many times to have another option come after the one i wanted, when working on something!

As for the two field-arrangement, i don't agree with you, i think that having a command line to type exactly what you want is more natural, i mean, everything goes in the same place. I understand that it is to have distinction between entering an action or a file, but IMO, it generates some confusion. I think that having the letters change colour when you type an actions would be easier. (I also think this should be features in the stack-bar, to have some idea of what we're doing.)

Amadawn:
My opinion is that is the aliases (or actions, or whatever you call it

) are configurable, you can change their names, and you can include that character in their names. I don't think there is a need to force the character to be there, unless it helps Farr to identify what it is working on, or something like that.

mouser · « **Reply #65 on:** February 06, 2006, 12:43 PM »

jdmarch said:

Second, the visible presence of a default OPEN/LAUNCH/RUN verb, in the first entry field, provides a visual clue that other verbs are possible.

i find this reasoning very compelling, and it also attracts me to the idea of multiple edit fields.

imagine two edit boxes:

ACTION: [FIND_______]
OBJECT: [___________]

cursor could start in OBJECT field, where you could type the name of a file pattern and it would behave exactly as farr currently does.

but you could also hit up arrow to go to action field, where it would select/prehighlight the word FIND and you could just start typing another action, like "kill". as soon as you enter the upper field, the results would switch to the actions list to select from.

after selecting an action, the tab or down arrow would take you back to OBJECT field.

we could also have the OBJECT field auto detect when you type an action and a space as your first word, and automatically fill it in on the ACTION field (while leaving it in the OBJECT line if deleting would be confusing).

the benefits of this approach would be
1. the 95% case requires no extra steps, you start the program and start typing to find an object to launch.
2. good visual feedback about how to change an action
3. very easy to change actions and select from a menu (just hit up arrow to go to ACTION field, then tab or down arrow to go back to OBJECT field)
4. pure commandline mode supported by autodetecting common actions typed in OBJECT field
5. obeys the rule of always specifying a verb first - which lets you do things like specify a verb of KILL and having the results list show a list of running processes that are searched when you are in the OBJECT field.
6. could have an option to start in the ACTION field for people who prefer that.

drawbacks:
1. you need two editboxes visible - annoying for people who prefer a streamlined tiny look.

however - it may be possible to use only edit box and a queue/stack like effect where we push the FIND action on the stack to start with but give user a way to backup over that - its the same idea but a different way of displaying it. i think basically the effect is the same but it might be more streamlined, but significantly more confusing for new users.

well one more benefit of the queue/stack effect, which could be substantial, is that it allowsq queueing of a string of objects, not just one for each editbox.
hmm still something to chew on...

jgpaiva · « **Reply #66 on:** February 06, 2006, 12:57 PM »

Second, the visible presence of a default OPEN/LAUNCH/RUN verb, in the first entry field, provides a visual clue that other verbs are possible.

Agreed. It made me rethink what i had said before, and I think you're right, it does help new people to understand how Farr v2 works. And if the box below recognizes the actions, everybody is happy

Just one suggestion: if the box below can do everything, why not have an option to remove the upper box? It's a way to make everybody happy

mouser · « **Reply #67 on:** February 06, 2006, 01:08 PM »

i think the option to remove the ACTION box might be reasonable -
maybe even have an option to switch between double editbox mode, and single editbox stack/queue mode, if we can figure out the best way to do that.

mouser · « **Reply #68 on:** February 06, 2006, 01:09 PM »

maybe the stack/queue and double editbox are really closer than we think.
i meant the stack/queue might really just be seen as the first action editbox.. then the ideas are almost identical.

jgpaiva · « **Reply #69 on:** February 06, 2006, 02:47 PM »

maybe the stack/queue and double editbox are really closer than we think.
-mouser (February 06, 2006, 01:09 PM)

I know what you mean, and i think that you are right, they are similar. But only under the conditions that you don't have several actions in one command, nor several files for the same alias, nor the "file"-"command"-"parameters" structure (like the "screenshotcaptor.exe email [email protected]" mentioned before).
I think that the matter that we need to discuss here, is more around the funcionalities that Farr will have, so as we can perfect the ui to use them. The examples i mentioned before, become confusing when the double-editbox appearance is used, but to use the action-file structure, the double editbox becomes much more fit, since it helps new users, yet allowing power-users to still have all their commands close.

mouser · « **Reply #70 on:** February 06, 2006, 02:52 PM »

I think that the matter that we need to discuss here, is more around the funcionalities that Farr will have, so as we can perfect the ui to use them.

i think this is a very good point.

let me try to work up a little document about the plans for farr2 (aka "Mercury Runner") keeping in mind nontroppo's idea of intrgrating it with launch bar functionality and my new configuration system.

i will try to have that ready by next monday (in 7 days). hopefully that will lay out a good foundation for us to work with. meanwhile people can try to think about the kinds of things they'd like to be able to type and have understood properly.

jgpaiva · « **Reply #71 on:** February 06, 2006, 03:18 PM »

let me try to work up a little document about the plans for Farr2 (aka "Mercury Runner")
-mouser (February 06, 2006, 02:52 PM)

Good to know that! ( i had already forgotten about farr's new name

)
I think that until then, this thread could become the "actions requests" thread, right?
Might help in creating new ideas and redefining concepts, possibly eliminating some of the problems that we had until now.
I'll try to search through this thread, collect some actions ideas, try to redefine them, (especially into the action-file structure, to simplify), and try to have some ideas about what Farr (aka MR) could do. I'll try to post this tomorrow, but probably, i can only have this by the day after tomorrow.
(exam tomorrow..

)

Jan-S · « **Reply #72 on:** February 06, 2006, 03:56 PM »

There are some interesting new ideas in this thread. jgpaiva (#64) already replied to most of them exactly as I wanted to before reading hist post (the SPACE problem; scoring for the task switching to give running instances a lower or higher score; being against two edit fields; not requiring aliases to begin with a special character).

Although I'm going to partly repeat myself and jgpaiva, here's what is important for me.
1. When using FARR, I want to type down what I have on my mind. This implies:
- A single edit field. I don't want to have to take care of which field I must type in.
- No special command character, whether prefixed or appended.
- No predefined action (e.g. starting the line with 'open ') that I have to delete first.
2. Multiple verbs should be possible - they would match the submenu grouping of the launch bar features (like 'mp3 enqueue').
3. Multiple params may be useful. Their order should be fixed (e.g. param1 always comes before param2), but the command verb should be allowed to change positions with the first param (e.g. 'cmd param1 param2 param3' should equal to 'param1 cmd param2 param3'). Note that the verbs and params should still be separated by a special key like TAB / ENTER / #, I'm just using spaces here for readability.

I agree that having a default command like 'open ' pretyped in the edit field would help new users to understand they can also enter commands instead of filenames. This wouldn't interfere with my personal requirements above (which are just the way I personally would love to see FARR) if the 'open ' default text would be preselected so I would overwrite it anyway. This wouldn't have any advantage when parsing the command line, but it would help new users. -> Even better: In Windows XP and above you can have edit fields display a grayed text that is automatically deleted when... oh well, when the edit field gains focus. Forget it.

Making it possible to switch between double editbox mode (the default setting for beginners) and single box mode ('classical') would be perfect.

Maybe we could start to collect commands we would like to have (although of course they could all be implemented by launching external applications, some of them should be included in FARR and the list of commands might reveal parsing problems that have to be considered by mouser when designing / defining the concepts).
- copy <file> {copies a file reference to clipboard so you can paste it in Windows Explorer, creating a copy of the file)
- cut <file> {copies a file reference to clipboard so you can paste it in Windows Explorer, moving the file)
- kill <task> {kills the task - should list both window titles and executable/module file names}
//edit: Ah, while I was still typing, jgpaiva had the idea of collecting actions, too. Good luck for your exam!

nontroppo · « **Reply #73 on:** February 07, 2006, 04:39 AM »

Sheesh, I go away for a few days and you guys write a books worth of ideas! Stop being so damn productive!

So we are hovering around a stack system / double edit box. Quicksilver is similar, except it doesn't show an edit box, but it does visually stack as object <> action <> option.

Looking forward to a document (mouser, are you going to use the wiki?)

mouser · « **Reply #74 on:** February 07, 2006, 04:42 AM »

great idea to use the wiki, yes that is exactly what i will do.