DonationCoder.com Software > Find And Run Robot
Thoughts of a new comer
cnewtonne:
Hi all,
Software as well as the forum are both impressive. I want to commend mouser for such a great accomplishment.
I've been monitoring FARR for more that a year now. Installed it several times but never became one of my essential tools. So far, I've been using the great TypeAndRun and to a lesser extent AppRocket. However, I have looked at every piece of software in this category. Futhermore, I evaluate software on a consistent basis and have learned across the years what really works and what does not. So allow me to add in my 1 penny worth of comments. In general, for any successful piece of software to succeed, developer must adhere to these principles...
1) know EXACTLY the scope and objective of the software. Users will always want everything. Unless developers have a clear vision of what the software can and should do, software will unquestionably deviate from its original scope and plunge in terms of stability and performance. FARR was initially started as a commandline launcher. Now, users want it to be a file navigator. This is fine as long as we stay focused on what FARR is and should be.
2) Exploit software logic and development tools to serve user needs not the other way around i.e. eliminate and trim down features due to restrictions in logic and tools. I have seen software trim down its features and introduce inefficiencies in user interface to comply with restrictions imposed by app logic and coding habbits and tools. This is a deadly mistake.
Having said that and having experienced almost every app in this category of software. I can say a software MUST make the most use of these features.
- software MUST be respectfull in terms of resource usage. As obvious as it sounds, it gets ignored more often than we think. Take Luanchy for instance, on my system it was using 44MB of memory. This is close to outlook and firefox. AppRocket is another example, the indexing process or just simply loading index data in my opinion is severely limiting. As much as I loved it, I had to stop using it. This is one area where FARR truly shines with no competition, period. It searches as it needs to and you can elegantly stop it when you find what you want. This is probably the reason I started looking into FARR nowadays again.
- complete as you type (or auto complete). I need not retype a command/path every time I use it. Software should cache it and attempt to auto-complete as I type.
- Search as you type.
- Smart search or patterm match without the need to use wildcards.
- eliminate or reduce to a minimum the need to navigate with a mouse or keyboard. If I have 8 matches, I need not hit my arrow 8 times to get to target. Instead, I can simply hit '8' and I'm done.
- implement a plugin solution so other people can help out adding features. Total Commander is a great example on this along with firefox. Why should we bombard mouser for the rest of his life with feature requests if we can simply develop a new plug-in and deploy it ourselves.
- Use of keywords. This is a feature that I'm just beginning to realize its immense potential. Initially, it may sound trivial and it did to me for years. It was only when I was playing with a PALM app called Memoleaf that I started to love it. PowerMarks also uses it and believe me it is an indispensable feature. As far as data management, there 2 major operations. Retrieving data and organizing it. The problem with keyboard or command line operations is you can easily solve the retrieval problem by using search as you type or auto complete and both apps do this very nicely. The issue really is organizing the data. In otherworlds, you can simple dump all your executables and files in one big folder and think that you really no longer need a folder tree to organize all. I got into this situation now as I have one big folder in my document that have 3000 files. I no longer have to create folders to organize files by subject. I did this only because it really takes me seconds to get to any file I want. Now, I'm faced with a situation where I need to get all files that talk about volume management on unix, for examle. How can a program like FARR help me do that. It can only if I named my files in such a way that it contained some variation of the subject name. The truth is, I did not and probably never will. It is the concept of keywords that solves this problem. PowerMakrs does exactly that. It allows you to associate kewords as you add link. So you can simply type 'unix' and 'storage' and all relevant links are before you eyes. I'm sure FARR can use this concept. It may by that FARR can use file paths as keywords. There is program called LinkStach that does this beautifully. It uses current folder names as keywords where you can simply type part of the path and it lists all relevant files for you. Truly nice.
So given all this and to help FARR plan for it future release, I would like to suggest these missing features (some I have read that they've been planned and probably is work in progress now):
- file navigation feature: the best way I've seen it AppRocket and TypeAndRun. Both cache the file system to be later auto-completed as you type the path or displayed as you provide them. Probably if FARR can recognise the '\' as path separator and narrow its search internally on folders.
I have some other ideas but I have written a post that is the lengthiest I've ever done in a forum. Please excuse me. take a look and let me know what you think.
Thanks again.
mouser:
great post -
i think most of your comments are probably read by people here with a big nodding head saying yes we agree.
and i very much appreciate the spirit of your post.
the real mental block i've had with v2 is all the conflicting issue and trying to solve some user interface issues. these are not programming issues but user interface design decisions.
an example of the conflicts is the indexing idea.. some people want indexing for speed.. others love the minimal memory footprint and hate indexing. i have decided in this case that i can support indexing as an option. but other cases of hard decisions are more difficult to resolve conflicts.
the most valuable thing for me is when people post very specific suggestions about how they would like to make farr v2 work.
the issue of auto-complete while typing is something ive struggled with - farr generally uses an alternative to autocomplete by showing possible multiple matches in its result list.. the question is, should autocomplete also be added in a different form? or is it better to find a way to make the result list serve the same purpose..
i hope you will post some more thoughts and also take a look at some of the v2 planning threads to see the kinds of dilemnas we have been struggling with.
farr v2 is never too far from my mind but i continue to feel like it's hard to work on it while these unresolved issues of user interface still remain.
urlwolf:
Here is one thing that I do to move around the filesystem...
it is not FARR what I use, but Dopus, and it is slightly inspired on how vim works (switching modes with esc).
I have a few aliases. They are called by typing "/' before the name.
I have mapped 'esc' to 'go to the "file:" command line. This was not possible from within Dopus, because esc was not an option, but I could do it with autoHotKey.
Everytime I need to go somewhere, I type 'esc' and the alias that is the closest, then move around the file list by typing the first letter, second letter, etc, and enter.
This is the fastest and most visual way of moving around I have being able to think of. It even combines the niceties of a shell apprach and a visual point-and-click approach. I/m very happy right now, although I'm sure there is room for improvement.
As it is based on aliases, any other program i. e. FARR, slickrun, etc can do it too.
I use slickRun. I don't have the same approach on SR because I would miss the visual part of a file browser and because the autocomplete list is littered with other non-filesystem related queries.
What do you think?
Amadawn:
the real mental block i've had with v2 is all the conflicting issue and trying to solve some user interface issues. these are not programming issues but user interface design decisions.
-mouser (July 19, 2006, 04:51 PM)
--- End quote ---
Mouser, it seems that perhaps you should borrow a trick from the Open Source community and follow their motto: "Release early, release often". It is almost impossible to get a program with such a big scope right on the first try. It is good that you take your time to think about the basic _philosophy_ of the program, but not about the actual implementation details, because those will only fall into place when people try to use them and discover whether they are useful or not.
So my advice, from a fello coder, is: Get the basic idea of what you want, make a prototype, something that takes FARR forward from what it it today, release an alpha version, listen to our comments, rinse and repeat.
Also you should probably try to draw inspiration for the "concept" from other programs that have tried to do similar things like FARR, with QuickSilver being, in my opinion, an obvious source of inspiration, as it has achieved the feat of being both useful and easy to extend.
As for your "caching" dilemma, I would suggest, as cnewtonne did, that perhaps you might want to pre-cache or index only the filesystem and the progra files shortcuts and do a search for the rest of items. That would make FARR great for file browsing and as good as FARR1 for searching. Keeping full indexing as an option seems a good idea as well.
Cheers!
Angel
jgpaiva:
Amadawn:
I don't agree with you. Although it's good to have many test versions, and it can speed up the development, it'd be too much unecessary work for mouser.
I think we should all help, try to get mouser new coherent ideas.
If everyone comes out with great ideas, we can select the best one, get a general concensus and get our new farr as soon as possible ;)
Navigation
[0] Message Index
[#] Next page
Go to full version