Re: [Gimp-developer] An update on the menu search

[peter sikking <peter mmiworks net>]

Srihari wrote:

> the above requires that GIMP is a tool that gets out of the way 
> ...your tool is the opposite of that...
> ...you get right in the way.
> 
> Very true. We din't have this perspective.
> Using keyboard shortcuts indeed gives the 2 operations per second thats required in production environments.
> 
> However, I guess the video has been a little misleading...
> The manner and frequency in which this tool is used, is up to the user.
> i.e, the tool is meant to be complementary. It is not meant to be a substitute for keyboard shortcuts.
> So, a power user would be experiencing a smooth workflow (which GIMP clearly provides) and this tool would help him when he's either stuck or trying to find something. (i.e, help/explore/documentation)

I think it is becoming really clear that that is what it is in
this form: help/explore/documentation. I am fine with that,
but the presentation of the system has to be one that is
tied to the help system (see for instance apple's system-wide
help system); not present it as some shortcut/command/quicksilver
system.

> "Almost forget that there is a menu-bar"
> 
> This anyhow, remains true.

a help/explore/documentation system would be all about
the menubar, the toolbox and further elementary GIMP
dialogs (layer stack, etc).

> Talking about increasing productivity, we've had ideas of extending the concept to offer a command execution.
> Wrt http://www.gimpusers.com/forums/gimp-developer/13823-fw-suggestion-for-new-versions-of-gimp#message63546 that is.
> This perhaps, would really mean "maximising productivity".

yes I must admit that for daily use of plugins and other
dialogs driven by 1–4 numbers (where the values have been
completely mastered by the users we target) that can be
a speedup. it really becomes a command line.

but here are some first thoughts:

- you need to design a command language, for this to work up
to speed I would say that all essential commands need to be
uniquely invokable with a 2 character code, the rest (any
plugin) with a 3 character code. else mousing to the menu
and fill-tab-fill-tab-fill-return is going to be quicker.
(a secret of shortcuts is that remembering the shortcut,
or the command code, takes time. this time is not registered
by users, they will always deny it. mousing is boring and
one is always fully aware of the time taken).

- so you design this command language, and it would be
good if the letter codes related to the menu item plugin names.
there are two problems:
--these names are localised, in 76 languages. this is not a
unix shell (100% USA) so you need to be too.
--any GIMP plugin in the world needs to fit in to this.

- what about dialogs that have input that is not a textbox,
like curves? there is still repetitive, rote work done with that.

- you need the help/explore/documentation system to be totally
out of the way of the command system. luckily this matches that
the help/explore/documentation system needs the interaction and
look of a help system, and the command system that of a fast
command line. total separation recommended.

my 2 cents,

    --ps

        founder + principal interaction architect
            man + machine interface works

        http://blog.mmiworks.net: on interaction architecture