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)

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

[cnewtonne]

Yes, I agree on the following ....

- QuickSilver is the landmark. Every time I hear QuickSilver I drool till I drown. 
- Final details can NEVER be anticipated. It is ALL in the usage. Software that is born out of the coder desk only, is useless. I have a dozen of software I can list for you where features meant the world for the developer (in terms of effort and knowledge) but translated little or no real life efficiency when it came to daily usage and experience. Will not mention names though.
- The ultimate goal for any software (after stability and performance) is EFFIENCY and nothing more. I measure efficiency in terms of ...

- number of steps.
- Time taken
- Human resource expenditure e.g. how much software relies on human memory, visual coordination and so forth. Even though taken for granted, these are most expensive of all. The least you force users to use them, the better.

Based on this, I can tell you what elements of the user interface design I think FARR should DEPART from and not use them (unless for emergencies)... This is the bad list when it comes to retrieving data ...

- Trees and hierarchies: too expensive in terms of human resources. Imagine having a tree of 100 branches with 20 child each. I can never understand software that users this is as a way to retrieve data.

- Aliases: bad, bad, bad. A software that users this approach will encounter 2 major hits/setbacks. First, there is an overhead to create and organize aliases. Second, there is the expensive operation to remember the alias as you need it. It just does not work. For one software, I had created 100 aliases. How on earth I'm supposed to remember all.

- menus and worst the cascading styles. I think it time has proven this to be bad.

I once paid $60.0 for a file explorer software that had me access any file I wanted from any application using manus. It displayed file system using cascading menus that I had to chase till I either had my mouse falls of the table or out of frustration in the trash bin. Compare this to a free software from sf.net that I used later to get the deepest folder in less than 3 seconds using auto complete.

I truly enjoy software and the source of this enjoyment is the fact it very truly reflects the limitless bounds of human imagination and abilities. The ultimate goal of any human endeavor to invent is to do one thing and ONLY this thing; it is to save resources whatever they are, specially resources related to our central nervous system e.g. attention, coordination, concentration, remembering, ...etc. The more you save the better the invention is.

Enough said for today. Got get back to work now. 
 

[jgpaiva]

Compare this to a free software from sf.net that I used later to get the deepest folder in less than 3 seconds using auto complete.

-cnewtonne (July 20, 2006, 02:31 PM)

Would you please tell which program is that?
I've been very interested in typeandrun too, so i think i'd love that program you mentioned

[mouser]

well i actually agree with amadawn (and nontroppo made similar suggestion); holding out till everything is figured out is a recipe for endless internal debate.  releasing intermediate attempts is a good idea and i'm going to try to do that, it's just easier said than done and sometimes the internal debate about alternatives can paralyze you.

[mouser]

- Aliases: bad, bad, bad. A software that users this approach will encounter 2 major hits/setbacks. First, there is an overhead to create and organize aliases. Second, there is the expensive operation to remember the alias as you need it. It just does not work. For one software, I had created 100 aliases. How on earth I'm supposed to remember all.

well you'll notice one of the special things about farr is that you can just type name of program and dont need to add aliases.

but it does support the idea of custom aliases which let you use regular expressions and groups/menus, launch web searches, etc.

ps a trick:
type: agroups
to see a list of all known aliases.

[cnewtonne]

I spent 2 hrs today to try to get FARR to display the group aliases. Nice trick