topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Tuesday March 19, 2024, 3:48 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

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

jgpaiva

  • Global Moderator
  • Joined in 2006
  • *****
  • Posts: 4,727
    • View Profile
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #25 on: February 03, 2006, 04:20 AM »
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

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #26 on: February 03, 2006, 04:21 AM »
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

  • Global Moderator
  • Joined in 2006
  • *****
  • Posts: 4,727
    • View Profile
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #27 on: February 03, 2006, 04:28 AM »
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

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #28 on: February 03, 2006, 04:31 AM »
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

  • Global Moderator
  • Joined in 2006
  • *****
  • Posts: 4,727
    • View Profile
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #29 on: February 03, 2006, 04:36 AM »
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}
« Last Edit: February 03, 2006, 04:41 AM by jgpaiva »

jgpaiva

  • Global Moderator
  • Joined in 2006
  • *****
  • Posts: 4,727
    • View Profile
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #30 on: February 03, 2006, 06:19 AM »
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).

 :feedback: :feedback:

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #31 on: February 03, 2006, 07:09 AM »
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

  • Global Moderator
  • Joined in 2006
  • *****
  • Posts: 4,727
    • View Profile
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #32 on: February 03, 2006, 07:10 AM »
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

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 23
    • View Profile
    • Big Bang enterprises
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #33 on: February 03, 2006, 07:12 AM »
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.
Jan Schlüter, author of DoubleKiller and DoubleKiller Pro
« Last Edit: February 03, 2006, 07:17 AM by Jan-S »

jgpaiva

  • Global Moderator
  • Joined in 2006
  • *****
  • Posts: 4,727
    • View Profile
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #34 on: February 03, 2006, 07:13 AM »
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

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #35 on: February 03, 2006, 07:27 AM »
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

  • Global Moderator
  • Joined in 2006
  • *****
  • Posts: 4,727
    • View Profile
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #36 on: February 03, 2006, 07:33 AM »
Good to know we're on the same page, jan-S! :D
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

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #37 on: February 03, 2006, 07:42 AM »
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

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 23
    • View Profile
    • Big Bang enterprises
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #38 on: February 03, 2006, 07:51 AM »
i think your solution also has a problem:
Even to select the first result, you have to do {tab}{tab}.
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?
Jan Schlüter, author of DoubleKiller and DoubleKiller Pro
« Last Edit: February 03, 2006, 07:55 AM by Jan-S »

allen

  • Charter Member
  • Joined in 2006
  • ***
  • Posts: 1,206
    • View Profile
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #39 on: February 03, 2006, 08:00 AM »
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..

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

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 23
    • View Profile
    • Big Bang enterprises
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #40 on: February 03, 2006, 08:12 AM »
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.
Jan Schlüter, author of DoubleKiller and DoubleKiller Pro

jgpaiva

  • Global Moderator
  • Joined in 2006
  • *****
  • Posts: 4,727
    • View Profile
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #41 on: February 03, 2006, 08: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.
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.
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  :Thmbsup: :Thmbsup:

allen

  • Charter Member
  • Joined in 2006
  • ***
  • Posts: 1,206
    • View Profile
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #42 on: February 03, 2006, 08:59 AM »
As for keeping it newb friendly -- the keystrokes and stuff aren't likely going to be used by anyone but power users
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.

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.

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

  • Global Moderator
  • Joined in 2006
  • *****
  • Posts: 4,727
    • View Profile
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #43 on: February 03, 2006, 09:06 AM »
It's not difficult to hit "enter" after typing a website, but users want a "go" button, you know?
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? :D

Jan-S

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 23
    • View Profile
    • Big Bang enterprises
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #44 on: February 03, 2006, 09:11 AM »
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.
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).
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.
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 :Thmbsup: :Thmbsup:
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? :D
Good idea, too! Pro users should be able to remove them, though :D 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 Schlüter, author of DoubleKiller and DoubleKiller Pro
« Last Edit: February 03, 2006, 09:14 AM by Jan-S »

Amadawn

  • Charter Member
  • Joined in 2006
  • ***
  • Posts: 86
    • View Profile
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #45 on: February 03, 2006, 11:32 AM »
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

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #46 on: February 03, 2006, 11:39 AM »
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

  • Global Moderator
  • Joined in 2006
  • *****
  • Posts: 4,727
    • View Profile
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #47 on: February 03, 2006, 11:41 AM »
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  :tellme:), 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? :D ).

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?
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 :D
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 :D

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 ;)
Agreed!  :Thmbsup: :Thmbsup:

jgpaiva

  • Global Moderator
  • Joined in 2006
  • *****
  • Posts: 4,727
    • View Profile
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #48 on: February 03, 2006, 11:43 AM »
the only choices are always verb first, or combined verb+subject first.
So, does this mean that the right approach is the context-sensistive groups?

Amadawn

  • Charter Member
  • Joined in 2006
  • ***
  • Posts: 86
    • View Profile
    • Donate to Member
Re: FARR version 2 - discuss the best way to handle 'actions'
« Reply #49 on: February 03, 2006, 04:32 PM »
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.

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! :)