On Wednesday 19 December 2007 12:12, Ricardo Cruz wrote:
If you guys are following the same path here, it would be cool to re-think the help material. I think most of it is an insult to the user; it describes the interface elements, while failing to explain what the tool is for, and how it will do what it purposes (it should state that it will overwrite file X, Y, and Z, and restart daemon A and B).
Exactly. This has been my argument for quite a while. But reading our help texts I find very little information what anything I could configure in that dialog is all about or why I would want or need to configure it. But I always get lectured about how to use an "Add" or "Edit" button. (BTW half an hour ago I deleted a nearly completed mail to this list suggesting to drop help texts alltogether for their overall lack of usefulness)
Some troubleshooting is also in serious need.
Right. This, however, is where we would need serious assistance from our documentation department. This goes far beyond what we as the development team can do. And then there is the issue of how to present it and disk space constraints (during installation). In an ideal world I would like to have HTML-based troubleshooting guides that preferably also include some mechanism to invoke the relevant YaST module. Our currently ongoing efforts to improve the YaST control center are heading into this direction. Help texts would also include Wikipedia links (so we could reuse a lot of very good existing documentation). [snip]
Also, it seems that the installer is becoming more RAM expensive at every release. Having a dedicated box to help won't help, because it will encourage people to expand it, and, as it is, the help text stays in memory, including when you go to sub-pages, the parent pages will still be in memory.
I am pretty sure that help texts are not what is clogging up memory. We are
talking about some kilobytes here (or more usually about a couple of hundred
bytes). This is not where all those megabytes go.
CU
--
Stefan Hundhammer