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

[jgpaiva]

I'm for the first option, mouser (and i think that nontroppo also is, right? ).
It is the most flexible one, as it allows to keep the interface farr has now, but with much more flexibility.
Only one proposition: When you type an action, it could like you said, copy it to the "then" box, but keep it in the same place that you wrote it, maybe with a different color, or something like that, to prevent you from getting confused. (it's not nice to see your cursor go back, to write another thing IMO).

For me, the first option you presented is just perfect, as i always launch the first option. I think the problem would ony arise when you want to specify an option in a result other then the first one. There would have to be the option to have ctrl + # (or something like that) to go to the actions over the # result.

[mouser]

I think the problem would ony arise when you want to specify an option in a result other then the first one.

yep, i modified my above post to discuss that..
we are getting warmer..

[jgpaiva]

Ok, checked your post, and i think there's a small minus in that.
To launch the first result with some action, i'd have to do:
screenshot captor{tab}{tab}launch
Which means one more tab then needed.
I still prefer the ctrl +# option. Or maybe instead of the first tab, you'd have to do {down arrow}, select a result with the arrows, and then hit tab to select the action.

[mouser]

if you're doing the default currently selected action you can just hit enter.
since the default action is "launch"
you could just type screenshot captor + ENTER

[jgpaiva]

Sorry, my mistake, i meant launching the first result, but with one other action other than the first.
How about this solution:
The disposition would be the first you proposed, 2 boxes at the top, and the results below.
And it would work the same way for both boxes. If you want a result other than the first, with an action other than the first, you do:
{partially write file} {down arrow}, to select the result from the results list. then, {tab}
{partially write action} {down arrow}, to select the option from the actions list, then {enter}

[jgpaiva]

I was thinking abou this, and i got to the conclusion that we might be over-complicating this problem.
The thing is that having farr parse a string in a way that makes sense is too dificult. And the 2 boxes- idea, just adds to the problem, as it becomes more and more dificult.

I have an inovative idea
How about instead of having poor farr trying to parse a string based on a lot of criteria, not have those rulles defined in each of the alias itself?
i.e. The alias would have the rules for what could come before or after it.
Right now, it is possible to do this, an alias with this regex:
(.txt) edit(.*)
with this line of execution,
c:\programas\pspad\pspad.exe $$1 $$2 |pspad $$1 $$2
Is close to execute what i'm referring to.

My idea is:
How about if initially, farr displayed every file and alias (the alias has to not need arguments before it) started by the letters you type.
Then, when you find the alias or the file you want, you press enter to launch it, or space to start another search based on your previous selection. Which means that if your first selection was a ".txt" file, "edit" alias could appear in the next option. If it was a .exe file, "edit" wouldn't have any sense, so, it doesn't appear.
What i mean is, have farr select a result on space, and the next results are based on that result.

This solution creates only 2 problems with prior requests:
1) The "f f" request, which would select firefox with the type of "f f", for which i can't find a solution other than typing "f*f".
2) The command line parameters solution, that i think can be fixed by adding a comma.I.E., "mini, capture" would make minicap capture the screen (if capture was the command line parameter that would acomplish that).

 

[mouser]

one problem with this is as you say, it makes it impossible to use spaces in the search.  so you cant use multiple words to narrow down a search, which was one of the most requested features for version 2..

[jgpaiva]

I just found out that the regex example i posted above doesn't work as i thought it would. I hope that you understand what i mean. *sorry*

[Jan-S]

