DonationCoder.com Software > Find And Run Robot

farr v2 planning - use cases and action idea

(1/7) > >>

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

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

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.   8)

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.

Navigation

[0] Message Index

[#] Next page