DonationCoder.com Software > Find And Run Robot

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

(1/16) > >>

mouser:
the single most unresolved issue at the moment for me regarding farr (aka "Mercury Runner") is the best way to be more flexible about letting the user choose "actions", which is a request that has been made several times before.

let's look at the different things people want to be able to do:

1) find an application program on the start menu and launch it - the main intended function of farr, and still the dominent use and most important thing to do efficiently.

here we want speed and ease of launching, so we have incremental search based on program name, followed by a simple hitting of digit key, or alt+digit key corresponding to its number, or hitting enter once or twice if its at the top of the results.  or double clicking the result of our choice.


2) using alias groups
here we have a preset group of applications or documents that we want to treat like a named menu.
we type the name of the menu (or partial), and then again simply hitting of digit key, or alt+digit key corresponding to its number, or hitting enter once or twice if its at the top of the results.  or double clicking the result of our choice.


3) use a regular expression to specify a command with an argument
here the user types some string like "define subjunctive verb"
and the keyword "define" matches a regular expression which knows how to grab the "subjunctive verb" string and knows to present one or more actions associated with the keyword which the user can launch just as above cases #1 and #2, simply hitting of digit key, or alt+digit key corresponding to its number, or hitting enter once or twice if its at the top of the results.  or double clicking the result of our choice.


4)  suppose instead of launching a program you want to open a document.
this is also easy, you can search for a document by typing the name of the document; it is incrementally searched for just like any other file.
now you have a list of candidate matches in your result list.
if you want to do the default opening of the file, like a double click would do, you can, as in cases 1-3 above simply hitting of digit key, or alt+digit key corresponding to its number, or hitting enter once or twice if its at the top of the results.  or double clicking the result of our choice.

cases 5+ are next..

mouser:
ok now the trouble starts.


5) but suppose instead of opening the document you want to perform some other ACTION on a DOCUMENT.

this is where farr does not seem as easy to use.

now you basically search for the document, and then you have to select the result you care about and then trigger the right click context menu, which presents you with some common options, or select a submenu items to view the default system shell menu, where you can perform other operations.

it's not very efficicent or keyboard centric.


it is this case #5 that i think we are trying to find a useful solution to, in terms of presenting a gui interface.


it would be nice if we could figure out a solution that let you choose ACTIONS to perform on files in the same kind of keyboard centric incremental search system used to select files.

sort of like, first you select the file, then you could hit some special key and be shown a menu of actions like "open, delete, zip, etc." which you could then select using number keys, or search and refine by typing letters, etc.

it seems quicksilver supports something like this, and our mission is to find the perfect solution, which does not interfere with cases 1-4 above.




6) an alternate but similar approach might be when you know the ACTION first and then want to search with stuff that matches that operation.
for example nontroppo has talked about process management,
so maybe you want to be able to type:
"kill "
and then see a list of running processes which you could choose from and hit enter to kill.

in this case, the first word you type someone is detected as an ACTION which then presents a context sensitive list of results (here processes, but other times maybe the normal full file searching).


the problem is it's not always easy to resolve the inherent conflicts in these cases.

jgpaiva:
That description is just perfect, nice way to organize things ;)

My 2 cents for the problematic questions:

5)
How far are you on ContextMenu Commander? Maybe it would be the solution to this problem.
Something like this: The user selects the actions he wants preformed for each type of file (maybe in the Pattern Scoring dialog) based on it's explorer context menu and Farr actions (add to aliases, add explicit rule, etc..).
And then, when executing Farr, the user presses tab and the actions menu appears on the right half of the results menu (this would make the results menu have to be quite large). The next thing the user writes, is the name of the option from the options menu. Enter, would launch the first result on both windows (ie, the first action on the first result). Alt + # would trigger #result with first action, and ctrl + # would trigger first result with #action. ctrl + alt + # selects the #result, and waits for another keypress with the number of the option to launch.
Another aspect is: after the search, the results window appears, the user presses tab, the actions menu appear, and if the user presses down, it allows to select one result, press enter to select it, then the focus changes to actions menu, and the user selects the action to be performed.
One note on this interface: for this to really make sense, the right keys to be used, should be ctrl + # to launch # result, and alt + # to launch # action, since ctrl is on the left, and alt on the right.
I think this method is quite consistent and doesn't interfere with the first results.

6)
I haven't thought much about this, but maybe you could have aliases defined for actions, and when you write the aliases, the action menu appears, and you press tab to search for the file to do the action on?
(This is not very consistent..)

nontroppo:
Good to see this discussion. i had raised this some time ago, trying to see how we could get the context menu amenable to keyboarders in an intuitive way.

The context is really what quicksilver excels at. I don't know much about your contextmenu utility, but maybe this can help? Can you give us a bit more info?

For the GUI it seems easier. For FARR, we start writing and FARR does its magic. At the moment we have focus in the text box. I see two things we may want to do next:

1) Select from the list: <up> and <down> arrow changes our list selection (which defaults to the first item normally). It would be neat that the focus is not taken off the text field (as it is currently). <TAB> does the same thing.

2) Do an action with our selection: just as with our list we had a "default" item, with actions there should be a default action. To activate actions, I'd recommend using the <right arrow> (activates the action pane even if we have focus in the text field), or <TAB> if somehow our focus is already in the list.

In these cases, <enter> executes the selected list item with the selected action. If the focus is in the text field, then it uses the defaults.

Thus we can keep typing, select the list with up/down and toggle whether we select items or actions with tab or left/right.

Here is a mockup for how actions can be presented. The panel slides out when a key that triggers an action selection occurs. This is normally hidden:
[attachimg=#1][/attachimg]

mouser:
have a menu that pops up (or slides out AFTER you select the item and hit a key) is not technically hard,
but i keep thinking of wanting to choose actions through a similar key-based menu (like with alias groups) or incremental search..

for example:

what if you when you hit alt+1 (or hit enter once or twice) it would launch result 1.
but if you hit ctrl+1 it displayed in the status bar like "With Ethereal.lnk do.." and then in the results list appeared all the actions appropriate for that file (launch, delete, zip, etc.). which you could then search within, etc.

i don't know, feels like of messy and confusing, but you see what i'm trying to get at, to bring the actions into the same search based system rather than a menu.

an action menu may still end up being the best way to go but it just seems not quite to fit with the method.

i cant help but think there is a wonderful user interface puzzle here that we might be able to solve somehow..

like here is a CONSISTENT solution that would work, but it would require some adjustment to thought process.

one solution might be like a special character saying you are specifying an action, like you would type

dylan *edit

that would basically search filenames for "dylan" and searching ACTIONS for "edit"
we'd still have to find a way to show the list of actions..

the thing is that 95% of the time people arent going to be using actions, so altering the display for this case seems troublesome.

Navigation

[0] Message Index

[#] Next page