farr v2 planning - use cases and action idea

[mouser]

i did come up with what i think might be the clearest description of the source of the major conceptual problem for the farr v2 interface.

and that is that the major "use cases" are somewhat in conflict.

Use Case One:
User has a program/file in mind, and wants to type in the name of that program, and then optionally specify an action relevant for that program/file from a nice context-relevant list (maybe with action search at that point).

Use Case Two:
User has an ACTION in mind, and wants to type in that action and THEN perhaps be presented with relevant parameters or files to operate on (maybe with action-context-relevant file search at that point).

[jukla]

Mouser,
All my FARR-use so far falls under Case One. I don't even understand when Case Two would apply. Can you give an example of such a case?

(The only thing I can think of would be a case where a user is not sure what exactly he's looking for, thus choosing for example only action "edit image" which then filters the search to only include editable images. But that could be had more directly through a filter for image file types.)

I find that 99% of the target files for my searches are for one of these file type categories (in the order given):
text (txt, pdf, doc ...)
application/script (exe, bat, vbs ...)
image (png, jpg, gif ...)
music (mp3...)

If many other users use of FARR also fall into a few categories like that, then filters of the kind I described above would be ideal.

BTW, It would be interesting with a poll on what kinds of searches FARR-users actually do!

[nitrix-ud]

IMHO, case TWO is quite relevant !

2 examples come to my mind :

1) i'd like to use FARR as a code snippets finder, i have a growing list of snippets stored in text files (this is really easy to maintain and manage with great file explorer such a Directory Opus 8, but that's another subject), i'd love to do that :
type : snippet php
and boom all my php snippets right there and it's only snippets, it's not mixed with other things

2)i'd like to use FARR to launch AI Roboform passcard
same use :
robo bank
boom all my bank accounts right there (not so many )

I really think this would be quite amazing and so fast !

Cheers, Nico
 

[jukla]

nitrix-ud,

Both your examples seem to involve narrowing FARR's search to only look for a specific type of file and/or in a specific folder. That's what I meant by filters above (and wanted to snap on/off through hotkeys). So in fact we agree that that'd be a good feature! 

But Mouser's Case Two explicitly involved a user having an action, rather than a file of a certain type, in mind. But maybe I'm just getting stuck in the semantics here - maybe he was really thinking of something similar to your examples. In that case we ALL agree.   

Cheers

[mouser]

if we imagine the entire set of "actions" and the entire set of "files",
then choosing an action narrows down the list of possible files you could be referring to,
and choosing a file narrows down the list of possible actions that could be applied.

and then you could add "modifiers" which further narrowed down both lists.

the problem i present is not significant if you assume that the results window only ever shows FILES.

then you could day that a user could start typing:
"PLAY bo"
where PLAY was an action (play an mp3 file) which would also make farr narrow down the coming search to only be of mp3 files containing bo.

then when you hit enter it would play the file.
in this case PLAY acts like a modifier AND it also specifies the ACTION to apply when you hit enter.

you might also have a command called
TAGEDIT

which says that you are going to be applying this action to an mp3 file, and you want it opened in your favorite mp3 tag editor.

so if you type "TAGEDIT bob"
it would end up showing all mp3 files with bob in their names, and when you hit enter it opens the file in the tag editor.


Now, as i've described it so far, there is no user interface quandry,
because we're saying that the results window only ever shows FILES (mp3 songs in my example above).
and we've just added the possibility of specifying ACTIONS which act like modifiers but also say what happens when you press enter.

The problem comes in when we want to *help* the user choose a relevant ACTION.

This impinges on the realm of group aliases as we currently have them - where what you type matches against not only files but alias regular expression commands.

And the same problem comes up whether you specify actions before or after.

For example,
imagine my "TAGEDIT bob" example above..
What happens as i'm typing "TAGE"?

Is it trying to find files with TAGE in them?
Wouldn't we want it to be helping me remember my list of available commands and reminding me about TAGEDIT in case i forget how this action is spelled, and to let me not have to type the whole thing in?

Same thing applies if we let user specify action later.

If the person types "bob dy" and then selects "bob dylan's dream" from the results list,
and now wants to perform an ACTION on this song - we want a way for them to select an action without having to use mouse context menu.

to think of another way this problem rears its head, just ask yourself
what happens when a MODIFIER is half-typed?
will it totally mess up the current search - because farr will be trying to match it against the file name list.

