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

Delete this message

Reply to this message
Author: sajolida
Date:  
To: Tails user experience & user interface design
Subject: Re: [Tails-ux] RFC: new time sync'ing user story
intrigeri:
> 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.


No, I just misread the intrigeri's introduction.

>> 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.


That would be a bit like the current GNOME Date and Time interface (the
one in Tails for example).

I tested it and it's nice. We could maybe reuse most of that UI. As I
said earlier I'm fine with that solution (even if the situation for
Windows users is a bit scary). But since my first email I realized
something else... The GNOME UI looks like a geolocation tool :)

In the context of Tails I think that displaying such a map of the world
(or any location information) should come with a clear message that this
is only to set the "clock display timezone" and not collected in any
way. We should also not mention any city in this interface (unlike GNOME
currently) but maybe only names of timezone.

Still, some timezone are only used in one country. For example Venezuela
is in -4:30, Iran in +3:30, and Afghanistan in +4:30. Yeah!
I could totally see people freak out about that.

https://en.wikipedia.org/wiki/UTC%E2%88%9204:30
https://en.wikipedia.org/wiki/UTC%2B03:30
https://en.wikipedia.org/wiki/UTC%2B04:30

>>> - 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.


I think it's less clear than that. We still don't have a design ready to
implement and haven't done any user testing. We should do without it but
I think I have a solution...

> 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.


Until we have Tails Greeter, why not save the timezone information in
persistence (as Tails Greeter would do) when it's configure through
Tails Clock or whatever timezone configuration tool we have? People
would start without timezone data from a fresh installation or when
using a DVD, but we save this information in persistence whenever
possible (maybe opt-in from the timezone interface).

I think that it should anyway be possible to reconfigure it after Tails
Greeter so that possibility might be good to have anyway.

> [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.]


Maybe Tails Clock and the timezone configuration interface should go
together (be part of the same extension) like in the current GNOME
interface we have.

--
sajolida