#14894 closed bug (invalid)
[QA] Expander settings window tab could use a close button
| Reported by: | -Meanwhile- | Owned by: | nobody |
|---|---|---|---|
| Priority: | normal | Milestone: | Unscheduled |
| Component: | Applications/Expander | Version: | R1/Development |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
Seen on hrev52849 x86_gcc2:
Haiku's Expander has a settings window with a tab that only shows the window's name and has no other functionality.
A similar type window can be found in 'SerialConnect/Settings/Baud rate/custom...' but there the tab does have a close button.
So (IMHO) it would be best if Expander gets this too.
Maybe the 'OK' and 'Cancel' button order and outlines can be made consistent across these two windows as well.
Attachments (3)
Change History (10)
by , 5 years ago
| Attachment: | expandersettingstab.png added |
|---|
by , 5 years ago
| Attachment: | ExpanderSerialConnectSideBySide.png added |
|---|
Slightly superfluous side by side version
comment:1 by , 5 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
This is a valid window type under Be/Haiku design philosophy; you can only close the window via interacting with the OK/Cancel buttons.
comment:2 by , 5 years ago
Yes, but my only point is getting rid of the inconsistency of using two varieties in similar situations.
The other window type is just as valid under Be/Haiku design philosophy, by the way... but that's not the point. What matters is that for this kind of window there exists a tab that has the added option of a close button, which makes it more user friendly, as can be seen and experienced in the SerialConnect situation.
So when one variety is more user friendly than the other plus you want to avoid using two versions for the sake of consistency and user-friendliness, then it's best to change to the tab-with-button variety for all cases.
comment:3 by , 5 years ago
IMO If we want to be valid with Be/Haiku design philosophy it shouldn't have OK at all, apply settings on change, and have a Revert button to quickly cancel changes, instead of having to click Cancel and reopen the window again.
comment:4 by , 5 years ago
have a Revert button to quickly cancel changes
+1. And a "Defaults" button when it makes sense.
That'll be another ticket, though. Maybe @Meanwhile would like to comb through Haiku apps/prefs panels to collect all offenders in one ticket. :)
comment:5 by , 5 years ago
IMHO there are some advantages for using OK/Cancel:
- Not all applications will apply settings live. The user could be wondering about this.
- Some settings will have no immediate effect, as with the Expander settings. Having an OK button is re-assuring.
- Imaging a dialog where something is configured and there is a preview inside that dialog. The settings are applied to the preview, having an OK button makes it obvious that these settings are now applied for real.
- I like the symmetry of representing different ways to proceed with similar UI. That's why I think an OK button (regardless of whether settings are applied live or not) is more obvious next to Cancel, than a completely different way to proceed by using the window close button.
- On other platforms, closing a dialog is often the same as canceling. Just look at how this ticket was implemented by Rob, it was obvious to him that closing the window is the same as canceling, given the presence of the OK button. I wouldn't force a "Haiku way" on users here, especially when the OK button is established as generally useful.
All in all, I'd vote for always having OK and Cancel buttons. Revert and Default should be optional.
Whether there should always be a window close button, I am not sure. Especially when settings are applied live, it is not clear at all whether it is intuitive to mean Cancel or OK. On the other hand, having no Close button could be irritating. It forces to read the dialog, even if it was opened accidentally.
comment:6 by , 5 years ago
Not all applications will apply settings live. The user could be wondering about this.
But most if not all system preflets do. If you have a common theme of Defaults/Revert, then I don't think assuming it works like this in app settings is too far-fetched.
Some settings will have no immediate effect, as with the Expander settings. Having an OK button is re-assuring.
Not really. When you change a setting, Revert becomes enabled. That's some form of feedback. Again, all preflets work that way. Why do they if it's bad?
All in all, I'd vote for always having OK and Cancel buttons.
I think I've read in our HIG that button labels should be descriptive. I know this document is outdated in a few places, but I think that one is good advice. OK is not a good label; Apply is better. And why have a Cancel button if it just duplicates another UI element?
comment:7 by , 5 years ago
This is really a difficult topic... I'm torn. :)
All in all, I'd vote for always having OK and Cancel buttons. Revert and Default should be optional.
Having 4 buttons in a panel is quite a lot...
Especially when settings are applied live, it is not clear at all whether it [the window close button] is intuitive to mean Cancel or OK.
If there's no OK/Cancel buttons, the Close button can only mean "OK". If you want to cancel your changes, you need to "Revert" them first. Generally, I find this "auto-OK" of settings (i.e. the applying live) quite elegant. It may take getting used to, and being a BeOS/Haiku user for over 20 years now (blimey), my view may be skewed. I suppose without getting the feedback of a significant number of (new) users, we won't arrive at the "truth".
Expander situation