Re: Debconf Templates Style Guide
Scripsit Matt Zimmerman <[EMAIL PROTECTED]> > On Fri, Oct 31, 2003 at 07:43:09PM +0100, Henning Makholm wrote: > > So instead you're recommending an approach that forces the user to > > choose *before* reconfiguring between > > a) not being told what the maintainer thought was a sensible default > > b) not being told how he has currently configured the package > You aren't making sense. Gee, thanks. > You said that the problem was that the user wanted the safe defaults > and couldn't tell what they were. I provided an idea for a > solution, which was to give the user an option to forget their > current configuration and confirm the safe defaults. Now you're > complaining that the user has too much choice. No, I'm complaining that the user does not have the information he needs to make an informed choice. What would be so terrible about letting the user know *both* of what the maintainer thinks is a sensible default *and* how the packages is currently configured? > > Which is not terribly helpful to a user who wants to make an informed > > choice *between* the safe default and his own prior customizations. > Writing a paragraph of text attempting to tell the user what the safe > default is, without making reference to any UI-specific widgets, is a waste > of time and space. You seem to be saying that giving useful information to the user is a waste of time and space in general. Why, then do debconf questions have long descriptions at all, then? -- Henning Makholm # good fish ... # goodfish, goodfish ... # good-good FISH! # -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debconf Templates Style Guide
On Fri, Oct 31, 2003 at 07:43:09PM +0100, Henning Makholm wrote: > Scripsit Matt Zimmerman <[EMAIL PROTECTED]> > > > Of course it would, and I would never recommend doing so. > > So instead you're recommending an approach that forces the user to > choose *before* reconfiguring between > a) not being told what the maintainer thought was a sensible default > b) not being told how he has currently configured the package > > I don't see why that would help anyone. You aren't making sense. You said that the problem was that the user wanted the safe defaults and couldn't tell what they were. I provided an idea for a solution, which was to give the user an option to forget their current configuration and confirm the safe defaults. Now you're complaining that the user has too much choice. > Which is not terribly helpful to a user who wants to make an informed > choice *between* the safe default and his own prior customizations. Writing a paragraph of text attempting to tell the user what the safe default is, without making reference to any UI-specific widgets, is a waste of time and space. Changing the debconf interface for the purpose of creating a horrific UI which attempts to present the user with three sets of options for each possible question would be equally silly. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debconf Templates Style Guide
Scripsit Matt Zimmerman <[EMAIL PROTECTED]> > Of course it would, and I would never recommend doing so. So instead you're recommending an approach that forces the user to choose *before* reconfiguring between a) not being told what the maintainer thought was a sensible default b) not being told how he has currently configured the package I don't see why that would help anyone. > No, you don't. You just need a command line option to dpkg-reconfigure > which says to forget the current/previous configuration. Which is not terribly helpful to a user who wants to make an informed choice *between* the safe default and his own prior customizations. -- Henning Makholm "En tapper tinsoldat. En dame i spagat. Du er en lykkelig mand ..." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debconf Templates Style Guide
Scripsit Christian Perrier <[EMAIL PROTECTED]> > > There used to be, somewhere, a guideline that told maintainers to let > > themselves be inspired by the descriptions in the kernel source's > > "make fooconfig", especially with regard to telling the user what the > > conservative default choice is. Many of the kernel option descriptions > > do indeed say "If unsure, answer No" or the like. Or do I misremember? > > If I'm right, then the relation between those two pieces of advice > > should probably be clarified. > Let's see in further discussion. However, there are very strong > arguments against this : Quite possibly. I'm not arguing either way - just proposing that if my memory of the "make fooconfig" guideline is correct, a document such as yours would be a good place to stress that is was not really a good one. Of course I realise that it would help if I could remember *where* I read that guideline. :-) > > The extended description should be able to stand on its own, > > *without* the short one. For example, the dialog frontend will > > sometimes choose to show the entire extended description first and > > only ask the actual question on a separate screen after the user has > > confirmed reading the extended one. This depends on the terminal > > size and the lenght of the extended description, so it may happen to > > users even if it does not happen to you. > Hmmm, this is a good point. Well, for string/select/multiselect, this > shoul dnot happen as extended descriptions should always ablance > between verbosity and quality. Sometimes a long extended description *is* necessary to enable the user to make an informed choice. FWIW, the case where I encountered this behavior was a Boolean choice - I have not checked whether it is specific to certain question types. -- Henning Makholm "Jeg har tydeligt gjort opmærksom på, at man ved at følge den vej kun bliver gennemsnitligt ca. 48 år gammel, og at man sætter sin sociale situation ganske overstyr og, så vidt jeg kan overskue, dør i dybeste ulykkelighed og elendighed." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debconf Templates Style Guide
On Thu, Oct 30, 2003 at 07:07:33AM +0100, Christian Perrier wrote: > > Someone do this please? :) > > Branden, no other comment on my document ? > > I was more or less prepared to several (constructive) comments, or > style corrections, coming from you and I'm wondering whether I should > be glad of receiving none.. :-) I haven't taken the opportunity to properly review it yet. You hit a lot of pet peeves I share with Joey Hess, though, so you're off to a good start. -- G. Branden Robinson| Eternal vigilance is the price of Debian GNU/Linux | liberty. [EMAIL PROTECTED] | -- Wendell Phillips http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Debconf Templates Style Guide
> Someone do this please? :) Branden, no other comment on my document ? I was more or less prepared to several (constructive) comments, or style corrections, coming from you and I'm wondering whether I should be glad of receiving none.. :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debconf Templates Style Guide
On Tue, Oct 28, 2003 at 11:43:55PM -0500, Matt Zimmerman wrote: > On Wed, Oct 29, 2003 at 03:52:27AM +0100, Henning Makholm wrote: > > > The default choice should always be what the user wants if they are > > > unsure. > > > > I'm afraid you need to redesign the entire debconf system then. > > No, you don't. You just need a command line option to dpkg-reconfigure > which says to forget the current/previous configuration. This is a bit shy > of redesigning the entire system. Ooh, ooh. +1! This would take a significant thorn out of my side WRT xserver-xfree86.config. Someone do this please? :) -- G. Branden Robinson| The noble soul has reverence for Debian GNU/Linux | itself. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Debconf Templates Style Guide
> There used to be, somewhere, a guideline that told maintainers to let > themselves be inspired by the descriptions in the kernel source's > "make fooconfig", especially with regard to telling the user what the > conservative default choice is. Many of the kernel option descriptions > do indeed say "If unsure, answer No" or the like. Or do I misremember? > If I'm right, then the relation between those two pieces of advice > should probably be clarified. Let's see in further discussion. However, there are very strong arguments against this : -some frontends do NOT show the user a Yes/No choice -some other frontends may have translated widgets. Some other may not. For instance, during a long time, the whiptail Yes/No strings weren't translated to french. As they are used by debconf dialog interface, this lead to stuff like this : Voulez-vousblabla ? Blabla..Si vous répondez "Oui".. Yes No The original said "If you answer Yes". It was then translated to "Si vous répondez Oui", but the user saw a Yes/No choice.. :-) > > The extended description should not repeat the short description. > > I'm not sure about this point, which seems to be taken from the > guidelines about package descriptions. I'd rather say The idea is motly the same, yes. The key here wass that extended description is never shown alone, but always as a complement to the short one. However, you give some counter-examples. > The extended description should be able to stand on its own, > *without* the short one. For example, the dialog frontend will > sometimes choose to show the entire extended description first and > only ask the actual question on a separate screen after the user has > confirmed reading the extended one. This depends on the terminal > size and the lenght of the extended description, so it may happen to > users even if it does not happen to you. Hmmm, this is a good point. Well, for string/select/multiselect, this shoul dnot happen as extended descriptions should always ablance between verbosity and quality. This may be true for notes.where the short desc is however more a title than a summary. > > Thus, even if the short description says "Complain about split > infinitives", the extended description contain something like > "Foobar can be configured to never complain about split > infinitives...", such that the user knows roughly which decision > he's going to make while he's absorbing the information in the > rest of the extended description. This is not a strict repeat, so I wouldn't consider this as a violation of the "rule" I wrote. In fact, this is a very good use of short and extended descriptions.. :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debconf Templates Style Guide
On Wed, Oct 29, 2003 at 03:52:27AM +0100, Henning Makholm wrote: > That would be a horrible sentence to put into a debconf > description. Of course it would, and I would never recommend doing so. > > The default choice should always be what the user wants if they are > > unsure. > > I'm afraid you need to redesign the entire debconf system then. No, you don't. You just need a command line option to dpkg-reconfigure which says to forget the current/previous configuration. This is a bit shy of redesigning the entire system. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debconf Templates Style Guide
Scripsit Matt Zimmerman <[EMAIL PROTECTED]> > On Tue, Oct 28, 2003 at 11:11:13PM +0100, Henning Makholm wrote: >> especially with regard to telling the user what the conservative >> default choice is. Many of the kernel option descriptions do indeed >> say "If unsure, answer No" or the like. Or do I misremember? > If we used a sentence like this, it would read "If unsure, accept the > default", which would be redundant. That would be a horrible sentence to put into a debconf description. The *first* time I configure the package, the defaults will be those specified by the package maintainer. But if it doesn't work and I decided I have probably botched the configuration and run dpkg-reconfigure on the package, the defaults are going to be whatever I answered the first time. Then I won't be helped at all by a sentence that just reads "use the default if unsure". > The default choice should always be what the user wants if they are > unsure. I'm afraid you need to redesign the entire debconf system then. -- Henning Makholm "The spirits will have to knit like banshees, but with enough spirits it *can* be done!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debconf Templates Style Guide
On Tue, Oct 28, 2003 at 11:11:13PM +0100, Henning Makholm wrote: > There used to be, somewhere, a guideline that told maintainers to let > themselves be inspired by the descriptions in the kernel source's > "make fooconfig", especially with regard to telling the user what the > conservative default choice is. Many of the kernel option descriptions > do indeed say "If unsure, answer No" or the like. Or do I misremember? If we used a sentence like this, it would read "If unsure, accept the default", which would be redundant. The default choice should always be what the user wants if they are unsure. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debconf Templates Style Guide
Scripsit Christian Perrier <[EMAIL PROTECTED]> [much good stuff snipped] > Templates text should not make reference to widgets belonging to some > debconf interfaces. Sentences like "I you answer Yes..." have no > meaning for users of graphical interfaces which use checkboxes for > boolean questions. There used to be, somewhere, a guideline that told maintainers to let themselves be inspired by the descriptions in the kernel source's "make fooconfig", especially with regard to telling the user what the conservative default choice is. Many of the kernel option descriptions do indeed say "If unsure, answer No" or the like. Or do I misremember? If I'm right, then the relation between those two pieces of advice should probably be clarified. > The extended description should not repeat the short description. I'm not sure about this point, which seems to be taken from the guidelines about package descriptions. I'd rather say The extended description should be able to stand on its own, *without* the short one. For example, the dialog frontend will sometimes choose to show the entire extended description first and only ask the actual question on a separate screen after the user has confirmed reading the extended one. This depends on the terminal size and the lenght of the extended description, so it may happen to users even if it does not happen to you. Thus, even if the short description says "Complain about split infinitives", the extended description contain something like "Foobar can be configured to never complain about split infinitives...", such that the user knows roughly which decision he's going to make while he's absorbing the information in the rest of the extended description. -- Henning Makholm "The raccoon's grandchildren are employed as raccoon children at the "Raccoon" laundering shop. They wash the laundry white when the laundry is dirty. And the laundry often is." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]