Hi,

I've noticed some seemingly needless clutter that (if it is indeed needless clutter) we should maybe make sure either doesn't get carried forward to any new window design or 'get rid of this clutter' gets incorporated into some guidelines.

As an example I'll use Dolphin, here's a screen shot of what I'm talking about:

http://element-6.deviantart.com/art/Dif ... 1398360517

The system obviously knows the difference between the main Dolphin window and it's 'settings' dialogue window that pops up. I can see exactly why there's a 'close' button on the top right of the dialogue window but do we need the 'minimise' & 'maximise' buttons next to it??

Also a 'help' button appears along with the 3 usual buttons at the top right ('close', 'maximise' & 'minimise') on dialogues but doesn't actually do anything at all when you click on it (I found it on many dialogues and none of them did anything) - if it doesn't do anything why keep it??

At the bottom right of the dialogue are 3 buttons, 'OK', 'Apply' & 'Cancel' - couldn't we get away with just 'Apply' like on all of the 'System Settings' pages? Clicking 'Cancel' is just exactly the same as clicking the top right 'close' button and the 'OK' button just seems to apply any changes before then closing the dialogue.

The window button issue in the decoration is an non-issue (it may be a default config issue), as you can disable it (Go to System Settings/Workspace Appearance and click "Configure Buttons ..." on the bottom, then tick "Use custom titlebar button positions" and drag away the question mark).
So the window decorations are flexible enough to get rid of this.

But in general the topic you try to address is indeed interesting would need some work, for example one thing is: why having both "Ok" and "Apply"? I think from a technical point of view enabling options that would need more time to apply should not freeze the UI at all if implemented properly so I see no reason anymore for having both Ok and Apply ...
Furthermore the "ok","apply" logic creates a bunch of problems in system settings: For example go to System Settings/Workspace Appearance and select "Configure Decoration" and change something there ... for example button size ... you will see it will apply without waiting for you clicking apply ... something that seems to contradict the overall logic. I have talked to a dev about this some time ago, but he said technically it would not be easy to make this consistent.

Apart from that I think duplication is bad anyway, look at System Settings: We have two entries called "Help" (on the bottom and in the toolbar) but the one in the toolbar is more general and includes an option that is triggered by the button on the bottom, so in theory the button on the bottom is kind of unnecessary.

I think duplication is bad anyway

I couldn't agree more!

ken300 wrote:At the bottom right of the dialogue are 3 buttons, 'OK', 'Apply' & 'Cancel' - couldn't we get away with just 'Apply' like on all of the 'System Settings' pages? Clicking 'Cancel' is just exactly the same as clicking the top right 'close' button and the 'OK' button just seems to apply any changes before then closing the dialogue.

I treat it as bad habit to use the top right close function instead of the Cancel button. Developers can implement functions for the OnClose-event as well as for the OnClick-event (of the button). The Close button sets a result flag and calls the close event itself. Users are often afraid of pushing buttons, but might miss cleaning up routines, for instance (whether or not its good coding practice).

In Windows a border style for tool windows is known which hides all 'decoration' (MSDN: WS_EX_TOOLWINDOW). But Linux (KWin?) does not limit flexibility and allows to resize all secondary dialogs. But since I'm not a developer it would be good to verify this information.

'Apply' keeps the dialog open whereas Ok closes it. It's very useful to test changes. If most KDE dialogs have this feature I'd vote for always providing all three buttons, for the sake of consistency, and to disable 'Apply' in case its not available. If only a few dialogs have the option to apply changes directly, it makes no sense of course. I guess KDE provides Apply in almost every dialog.

We have written a guideline for dialogs (HIG) but it does not deal with these issues. Perhaps its worth to enhance it...

Heiko Tietze,

I see what you mean, clicking the top right 'close' button just closes the dialogue regardless of whether you've changed anything.

I assumed the dialogues behaved the same as the System Settings windows - in them if you change any of the settings, don't hit 'Apply' and try and close the window with the top right 'close' button then you get a dialogue asking if you want to 'Apply', 'Discard' or 'Cancel' closing the window.

I think we need to separate bugs and design here. The differentiation between Ok and Apply is a feature, it's intended to be like that. Changing it to what e.g. gnome does, which is apply as soon as something changes, is a discussion which is started on a regular basis. I don't think it's a good idea for various reasons.

Making dialogs non-resizable and non-maximizable is a bad idea, I don't think we need to discuss that (tell me if you think we need to). Lots of dialogs profit from a larger size and removing the ability to maximize a dialog just to get rid of the button makes no sense.

Why would you forbid minimizing dialogs? I hate that you cannot minimize dialogs in MS Windows. Why?

Dialogs not asking whether you want to save your changes, if there are changes, when you click the close button in the window decoration are a bug in the respective application and should be fixed.

