Re: [Tails-ux] RFC: new time sync'ing user story

Hi,

anonym wrote (18 May 2015 13:55:55 GMT) :
> Dropped tails-dev@ now, which apparently was forgotten. :)

Perhaps sajolida intentionally cross-posted because of "Maybe I'll mix
up too much UI and implementation". Anyway.

> On 05/18/2015 01:42 PM, sajolida wrote:
>> - Shouldn't we ask for the timezone first and then the time, or the
>> two things at the same time. Maybe that's what is already meant by the
>> "and" in "And the corresponding UI lets me choose my preferred timezone".

> The idea is to show all of it: date, time and timezone. And all of them
> can be altered to set the system clock.

Now clarified on the blueprint.

>> - Would people on Windows be asked for this every time or otherwise
>> have a wrong clock on Windows?

> In the first and second iterations, we would nag users with a popup as
> soon as the clock is detected to be incorrect (i.e. Tor complains that
> it is when we bootstrap). For Windows users that indeed means that
> unless they live in a timezone close to UTC (so their local time
> coincides with UTC == what we expect ==> Tor will be happy) they will be
> nagged every single time.

> Of course, in the final iteration we'd always show the clock in the
> Greeter, and the hope is that users will fix it there if needed so they
> won't be nagged later. And with persistence we'll preserve the timezone
> choice so that it only have to be selected once (or until Windows
> manages to set the time incorrectly, which unfortunately isn't so rare).

> It could be that the situation in the first and second iterations is a
> bad enough UX regression that we don't want to do it. If so, perhaps it
> can be mitigated by supporting persistence of the chosen timezone
> already in these iterations?

I think it partly depends on the new Greeter's ETA: if we're going to
have it included e.g. in the first Tails/Jessie release (late 2015, or
early 2016), then perhaps Windows users who don't live close to UTC
can live with that regression for a few months. If the new Greeter's
ETA is less clear than that, then perhaps we should indeed block on
display timezone persistence before dropping the current automatic
time sync' scheme.

Another temporary mitigation could be to get the preferred display
timezone from the kernel command-line, so that power-users can encode
their choice in the bootloader configuration and avoid going through
manual timezone configuration on each boot. Of course this has very
small advantages in terms of usability since it targets a tiny
minority of Tails users, but implementation-wise, it would be a first
incremental step towards loading that information from somewhere when
available, and else asking the user.

[Nomenclature: let's use "clock display timezone" or something as much
as possible here, since the actual system timezone will still be UTC
in any case -- times in Nautilus etc. will still be displayed in UTC,
and only Tails Clock and the time fixing dialog will use the
configured timezone.]

Cheers!