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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]