In some sense a solution would be like two side-by-side results and search windows,
one for actions, one for files
and let users have two keyboards so they can type in both at the same time and restrict results in both windows.

[jukla]

Mouser,

Ok, I see the problem now.

"and let users have two keyboards so they can type in both at the same time and restrict results in both windows."

Let them have four hands too 

One could perhaps handle the problem with FARR interpreting misspelled action modifiers as regular search terms by demanding some unusual prefix letter before all actions. Alternatively, when pressing some hotkey, FARR interprets the next term as an ACTION specification (and highlights the term to show that the hotkey worked)
A downside is that users must press an extra letter/hotkey.

With risk of repetition, another solution is to sidestep the problem more generally by letting users specify actions and/or filters for file-types or certain folders through hotkeys alone. (Yep, I'm turning more and more into a hotkey fanatic)

GOOD THINGS WITH HOTKEYS:
- Hotkeys have less ambiguities - either you press the right one or you don't.
- When known, hotkeys are faster than typing.

BAD THINGS WITH HOTKEYS:
- Users may fail to memorize them, making them slower AND frustrating.

But that can be handled by some hotkey help displayed in the GUI, like the L i illustrated or like how Adobe Photoshop shows alternative actions in the taskbar when for example CTRL is held down.

- There's tension between uncomplicated hotkeys and having many alternative actions/filters to choose from. Handling the latter through hotkeys necessitates more complexity. Which take more time and more effort to remember.

But I think a good trade-off would be to
(1) to (as said before) guide the hotkeys through help in the GUI and
(2) limit them to one- or two-key-combos. For example: simple hotkeys = one of CTRL/ALT/SHIFT. More complex hotkeys = simple hotkey + another key (perhaps right SHIFT can be used for that?). That give's six modes in addition to default. Wouldn't that cover most usage for most users?  The rest could be handled via context menu.

Also, if the hotkeys are given different usage for when the search field is in focus (call them search modifying hotkeys) and results list is in focus (call them action specifying hotkeys) we get six file/folder filter modes and six action modes from only four keys (in addition to the default modes).

[jgpaiva]

@jukla:
I'm not much for hotkeys, let me explain you why:
hotkeys are counter-intuitive, someone that uses the program for the first time, doesn't know them.
hotkeys aren't dynamic, you have to set them up
hotkeys are limited, which means that you'd only have a bunch of actions
lots of people have several hotkeys set in their system, that might conflict.

The rest could be handled via context menu.

-jukla (May 19, 2006, 04:53 AM)

That's the thing here, right now, we can play mp3 files through the contex menu, what we'd like would be to be able to not use it, just have that action predefined.

I just came up with this idea: (which has been already proposed in a similar way)
as farr will have indexing, at the time of creation of this index, when evaluating each of the files, it could see what the right-click context menu allows to do with that file (this is the hard part, i think), and generate a bunch of actions, each of them with a every file that can have that action.
then, we'd only type the action (and the blank list would include files and alias), and when it had a match, we press [enter]/#/whatever, and then, search for the file we want to apply that action to.

The limitation of the above is that we can only have actions applied to single files, but it'd have the good thing that, just as it is now, farr wouln't need any configuration to have it's full functionality.

To complete this system, there could be a way to set alias that would take more than one file, and would know what to do with them (example: move "from" "to").

[mouser]

One could perhaps handle the problem with FARR interpreting misspelled action modifiers as regular search terms by demanding some unusual prefix letter before all actions.

this is an interesting possibility.. it has been raised before but i always though, ok let the user create their own regex aliases with a special prefix if they want but don't force it.

however, if we said that all actions start with some character (say $ or ` or  . or whatever), then that might solve the core of this dilimena, in that anytime a word starts with $ then farr knows the users is specifying a modifier or action and it would NOT be involved in narrowing down file names (except to the extend that it matches a modiifer name).

then we could have action searching either in the results window temporarily, or in a separate window or edit field.

so for example, revisiting my example above, if you type "bob dyl" and then you've got 3 results of bob dylan songs, you could then type
'bob dyl +tagedit"

and then hit enter for #1, farr will know you want to perform the tagedit operation on file result #1.

furthermore it would let you type
"+play bo"

and +play would act both as a modifier restricting search to mp3 files and as an action specifier for when you hit enter.

you could also use it as a pure modier like "+mydocs bob dy"

the other nice thing about having a special character for actions is it lets farr HELP YOU when you start typing a modifier
so that when you type "+m" it could remind you of matching modifiers as a hint.
it could do that EITHER by temporarily changing the results list to a list of matching modifiers/actions, which you could select by number,
OR it could use a secondary results box of available actions (same input field different results box), or it could insist you always fully type out a modifier but give you a little hint about matching modifiers/actions in some little box somewhere, OR it could provide some kind of autocomplete.

at this very moment im feeling like this might offer the key solution to letting us move forward on this.. there would still be some hard decisions about user interface but i think this might solve the core of the use case dilemna i have been struggling with.

-

i tend to agree with jgpaiva in terms of hotkeys; some people love them - i personally can NEVER remember any, so they just drive me crazy.  i like that farr is meant to let users just start typing and not have to remember anything.

having said that, i like the idea of being able to allow experts to specify hotkeys for any modifiers/actions, but it should be optional and not central to use.

[mouser]

i really would like to hear some thoughts from nontroppo and others involved in past farr v2 planning discussions.

[jdmarch]

I appreciate that this  topic is being clarified. Unfortunately I won't be able to attend to it until mid-June.

[nontroppo]

i need to sit down and read over the weekend - I will get round to it 

[Jan-S]

I think I'd still prefer the TAB-based approach discussed in the last thread, but I see that the special character approach is easier to implement.
You should be able to customize this character, though, as not all keys are easy to reach on all keyboards (e.g. I would prefer a dash as a command prefix). Secondly, the existing group aliases should still be accessible without a prefix. And thirdly: Do you still think of the multilevel keywords that would go with the launch bar features (being able to specify menus and submenus and access them via toolbar buttons or by typing them into the search field)?

when evaluating each of the files, it could see what the right-click context menu allows to do with that file (this is the hard part, i think), and generate a bunch of actions

-jgpaiva

Cool idea. With the TAB-based approach it would be enough to only do that for a single file after the user chose a file and pressed TAB. But even with multiple files this is not hard to implement as Windows takes care of finding actions that apply to all files in a certain set of files (try selecting multiple files of the same type and then multiple files of different types in Windows Explorer and compare the context menu) - @mouser: contact me if you can use some example code I've written in Delphi.

[jgpaiva]

farr v2 is back in discussion! 
Let's see...

I think that after so many discussions and thinking about this matter, the modifier might really be the best solution. It's much more flexible, and makes the parsing much easier (and faster ). I'm with Jan-S, thought, it needs to be costumizable, because in different keyboard layouts, some modifiers might not be fit.

As for hotkeys, modifier hotkeys might have one problem: they already exist right now, ctrl, alt and ctrl+alt are already used for different launch methods for farr.

Now for things that i think might need to be further discussed:

• Is the automatic action detection possible?
• How would the setting up of the actions be made?

[jukla]

jgpaiva (on hotkeys):

hotkeys are counter-intuitive, someone that uses the program for the first time, doesn't know them.

Often true, but not if the hotkeys are few and simple and help is displayed in the GUI. Like pressing CTRL in Photoshop and seeing the title of the special action in the taskbar.

hotkeys aren't dynamic, you have to set them up

Yes, but there could be helpful templates. And some default hotkeys (narrow search to text, to music etc) that'd work for many persons.

hotkeys are limited, which means that you'd only have a bunch of actions

True, but how often are more than "a bunch" of actions for a file type needed? If seldom, then falling back on context menu in those cases would be more efficient than alternative solutions, since users might forget a seldomly used action's name in FARR and/or spelling (but recognize it when seeing it in a context menu).

lots of people have several hotkeys set in their system, that might conflict.

True, but the risk is small if the hotkeys are limited to one-key-hotkeys like CTRL, SHIFT or ALT since no app makes (or should ever make) a single press of CTRL etc into a GLOBAL hotkey.

jgpaiva (later post):

As for hotkeys, modifier hotkeys might have one problem: they already exist right now, ctrl, alt and ctrl+alt are already used for different launch methods for farr.

True. That could be changed, but I admit that it's a drawback.

Ok, I'll rest my hotkey craze now. 



Regarding a modifier prefix: File names never begin with a space, right? If so, then a space at the start of the search box could work as prefix. FARR could read anything that matches [initial space + string of letters without space + space] as a modifier.

Example: " mp3 moby" would search mp3-files with string "moby" in name

That's perhaps quicker than using some other prefix, especially some unusual key.

Drawback1: might collide with some other use of the space bar in FARR?

drawback2: only supports one modifier.

But multiple modifiers COULD be handled by a suffix (though that would complicate things) at the end of a string of multiple space separated modifiers.

Example: " vbs edit# xmltv" would search vbs-files (=VBscript) in folder NNN with string "xmltv" in name and set default action to edit

Another alternative would be a special letter between each extra modifier.
Example: "+" in " vbs+edit xmltv"

[mouser]

the most important part of this idea is that the special key comes as a PREFIX to an action/modifier,
so

+vbs +edit xmltv

or

`vbs `edit xmltv

or
xmltv +vbs +edit

(all would mean same thing; user can change prefix character)

the reason this is so important is that farr can know that when it sees the prefix, then the typed characters afterware do NOT narrow down the search for filenames.

now we still need some feedback for actions and mofiers.  we would have lots of choices:
1) when you type the modifier prefix, the results switch to a list of matching actions until you finish typing the modifier
2) any string you type after the modifier prefix would be "auto-completed" (ie auto-suggest word completion as you type)
3) we could have another pop up results mini window for possible matching actions/modifiers
4) we could have a simple 1 line reminder of matching actions

(the point of the 1-4 above is to give some kind of feedback/reminder for modifier keywords so you have some help remembering them)

then ANOTHER issue is after you finish typing and have a result list of files,
and there is more than one possible action applicable, how does user choose action.
if there is only one then we can just run it.

what about have 2 result lists.
one for files, and one for actions.

the action list will show relevant actions for the selected or currently viewed files.

[jukla]

the most important part of this idea is that the special key comes as a PREFIX to an action/modifier

Agreed.

But is the combination of "initial space prefix" plus some other suffix/prefix for multiple modifiers out of the question? Just try to type " mp3" and compare it to "+mp3". The former is a lot quicker (due to space bar size and position). Come to think of it, the most coherent way to have the "initial space prefix" might be to just make it an (optional) addition on top of another prefix.

Example: " mp3 +edit +d: moby" would (i) search for mp3-files, (ii) set action to edit, (iii) narrow search to D: and look for files with "moby" in name.

Those who don't like the "initial space prefix" could still type "+mp3 +edit +d: moby"

Another quick "extra prefix" would be to read all phrases that begin with an uppercase letter as modifiers ("Kill" is a modifier, "kill" is not).

re: actions and modifiers:
1 & 2! Also, since most modifier phrases will be brief (mp3, edit, kill...), allow multiple columns in the result list (edit: only for the list of actions, not for regular results). That gives maximum overview of available actions and speeds up selection.

[jgpaiva]

@jukla: I see where you're heading to with space as modifier. It really is faster if you use only one modifier.
IMO though, this should be added as an option and not by default. Only because it still forces you to have another modifier if you'd like to have more than one action on the same file, or the action specified after the file.
I find the idea of using caps letters in the actions interesting, let's hear come more opinions on that.

As for action-finding help, i think that there should be a second result box, maybe dividing the already existent search box, or appearing in the other direction. I mean, if farr was configured to have a drop-down results list, the actions would come on a "appear-up" list.
Another important point is that you can never be looking for both a file and an action (because of the modifier key), so, i guess the simplest solution would be to just have the same results list used as "possible actions" list.

[mouser]

Another quick "extra prefix" would be to read all phrases that begin with an uppercase letter as modifiers ("Kill" is a modifier, "kill" is not).

thats an interesting idea.
and i dont mind making an initial space signify a modifier in addition to a custom prefix.

we could also say that whenever an exact match to an action is typed, it is automatically recognized as an action; just keep in mind that searching for file result would get disrupted while you were typing.

so for example, if you typed

dylan pla

youd get no results

but after you finished typing

dylan play

then the program would automatically convert your typed text to

dylan +play

[jgpaiva]

The last thing you mentioned, mouser, i still don't understand the problem about having farr searching for files and actions at the same time..

[mouser]

consider this:
i type
"dylan pl"

now, at the time you type pl
farr will think you mean do limit results to files with pl in their name
it doesnt know that you are typing an action
so it will be using what you type to restrict file name results.

[jgpaiva]

yes, i understand that, but why can't farr think of an alias just as if it was a file?
the alias would appear there, and if it was the first result, the user would only press [enter]

[mouser]

yes this would work for any alias that you want to treat like a file result.
the problem is when you want to use an action/modifier/alias which isnt meant to compete with files and not change this list of found files.

[nitrix-ud]

i may be completely off topic, and i'm sorry if it's the case 

do you have plans to allow the following :

pretty much like the alias mechanism, one would type the name of the alias, ex:

snippets

then (after a space) it would search within a specific folder(s) / file(s) type(s) (specified in the alias "snippets"), ex:

snippets php

it would search "php", but it would also know (because specified in the alias) that it uses a specific action for the found file, ex:
(imagine i have a small app to copy the text inside of a text file)
copy_text_inside_file_to_clipboard $$1

Imagine how powerfull this would be, you could use FARR for so many things !
todo manager
code snippets manager
and so on

I really hope, i'll be able to do that

In any case, keep up the good work mouser (and all others contributors), you are building a great app !!

Cheers, Nico

[QuickBrownFox]

Please, please do not let the tab key have anything to do with the functionality of v2. The tab key is terrible for any kind of navigation and it really annoys me that software uses for anything other than creating tabs in text files. The problem is that you have to cycle through items in a fixed order and to cycle backwards you must hold down shift and then press tab which is awkward and annoying. Any moving between potentially multiple text boxes should be done with the arrow keys.

Also, aside from being unnecessary, I think that the idea of multiple text boxes undermines the visual simplicity of FARR.


OK so after criticising your ideas let me be a little productive and contribute one of my own.

In the case of finding a file/shortcut and running it: v2 should behave exactly as it does now.

In the case of finding a file and performing a different action on it, in ADDITION to being able to type the action followed by the file (or however you choose to make the syntax work)...

...how about searching for the file in the normal way, selecting it by cursor keys, and then typing the action you want to perform on it. As a keypress other than enter is detected another text box pops up to the right of the item and searches for actions relevant to the file type similarly to the way that the main text box searches for files.

While all this is being done, perhaps the main text box could be automatically updated to reflect the action that the user is attempting in such a way that if you had typed it's contents into the main text box originally and pressed enter then exactly the same action would have been performed on exactly the same file.

Example:

User types "mp3 dylan" into main text box
10 results displayed
User keys down to the fourth one (4.mp3) and types play
By now the main text box has automatically changed it's contents to "play mp3 4.mp3" (or whatever you decide is best)
User presses enter. Action is performed
The entry in the history is "play mp3 4.mp3"

Perhaps some visual cue could exist to let users know that when they select an item they can type an action.
The advantage of this approach is that it guides users through the process of performing more complicated actions on files but also shows them how they could've saved time by typing the action and searching for the file at the same time in the main text box.

[Jan-S]

1) when you type the modifier prefix, the results switch to a list of matching actions until you finish typing the modifier

-mouser (May 20, 2006, 03:03 PM)

This is my favorite. You will not need the file list when you've indicated you want to type an action by entering the special action prefix.

Another quick "extra prefix" would be to read all phrases that begin with an uppercase letter as modifiers ("Kill" is a modifier, "kill" is not).

-jukla (May 21, 2006, 05:42 AM)

Cool idea. I don't think I would use it as for me it's faster to type a dash before the action, but it wouldn't hurt to offer this as an option (it's just as easy to parse).

Please, please do not let the tab key have anything to do with the functionality of v2.

-QuickBrownFox (May 21, 2006, 01:27 PM)

In the TAB-based approach mentioned above the TAB key was not used for navigation, but to confirm an action or select a file you want to perform an action on. RETURN should still launch a file and TAB is another easily reachable key which could be used to push items on the "command stack". Please see the thread I've linked in my last post to learn more about this idea.

In the case of finding a file and performing a different action on it, in ADDITION to being able to type the action followed by the file (or however you choose to make the syntax work)...

...how about searching for the file in the normal way, selecting it by cursor keys, and then typing the action you want to perform on it. As a keypress other than enter is detected another text box pops up to the right of the item and searches for actions relevant to the file type similarly to the way that the main text box searches for files.

-QuickBrownFox (May 21, 2006, 01:27 PM)

This is a very important point. You should be able to browse for a file and decide about the action afterwards. I think when you highlighted a file and start typing, FARR should put the filename into the list (just the filename, without path - this means FARR has to map the abbreviated form to the full file name, internally (maybe it should even just keep the part of the filename you entered)) and append a space sign, the command prefix character and the first character you typed, filling the result list with matching actions.