Bug 388592

Summary: YaST help popup usability a bit awkward
Product: [openSUSE] openSUSE 11.0 Reporter: Johannes Meixner <jsmeix>
Component: YaST2Assignee: Thomas Göttlicher <tgoettlicher>
Status: RESOLVED FIXED QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P5 - None CC: fs
Version: Beta 2   
Target Milestone: ---   
Hardware: All   
OS: openSUSE 11.0   
Whiteboard:
Found By: Development Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: navigation in Firefox

Description Johannes Meixner 2008-05-09 07:52:08 UTC
I did a 11.0 beta2 installation from scratch
with KDE4 on x86_64 hardware.

After clicking the [Help] button, a help popup appears.

But - as far as I see - it is not possible to keep it open
so that oine can read it e.g. while filling in the dialog
to which the help text belongs.
Instead on has to close it before one can do something
in the dialog to which the help text belongs.

This is o.k. for general help texts which describe
only the general idea what the dialog is about.
But it is annoying if the help text describes specific
stuff like special syntax or when the help text provides
useful examples what to enter and things like that.

Furthermore the usage of the search field is awkward
at least for me.

When there is somewhere a search field, I enter something
and then I hit the Enter key to get the search results.

But for the help popup the Enter key is bound to the
[Close] button so that the help popup just disappears
and then one waits for a new popup which would show
the search results...

...until one finds out by trial and error that the
search field works different here.

I think it is perfectly o.k. to highlight while typing
happens but please remove the binding of the Enter key
to the [Close] button.
Comment 1 Stephan Kulow 2008-05-09 09:03:29 UTC
should be possible to do it nonmodal
Comment 2 Martin Schmidkunz 2008-05-12 11:05:19 UTC
What about using "previous" "next" buttons for navigation within the help text?
Similar to Firefox.
Comment 3 Martin Schmidkunz 2008-05-12 11:09:03 UTC
Created attachment 214354 [details]
navigation in Firefox
Comment 4 Thomas Göttlicher 2008-05-14 12:58:02 UTC
The 'previous' and 'next' buttons are useful when there is a lot of text displayed. Most help text consist of few lines at the moment, therefore I think we don't need 'next' and 'previous' buttons.

The modality and the default button are fixed in svn r47527.
Comment 5 Stefan Hundhammer 2008-06-05 11:33:27 UTC
This will raise the next problem really soon:

When you use the wizard "Next" and "Back" buttons, respectively, you'd expect the help text to be automatically updated to refer to the (then) current dialog content. But this will not happen; the old help text will remain. A user will need to click the "Help" button again to see the help text that belongs to that new dialog content.
Comment 6 Johannes Meixner 2008-06-05 11:58:10 UTC
At least I don't expect this.
At least I expect no such overeager automatism.
At least for me it would be perfectly o.k. when the
help text stays open regardless what happens until
I close it intentionally (or I exit the whole program)
just like X windows for programs which use more of them.

Consider another situation:
Assume I am in a "detailed settings" dialog and have
its help window open and I scrolled to a particular
section of my interest in a longer detailed help text.
I do some settings but then I don't like them.
Therefore I click [Back] and enter the "detailed settings" again.
In this case I would appreciate it if the help window stays as is.