What about nested commands in this two-box solution (see jgpaiva's post above)? I think they would be great, especially as they would nicely match the ideas of being able to add buttons and submenus to FARR to use it as a launch bar, too (submenus = nested aliases).
I think a single edit box would be better, and I also think you should be able to specify the command first OR search for the file first.
When you start typing, FARR just matches the string against all keywords (aliases, commands) and all files - the commands should have a special icon (user-definable) or maybe even some special text attribute (bold, underlined, colored). They should not have to begin with a special character (like *), but of course you can create your commands like that if you like it.
Pressing RETURN launches the first entry - no matter if it is a file or a command. Pressing a number key also immediately launches the specified entry.
Pressing TAB+TAB uses the first file, meaning you are then presented a list of possible actions. If you want to take another file and execute a special command on it, it should be possible to select it using the arrow keys and press TAB, or, which would be much faster, press TAB, followed by the number (I think it's important not to be forced to use the arrow keys).
FARR would have to display the current command / params stack (as suggested, but a textual representation should be enough), marking the position that needs to be filled next.

To execute jgpaiva's example 'mp3 enqueue somemusic.mp3' the following sequences would be possible:
"mp3" -> FARR recognizes the keyword and shows the 'mp3' command in the list, continuing to scan for files matching "mp3" nevertheless
TAB -> FARR adds 'mp3' to the command stack, empties the edit box and displays something like "mp3 > [?]" in the status bar; the list is populated with mp3's subcommands
"enq" TAB (or press #) -> Assuming that 'enqueue' was the first match for "enq", FARR adds 'enqueue' to the command stack, empties the edit box and displays "mp3 > enqueue > [?]" in the status bar; the list is populated with the last used files
"some" -> FARR lists all files that match "some" (BTW it could even list all matching directories or keywords that modify the search path)
# -> FARR adds the specified file to the command stack, finds that no additional params are needed and executed the command

Another sequence:
"some mp3" -> FARR lists all files that match "some mp3" (e.g. this could mean *some*mp3*)
TAB -> FARR switches focus to the list and shows that it is awaiting a file to be used with a command, e.g. displaying "? > [?]"
# -> FARR adds the specified file to the command stack (on the second position), restores focus to the edit box and clears it, displaying "[?] > somemusic.mp3". The list is populated with available commands that take a file as one of their params - this is transitive, e.g. 'mp3' is listed because it offers subcommands that accept a file param (or maybe 'mp3 > play' and 'mp3 > enqueue' should be listed immediately?)
"mp" -> FARR limits the list to all fitting commands that also match "mp"
# / Return / Space / TAB -> FARR takes the specified cmd / first cmd / first cmd / switches focus to list, adds 'mp3' to the command stack (first position), finds that 'mp3' is not satisfied with just a file param and thus clears the edit box (restoring focus to it), displaying "mp3 > [?] > somemusic.mp3", populating the list with all commands in the 'mp3' menu that accept a file param
"enq" & RETURN / # -> inserts 'enqueue' into the middle command stack position, finds that the command is complete and executes it

I think this is better because you can start typing rightaway what you have on your mind, not taking care of which box you are in. Also this approach would allow for commands accepting multiple params (e.g. two files or a file and a folder). It would be perfect if you could access submenus without having to press TAB, e.g. "mp3"-TAB-"enq" should equal to "mp3 enq" - when generally listing these commands in the format "mp3 > enqueue", "mp3 > play", "mp3 > mute", "inet > apache > start" etc. this should be possible without special treatment of commands.

[jgpaiva]

Mouser, how about using the prosition i posted, but instead of using space to accept the result, use tab, and space to narrow searches?
(the solution you posted has the same problem, if you type the action before you type the file on that action is to be executed, doesn't it?)

[mouser]

i like some of what Jan is saying, the idea that you can search for anything combined actions and files and the put it on the queue with a keypress, and using only 1 edit box.  does make things simpler in some ways.

i'm just trying to imagine how it will work when you want to select an item that isn't at the top of the results, and then how to change your mind about what you've queued up.

boy this stuff is really tricky.

[jgpaiva]

Good to know we're on the same page, jan-S!
I agree with you, replacing {space} with {tab} in my example might be the solution.

But i couldn't give a working solution for the launch of a command other than the first, and i think your solution also has a problem:
Even to select the first result, you have to do {tab}{tab}. Although it's a minor overhead, i think this could be solved with having f# selecting the option and alt + # launching it. This would be a smaller overhead, since the user could  press f# to select, then press enter to launch it with the default action.

@mouser: to delete something that already is in the queue, could be used ctrl + blackspace, or something similar..

[mouser]

part of the challenge is figuring out a solution that doesnt require opening the help file and searching for a day looking for the magic keystroke to do things..

it's hard trying to do all these things at once, make it suitable for newbies, and pros, and support all these different ways of working.

[Jan-S]

i think your solution also has a problem:
Even to select the first result, you have to do {tab}{tab}.

-jgpaiva (February 03, 2006, 07:33 AM)

Some combination like ALT+# would be ok, too, but I personally would rather tap tab (pun intended) twice instead of having to press a key combination. But as we are speaking of the command selection, # or RETURN alone would launch the command. The only problem with # / RETURN launching the entry directly is when selecting a file because we may want to execute a command on the file instead of executing it. That's what I suggested TAB, # for.

As for dequeuing: Both ESC and SHIFT+TAB should dequeue the last added item and return back to the appropriate list (e.g. when you are in 'mp3 > enqueue > [?]', ESC would return to 'mp3 > [?]'). Or did you mean something else?

[allen]

part of the challenge is figuring out a solution that doesnt require opening the help file and searching for a day looking for the magic keystroke to do things..

-mouser (February 03, 2006, 07:42 AM)

One thing to consider is something I've seen in several applications in recent years -- a section of the help file devoted exclusively to listing keyboard accellerators and link directly to it in the help menu.

As for keeping it newb friendly -- the keystrokes and stuff aren't likely going to be used by anyone but power users, so it seems the trick there is to have all those available shortcuts available as items in a right click contect menu as well as, perhaps, a drop down button in the toolbar.  An "actions" button, so to speak.

[Jan-S]

You could also use the status bar (or an optional "help" bar) to tell the user what is currently possible - e.g. when a command is currently the first item, you could display "RETURN/SPACE/#: executes command, TAB/arrow: go to list" and when a file is the first item: "RETURN/#: launch file; TAB: select file to use with command" and so on.

[jgpaiva]

One thing to consider is something I've seen in several applications in recent years -- a section of the help file devoted exclusively to listing keyboard accellerators and link directly to it in the help menu.

-allen (February 03, 2006, 08:00 AM)

I sure agree with you, all this will have to be well documented, so as everyone can know how to use the power we are generating here

As for keeping it newb friendly -- the keystrokes and stuff aren't likely going to be used by anyone but power users, so it seems the trick there is to have all those available shortcuts available as items in a right click contect menu as well as, perhaps, a drop down button in the toolbar.  An "actions" button, so to speak.

-allen (February 03, 2006, 08:00 AM)

Here, i don't agree with you. I think we should try to fins a solution that is both suitable to power-users as much as intuitive, so as someone new to farr can see it's power immediatelly. As it is often descibred, most people when trying to use a software, only evalute it in the first use, which means that these kind of functions should be as easy as possible, but also providing as much flexibility as possible. IMO, that's the problem with powerpro, for example, os even my former shell, blackbox. Although being immenselly powerfull and configurable, the average user rejects it imediately, because it's to complex to handle.

Jan-S: that status bar idea is great, exactly what mouser was referring to, having the help file without opening the help file

The problem i was referring before with the {tab} action, is that tab's would have 2 different uses aren't very well specified, and i don't think it should behave differently when there is a file or an alias, or when it is the first item or not, the idea is make everything work the same way, i think.
My point is that seen that you will be using the arrows to select the result from the result list, the way to access it should be with the down arrow (or up arrow, to start at the other end of the results, maybe). Or instead, use a number combined with a modifier, something like that.

I think that esc to go back one level is a good idea, and shift-tab is even better, since you make the queue with tab, it makes sense to dequeue it with the oposite 

[allen]

As for keeping it newb friendly -- the keystrokes and stuff aren't likely going to be used by anyone but power users

-allen (February 03, 2006, 08:00 AM)

Here, i don't agree with you. I think we should try to fins a solution that is both suitable to power-users as much as intuitive, so as someone new to farr can see it's power immediatelly.

-jgpaiva (February 03, 2006, 08:42 AM)

I don't disagree with you on this point -- I absolutely agree that it should be intuitive regardless of experience level.  All I'm saying is no matter how much brainstorming you do to have optimized keyboard shortcuts, keyboard shortcuts are not par for the course for less experienced computer users.  My point was that there should be an alternate method or methods of accessing all this functionality without expecting a point-click user to use the keyboard.

As it is often descibred, most people when trying to use a software, only evalute it in the first use, which means that these kind of functions should be as easy as possible, but also providing as much flexibility as possible.

-jgpaiva (February 03, 2006, 08:42 AM)

Right, which is precisely my point.  There needs to be a quick, easy way to access the features from the start -- if a user has to spend the beginning of their trial of the software learning a bunch of proprietary keystrokes, they're going to throw in the towel.  Give them things to click on, and display the shortcuts next to the menu items or in tooltips and they'll have their GUI interface and the shortcuts will be right there for them to learn when they're ready.  It's not difficult to hit "enter" after typing a website, but users want a "go" button, you know?

[jgpaiva]

It's not difficult to hit "enter" after typing a website, but users want a "go" button, you know?

-allen (February 03, 2006, 08:59 AM)

Got your point allen I understood you completelly wrong
I also think that it is not to forget that there has to be a more (even more??) straight-forward way to do it. And your statement gave me an idea. How about having a "launch" button and a "with.." button?

[Jan-S]

The problem i was referring before with the {tab} action, is that tab's would have 2 different uses aren't very well specified, and i don't think it should behave differently when there is a file or an alias, or when it is the first item or not, the idea is make everything work the same way, i think.

-jgpaiva (February 03, 2006, 08:42 AM)

That's right, it might be confusing. However, I wouldn't know how to make it faster / easier. The different TAB behaviours between files and aliases/keywords are just because we can speed things up for commands as we don't need to distinguish between 'open it' and 'use it (= combine it with a command)'.

My point is that seen that you will be using the arrows to select the result from the result list, the way to access it should be with the down arrow (or up arrow, to start at the other end of the results, maybe).

-jgpaiva (February 03, 2006, 08:42 AM)

When you are using the arrows, the down arrow should bring you to the list as usual. But I wouldn't like to have to use the arrows to browse to the 5th entry to select it. We definitely need a way to use the number keys - still being able to distinguish direct execution of a file entry from pushing it to the command stack.

Or instead, use a number combined with a modifier, something like that.

-jgpaiva (February 03, 2006, 08:42 AM)

This would probably be less confusing and maybe should be the default behavior. If you did a search for files and want to execute an action on a file (but not on the first match), you have to press MOD+# (with MOD being configurable as it already is) or use the arrow keys and press TAB. However, I personally am slower at using a combination like ALT+# (firstly it is slower to type and secondly I have to remember if to use ALT or CTRL or both) and would rather like to press TAB followed by the number. TAB would still have the single meaning of "combine commands" or something like that - it is always used in this context. This doesn't need to be the default behaviour, though.

I think that esc to go back one level is a good idea, and shift-tab is even better, since you make the queue with tab, it makes sense to dequeue it with the oposite

-jgpaiva (February 03, 2006, 08:42 AM)

Actually it's not my idea, I've read that SHIFT+TAB is used by Quicksilver (in another thread). And again, ESC is easier to use than a key combination here, but nothing speaks against using both shortcuts here, does it?


@allen: ACK. All these things should be available in context menus, too - e.g. doubleclicking a file entry will open the file while the context menu will have a submenu like 'with this file do >' (or similarly). And just entering a program name and pressing RETURN should still immediately execute it because this is what users will expect.

How about having a "launch" button and a "with.." button?

-jgpaiva (February 03, 2006, 09:06 AM)

Good idea, too! Pro users should be able to remove them, though And the buttons could have a "return key" and a "tab key" icon so users will eventually try them and notice how much easier this can be

[Amadawn]

Wow! This is an interesting thread!

mouser, you talk about having the first word be always a verb. In my opinion that causes a problem because most of the time what you want to do with FARR (or at least that is what I want) is to find SOMETHING. So why not do as QuickSilver does, and require always to have first a "SUBJECT" (i.e. what we are going to work with), then a verb (what we are going to do with it, which by default would be launch) and finally an object (if the VERB requires another parameter, like where to copy a file for instance).

I think that would solve the problem because you would get the current, default behaviour (which is what you normally want) but can still add modifiers to the task at will. Also it does not limit you to actions that work on a single file.

Amadawn

[mouser]

i think its impossible to do what we want and have subject first.
the only choices are always verb first, or combined verb+subject first.

why cant you do subject firt? well because we want to support things like being able to say:
"email [email protected]"
or
"define subjunctive"
or
"google happiness"

ie after you type the verb only then does it know how to interpret what you type.


but we could stick with the approach we have now which combines the two and tried to guess what you want.


requiring a verb first (which would default to "launch" if you hit space or tab) would make life a lot cleaner.

the main problem is it makes the 95% case more troublesome.

[jgpaiva]

OK Jan-S, i think you got me convinced
Double-pressing TAB to select the first result seems the right solution to handle all the problems.

I think that now this solution has came to a mature state, it can successfully handle all the cases and is both intuitive and powerfull, now, let's hear the word of the "headmaster" (aka mouser  ), and i think it would be nice if other Farr-using members could post their opinion (who knows, there might be a better way to do this? ).

Actually it's not my idea, I've read that SHIFT+TAB is used by Quicksilver (in another thread). And again, ESC is easier to use than a key combination here, but nothing speaks against using both shortcuts here, does it?

-Jan-S (February 03, 2006, 09:11 AM)

Yes, i agree that ESC is easier to use, but SHIFT+TAB makes more sense. This only proves that not always the most intuitive way of doing things is the easier way

As for the manuals and help files for this, i hereby officially offer myself to do (at least a few) screencapture animations of how to do use these new features.

Pro users should be able to remove them, though

-Jan-S (February 03, 2006, 09:11 AM)

I agree, having the possibility of removing them would be nice, since Farr will also become a launchbar, you want to have as much space available as possible

And the buttons could have a "return key" and a "tab key" icon so users will eventually try them and notice how much easier this can be

-Jan-S (February 03, 2006, 09:11 AM)

Agreed!  

[jgpaiva]

the only choices are always verb first, or combined verb+subject first.

-mouser (February 03, 2006, 11:39 AM)

So, does this mean that the right approach is the context-sensistive groups?

[Amadawn]

i think its impossible to do what we want and have subject first.
the only choices are always verb first, or combined verb+subject first.

why cant you do subject firt? well because we want to support things like being able to say:
"email [email protected]"
or
"define subjunctive"
or
"google happiness"

ie after you type the verb only then does it know how to interpret what you type.


but we could stick with the approach we have now which combines the two and tried to guess what you want.


requiring a verb first (which would default to "launch" if you hit space or tab) would make life a lot cleaner.

the main problem is it makes the 95% case more troublesome.

-mouser (February 03, 2006, 11:39 AM)

OK, I understand the issue. However, I still believe that there must be a way to cover all cases and keep everybody happy.

As you say, the cases in which we absolutely need the verb to come first correspond to perhaps 5% of the functionality of FARR. Those, I believe, can be covered as "special cases" where the user can define "keywords" that when selected would require some additional parameter.

But if the user types/selects any other item, it could then simply type the name of one of the actions linked to that action, and perhaps follow by another parameter.

For instance:

Type: tax<tab>(finds "tax plan.doc") em<tab>(finds "email to")[email protected]<ENTER> (eventually FARR could even search in the addres book, but that's another issue). This sends "tax plan.doc" by email to "[email protected]".

But you could also type:
define<tab>(finds "action define:", stops searching for stuff)rose<ENTER> which fires the default web browser and looks for the definition of "rose".

I think that this method has the advantage of being very intuitive, covering all cases and requiring very little keypresses. Of course if at any point there is some ambiguity (like for instance if there were both a "tax plan.doc" and a "taxi address.txt" the user would need to use the keyboard arrows or the Ctrl+number technique to select the one that he wants. Same thing for actions, where instead of typing "em" you could simply use the arrows to select "email", "copy" or whatever other actions supported by that file type.

I agree however that this might be complicated to code, but hey, you are the wizard coder and the one that seemed eager to solve a complex UI puzzle!