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

[Aleksandar Kovač <alex open design gmail com>]

On 2012-10-03 4:11 AM, peter sikking wrote:
> sorry to spoil the party, but to see how think this is a good thing,
> when it can be so treacherous, is quite dangerous.
But Peter, that's how all the experiments, prototypes, working models 
are! It has to be treacherous and it has to be dangerous. But exciting 
and inspirative, too. It's the fun of creation. So we can learn. Please, 
let's afford ourselves some (U)ser e(X)perience with this work before we 
judge it with too much ossified experience. No one will be hurt.

To use the example from the video: Ellipse. Yes, I agree with the 
assertion that clicking the icon is faster. How about typing even this 
expression in Srihari's prototype: e.g. 'selectellipse 304.4*304.4mm'. 
Results in: a 304.4*304.4mm elliptic selection loaded right on the 
cursor. It is arguable that this example would have an equally effective 
counterpart in either of suggested visceral/hands-on/shortcut approaches.

There are possibly a few more benefits. For example, if we imagine that 
each word is perhaps auto-filled, that the word order can be changed 
(i.e. '304.4*304.4mm selectellipse' = 'selectellipse 304.4*304.4mm'), 
that it 'gets' the meaning (these commands would have the same result: 
'selectcircle 304.4mm', 'selectelipse 304.4mm', '304.4mm*304.4mm 
selectellipse', ...), or that the thesauri and the dictionaries could be 
'translated' for other applications.
...

Maybe I am missing a point, but what is the substance of this 
'tick-tick-tick' heuristics/metaphor? ...I like it very much, tho! ;)
I did observe guys and girls working in newspaper offices, printing 
offices, etc. working like that. They are fast. But, they are not 
creating, they are editing. On the other hand, I have observed creatives 
whose rhythms are much different than that.
Or is it to suggest the access time for individual commands and operations?

On 2012-13-03 7:49 AM, peter sikking wrote:
> 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.
Rhino, Wolfram Alpha, Blender and even Spotlight provide some capable 
'command-lineish' interaction approaches. All of them mostly outside of 
the suggested help/explore/documentation category. Turning Srihari's 
command line into spoken commands, even. (and then we have Siri ;)). 
Would I let Siri be an mediator between GIMP and the user? Not sure, but 
I would like to try and experience it. By leaving intact, of course, all 
the great UI/UX work so far and the core elements of GUI; besides the 
issues, this prototype suggests some interesting things to me:

- Possibility of using human language (text or utterances) in GIMP to 
accomplish goals.
- Possibly more humane or even faster way to executing complex commands.
- Possibility of linking macros or actions to custom commands.
- Allowing users variance in commands, with predictive results.
- A small step towards a more universally designed GIMP.
- A valuable UX, UI experience and a possibility to disseminate new 
ideas or solutions.

> ... all essential commands need to be
> uniquely invokable with a 2 character code, the rest (any
> plugin) with a 3 character code. ...
I did not understand this, sorry.


---
Alex