Hello Peter, thank you for this mail. It answers all my questions and I think it is very productive. Perhaps even both 1) and 2) can be implemented as two separate systems.
Regards Tobias 2014/1/15 peter sikking <pe...@mmiworks.net> > 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@gnome.org > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
