DonationCoder.com Software > Find And Run Robot

FARR version 2 - discuss the best way to handle 'actions'

<< < (12/16) > >>

jdmarch:
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:
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:
jd can you talk a little bit more about what you think the ideal way would be to tell farr to switch tasks?

jdmarch:
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:
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page