Opened 2 months ago

Closed 2 months ago

Last modified 2 months ago

#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:
Has a Patch: no 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)

expandersettingstab.png (80.5 KB) - added by -Meanwhile- 2 months ago.
Expander situation
serialconnectsettings.png (60.8 KB) - added by -Meanwhile- 2 months ago.
SerialConnect situation
ExpanderSerialConnectSideBySide.png (43.2 KB) - added by -Meanwhile- 2 months ago.
Slightly superfluous side by side version

Download all attachments as: .zip

Change History (10)

Changed 2 months ago by -Meanwhile-

Attachment: expandersettingstab.png added

Expander situation

Changed 2 months ago by -Meanwhile-

Attachment: serialconnectsettings.png added

SerialConnect situation

Changed 2 months ago by -Meanwhile-

Slightly superfluous side by side version

comment:1 Changed 2 months ago by waddlesplash

Resolution: invalid
Status: newclosed

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 Changed 2 months ago by -Meanwhile-

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 Changed 2 months ago by KapiX

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 Changed 2 months ago by humdinger

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 Changed 2 months ago by stippi

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 Changed 2 months ago by KapiX

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 Changed 2 months ago by humdinger

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".

Note: See TracTickets for help on using tickets.