Passing Back the Ball
It seemed I made a wish of some people from the usability folks come true. Presenting: my first approach of a CollapsibleWidget!
The same dialog with two filled and one empty collapsable item on Linux, OS X and Windows:
Interesting to see that there are so many differences in the layouting among the different platforms — odd. But I will sort them out eventually. On the positive side of things, this allows us to finally get rid of the tab-desert in most kde applications and separate common settings from rarely used ones.
This is the part of the usability guys: It’s your turn again 🙂 .
PS: Whoever finds typos may keep them 🙂
First off, I just wanted to say good job!
I do however have some conserns… I guess the window gains a ‘scrollbar’ to let us access content that moves off the viewing area of the dialog?
Now, I do agree that having an expanding ‘context’ is a good idea. In fact, I feel there are many places they should be used.
However… I do not think they should be used in ways that would make a dialog feel more like an application window.
A good example of expanding widgets is IMHO the gnome file dialog. You get a basic dialog with the options most users will need… But by pressing the expander you actually expand the dialog to display the more verbose information. The same idea can be found in the drawers applications have now on MacOs X. (Eh… when they are used correctly I mean. There are currently quite a few examples of how NOT to design an application drawer currently…). Do not get me wrong here about the gnome file dialog however. I have some issues with how the gnome dialog does some things… but the expander is not one of them.
For a bad example… PLEASE have a serious look at how the current version of firefox implements them. Especially considering the fact that the FireFox options dialog implements not just one… but MANY conflicting designs.
General Window:
We have sets of buttons and text grouped together. The top set of buttons change a behavior of something. The buttons below it all bring up a dialog.
Privacy:
We have a table of expandable rows. Each row has an expander, a title, and a clear button. Expanding a row hides any previously expanded rows… colors the row yellow and adds some poorly aligned text/buttons to the row.
Web Features:
We have a list of checkboxes, with ‘advanced configuration’ buttons to the right. This is by far the easiest to understand option screen.
Downloads:
This is your average configuration screen. Much like any basic configuration screen created for the last 10 years.
Advanced:
This is what I imagine you are trying to emulate. While I can’t get an idea of whats ‘configurable’ at a first glace (half the content is off the screen)… at least this time around things are actually aligned! Rows expand in a way I expect them to and for the most part the option screen ‘works’.
Righto… so this post ended up a little larger than I wanted… but anyways… =)
Triangles… Although I don’t mind them personally. I see them as being configurable via the style chosen by the user. Alternatives should probably be selected through that route if the selected style you are using uses triangles, or whatever.
I personally like ‘+’ and ‘-‘, like this:
http://kde-artists.org/main/component/option,com_smf/Itemid,48/expv,0/topic,19.msg671#msg671
-Ryan
Keep it simple and consistant. Let the theme decide whether the list items have triangles or +/- symbols next to them.
If extra configuration is needed it should be part of the theme.
I absolutely agree with this. It greatly annoys me when one program or the other decides to draw it’s own expand/contract buttons, which then carry the hallmark of the programmer’s favourite widget style. In most cases this means that they are the [+] and [-] marks, but in my style they are arrows like here.
It would as Ryan says be achieved best simply by reusing the tree-view drawing routines, asking the widget style to draw the expand/contract graphic.
Personally I’m not really sure about having hidden options. If the options aren’t important, maybe they shouldn’t be there in the first place.
But anyways, KDE already has for instance “Advanced Options”, a popup dialog in the Kicker configuration. That really sucks usability wise, since I’m looking for the option I want not a button. I think this would be an improvement, make it more obvious that there are options currently hidden. A button doesn’t give any indication of this.
Personally I’ve never like that kind of hide the options style of interface. I also notice that it means you’ve got a form-style widget with scrollbars which is also frowned upon. What is the motivation behind having collasible widgets?
…use these fugly small triangles. It’s something I really hate when using Ethereal or other Gnome’ish applications.
I don’t like’em either, but it’s a decent compromise between removing some options and screw your geek users, or clutter the interface and screw your averagely dumb users. I wonder if there might be a better metaphore for the icon, as the triangle is often too small and hard to click on (maybe something expanding?), but anyway.
I agree that option panels should not have scrollbars if possible. But that should be left to the individual application design.
…the alt+f2 dialog. What do you see? Yes, a button. A real fat [button >>]. It’s far better to click on it, than aiming at a small “>”, it’s more UI consistent and you even can assign a shortcut.
And it’s not a compromise, it’s a step backwards. You have to go through the whole dialog with your eyes to detect if there is a hidden subsection of the dialog. It’s as annoying as Microsoft’s hidden menu entries. If you have too much options, use a tabbed dialog. If there are still too much options, there’s the chance that it will be possible to strip them down. If nothing helps split the dialog in two or multiple ones.
> …the alt+f2 dialog. What do you see? Yes, a button. A real
> fat[button >>]. It’s far better to click on it, than aiming
> at a small “>”, it’s more UI consistent and you even can assign
> a shortcut.
More consistent with what? This new solution is at least consistent with other platforms (i just found out from danimo that Next has had it for 15 years already! – and gnome and the mac have it as well) and consistent with itself. Now we at least have a standard – before everybody just implemented advanced options hiding differently.
The big fat advanced-button had some flaws that made it impossible to keep it. One was that it jumps around and you can’t keep your mouse in one place to open and close it again immediately if you notice there’s nothing you need under it.
> And it’s not a compromise, it’s a step backwards. You have to
> go through the whole dialog with your eyes to detect if there
> is a hidden subsection of the dialog.
Yes, advanced options are less obvious now, that was the point, they are supposed to be quite subtle. We didn’t want them to clutter up the interface. Options a majority of users need often should of course not be hidden under them. But for options that are rarely needed a bit of searching doesn’t do that much harm. Less harm than confronting most people with a lot of options they will never need.
Tina
> More consistent with what?
With the other widgets you usually click on. It looks totally different to buttons, scrollbars etc.
> Next has had it for 15 years already!
That doesn’t make it better. I’m surprised you name consistency with other desktops. “They all do it, so this is the best possible solution.” is a questionably tautology.
>The big fat advanced-button had some flaws that made it impossible to keep it. One was that it jumps around and you can’t keep your mouse in one place to open and close it again immediately if you notice there’s nothing you need under it.
Right. But I don’t see a reason why the button has to jump around. Leaving it at its place shouldn’t be that hard.
> Yes, advanced options are less obvious now, that was the point, they are supposed to be quite subtle.
It will make configuration only harder, since it’s easier to overlook options. In the end you don’t configure once, but search a few times where the one or the other damn option you have missed may be hidden.
> > More consistent with what?
> With the other widgets you usually click on. It looks totally different to buttons, scrollbars etc.
I fully agree that it will mean another thing to learn, and due to that, options that are needed by users that are typically afraid to click on things should certainly not be placed in such a box.
For the minicli and kcms this solution seems to not violate that principle and even with discoverability in mind, its better then the alternatives.
That said; the real version will probably have a different mousepointer over the whole header so discoverability goes up.
> > The big fat advanced-button had some flaws that made it impossible to keep it. One was that it jumps around and you can’t
> > keep your mouse in one place to open and close it again immediately if you notice there’s nothing you need under it.
> Right. But I don’t see a reason why the button has to jump around.
> Leaving it at its place shouldn’t be that hard.
Hmm? Did you actually look at it? Its at the same level as the ok/cancel buttons, you can’t just take it out of that in one state..
And placing the button inside the dialog is certainly not the solution.
I’m sure you did not look into this very long 🙂
> It will make configuration only harder, since it’s easier to overlook options.
Less (visible) options makes finding one of them harder? Not in my world
>Hmm? Did you actually look at it? Its at the same level as the ok/cancel buttons, you can’t just take it out of that in one state..
And what stops you changing this, when the dialog changes? I never made a dialog with Qt-designer. Is the Qt layout concept that limiting, that you can’t change it dynamically?
Minicli isn’t done with designer. But that’s not the point. I could put it right below the command line box, and it would immediately start to look crappy. Try it yourself!
Can’t really disagree, when speaking about such a large button. But it doesn’t help that I strongly dislike the approach you’re presenting. Each attempt to improve KDE is worth it, though. How about placing the “>” on a (slightly smaller than usual) button at least? While not alleviating the impact of hiding options (controversial subject imho) it would bring back a bit ui consistency at least.