On Fri, Mar 9, 2012 at 6:55 PM, Srihari Sriraman wrote:

Hey,

We now have it up and working. Still looking to implement loads of features... Do pool in suggestions!

Reminds me good ol' gnome do :) and other quicksilver derivates. What key combination activates that?

Also, do you have a public Git repo or something? People round here are used to having access to code.

Alexandre Prokoudine http://libregraphicsworld.org

Srihari Sriraman wrote:

We now have it up and working.
Still looking to implement loads of features... Do pool in suggestions!
http://youtu.be/hGAgG_XRhHc?hd=1

being part of the GIMP UI design team, I have to ask:

can you give a statement what this is suppose to achieve.

I can see the value in having searchable all the tooltip text and have that mapped to obscure plugins, to find them. and why not extend that with more keywords, or even the documentation for searching (to find the right command, or to look up documentation).

but doing a delete? the Delete key is a hell of a lot faster for that.

doing a ellipse selection? click on the tool icon.

all this typing, then scrolling, is a very slow way of doing that. and GIMP is a tool for working fast.

--ps

founder + principal interaction architect man + machine interface works

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

Srihari Sriraman wrote:

We now have it up and working.
Still looking to implement loads of features... Do pool in suggestions!
http://youtu.be/hGAgG_XRhHc?hd=1

Nice one. We had a failed GSoC project(student disappeared) for something similar. Is it a plugin or is it hacked into gimp core?

On Fri, Mar 9, 2012 at 9:42 PM, Srihari Sriraman wrote:

Also, do you have a public Git repo or something?

We do now -https://github.com/ssvz4/tito

Oh..kay... This is going to be a bit of an issue. It looks like you are changing stuff on top of a code from a tarball or a Git snapshot. In that case merging your changes is going to be an issue, because by the time you end the project, the upstream project will move further, and thus merging your changes is going to be pain in the arse.

We recommend working on top of the current Git master and merging upstream changes to your branch and publishing all of it.

Talking of improvements, we're thinking of regex, adaption, vocabulary, auto-complete, hierarchy based search, etc.

Depending on what exactly you mean with regex this could be an overkill, especially since there are so many of variants of it :) The rest needs at least a rough spec. We are passing most/all UI changes through Peter Sikking who is our UX architect, and I'm heavily betting that right now he's preparing one of his (in)famous Stern Looks for you :)

Alexandre Prokoudine
http://libregraphicsworld.org

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

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

I also think that it does not collide with the product vision. Even a professional user need to learn a tool before using it. Also, I know a lot of people that see GIMP as an enhanced MS Paint, because what GIMP is capable of is not obvious. The menu search allow to answer the question "what can I do with X (layer, selection, image ..)", without needing to search in all the menu.

Also, I think you really should display the keyboard shortcut next to the name of each item. It would allow to learn easily these shortcut, to use them later at high speed.

My 2 cents.

2012/3/11 Srihari Sriraman

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

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

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

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

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

On Fri, 2012-03-16 at 04:44 +0900, Aleksandar Kovač wrote:

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.

Especially useful in inkscape; one might be more likely to want just pixels in gimp rather than mm of course, although people working with a single specific print use do often think in mm/inches.

Bigger is to note that this is drawing-as-maths not as manipulation. There are times you want both, which is why Tool Options lets you enter the numbers too.

Liam

On 12-03-27 10:50 AM, Srihari Sriraman wrote:

We've developed TITO further.

[snip]

We're hoping to develop this further and build the command system...

It looks promising. It helps to find all features with a given key word but there still seems to be a bit of scrolling up/down the list which would seem to slow down the selection of functions/features.

One program that allows selection of operations via a command line interface and allows setting/changing of command parameters is Rhinocerus 3d. You can see a video of it at: http://www.youtube.com/watch?v=hJVrUqytvhA

When using the program I select a few things from the menus, often use the icons I have on the screen, but I use the command line to invoke some common operations for which I know the name. I can type "SW", then tab which uses completion to turn that into "Sweep" followed by either a "1" or "2" depending on if I want a one or two rail sweep. All options for the sweep command are shown with keyboard shortcuts so it is very quick/easy to select an operation and set its parameters.

The one difference between what you have done so far and Rhino's use of a command line is that Tito is useful when you don't know the name of a command but Rhino's use is good when you know the name of a command.

Srihari Sriraman wrote:

A command system would really boost the speed of interaction.

now that would really depend a lot on how you design this. I must admit there is a tiny opportunity to come out faster than mousing the menus for a plugin without a shortcut key (ctrl-...). where is comes to menu items with shortcut keys, I am not sure you ever can.

so let's see, you have an opportunity to do something good for a minority part of the menu structure, which by itself forms 1/3 of the GIMP interaction system.

is that worth it?

this of course apart form the help/explore/documentation system we talked about here and on irc. I thought we had understand each other during those talks.

We're headed there.
Blender's and Rhino's systems are great, so we'll be taking inputs from their design too.

that does not sound like a confident approach to designing this for GIMP. think about the whole context of GIMP, its vision and its core users. all the work on the canvas.

it starts with that realisation that you are working on what is a minority part of 1/3 of GIMP's interaction.

Currently we're thinking of using a command syntax similar to that of ImageMagick.. Would be great if we could pool in ideas regarding the command system here... (Will probably start a new thread on that soon).

Just to note, Tito has this handy feature. If you enter 2 letters, it matches those actions with those 2 letters as the first letters of its words... Ex:
You can "Apply Canvas" by typing in "AC" and hitting enter. Or say "Gaussian Blur" by just "GB".

have you run statistic on how many clashes (same 2 or 3 letters for different commands) in english? and then on to other languages, where the 2 or 3 words english needs to describe something (a peculiarity) is localised with a single word.

there is 76 localisations of GIMP, I would not blame you if it can be made to work for all languages apart from urdu (or something like that). but if at the end it only works for 5 languages out of 76, then it would of course go nowhere.

then on to non-latin input methods, on those standard latin keyboards computers are sold with. how would that be fast?

--ps

founder + principal interaction architect man + machine interface works

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