I think from a technical point of view enabling options that would need more time to apply should not freeze the UI at all if implemented properly so I see no reason anymore for having both Ok and Apply ...

I don't think that's the point of having Ok and Apply instead of Close. The idea is that you can make some changes and then decide if you want to indeed apply or discard them. For example, accidentially clicking a button or checkbox will be very easy to undo with this pattern, but might be annoying if the option is applied immediately.
Furthermore, "properly" in this case will often mean much higher code complexity, if "properly" means "you can change arbitrary options while the UI stays responsive". Of course, for 99% of all options this is a non-issue.

Furthermore the "ok","apply" logic creates a bunch of problems in system settings: For example go to System Settings/Workspace Appearance and select "Configure Decoration" and change something there ... for example button size ... you will see it will apply without waiting for you clicking apply ... something that seems to contradict the overall logic.

That's right, but you will have similar inconsistencies if you apply stuff immediately. For example, that won't work for the screen configuration dialog (you can't / shouldn't immediately change screen settings when the user clicks stuff there). This just means that the paradigm which works well in most cases is not suitable for this particular thing for whatever reason, be it technical or logical, and a different paradigm is used instead. Not great but I think unavoidable, and not solved by switching to the other paradigm.

Apart from that I think duplication is bad anyway, look at System Settings: We have two entries called "Help" (on the bottom and in the toolbar) but the one in the toolbar is more general and includes an option that is triggered by the button on the bottom, so in theory the button on the bottom is kind of unnecessary.

That's a bit unrelated, but a valid complaint -- you should maybe start a new thread about that and try to find a solution.

But Linux (KWin?) does not limit flexibility and allows to resize all secondary dialogs. But since I'm not a developer it would be good to verify this information.

To resize a window the application itself plus the window manager (KWin) need to allow that. I think in Windows the problem is that the applications usually don't support it; it's slightly more effort to do a resizable dialog than a fixed-size one sometimes.

Couldn't the dialogues be made to behave like that too so that System Settings window and the dialogues all behave the same way??

Yes, they definitely should.

Greetings!

scummos

I'm not a 'power' user. I noticed that from a purely visual point of view that the dialogues for changing settings in applications can look a bit cluttered with all the buttons so thought 'i wonder if anyone's thought if we really need all them?'.

Obviously they have! I wasn't suggesting that settings changes are applied immediately like in Gnome, I really like that in KDE you can change a few settings and they have no effect, you can take a moment to think about the changes that you've made before clicking 'Apply' to actually make the changes. What i was trying to understand was why there's still the three buttons on the dialogues ('OK', 'Apply' and 'Cancel') when in System Settings, which works really well, there's only an 'Apply' button & once you've clicked that to apply the changes that you've made you can just close the window with the 'Close' button on the top right.

I suppose the one thing we all agree with is that the "?"-Button in the titlebar has to go (or "Killed with fire", as Jens would put it).

Unlike kdeuserk, however, I don't think it's a "non-issue" which should be fixed by simply removing it from the decoration in the default config, because
1) Other themes may still have them and they'd still be annoying and useless
2) (and most importantly) If we don't tell developers "This feature is not available anymore", they might still rely on it, unaware that by default, users won't even see it.

That context-senstive help feature might have been a nice idea, but obviously it was far too subtle for people to notice. Interestingly, I showed that button to a long-time KDE developer recently, and he (consciously) saw it for the first time! Therefore, only a tiny minority of dialogs implement that feature, and even out of those, only a minority actually puts useful information in the tooltips.
If a control in a dialog needs further information, it should either be written out directly, in a normal mouseover tooltip or with a link in the UI, but not via that button.

The reason for that discrepancy is simple: System Settings isn't a dialog. It's a control center which embeds the config widgets; having an Ok button would be weird there, since it would not only confirm and close that particular widget, but the whole program. You can start the individual control modules on their own, for example "kcmshell4 colors". Then they have an Ok button.

I think the Ok button is good practice in the dialogs, since it affirms users that their changes are saved when they close the dialog by clicking it (unlike just closing it using the window manager). So, on the contrary, maybe the question should be whether systemsettings should have a close/ok button in each dialog?

In general I think the window decoration and the buttons provided by the program itself serve different purposes. When you are currently doing stuff in the program, you will prefer the button the program itself provides, since it fits your way of thinking ("make changes, click ok"). But if you have the window around somewhere and just want to get rid of it, the window decoration is the "hot spot": it offers all the options to interact with the window on the "do this with the window" level. I do not think those two usage patterns should be mixed.

I suppose the one thing we all agree with is that the "?"-Button in the titlebar has to go (or "Killed with fire", as Jens would put it).

haha, yes, definitely
It's a miracle how this feature used by nobody ever still sticks around after twenty years.

