Re: [Gimp-developer] Search Action dialog feature

[Tobias Oelgarte <tobias oelgarte googlemail com>]

Am 15.01.2014 11:15, schrieb peter sikking:
> I actually did not say that. I do not see it that way.
>
> and instead of going into the smaller points that are being raised
> in the replies to my previous post, I am going concentrate on
> the main point.
>
>
> Structuring the design process is ‘half the work’ in my daily
> practice and in order to enable the TITo situation to turn
> from negative to positive, I will contribute this:
>
>
> 1) the people who are really driving this (Srihari Sriraman and
>   Jehan Pagès I believe) have to take a hard choice; is TITo
>
> a) a help system via text search to learn using GIMP
>
> b) a command-line system for operating GIMP
>
> these things are mutually exclusive (too long to explain, but see below...)
> and that is why there is no fudging possible. Make the choice
> and write it at the top of the spec page (“TITo is ...”)
>
> 2) remove from the spec (and the code) everything that belongs
>   to what you chose TITo _not_ to be (not to worry, I will point
>   out what will have to go).
>
> examples:
>
> if you chose TITo to be a) (a help system) then things that
> belong to b) have to go. this include the 2-char command thing
> and the f-recency prioritisation (or, you will need to change that
> for learning situations so much that you would not recognise it
> anymore).
>
> if you chose TITo to be b) (a command-line system) then things
> that belong to a) have to go. this includes verbose explanations
> when showing the actions that match the query string.
>
> 3) now you have to design TITo, for the goal you set.
>
> examples:
>
> if you chose TITo to be a) (a help system) then you must build
> a bridge to the docs.gimp.org (in the right localisation); there
> are many ways to do this. as I said before, if you are serious
> about “Text-based Intent driven Tool” then you have to build a
> synonym list for all GIMP command keywords, in all localisations;
> since this is open source, I recommend you design a system where
> users playfully add synonyms themselves to their own localisation
> (which is then shared across the GIMP community).
> also you need to concentrate on teaching users where they find
> the thing they have queried in the UI (show it, not say it),
> instead of invoking it.
>
> if you chose TITo to be b) (a command-line system) then
> you need to design a super-fast input method, maybe permanently
> available if users chose so. and you need to design a command
> language (a difficult job I would not like to take on, even if
> they paid me double); the current 2-char lets-see-if-we-get-lucky
> is simply not going to cut it.
>
> 4) we review the spec, and adjust until you have something that
> realises you stated goal.
>
> 5) implement. you can do this before, during or after you
> write your spec. the spec however is authoritative, and at
> the moment that you want TITo to be included in a GIMP
> release, that implementation most match the spec. no fudging
> with less or more features.
>
> when you have successfully taken steps 1–5 you can get
> TITo into the standard GIMP release. if you decline, or
> are unable, to complete any steps, then as far as I am
> concerned TITo will not get into the standard GIMP release.
>
> in that case you better think of how TITo can be distributed
> as a user-installable add-on. in that case you can also
> make TITo whatever you want (it is a free world), because
> it no longer reflects on the GIMP project how it turns out.

I can't really follow your arguments. You want something to be either 
the one thing or the other. But does a user really want the one thing or 
the other?

Many users do not need a real help system (a long boring text document 
with a full text search) or a console (shortcuts or a history are 
usually the best way for repeated actions). They actually search for a 
functionality (action) that does the trick, while the function itself is 
usually self explanatory (otherwise it is badly designed itself). The 
worst part of complex software programs is not the amount of 
functionality, but to find the right menu entry or shortcut in the 
endless list of possibilities. A simple search tool for this actions is 
big help for new and even experienced users that don't know where a 
functionality is hidden or how it even has been named. That is it's purpose:

1. Finding an functionality by typing in a related term
2. Looking up or changing the shortcut for a functionality
3. Finding and executing an functionality that is used quite seldom. 
While the name might be known, the location often is not (hovering over 
menus takes way longer as typing).

Greetings from
Tobias Oelgarte