2005
14
Jul
14
Jul
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 ;).
- daniel molkentin's blog
- Login or register to post comments
- 1074 reads
Syndicate Blogs
Comments
Awesome work =)
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
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.
Re: Triangles...
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.
good
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.
A bit dubious
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?
Please don't...
...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.
Have a look at...
...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
> ...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