Tuesday, 9 December 2008

KRunner and "the new command interface"

I use KRunner for launching most of my apps, it's very flexible when it comes to reading user input but it needs to match this with richer feedback to the user if it is to fulfil it's potential and be more than just an application launcher.

La Nouvelle Interface de Commande has been popping up all over the place. And it's not a regression to terminal computing; it's not about remembering lots of commands and syntax. It's about you starting typing what you want and your desktop letting you know what it thinks you might mean, you narrowing down your description and reaching the desired action in a hand-full of keystrokes. The key here is constant feedback: parsing, matching and displaying information as you type.

Because KRunner uses a plug-in architecture and gives the individual plug-ins ("runners") complete control in parsing the input, it allows them to perform tasks such as spell-checking or evaluating arithmetic expressions as well as simply executing commands. However when it comes to displaying information, all a runner can do is add an item to the list of actions, which in practise means an icon and about 10-characters of visible text. Lets have a look:



This is OK if you are simply launching applications (and KRunner is foremostly an application launcher) but not great for anything else. Lets see how another app, actually a firefox plugin, Ubiquity, makes it much easier for the user to find what he wants.

Ubiquity uses scripted "commands" rather than compiled plug-ins, but the principle is similar.

Start typing and a list of matching operations appear:
Some points to note: The first section contains a list of commands with syntax hints which make it easy for me to input the correct information, the second section contains output from the highlighted command, in many cases this information is sufficient and there is no need to "execute" the command at all.

I can use the arrow keys to navigate the list of commands but it is usually easier simply to narrow down my search by typing a couple more characters.

Now that I have the command I wanted I can start typing an argument. Here returning a list of results from wikipedia.

Ubiquity can do all sorts of things.

KRunner has the potential to be more powerful than this but it needs richer feedback. How to integrate this into KRunner is not obvious. My own thoughts for now summarised below.

The scheme I envisage is the following: Runners would publish matching commands to KRunner as they do now, however the selected command item would then be communicated back to it's parent runner which would then be able to publish further information to KRunner. A possible format for this further information is to allow a single JSON (allowing the definition of lists, tables etc without specific layout markup) information widget and/or a list of JSON formatted sub-command widgets (or nothing at all). OK So to the mock-ups:


More space for text makes identifying commands easier and allows for those vital syntax hints which allow the user efficiently execute the intended command. Hints in the top-right corner of tthe command widgets tell you which runner produced them.


Some "command items" may display an information widget when they are selected...


...or may display a list of sub-command widgets. Here the search command performs an incremental search and displays a list of results in a table form. Each of the results is a runnable command.


Unlike Ubiquity, KRunner is not limited to using keywords to activate commands, here, for longer text entries activate the search and spell runners without the use of a keyword.


A command can display an information widget and a list of sub-command widgets at the same time.


Another use of the both information and sub-command widgets.


Filtering down the sub-commands.


mmmm Akonadi




Well there you go, it's a starting point for discussion at least. Comments welcome.

No comments: