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