Burnie West wrote:
> On 01/14/2014 03:13 PM, Chris Mohler wrote:
>> Staying with the same example, then English menu entry is 'Chromium
>> Web Browser'. When switching to Spanish or Chinese, the 'Chromium'
>> remains the same while 'Web Browser' is translated.
> I read peter's objection to the requirement that the entire language translation process would be impacted, making maintenance nearly impossible.
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.
--ps
founder + principal interaction architect
man + machine interface works
http://blog.mmiworks.net: on interaction architecture
_______________________________________________
gimp-developer-list mailing list
List address: gimp-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
