> > the above requires that GIMP is a tool that gets out of the way ...your tool is the opposite of that... > ...you get right in the way.
Very true. We din't have this perspective. Using keyboard shortcuts indeed gives the 2 operations per second thats required in production environments. However, I guess the video has been a little misleading... The manner and frequency in which this tool is used, is up to the user. i.e, the tool is meant to be complementary. It is not meant to be a substitute for keyboard shortcuts. So, a power user would be experiencing a smooth workflow (which GIMP clearly provides) and this tool would help him when he's either stuck or trying to find something. (i.e, help/explore/documentation) "Almost forget that there is a menu-bar" This anyhow, remains true. tick-tick-tick-tick So beautifully put. I've quoted this to a few people already! :) The menu search tool will not give this speed. Talking about increasing productivity, we've had ideas of extending the concept to offer a command execution. Wrt http://www.gimpusers.com/forums/gimp-developer/13823-fw-suggestion-for-new-versions-of-gimp#message63546 that is. This perhaps, would really mean "maximising productivity". On Sat, Mar 10, 2012 at 12:41 AM, peter sikking <[email protected]> wrote: > Srihari Sriraman wrote: > > > can you give a statement what this is suppose to achieve. > > > > Maximize productivity > > Almost forget that there is a menu-bar. Use the mouse/touchpad lesser. > > I accept the 3 points you write below, it is that > help/explore/documentation system I can see in this. > > but the statement above? you do realise what GIMP is being > (re)designed for, no? it is for serious image manipulation, > seriously creative working and for production environments. > > a lot of this work is hands-on on the canvas, in the context of the > graphics on the canvas, which are not like vector graphics or files > in a browser something that can be keyboard transversed. > > the above requires that GIMP is a tool that gets out of the way, > by being visceral, part of motor memory. you tool is the > oposite of that, by users having to formula what they want > and type (part) in to get a query going then scan the results > and pick one, you get right in the way. > > GIMP also requires that everything designed for it can support > working at a speed of 2 operations per second. just for a moment > say tick-tick-tick-tick-etc. at that speed. I do it every time > I bring this up in a lecture or when I teach interaction design. > it gets the point across right away. > > so I have given you now 2 concrete requirements in a GIMP > context how you can prove the phrase "Maximize productivity." > one is even quantitate, which is rare in user interaction design. > > tell me how you meet them. if you don't, you are providing > anti-usability. (that is apart from the help/explore/documentation > system below:) > > > Intent driven rather than hierarchy driven navigation > > Focus on 'what' rather than 'how'. > > Discover functionality > > For new users > > Help transition > > From proprietary software. "What is 'smth' in GIMP?" > > sorry to spoil the party, but to see how think this is a good thing, > when it can be so treacherous, is quite dangerous. > > --ps > > founder + principal interaction architect > man + machine interface works > > http://blog.mmiworks.net: on interaction architecture > > > > -- * * *Regards, * *Srihari Sriraman *
_______________________________________________ gimp-developer-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gimp-developer-list
