d-akara / eclipse-plugin-commander

Eclipse user interface enhancements
MIT License
55 stars 4 forks source link

Use number for selection within list #44

Open paulvi opened 6 years ago

paulvi commented 6 years ago

When selecting within a list, number should be used first, e.g. sequence of

1,2,3,4,5,6,7,8,9,a,b,c,d,e,f...

instead of starting with a,b,c,d

d-akara commented 6 years ago

Letters are used because they are quicker. Letters exist closer to the home row position of your hands when typing.

This precedent has been set by extensions such as Ace Jump which is available for most editors.

paulvi commented 6 years ago

well, should be matter of preferences.

Not everybody masters touch typing and knows what home keys are.

d-akara commented 6 years ago

Not everybody masters touch typing and knows what home keys are.

This interface is attempting to target a set of users who you might call power users who want to achieve the fastest possible user input. Just like VIM probably would not be very productive for anyone who isn't a touch typist, this feature might not be either.

In such case, traditional methods of UI input are probably going to be better. For example, just use the mouse to pick the item you want or cursor down to the item you want is likely to be just as productive if you are not a touch typist.

paulvi commented 6 years ago

I would like to be able to command IDE without touching mouse.

But personally I consider VIM to be contrary to good UX, it is just that it is by default within Linux people have to learn it, but it is pain.

In other words "mouse-less" should not mean "VIM keyboard shortcuts".

d-akara commented 6 years ago

The point is that this feature (fast select) is targeted only for speed. You can still cursor down to the item you want and if you are not a touch typist, then it will likely be just as fast or even faster than typing a slash + number.

VIM succeeds at what it intends to do. That is be fast at editing. It wasn't built to be easy to learn. To some degree, those are mutually exclusive. The more you would make VIM conform to typical editor UX, the original purpose is lost.

Fast select is like VI mode for Commander. It is there for those who want to attempt to push the boundaries. Just like Ace Jump or any other such paradigm is optional, but does require a paradigm shift in how you interact with the UI. Ace Jump wouldn't be effective with number indexes. They even optimize the letter selections to those being already on the home row as higher priority to you don't even have to move your finger to a different key. However, as I timed myself using Ace Jump compared to normal cursor navigation, I actually could only barely beat normal cursor movement with a lot of practice. Especially if I set the key repeat speed to maximum, then it really is not much of an advantage.

In summary, if Fast Select implementation isn't actually faster than typical UI paradigm, then it doesn't have much value and to get that gain from Fast Select it may actually require some practice and paradigm shift from normal usage. Otherwise, users are probably going to be more proficient using traditional cursor navigation as input.

Question: are you interested in this change mainly because you believe it is a good idea? or do you find that you use Fast Select often? I'm curious as to better understand if you have unique use case, as I almost never use Fast Select despite building it :-) That is mainly because I almost always have the command I want to execute as the first item with just one or two characters entered in the input and then I can just hit enter to execute. The somewhat infrequent times I do use it, is more with Finder when searching for a class or file.