Re: [Gimp-developer] Search Action dialog feature

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


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

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.


if you chose TITo to be a) (a help system) then you must build
a bridge to the (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

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