--- Tommi Komulainen <[EMAIL PROTECTED]> wrote: > Hmm, I had thought it was already discussed that > having Add and Remove > buttons is mandatory, for accessibility and > discoveribility. I guess I > misread something.
AFAIR, I was just wondering if they were need for accessibility and discoveribility. Later I though that adding the <Type...> label makes editing in place so easy to discover as with a button. I've got no feedback from the accesibility guys, but even with a button, you have to browse a tree view in the dialog that opens with all the signals, and in place editing has been used before. So I guess that accesibility wise it's ok. [snip] > The above should be clean, and show all and only the > relevant > information. Also the use of normal buttons should > be familiar for > everyone. > > It is slightly slower than your mockup since you > need to go through the > dialog (three clicks, always) instead of just > clicking on the treeview > directly (one click, best case.) I just don't > believe adding a signal > is done often enough that saving the two clicks > compensates enough for > the issues I've mentioned. So, in short, the issues are: * discoverability * accesibility * familiarity * shows more information than need As I said, I think discoverability got addressed with the <Type...> label, even if it's yet a bit too visible. I'm playing with several alternatives to make the label less ubiquious, and yet make it easy to see where can you type the handler. Accesibility wise, I think we're ok, but I'm ready to be proved wrong :-) For the familiarity, in place editing is used in any RAD tool I can think of, and the concept has been with us for a long time across any OS. We're also targetting developers, which are usually a bit more computer savvy than the mean. So I don't think that any glade user can honestly say that he had problems grasping the concept. The "shows more information than need" problem is only real if you define the "need" as remove/modify handlers. As soon as you add the "add" a new handler operation, then the dialog shows just the information you need. So I guess the question is if easing the adding of a new signal handler is worth the space taken by the signals without handlers + the unused classes. In my opinion, yes, it is, as there is indeed a very little number of signals on a widget (usually 5-6) and you will rarely use a signal on a parent class (usually people connect to "pressed" signals and such). And I don't consider a list of 5-6 signals to be a problem at all when you're looking for your signal :-) > I'd argue the most used operation is to see what > signals already have > handlers. Before you add a handler you probably > take at least a cursory > glance to see that the handler isn't already there. > With new widgets > you'll probably skip that step, but the longer the > widget has been in > the model, the more likely I think you need to > refresh your memory. You can see if your signal has a handler at a glance. If you're going to take that as an "operation", then the new design also frees the user from 1 additional search when adding a new handler, as with the old design you should first see if your signal has a handler, and then search your signal in the dialog box. But again, the first search is just a glance, you see clearly what are the signals with a handler as those without a handler have the <Type...> label with a different colour (gray instead of black). We can put the signals with a handler in bold to make it still clearer, though. Thank you for your comments! Cheers, ===== Joaquin Cuenca Abela e98cuenc at yahoo dot com __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus _______________________________________________ Glade-devel maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/glade-devel
