[yast-devel] Help Texts and Help Buttons in YCP Dialogs
We needed this to make removing the permanent help panel in the NCurses wizard
possible, but it might also be useful at other places (Popup.ycp?):
You can now declare a push button a "help button". When activated, that button
will now try to automatically show the help text that belongs to its dialog.
The help text is stored as a (new) widget property `HelpText in some parent
widget in that dialog, preferably a layout widget like `VBox() or `HBox().
Example: (ycp-ui-bindings/examples/HelpText.ycp)
{
UI::OpenDialog(
`VBox(`id(`mainLayout),
`Label("Hello, World!"),
`HBox(
`PushButton(`opt(`helpButton ), "&Help"),
`PushButton(`opt(`default ), "&OK")
)
)
);
UI::ChangeWidget(`mainLayout, `HelpText,
"Oh, come on, do you really need help for this?" );
UI::UserInput();
UI::CloseDialog();
}
Please note that we might do cooler stuff with this new `HelpText widget
property, so for now please use it in this way. In the future, we might use
this for tool tip help, so the dialog's help text should really be in a
container widget like this VBox and not on the help button itself (otherwise
the tool tip of that help button would be the entire dialog's help text - not
desirable). The help button will traverse up its widget hierarchy and use the
topmost `HelpText it can find.
CU
--
Stefan Hundhammer
... and some pictures of ncurses Wizard without left help panel: http://en.opensuse.org/Image:Helpless-wizard.png http://en.opensuse.org/Image:Help-in-window.png So - no more problems with lack of horizontal space in ncurses (bright future :) ) We should now probably consider shortening our help text and listing only relevant information there, as in the above small popup window, it is rather difficult to read (which it probably was even before and that's why hardly anyone bothered to read the help text at all) B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter
Hi there,
We should now probably consider shortening our help text and listing only relevant information there, as in the above small popup window, it is rather difficult to read (which it probably was even before and that's why hardly anyone bothered to read the help text at all)
There is no reason why it has to be difficult to read. In your screenshots, there's plenty of room to enlarge the window. Just add some sensible size calculation function there like size = 80% * main_window->size if (size > 600) size = 600 if (size < 100) size = main_window->size With different values for width and height... I think the side help made some sense for some kind of text: like "please wait...", and generic informative stuff like: "you have to select a package to configure", but this should be presented in a different way. I think generic informative text should be presented as a sub-header. You guys mentioned tooltips, and I'm not really sure it's a good idea. I don't think it's usable and developers tend to neglect them, which just makes the situation worse, because users never know what has some help and what hasn't. Better to focus on enriching help as it is, with information and navigability. Possibly, what we could do is to set a link from fields to some anchor in the documentation. When the user presses the tooltip button, we show part of the help from there, cut with a "More" button that takes the user to the help dialog. Seems like a simpler solution, and better for the user because it would be better integrated with the rest of the documentation. Important remarks about some field or the dialog in general should simply be visible in the interface, as a label (maybe with a icon to go with it). Cheers, Ricardo -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Friday 04 April 2008 02:39, Ricardo Cruz wrote:
There is no reason why it has to be difficult to read. In your screenshots, there's plenty of room to enlarge the window. Just add some sensible size calculation function there like size = 80% * main_window->size if (size > 600) size = 600 if (size < 100) size = main_window->size With different values for width and height...
Yes, I was thinking about the same lines. But for now, we have the help
mechanism - that's a start. ;-)
CU
--
Stefan Hundhammer
On Friday 04 April 2008 02:39, Ricardo Cruz wrote:
You guys mentioned tooltips, and I'm not really sure it's a good idea. I don't think it's usable and developers tend to neglect them, which just makes the situation worse, because users never know what has some help and what hasn't. Better to focus on enriching help as it is, with information and navigability.
Tool tips serve another purpose. They describe individual widgets, not the dialog as a whole or background information about the technology the user is about to configure or helpful tips. That is the stuff I'd like to see in help texts. IMHO things like "Enter your user name here" for an input field labeled "User name" is useless (and often enough an insult to the user's intelligence).
Possibly, what we could do is to set a link from fields to some anchor in the documentation.
While I do think that we can manage that in the installed system (browser etc. available), I have doubts if this would ever work out right to coordinate all those things with the documentation people.
When the user presses the tooltip button, we show part of the help from there, cut with a "More" button that takes the user to the help dialog. Seems like a simpler solution, and better for the user because it would be better integrated with the rest of the documentation.
Think about the installation, too. We are very limited with what we can do there. In particular, putting all the doc PDFs for all the languages into the inst-sys would be very painful. And getting the required browsers there, too.
Important remarks about some field or the dialog in general should simply be visible in the interface, as a label (maybe with a icon to go with it).
I beg to differ. Look at most web apps. They are crowded with text that is
mostly useless. All this does is teach users to generously skip small-print
text and to read headlines only. So that stuff fills up the screen, yet it
does not fulfil its primary objective: To improve usability.
BTW MS Win has been going the same way for a while. They manage to write a
windowful of meaningless blurb for one or two input fields or check boxes.
Nobody wants to or can read that amount of text while doing some sysadmin
task; users just read the headlines and click "Next", hoping that everything
will be well.
Static text in dialogs should be minimized. Many users feel compelled to read
every piece of text there, and putting help texts into the main dialogs would
force them to read even more. Until they learn to skip that stuff in a
wholesale manner - see above.
CU
--
Stefan Hundhammer
Katarina Machalkova wrote:
... and some pictures of ncurses Wizard without left help panel: So - no more problems with lack of horizontal space in ncurses (bright future :) )
Cool! This really brightens up the future :-)
We should now probably consider shortening our help text
Skipping unnecessary explanations like "Add: Click here to Add" :-) Cu, Martin -- Martin Schmidkunz User Experience Specialist martin.schmidkunz@novell.com +49 (0) 911 740 53-346 ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ----------------------------------------------------------------- Novell, Inc. SUSE® Linux Enterprise 10 Your Linux is ready http://www.novell.com/linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (4)
-
Katarina Machalkova -
Martin Schmidkunz -
Ricardo Cruz -
Stefan Hundhammer