Play it again Sam
What to do when something is not as good as expected (or as intuitive as expected) ? Well, you drop it. That is what I’ve done with the way the plugin selector handles the Configurations dialog & the about dialog. Now they are separate buttons. It didn’t make so much sense when having configuration dialogs putting instead of “About”, “Options” and adding there the about information of the plugin. Mandatory screenshot:
This time the glory is for Kopete 
Categories: KDE Development
I like how the plugins are neatly organized in their own panel. The first thing that came to my mind when I saw this screenshot was the same buttons repeated over and over again for each entry. Wouldn’t the interface look cleaner and simpler, and a lot less redundant, if the two key buttons present in each selection were simply placed down once in the menu? Then, when you highlight one option, you click on the respective button and configure the plugin. Just a thought.
Hi Skutobantao,
The idea is really welcome, but here we face a usability problem. There are some plugins that are able to be configured, and others that aren’t. In the scenario that you present if you have 100 plugins, you would need to click 100 times for each plugin for checking if that plugin was configurable or not (depending if the only “Configure” button gets enabled or not).
Taking in count I really think plugins are going to become really more used nowadays, we will have tons of thems. What’s worse, imagine you have a plugin “foo” and we use the scenario you present. On version number 0.1 of the shiny plugin “foo” that poor plugin hadn’t got configure options, everything was hardcoded. Then the developers of the plugin decided that they wanted to make something configurable. The worst thing here is that you won’t even try to click on it again when 0.2 appears [you probably won't even notice a 0.2 version had been installed] and see if the “Configure” button is enabled. In the current approach, just when you open the dialog for enabling/disabling a plugin you would go “hey ! now this one is configurable !”.
Thanks for your opinions and suggestions
Hi , I was about to comment the same as first comment but your justification seems to be correct.
Anyway if there is gonna be so many plugins, wouldn’t it be better to provide a filter line edit as well ? (as in amarok)
I found the previous version with the links looking much cleaner than that. Its exactly this things (eg. many buttons) which always lets KDE’s interface look crowded and busy comparing to gnome.
What I learned is that every line in an interface makes it looking more crowded and “unclean”. With so many Buttons (and four “lines” for every button) on the list you have many lines which could have been saved for more cleanliness.
So what was the reasoning to change the links into Buttons?
I don’t know what the previous one looked like, but that certainly looks fine to me (and I can see it minimizes the clicking and mouse moving over having having to select a particular entry and then move the cursor somewhere else to click the buttons).
I like it, however I too think all the conf/about buttons are a bit messy.
Also, the filter-suggestion is great. It should be everywhere
Good work!
What about making the buttons appear only on the selected line (or maybe on the line under the cursor)?
@Rafael
>> There are some plugins that are able to be configured, and others that aren’t. In the scenario that you present if you have 100 plugins, you would need to click 100 times for each plugin for checking if that plugin was configurable or not
Why would anyone do that? Do you know anyone that installs 100 plugins and then really wants to know if he can configure each one or not? That’s silly. If you’re looking at the plugins dialog, then you’re just interested in finding a particular feature. Once you have located it in the list, you might want to check the settings for it. Personally I feel that the best solution is to only show the buttons on mouseover or selection, as Fredp proposed. But either way is probably fine. Most users won’t spend much time in this dialog anyway, so a few extra buttons won’t be a deal breaker
Which brings to mind that another nice feature to have might be a quick search bar that filters the search dialog so you can find the feature you want quickly. Especially if you have 100 plugins installed, which you seem to think is a possibility.
Good work!
Hi all !!
@Shyru
I guess I have to say the magic word here: usability. The question that needs to be asked here is: do users expect a dialog to be opened when they click a link ? The optimal (and the most intuitive thing) is to draw a button as the rest of the system does for actions.
@Fredp && @Leo S
I don’t know if making things appear by magic is a good idea (specially on hover-mouse events). With this I mean: we should think about people that is visually handicapped. They should be able to see what’s going on, and things (dis)appearing by magic is such a bad thing for them, that they can decide to don’t use the sytem at all. Let’s make them life easier
. Less magic and things more clear 
@Leo S
As mentioned, that was only an example. There’s the other good reason (and reasonable) of improving a plugin and creating a config dialog for it. With the other solution you probably were going to miss it.
The filter thing should be added to this dialog. As this dialog is somehow special (because of the categories drawn), I think I need to concentrate better for adding the filter feature for 4.1. I need to concentrate now on Dolphin, and I think this dialog is probably ready for 4.0.
Really, thanks for all your comments and opinions. They are so good… you guys help us to make things better and see our own design errors. THANK YOU.
I think the reasoning for putting the buttons behind each plugin is flawed. It’s just like I would think, which makes me suspicious
I’ve been thinking about it, and I think you should try to see it from the users perspective. they don’t look for a configurable plugin, they don’t care about that. They want a certain function. So there is the plugin. They enable it, that’s the most important part. They MIGHT want to configure it or to read about it’s author, but that’s secondary. So I think by this reasoning, you should put the buttons on the bottom. It would make the look much cleaner, it doesn’t take away features, and the scenario you give doesn’t work for common users – they couldn’t care less.
I think…
Maybe some usability person could speak up, no idea if this has theory on it.
Now I thought about it even more, and I’m pretty serious about it. I think it’s not smart to clutter the UI for some very unlikely benefit… so please don’t
Actually, that’s a good reason to include the buttons for each entry.
>superstoned
Plugins are quite configurable by nature, they don’t just serve the purpose of being enabled or disabled. If it were like that, then the need for changing their settings wouldn’t exist. If the present situation is anything to go by, then many plugins have their own dialog boxes for changing various settings. Therefore, anyone who wishes to use these plugins and customize them will need quick access to them. This applies to anyone who is using the program. I think you should read Rafael’s post because he has a very convincing reason to go along with the present display method.
My concern is that simplicity should be adopted in the program windows which are most going to be viewed by the user. It doesn’t really matter for configuring options here, but the chat window, the message style window etc. They need more attention.
I have to agree that it looks “cluttered” with all those buttons. However, I still prefer buttons over links, and I definitely don’t want to show them at the bottom.
How about this: Make the “About” look like a link with dashed underline. Then, show a tooltip with the about information on mouseover (this would be useful if you look through the plugins and want to know more about what they go). The “Settings” would remain a button.
I thought about doing a mockup, however I simply don’t have time today. I wonder if this will reduce the feel of clutter, if it looks good, and if the “link” and button should be placed horizontal (beside each other like now) or vertical. However, I believe the first choice would be the best, as the latter one will contribute to something we want to avoid.
With that said, I don’t know if it’s a good idea at all; any usability expert who wants to speak up?
@skutobantao:
How relevant is it if a plugin is upgraded and now has a config button? It’s great for geeks, but most other ppl wouldn’t care much. I think it’s more important to enable them to use the plugins at all – and that’s gonna take some effort in simplifying the dialog and making it less distracting…
But putting the buttons on the botom might als not be the best solution. Maybe enlarging the selected item, and showing the buttons, otherwise hiding them? How do other plugin dialogs do this?
Hi,
@superstoned
That is something we discussed at kwrite-devel. I really think what one would like to is to go to the plugin manager, see what is available and if someone wants to enable a plugin of the list, he/she checks if it is configurable. Configure it for his/her needs. Enable it.
On Kate/Kwrite for example, plugins are added per view, and each view contains its own configuration. That means that all they load the defaults of the plugin (or the last saved), but then you can enable/disable features on the views individually. That’s is a corner case for the stuff you present. Probably a user will load the plugin first (without configuring it). See that the “word completion” plugin he doesn’t want the list to come up automatically. Go to the plugin manager to configure it and that has no effect on his decision, because the view has now its own configuration and has to be configured on the view itself (on the menu that the plugin added or whatever).
I think you are wrong on the “geeks” part. If I am a user of Kwrite because I do lots of works for the university with it, and I love the word autompletion plugin. Probably I will go really glad if it is improved. I don’t think a gamer is a geek because he finds out that from version 1 of game X is improved the feature Y to version 1.1. That makes users glad, and not only geeks, but users.
@Hans
> How about this: Make the “About” look like a link with dashed underline. Then, show a tooltip with the about information on mouseover (this would be useful if you look through the plugins and want to know more about what they go). The “Settings” would remain a button.
I really think this is no good. As I said on other post (or above) what we should think about is if a user expect a dialog to be opened when they press a link. What’s worse: even on Konqueror users are able to select “DO NOT UNDERLINE LINKS”. That would have a really bad effect on this decision. Mainly because of two reasons: 1. We are forcing the underlining. 2. We are forcing the dashed underlining. Nowhere on the system I have seen a dashed underlining. That completely crashes with the unification of the system.
Thanks !
@rafael: about the geeks, I can see why most ppl would enjoy the improvements to plugins. That makes sense. But I don’t think you should optimize the dialog for the very unlikely case there is: 1. a plugin which the user uses. 2. which didn’t have a configure option. 3. Now is improved. 4. now DOES have a configure option.
I mean, how often does that happen? This shouldn’t be a reason to dis-optimize for all users…
i wonder what you think about the ’show configure on selected plugin’ option?
I agree on the underlining. It does look pretty, but it’s inconsistent. And consistency is important in itself… BTW whatever you decide – props for thinking it through so well
@superstoned
. the point is: most users configure once. configuring kopete plugins the first time with only one configuration button is simply a pain. you double the effort it takes to get to the plugin configuration… also note that many of those plugins are completely useless when not configured (at least in this application/screenshot).
well, i think users _do_ care about configurations, if they open the configuration dialog
but still, this dialog is way to crowded right now. i think the about button isn’t needed. thats what users realy don’t care about
. showing the author (or website, both as links) somewhere in the description should be enough.
also, configure buttons don’t need to be so big. don’t draw the icon, even if its enabled in the config. and maybe make the button text 20% smaller (so the button is 20% smaller too).
i think that would remove most of the visual noise. there would even be lines without a button at all.
Yes, I think the entry for the plugin could definitely have more information in them right from the onset, instead of just a single line. I mean, if there are big icons going to be used then there needs to be such a thing. Secondly I would suggest eliminating the about button altogether and perhaps placing that information within the entry box? I mean, the about dialog is surely going to display minimal information (like the developers name, version and website of author) which would easily be placed within each entry’s selection without it looking crowded.
Anyway, I hope Kopete gets more features as part of KDE4
I even use it in Gnome, even though Pidgin integrates a lot better.
I’m not sure if this is the right place to ask but how likely is it that Kopete can import the contact list styles from Adium? It already can import the message styles, so I think importing the contact list styles should be thought about. I feel that’s the right approach to take for Kopete’s development – interoperability with a messaging client that already has a creative and prolific community supporting its development. Now that KDE apps are going to OSX and Windows, that would give even more reasons for people to use and develop for Kopete.
Looking over the fence, Firefox only shows the buttons for the selected item. I agree that this makes the dialog much less crowded.
IMHO, please also remove the vertical space between plugin name and description. It looks disconnected.
Thanks for your work!
Christian
Rafael,
I see your point and I completely agree. However, I also agree with the people who think a About button/plugin, and sometimes a Settings button, is too much.
If the About button is going to show information like version, developer etc. I also think that it should be placed somewhere else. Maybe as a menu item in a right click context menu?
looks very nice, a find as you type feature would rock!
keep up the excellent work!
btw nice blog layout
If one doesn’t see the configure dialog as soon as one selects a plugin, there may be a usability issue. In Kopete in openSUSE 10.2 (KDE 3.5.7), for the Translator plugin, the default Native Language chosen is German. With the current system, I see right away that the wrong language is chosen for me as soon as I enable the plugin, and I can fix it. If I do not see the configure dialog as soon as I select it, I may not press Configure, and the wrong language will be chosen for me.
So, either the configure dialog should automatically come up, or one has to make sure that all plugins’ defaults are chosen appropriate; e.g., for Translator, it should default to Unknown.
For the layout of the plugin selector, I’d suggest one remove the About button, and instead have each plugin have three lines of text:
Title
Description
More info…
More info would be a text link to the About information.
I think this would arrange the layout better. On the left you’d have all the “information” of the plugin (Title, Description, More info…). On the right, you’d have the configuration, and it’d be much more visible which plugins are configurable or not, because it’d be the only button on the right. Now there is visual “noise” from the About button, so it’s hard to see the “signal” of the configuration button, because it’s obscured from the About button “noise.”
i am so pissed. the translator plugin wont retain the configuration. it keeps going back to the default language of “german” and “do not translate” for both incoming/outgoing messages. GRRR!!!!!