Re: [Gimp-developer] Search Action dialog feature

[Jehan Pagès <jehan marmottard gmail com>]

Hi Peter, and all,

Wow this created quite a discussion. I am on the road, so I have just
been skimming through the whole thread, and I will answer to the
first.

On Wed, Jan 15, 2014 at 7:52 AM, peter sikking <peter mmiworks net> wrote:
> Srihari Sriraman wrote:
>
> > Have we had a chance to look into this?
> >
> > On Sat, Nov 30, 2013 at 11:06 AM, Jehan Pagès <jehan marmottard gmail com> wrote:
> > Hello Peter,
> >
> > Some time ago, a contributor developed a very interesting feature,
> > allowing to search actions with natural language keywords
> > (https://bugzilla.gnome.org/show_bug.cgi?id=708174).
> >
> > I have also written an exhaustive specification draft of the current
> > implementation:
> > http://wiki.gimp.org/index.php/Specs:Action_Search_Dialog
> >
> > This specification details the search algorithm, and the GUI interaction.
>
> OK, I have looked at that spec.
>
> then I thought about it for hours, and here is why:
>
> this thing is still giving me a serious stomach ache
>
> (I hope you guys realise that when something that is 100% UI
> gives me a stomach ache, that is quite significant)
>
> even trying to explain to you (and me) why this gives me
> a stomach ache, gives me a stomach ache.
>
> I could talk long or short about all its aspects, but
> I have decided to cut it short and tell you this about it:
> when I read the spec or think about TITo, this comes to my
> mind, second by second:
>
> ‘that is OKish, give these guys a break’
> ‘that is awful, completely misguided’
> ‘that is OKish, give these guys a break’
> ‘that is awful, completely misguided’
> ‘that is OKish, give these guys a break’
> ‘that is awful, completely misguided’
> ‘that is OKish, give these guys a break’
> ‘that is awful, completely misguided’
>
> so after hours of thinking I have come to this conclusion:
>
> the problem with TITo is that as it stands now it is a
> conflicted mix of two intentions:
>
> 1) a help system via text search to learn using GIMP
>
> 2) a command-line system for operating GIMP

This is none of them. This is a search tool through available
contextual commands. So that's kind of 1) "help system", but not with
"learning" as intent. Only with "searching" as intent (you may
"discover" some commands or filters of course, but that would be a
happy coincidence, same as when you may discover these same filters by
wandering in menus. There is no learning intent at all in this tool).

And this is definitely not a command line system. At least, when I
hear "command line", I would usually hear "language script". Here
that's just a list of commands, and you can search through them.
This is, in 2 words, a "search tool".

> some note:
>
> - yes, for me 1) maps to ‘give these guys a break’ and 2) to
>  ‘completely misguided’ sort term _and_ long term;
> - if you are serious about “Text-based Intent driven Tool”
>  then you have to build a synonym list for all keywords,
>  in all localisations; else you are just bluffing;

I am pretty sure that this was written in the bugzilla thread: the
name "TITo" is only a working name. Actually I am very careful to
never use it when I present the tool (the original email I wrote was
titled "Search Action dialog tool", and I think I did not say tito
anywhere in it, except as a git branch name). This name was originally
given by the original contributor (Srihari), but it does *not* exist
anymore. There is absolutely no "tito" written anywhere in our code. I
even wrote in the spec «The "tito" feature would be named more
generically: "Action Search" »

So please do not focus on this name. This is only a code and it is
non-existing in GIMP. If this name makes you uneasy, just don't use
it, just as I do (I always say the "action search tool").
And we do not plan on creating "synonyms" for any command in all
localizations! uhuh :p

> - with different people working on it, I suspect they have
>  different intentions, or are conflicted internally themselves;
> - since TITo is right now a random mix of 1) and 2), it is
>  really not working for either intentions; things implemented for
>  1) get in the way of 2) (and vice versa);

