From kde-usability Tue Aug 14 00:32:06 2007 From: "=?UTF-8?Q?Rafael_Fern=C3=A1ndez_L=C3=B3pez?=" Date: Tue, 14 Aug 2007 00:32:06 +0000 To: kde-usability Subject: Re: KPluginSelector improvement suggestions Message-Id: <93f85fee0708131732g79cf8347qbc48b1f6e93a6515 () mail ! gmail ! com> X-MARC-Message: https://marc.info/?l=kde-usability&m=118705156908598 2007/8/13, Sebastian Pipping : > Hello Rafael! Hey Sebastian, Dominik and usability list members, First of all: I took the freedom to send this mail to kde-usability mailing list, since I think we can have good input from them. Your comments are very valuable :) > I wrote the following mail under high pressure of time > and without knowledge of all the details. > Please excuse if I am a bit rough here and there. Yeah, no problem, understood. > While checking out the current state of the plugins selector > I stumbled upon a few major usability problems. I hope to > find open ears for this so we can have a killer and by the > way quite sexy plugin selector for Kate and KDE 4. > > The checkbox > To check/uncheck a plugin I have to exactly hit the > checkbox. At least a larger area around it should also > do this for the user. I tried it myself and it really > was no fun, especially because I have to be precise in two > dimensions at once. You can also hit space. Nothing better comes to my mind about the checkbox, I mean, what could we do for fix that ? The checkbox corresponds to the whole delegate, we can't say: "if you click on the title of the plugin the check is toggled", at least I think so. If you have better ideas, just tell them here and will be heard :) > About / More options > This is several problems at once: "About" and > "more options" are very different things. The only > thing they share is popping up a dialog. Different > things should be easily distinguishable for the user, > especially when one is of high importance like > configuration and the other of low importance > like an about dialog. Also this hyperlink-style > buttons don't stand out at all. Why "more options"? > I mean there can only be more if there already is > options. The load state itself doesn't count for > me here. Only is "more" if there are options. "More Options" is shown when the plugin has configuration dialog, and "About" when not. If "more options" is not good enough, tell us your proposal :) > Double click > I gues most users expect that when they double click > a plugin something happens about it. It could be > config open, check/uncheck or the about dialog popping up > but they sure expect something to happen. Currently double > clicking does nothing. Please don't give that away. Why ? I think you are missing here that it is possible to configure your desktop for single-click. What's more, double-click is completely unnecessary on today's desktops. Clicking twice on a delegate and doing something is one of the worst usability things I can think about: what would you do ? I would tick-detick the mark, my brother says he would open a dialog, my mother that a plugin preview is shown... hmmm... completely random from my point of view. > Icon size > With such a huge size for the icons there won't be space > for more than 6 plugins on a single page. I think this is > waste of space. Maybe try something 2/3 of the current. > It also feels a bit toy-like with such a size. Yeah, I agree with this. ****** CODE DISCUSSION FROM HERE ****** > There also is a thing about the API that maybe can be solved > in a more flexible way: When dealing with different kinds > of plugins you cannot offer functionality specific to a single > kind of plugin if you don't pull it out of the selector code. > One way is to move the show-dialog functionality into the plugin > class since it knows what i is and what it needs, which the > selector doesn't. You can go one step further and let the > plugin create an instance of a specific handler that does the dialog > stuff to better separate code. I am talking about this to > re-enable the dialog derivation concept that seems to got lost > on the way (think hasConfigPage and showConfigPage for Kate). The trick is that applications should fit for the general purpose libraries. The main problem is that we have other applications running nicely with the plugin selector (Konqueror, Kopete, KWin), and we should think about them too. I don't think the way the plugin selector handles configurations dialogs is "worst" separated than your solution. I even think is better because we use KCModules, that is their main purpose (yeah, "K Configuration Modules"). That's their purpose. And you can also [since my work looking forward for kate] provide on a plugin library the plugin and the KCModule(s) for it, in the same library. And yeah, from my point of view that is far better separated, because the configuration dialog is NOT on the plugin code, is on the KCModule code, where it should be, on something that is meant for configurations. What we can't do is change this code on the libraries for the libraries fitting Kate, while Kate is an app, and we have another apps that nowadays use that library. The best thing is that this requires a change of removing two methods from an interface for plugin purposes in your Kate skeleton plugin code. From my point of view the work is near to 0, while changing the libraries would need some porting from other apps. Bye and thanks, Rafael Fernández López. _______________________________________________ kde-usability mailing list kde-usability@kde.org https://mail.kde.org/mailman/listinfo/kde-usability