[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: KPluginSelector improvement suggestions
From:       "=?UTF-8?Q?Rafael_Fern=C3=A1ndez_L=C3=B3pez?=" <ereslibre () gmail ! com>
Date:       2007-08-14 0:32:06
Message-ID: 93f85fee0708131732g79cf8347qbc48b1f6e93a6515 () mail ! gmail ! com
[Download RAW message or body]

2007/8/13, Sebastian Pipping <webmaster@hartwork.org>:
> 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

[prev in list] [next in list] [prev in thread] [next in thread]