jdmarch said:
Second, the visible presence of a default OPEN/LAUNCH/RUN verb, in the first entry field, provides a visual clue that other verbs are possible.
i find this reasoning very compelling, and it also attracts me to the idea of multiple edit fields.
imagine two edit boxes:
ACTION: [FIND_______]
OBJECT: [___________]
cursor could start in OBJECT field, where you could type the name of a file pattern and it would behave exactly as farr currently does.
but you could also hit up arrow to go to action field, where it would select/prehighlight the word FIND and you could just start typing another action, like "kill". as soon as you enter the upper field, the results would switch to the actions list to select from.
after selecting an action, the tab or down arrow would take you back to OBJECT field.
we could also have the OBJECT field auto detect when you type an action and a space as your first word, and automatically fill it in on the ACTION field (while leaving it in the OBJECT line if deleting would be confusing).
the benefits of this approach would be
1. the 95% case requires no extra steps, you start the program and start typing to find an object to launch.
2. good visual feedback about how to change an action
3. very easy to change actions and select from a menu (just hit up arrow to go to ACTION field, then tab or down arrow to go back to OBJECT field)
4. pure commandline mode supported by autodetecting common actions typed in OBJECT field
5. obeys the rule of always specifying a verb first - which lets you do things like specify a verb of KILL and having the results list show a list of running processes that are searched when you are in the OBJECT field.
6. could have an option to start in the ACTION field for people who prefer that.
drawbacks:
1. you need two editboxes visible - annoying for people who prefer a streamlined tiny look.
however - it may be possible to use only edit box and a queue/stack like effect where we push the FIND action on the stack to start with but give user a way to backup over that - its the same idea but a different way of displaying it. i think basically the effect is the same but it might be more streamlined, but significantly more confusing for new users.
well one more benefit of the queue/stack effect, which could be substantial, is that it allowsq queueing of a string of objects, not just one for each editbox.
hmm still something to chew on...
Recent Posts