As said above, this is neither 1) nor 2). Really this is a very common
UI tool. I can see the same feature in blender (they call it the
"space menu"). And my program menu in my desktop has the exact same
tool. When I want to start a program, instead of searching through
submenus (which may have a huge list since a lot of programs are
installed), I can just type the name of the program and it finds it
for me.
So if I want to find GIMP in my application menu, I just type "gimp"
in the search. Even better, if I don't remember the name (let's say I
use GIMP once in a while and can't remember its name), I just write
"image", or even "photo" and it will list various software, among them
GIMP (or "dartktable", etc. Note that it does not search by name only,
but also description, etc. And it is localization aware, which is also
great).

Well that's the same but inside GIMP for internal commands. You want a
blur command?  You type "blur", and it will propose all the various
filters, like "gaussian blur".

This is such a common feature, and useful as hell!

> when I had me face-to-face meeting with Mitch to patch things up
> we did talk about TITo (that’s how big an issue it is...).
>
> I said: when a version of GIMP comes out with TITo in it
> and the press writes about it:
>
> “GIMP now has a command-line system for operate it”
>
> then we have a all lost, big time, because a million users
> then expect that this will actually make sense
> (and btw: I lose the most, because this is a pure UI matter)

As said, this is not a "command line system". If the press ever writes
that, that's wrong.

> when the press writes:
>
> “GIMP now has a help system via text search to learn”

That's also wrong. This is a search tool.

> then we have a chance that this will be useful for
> a good chunk of our users, some of the time.

Maybe for a learning tool, that would be the case. But a search tool
is useful for many users all the time!

> all this is not about what we tell the press for that release,
> this is about what TITo _is_, what it is designed to be.
>
> being a conflicted mix of two intentions is certainly not
> going to help TITo in any way.
>
> some more things that are very important:
>
> - even if TITo response time is instant, keyword formulation ->
>   typing in a text based interface is not exactly fast;
>   please drop the ‘its fast’ argument;

I'm sorry, but I can't agree. I use this all the time to search for
programs in my application menu (unless I have created a shortcut
because that's an app I use every 10 min). Like I have a scan program
for instance. I use it once every few weeks or months because I don't
scan that much. So I can't remember at all the program's name. No
problem, I just write "scan", and it finds it.
Of course, I know it will be in the "Graphics" submenu in the root of
my app menu. That's easy with the mouse. Except that I have to move
the mouse over the submenu item, wait for it to open, and search in
the about 2 dozen applications listed under "graphics" for an app I
don't know the name. So no, I am sorry, opening the search tool,
typing "scan" and being given a unique or 2 responses, is so so so
much faster.

> - I read in the bug report that peple are contemplating changing
>   labels of menu items to help TITo to perform better;
>   that is the most dangerous thing I have heard in a long while;

I don't remember reading this, but maybe someone did say so. In any
case, this is definitely *not* my intent. I certainly don't think we
should rewrite labels of menu items. A filter/command with a clear
name and description will perform well with the search tool. By
definition. If we were to rewrite a label, that would be because the
current label is bad. We certainly don't plan to rewrite a currently
good label just for the search tool. So if this is one of your
concerns, well we can all be happy because it is a misunderstanding.
:-)

> - if anyone is serious about solving how to help serious GIMP
>   users with faster use of plugins and other sprawling stuff,
>   let me know; it can be designed...

I think we are all serious about improving GIMP UI. :-)
But please do not abandon this idea that easily. I think there has
been a misunderstanding on what its intent was.
This is really nothing more than a simple search tool, very useful,
very common tool. On the user side, it is extremely *easy* and obvious
to operate. This is basically nothing more than a text entry. The only
slightly complex part is hidden, this is the ordering part to provide
intelligent answers (top answer is likely to be what the user is
looking for).

You can also compare this feature to Firefox's "Awesome Bar" feature.
It searches through various items, which are the currently opened
tabs, in your history of visited websites,  your bookmarks, etc. And
it would order them intelligently. From the user point of view, that's
still a basic bar where you type things. And it is very useful.
As I told earlier, this feature is really everywhere.

Thanks!

Jehan

>     --ps
>
>         founder + principal interaction architect
>             man + machine interface works
>
>         http://blog.mmiworks.net: on interaction architecture