|
JUL
14
2005
|
Passing Back the BallIt 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 ;).
|
 |
Comments
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
Consistency
> 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.
Re: Consistency
> > 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
>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
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!
...start to look crappy
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.
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?
Pages