219865 - Remove the alwaysRaised attribute in the help window.

Status: RESOLVED WONTFIX

(SeaMonkey :: Help Documentation, defect)

Description

[R.J. Keller]

The help dialog has alwaysRaised set so that the help window is above all other 
dialogs. I find that this makes help difficult to use since it's difficult to do 
work in a window while the help window is open. If a user wanted help to always 
be on top, it is very easy to just resize the windows.

This is a one line patch.

Comment 1

[R.J. Keller]

Attachment: Patch removes alwaysRaised

Comment 2

[Ian Graham]

I disagree with this recommendation - in my experience with relatively novice
users, the danger of 'losing' the help window behind other windows far outweighs
the benefit. For such users it's important that help be always up front.

On the other hand, I believe this should be a configurable option, so that
advanced users can reset this default. Perhaps as an advanced setting? 

Comment 3

[R.J. Keller]

Maybe we should do something like Microsoft Word does where it repositions the
main window and shows the help window to the right.

Comment 4

[Ian Graham]

Office '97 (Word) did what Mozilla does now -- Help windows are alwaysRaised. I
don't have a more recent Office version at home, but your suggestion (attach the
help window to the right of the application pane) sounds reasonable too.
However, I suspect Office 2000+ lets you move the help window around -- and that
in that case then it probably remains alwaysRaised. Can you check and find out?  

Perhaps the following sequence of steps makes sense: 

(a) Create a  new pref for the 'raised' status ofhelp window (so it can
    be changed in about:config, or by hand-editing prefs.js ) 
(b) consider whether or not this should be editeable in the 
    Edit --> Preferences ---> Advanced utility (perhaps not...)
(c) Review other help pane options (like that in Office 2000+) and 
    see how we could implement this, and add appropriate prefs to 
    support that mode as an option.

Thoughts? 

Comment 5

[R.J. Keller]

> Office '97 (Word) did what Mozilla does now -- Help windows are alwaysRaised. 
> I don't have a more recent Office version at home, but your suggestion (attach 
> the help window to the right of the application pane) sounds reasonable too.
> However, I suspect Office 2000+ lets you move the help window around -- and 
> that in that case then it probably remains alwaysRaised. Can you check and 
> find out?  

I'm talking about Word 2002. Not sure about the earlier versions.

> (a) Create a  new pref for the 'raised' status ofhelp window (so it can
>     be changed in about:config, or by hand-editing prefs.js ) 
> (b) consider whether or not this should be editeable in the 
>     Edit --> Preferences ---> Advanced utility (perhaps not...)

This does not seem big enough for prefs. We have too many anyway.

> (c) Review other help pane options (like that in Office 2000+) and 
>     see how we could implement this, and add appropriate prefs to 
>     support that mode as an option.

Notepad Help does not have alwaysRaised. Word 2002 resizes the word window in
order to see both the help menu and the document window. But word 2002 is not
always raised to the top.

I think that the Word 2002 way, of resizing the browser window and moving help
to the right side of the screen sounds most appropriate.

Comment 6

[R.J. Keller]

WONTFIX. Most of the problems related to alwaysRaised seem to have been resolved.

Comment 7

[Dan M]

Well, good. I guess. However I just spent a boatload of time writing up this
honking analysis and I don't want to throw it away. Perhaps it'll be useful in
the future should the issue be raised again:

---

The Help window wasn't always alwaysRaised. It was made that way because novice
users lost their Help window before they were finished with it. Likely they were
using a maximized browser window and trying to follow instructions from the Help
window. Apparently this was the result of an actual study, done by filming
volunteers in a booth. I haven't seen the study, but its synopsis in the
corresponding bug report is worded pretty strongly (bug 136647, original comment).

Admittedly the complexity of Mozilla's UI makes the UI slanted toward advanced
users. Yet it does make several concessions to the novice. alwaysRaised Help is
one of those and it seems to be an important one. Since novices are more
delicate, any attempt to make the UI address both them and a more advanced user,
excuse me while I pontificate, must favour the novice. I liked your earlier
plan: leave Help alwaysRaised but give a knowledgeable user some way to override it.

danm's summary of solutions on the table:
  1) make Help a normal, not alwaysRaised window
  2) #1, plus size and position browser and help so that they don't overlap
  3) make a preference to override alwaysRaised
  4) put a control in the Help window to unraise it

I've just argued that #1 is bad for novices. Dare I say, unacceptable. #2 is
also problematic. You'll notice the Help window already positions itself on the
right edge of the screen, yet that wasn't enough. The problem is users of
maximized browser windows. You'd have to unmaximize their browser as well as
reposition and resize it. That's a lot of movement. I think it'll be confusing
to novices and annoying to a great many more advanced users, who had their
window just the way they wanted it, thank you muchly.

I also don't like #3 and it warms my heart to see I'm not alone there. I agree
that a preference seems out of place. Though a pref to remember the setting,
once made, seems appropriate. But a pref without a control in the affected
window is a crummy UI. Who thinks to trudge through the Prefs Window looking for
potential solutions to an annoying feature of the Help Window? An advanced user
might, of course. It's still a very undiscoverable UI.

My preference (so to speak) is #4. Leave Help alwaysRaised by default but add a
control in the Help Window allowing it to be returned to normal. And so a user
who dislikes alwaysRaised need not punch the control every time, make this
control's setting persistent by storing it as a preference. There'd be no need
for additional access to this setting in the Preferences window.

At the moment, #4 is difficult to implement. alwaysRaised is a read-only
property of a window. However I expect it'll become mutable before the 1.6a
milestone is finished (see bug 42557). Once that's done it's straightforward to
add a control to the Help window to make all this work, if you can only figure
out where to put it. A UI for 42557 is also on the way, though as written (it is
written) it's not immediately applicable to the Help window. But all the
preliminary steps are being taken.