On Fri, Nov 13, 2009 at 11:01:09AM +0100, Frans Pop wrote: > On Thursday 12 November 2009, Colin Watson wrote: > > No it doesn't. If there's only one choice for the timezone, then you get > > a medium-priority question asking you to confirm your current time, as > > before. The only difference is that this question is now more useful, > > because it gives you the option of bailing out and selecting a different > > timezone when d-i's default is wrong. I did not change any question > > priorities. > > > > In some ways it is suboptimal to offer this facility only at medium > > priority just because the country you selected only has one timezone, > > but I didn't want to add an extra question. > > Right, and this means that you introduce a significant inconsistency in the > functionality offered to users installing at default prio who happen to > select a country with multiple time zones versus a single time zone.
It's an inconsistency, but not all inconsistencies are worse than nothing. Besides, it's not as if the extra question you're relying on for your argument in localechooser is asked outside expert mode ... Actually, personally I think that it wouldn't hurt to promote tzsetup/selected to high priority. It was medium at least in part because it didn't offer any additional flexibility, but now it does. > My viewpoint is that you're solving the problem in the wrong place. The > problem was a limitation in localechooser, which is now resolved. I don't agree that you have resolved this adequately. Any interface that involves innocent (non-expert) users having locale strings inflicted on them is not really fit for purpose. I'm also not particularly happy with the obvious alternative, which is effectively to ask the country question twice with slightly different semantics. The only purpose for asking which country you live in (as opposed to which country's localisation conventions you want) is to select an appropriate timezone; as such, this operation logically fits in tzsetup, not in localechooser. Furthermore, we should just get on with it and let the user choose the right timezone rather than making them jump through hoops by selecting the right country followed by the right timezone. At least if this all lives in tzsetup it's trivial to go back and forward if you make a mistake. Artificially splitting it up between localechooser and tzsetup makes it awkward for the user to do so (when you find yourself wanting to add template text telling the user to go back to the main menu and select a different item there in order to get the option you want, it's a good sign that you've probably made a design error). In addition, localechooser is memory-constrained (since it lives in the initrd) in a way that tzsetup is not so much. As such, I'd have thought you'd be in favour of moving things *out* of localechooser when possible. Shoving all this stuff into localechooser is going to make it even more hideously complicated than it already is. > I'm currently considering the following additional changes: > - revert your patch: with localechooser in SVN it's no longer needed I don't want to get into a revert war. Please do me a favour and don't start one ... This attitude really frustrates me. > - apply my patch to allow selection of UTC at medium priority Again, I think that special-casing UTC is missing the point. > - add a para to the description of time/zone saying something like: > "If the desired time zone is not listed, then please go back to > the step "Choose language" and select a country that uses the > desired time zone (the country where you live or are located)." Going back this far in the installer doesn't really work all that nicely. I recommend against this. In any case, this is unreasonable - it's asking the user to take manual action when the installer could just let them do what they want (the equivalent of saying "please run this command to recover" rather than just doing it). I do not think that it particularly helps users to insist that they be aware of and honour a tight binding between countries and time zones in order to make their computer keep the right time. We should be more flexible than that. Good user interfaces let the user do what they need to do rather than making them read the software's mind up-front and effectively punishing them by sending them back through convoluted channels when they fail to do so. Regards, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