About resizeable dialogs:
Configuration dialogs in GNOME 3 have a fixed size (though minimizing them is still possible, and I see no reason to not allow that). There are pros and cons to that
+ Developers have to make sure their dialogs fit into the default size, so "Ah, users can just resize of it gets too big..." simply isn't an argument
- If the usability would benefit from a bigger dialog in certain situations (for example if a list gets rather long and resizing the dialog would mean less scrolling and better overview), this isn't possible.
I agree with scummos: The fact that in Windows, every dialog has a fixed size has driven me nuts in numerous occasions. It might work if developers took the time and effort to make sure that every dialog is always perfectly usable in the default size, but - surprise! - they all too often don't. This causes things like tiny text fields into which you have to enter text of potentially large length but can only see a few words of it at a time, or endless scrolling because a list which the developers apparently thought would never contain more than a few items suddenly got veeeeery long.

What we have to make sure, though, is that every System Settings module actually fits in the default size. Currently, some modules don't fit, so users always have to resize the window when they navigate to one of them. This, however, should be prevented by providing and "enforcing" clear guidelines, not by imposing technical limitations.

This discussion makes me think , if there is a need for another topic more generally, on the user experience, I do not know if this is the task of the VDG , but I think so!What I mean is , we really want the user experience of KDE -Next is by default the same as it is now on kde 4 ?I try to explain better , we still want that default KDE is always present in the classic way with the plasmoid Folder View in the upper left ?We still want that by default is set to the single-click on the folders ?As in this case , we still want the buttons of the windows set in a certain way ?And anyway, do you really believe that in the current default settings , there is nothing to refine or improve ?To me it would take a study on this , with no obligation to change, but simply to improve if it is possible , the current experience , especially if you think that there are unnecessary things or improvement, or if you know that there are things , for example, all change after the first start

colomar wrote:I suppose the one thing we all agree with is that the "?"-Button in the titlebar has to go (or "Killed with fire", as Jens would put it).

Unlike kdeuserk, however, I don't think it's a "non-issue" which should be fixed by simply removing it from the decoration in the default config, because
1) Other themes may still have them and they'd still be annoying and useless
2) (and most importantly) If we don't tell developers "This feature is not available anymore", they might still rely on it, unaware that by default, users won't even see it.

That context-senstive help feature might have been a nice idea, but obviously it was far too subtle for people to notice. Interestingly, I showed that button to a long-time KDE developer recently, and he (consciously) saw it for the first time! Therefore, only a tiny minority of dialogs implement that feature, and even out of those, only a minority actually puts useful information in the tooltips.
If a control in a dialog needs further information, it should either be written out directly, in a normal mouseover tooltip or with a link in the UI, but not via that button.

I'm definitely in the boat of burning the "?" with fire and agree with colomar on pretty much everything said here. It was mimicry of a cute feature Win95 had. I think It's rarely used anymore. Removing it from the default window button configuration, which is independent of theme, is probably a good start though to signal to developers that it should not be expected that this feature will be there anymore if/when it actually goes away.

Can we get more great Jens quotes, please?

scummos wrote:Why would you forbid minimizing dialogs?

If just the modal dialog is minimized the application would become unusable. Therefore minimize in modal secondary windows works as if the main windows is being minimized. For modeless windows it works as expected. That might be confusing. And to quote Thomas: "Who needs to minimize an app when the workflow has reached a critical state, which is the only situation to show modal dialogs?"

But after all, I think its good as it is. The freedom of KDE (I believe Gtk or TCL/Tk works the same way) is worth to remove those restrictions. So please treat my reply as use case for discussion and not as recommendation.

Heiko Tietze wrote:

scummos wrote:Why would you forbid minimizing dialogs?

If just the modal dialog is minimized the application would become unusable. Therefore minimize in modal secondary windows works as if the main windows is being minimized.

Sounds good to me. And that already exists, so it's all good, no?

Heiko Tietze wrote:That might be confusing.

Yeah, I guess if the user does not know how a modal dialog works, it might be confusing. But most users do, I would say.

And to quote Thomas: "Who needs to minimize an app when the workflow has reached a critical state, which is the only situation to show modal dialogs?"

There's a variety of situations where that makes sense. Lots of applications have modal configuration dialogs; for a modal "Save changes?" dialog you might want to look something up in your file manager first; you might want to look up on the internet what a particular message means; etc.

But after all, I think its good as it is.

Yep

(I believe Gtk or TCL/Tk works the same way)

Only resizing can be effectively prevented by the application, everything else is ultimately up to the window manager to decide.

Greetings!

There's one possiblilty I believe hasn't been mentioned yet: removing the 'ok' button but keeping 'apply' and 'close'. Then one would need two clicks to apply changes and close, but the advantage would be simplicity and unambiguousness. Clicking 'close' without applying first could bring up a confirmation dialog that asks whether you want to discard changes (as it already does in system settings I believe).