459578 - Ensure Help doesn't describe non-existing OK/Cancel buttons

Status: NEW

(SeaMonkey :: Help Documentation, defect)

Description

[Stefan [:stefanh]]

Since it's only windows that has instantapply="false" set, we need to check the docs so we don't tell users of non-windows systems to "Click OK" in the pref window. I stumbled upon one case in bug 459560, but there might be others.

Comment 1

[Lars P M]

Only a Close button in the Cookie Manager: http://mxr.mozilla.org/comm-central/source/suite/locales/en-US/chrome/common/help/using_priv_help.xhtml#171

Comment 2

[Stefan [:stefanh]]

Hmm, is that the only one? Interestingly, that doesn't depend on the instantapply settings - so even windows users will lack an OK button.

Comment 3

[Lars P M]

Attachment: List of Help appearances of the string 'Click OK'

(In reply to comment #2)
> Hmm, is that the only one? 

No, "Click OK" appears 90 times in 12 files... See attachment.

Is there an easy way to figure out which of those that don't take care of a possible instantapply setting dependance?

Comment 4

[Stefan [:stefanh]]

(In reply to comment #3)

> Is there an easy way to figure out which of those that don't take care of a
> possible instantapply setting dependance?

I think it'd be safe to say that if they're not in the main prefpanel, they don't depend on the instantapply setting.

Comment 5

[Stefan [:stefanh]]

Basically, instantapply="true" is the default for mac/linux and that means that OK/Cancel buttons are not shown in the prefpanes (it doesn't makes sense to show them since the pref applies instantly). Dialogs with preference elements that are children of prefpanes display OK/Cancel buttons, though.

Comment 6

[Lars P M]

Attachment: Revised list showing the wrong click calls

So here are the occurrences that need to be altered (in one way or another).

Comment 7

[Stefan [:stefanh]]

(In reply to comment #6)
> Created an attachment (id=343209) [details]
> Revised list showing the wrong click calls
> So here are the occurrences that need to be altered (in one way or another).

Excellent - thanks! I'll wade through the list ;)

Comment 8

[Jens Hatlak (:InvisibleSmiley)]

1. The Allow button in the Popup Windows dialog will be covered in bug 543332.
2. I spotted two "take affect" in Lars' list which need to be changed to "take effect". Since both occurrences are still valid and these lines need to be modified in this bug anyway we should IMO correct those two at the same time.

Comment 9

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #8)
> 2. I spotted two "take affect" in Lars' list which need to be changed to "take
> effect". Since both occurrences are still valid and these lines need to be
> modified in this bug anyway we should IMO correct those two at the same time.

This part might be fixed in bug 543336.

Comment 10

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #0)
> Since it's only windows that has instantapply="false" set, we need to check the
> docs so we don't tell users of non-windows systems to "Click OK" in the pref
> window.

Reading that I thought you were referring to a XUL attribute that somehow is set depending on the OS. Instead I found that we're talking about a pref (browser.preferences.instantApply) here. Only the default of that is set per platform (through preprocessor commands in browser-prefs.js) but the user can change the pref at any time, though not using the UI (about:config doesn't count). It's probably impossible to have Help react in real time to changes to that pref and describing both variants in all applicable places doesn't make sense but maybe we could put a note somewhere explaining it. Just a thought.

> I stumbled upon one case in bug 459560, but there might be others.

As a note to myself or anyone else trying to take this bug if you don't find the time: In that bug you solved it using class="win" which hides a tag's (e.g. list item's) contents on all platforms but Windows (cf. platformClasses.css).

Comment 11

[Stefan [:stefanh]]

Actually, couldn't we just assume that users will understand that they (if no instantapply) need to click "OK"? Then we don't need worry about whether to tell them/not tell them to click "OK".

Comment 12

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #11)
> Actually, couldn't we just assume that users will understand that they (if no
> instantapply) need to click "OK"? Then we don't need worry about whether to
> tell them/not tell them to click "OK".

IMO common sense would imply that but the current style in Help seems to be to tell the user exactly what to do, especially when it comes to following something step by step. I was thinking about just saying "close the window" but unfortunately doing that without using any button (i.e. using the window controls) seems to be equivalent to clicking Cancel (in the instantApply=false case).

I wonder whether we should instead just replace the applicable occurrences by "OK/Close". That will tell the user to click the OK or Close button, whichever he/she finds. It will also imply that this is an advice, without implying that it's a mandatory step. If there's an OK button (instantApply=false) the user will be safe when following the steps; if there's a Close button no harm is done (and if a user knows that instantApply is active he/she can choose not to follow the advice and leave the window open).

Comment 13

[Ian Neal]

The other issue, of course, is that instantapply is a pref (browser.preferences.instantApply) which means users could override the default value for their platform.
So might be easier to go for the "OK/Close" option suggested.

Comment 14

[Stefan [:stefanh]]

Are we consequent regarding the 'OK' clicking or do we just mention it in some files/sections? I mean, looking at Lars list, it seems we're not consequent.