Author: intrigeri Date: To: Tails user experience & user interface design Subject: Re: [Tails-ux] RFC: new time sync'ing user story
Hi,
Thanks for all this useful input! :)
sajolida wrote (06 Jun 2015 15:42:17 GMT) : > 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.
Agreed on all this, added to the blueprint. In the Greeter, perhaps
region selection (do we still have that, or is it hidden behind the
Formats thing?) could be somehow merged with timezone input. Can be
refined later.
> We should also not mention any city in this interface (unlike GNOME
> currently) but maybe only names of timezone.
Yes, perhaps. I'm unsure but the details can be refined later.
> 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.
If they don't freak out when Tails is asking them a region in the
Greeter, then perhaps they won't freak out when we ask them the
same elsewhere, but who knows.
>>> 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.
OK.
> We should do without it but I think I have a solution...
Oh oh :)
> 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).
OK. Added to the blueprint.
Opt-in sounds good: I'm personally mentally ready to make persist some
stuff by default when persistence is enabled (e.g. the entropy seed),
*but* that's because it's critical for security, combined with the
fact that the user has little incentive to actively enable such
a persistence feature, because they don't _feel_ the effects of not
enabling it. Here, the drawback of not persisting is inconvenience for
the user, and has no security implications, so I think we can leave it
to them to decide whether they want more convenience (but some
infoleak to persistence -- some people travel) or more security.
> I think that it should anyway be possible to reconfigure it after Tails
> Greeter so that possibility might be good to have anyway.
OK.
>> [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.
I think that's covered in the blueprint already: "The interface used
by Tails Clock and by the upcoming time input GUI could perhaps be
shared; this raises privilege separation issues that need to be
thought through."