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

[Srihari Sriraman <techie visishta net>]

> 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)

> "Almost forget that there is a menu-bar"

This anyhow, remains true.

>  tick-tick-tick-tick

So beautifully put. I've quoted this to a few people already! :)

The menu search tool will not give this speed.

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".

On Sat, Mar 10, 2012 at 12:41 AM, peter sikking <peter mmiworks net> wrote:

Srihari Sriraman wrote:

> can you give a statement what this is suppose to achieve.
>
> Maximize productivity
>   Almost forget that there is a menu-bar. Use the mouse/touchpad lesser.

I accept the 3 points you write below, it is that
help/explore/documentation system I can see in this.

but the statement above? you do realise what GIMP is being
(re)designed for, no? it is for serious image manipulation,
seriously creative working and for production environments.

a lot of this work is hands-on on the canvas, in the context of the
graphics on the canvas, which are not like vector graphics or files
in a browser something that can be keyboard transversed.

the above requires that GIMP is a tool that gets out of the way,
by being visceral, part of motor memory. you tool is the
oposite of that, by users having to formula what they want
and type (part) in to get a query going then scan the results
and pick one, you get right in the way.

GIMP also requires that everything designed for it can support
working at a speed of 2 operations per second. just for a moment
say tick-tick-tick-tick-etc. at that speed. I do it every time
I bring this up in a lecture or when I teach interaction design.
it gets the point across right away.

so I have given you now 2 concrete requirements in a GIMP
context how you can prove the phrase "Maximize productivity."
one is even quantitate, which is rare in user interaction design.

tell me how you meet them. if you don't, you are providing
anti-usability. (that is apart from the help/explore/documentation
system below:)

> Intent driven rather than hierarchy driven navigation
>   Focus on 'what' rather than 'how'.
> Discover functionality
>   For new users
> Help transition
>   From proprietary software. "What is 'smth'  in GIMP?"

sorry to spoil the party, but to see how think this is a good thing,
when it can be so treacherous, is quite dangerous.

   --ps

       founder + principal interaction architect
           man + machine interface works

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

--

Regards,                                                                                         

Srihari Sriraman