>> > Since the menus were reorganized I am constantly guessing wether >> > "Repeat Last" will repeat my last action, the one before or not work >> > at all, since you can't tell from the menu anymore. >> Huh? Sounds strange, could you provide a snapshot in a private EMail? >> I can't image what this should look like.... >"Repeat Last" will repeat the last plug-in. Since menus do not provide a >feedback of wether an entry is a plug-in or "built-in" (I think it would >even be wrong to do so), you have to know this, which is not easy for >beginners. True, I have users with problems in this line, things that are plugins but appear as core, scripts that appear as filters, scripts that are undoable. Well, you get the idea, a mess and the user becomes crazy. >> > I am quite sure it improves usabiloty for me a lot. >> Well, I could provide you a patch which reverts it when you compile >> it with CFLAGS="$CFLAGS -DIMPROVE_USABILITY_FOR_MARC" :) >Please note that I am not alone with that opinion... -DIMPROVE_USABILITY_FOR_MARC_AND_OTHERS ? ;] >> Right, and if a window want's your interaction it's called a dialog. >> Everyone sees that, so why bother with titling it a dialog? >Because a dialog already provides enough visual feedback to let you tell. >Tools vs. Plug-ins vs. Other dialogs often do not provide this. I doubt there is too much info in this case (I have too see a place where too much info can be a bigger problem than too few), specially if window manager can paint dialogs without title. In other words, provide the info, and let the user decide if it must be shown or not. >I mean, with your logic, you could remove all text from the dialogs, since >the layout is enough to find out what the dialog does, and the tooltips >can help you. Yeah, tooltips... fine if you use a thing a lot, a pain if not, cos you have to wait every time you need it. Tooltips are to give more info, not "the" info. >You need the right mix between feedback and not, and I think yours is too >low. Especially since you are a skilled gimp user, while others are not. Those users, the unexperienced ones, complain to me about computers. Typical problems are instructions not read (their problem) or not avaliable (coder's problem). >> > Tool tips are a very slow way of interacting with a user. >> impressive icons are a lot better >This is wrong. Many people (like me) rely on text to quickly evaluate a >situation. This is common for unix-type-people. Icons are a much slower >feedback then text. At home 3 of 3 read text better than understand icons. Dunno way, but that is the fact (rare family?). You give us an icon with a scissors and we say "aahh, what? seems to be scissors, uuumm... cut?" you give us a button named "Cut" and we say "cut". What is more, icons can distract us. We do not use icons when we can avoid them. Unluckly some apps force icons even if you do not want (we use shell a lot, as you may guess). Anybody want to do a clip for Gimp like Vigor for vi? Hey, just joking. >Take, for example, the gimp toolbox. Manye of the icons look almost the >same, so I actually select tools by _position_ in the toolbox, not by a >quick look. Yes! True, and sometimes by trial and error, or shortcut (faster and never fails). >> can't image what a tool is supposed to do, a tooltip can help a lot. >Thats not the point. The point is effective user feedback. GNOME (sorry to "use" these guys) has set a page about newbie users, it is called Sysadmin experiences or something. It speaks about what problems that newbies have, narrated by sysadmins. Some days ago there was some post about this in giimp-dev list (by Daniel?). All apps need to be tested with other persons, not among the coders or experienced users. Should we start one? How? I can post all things I now about users, but we could do something better, I guess. GSR
