Re: [Gimp-developer] An update on the menu search
- From: Srihari Sriraman <techie visishta net>
- To: Michael Muré <batolettre gmail com>
- Cc: gimp-developer <gimp-developer-list gnome org>
- Subject: Re: [Gimp-developer] An update on the menu search
- Date: Sun, 11 Mar 2012 12:32:10 +0530
should display the keyboard shortcut next to the name of each item
Shall soon be done
On Sun, Mar 11, 2012 at 11:55 AM, Michael Muré
<batolettre gmail com> wrote:
I also think that it does not collide with the product vision. Even a professional user need to learn a tool before using it. Also, I know a lot of people that see GIMP as an enhanced MS Paint, because what GIMP is capable of is not obvious. The menu search allow to answer the question "what can I do with X (layer, selection, image ..)", without needing to search in all the menu.
Also, I think you really should display the keyboard shortcut next to the name of each item. It would allow to learn easily these shortcut, to use them later at high speed.
My 2 cents.
2012/3/11 Srihari Sriraman
<techie visishta net>
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.
This perhaps, would really mean "maximising productivity".
On Sat, Mar 10, 2012 at 12:41 AM, peter sikking
<peter mmiworks net> 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
--
Michael
--
Regards,
Srihari Sriraman
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]