826359 - Remove timezone-setting screen from FTE entirely

Status: RESOLVED DUPLICATE of bug 1026098

(Firefox OS Graveyard :: Gaia::First Time Experience, defect)

Description

[Gervase Markham [:gerv]]

There are various bugs in the FTE timezone screen's UX - e.g. 

* bug 826283 for an incorrect timezone default
* bug 826286 for an incorrect time on timezone selection

Fabian keeps telling us that the phone will automatically set the time from the mobile network on supported networks, and that this support works in Brazil. So, the phone's time will be correct on first run, and will be kept up to date with DST changes without any user intervention.

Given this, why don't we just remove this screen entirely from the FTE app? This would mean a simpler and quicker FTE, and we wouldn't have to fix those various bugs. Users who need to set the value manually can still do so through the settings.

Gerv

Comment 1

[Gene Lian (I already quit Mozilla)]

Bug 820696 also addresses a related issue that the time settings between FTE and Settings app is not consistent. Supposing you don't choose any timezone at the first-run settings (just skip it). When you go to the "Date & Time" in the settings app later, it shows "Set automatically" is enabled. However, the current system time is actually wrong.

I don't have strong opinion of removing the time setting in FTE or not. However, if we choose to keep it, I suggest we should provide a "Set Automatically" option for setting time in FTE (just like the Settings app).

Comment 2

[Fabien Cazenave [:kaze]]

(In reply to Gene Lian [:gene] from comment #1)
> I don't have strong opinion of removing the time setting in FTE or not.
> However, if we choose to keep it, I suggest we should provide a "Set
> Automatically" option for setting time in FTE (just like the Settings app).

+1

Comment 3

[Beatriz Rodríguez [:brg]]

(In reply to Gervase Markham [:gerv] from comment #0)
> There are various bugs in the FTE timezone screen's UX - e.g. 
> 
> * bug 826283 for an incorrect timezone default
> * bug 826286 for an incorrect time on timezone selection
> 
> Fabian keeps telling us that the phone will automatically set the time from
> the mobile network on supported networks, and that this support works in
> Brazil. So, the phone's time will be correct on first run, and will be kept
> up to date with DST changes without any user intervention.
> 
More countries than Brasil are being considered for first launch without NITZ support. IMHO, the functionality is very important and many feature phones already include it, maybe just as the only thing to set in the FTE. 

> I don't have strong opinion of removing the time setting in FTE or not.
UX and Product team should make a decission here about how they want it to be. The FTE is when the customer will be in touch with FFOS for the frist time.

Comment 4

[Fabien Cazenave [:kaze]]

(In reply to Beatriz Rodríguez [:brg] from comment #3)
> More countries than Brasil are being considered for first launch without
> NITZ support. IMHO, the functionality is very important and many feature
> phones already include it, maybe just as the only thing to set in the FTE. 

Precisely, if we keep this screen the suggestion here would be to rely on NITZ when available, and switch to manual date/time setting + timezone selection only when requested.

Comment 5

[Joe Cheng [:jcheng] (please needinfo)]

Triage: Require Product / UX input.
if this bug decides to keep the timezone selection page, then a follow up bug 820696 is to be decided if automatic timezone option is to be added or not

Comment 6

[Beatriz Rodríguez [:brg]]

(In reply to Fabien Cazenave [:kaze] from comment #4)
> (In reply to Beatriz Rodríguez [:brg] from comment #3)
> > More countries than Brasil are being considered for first launch without
> > NITZ support. IMHO, the functionality is very important and many feature
> > phones already include it, maybe just as the only thing to set in the FTE. 
> 
> Precisely, if we keep this screen the suggestion here would be to rely on
> NITZ when available, and switch to manual date/time setting + timezone
> selection only when requested.

+1

Comment 7

[Joe Cheng [:jcheng] (please needinfo)]

(In reply to Beatriz Rodríguez [:brg] from comment #6)
> (In reply to Fabien Cazenave [:kaze] from comment #4)
> > (In reply to Beatriz Rodríguez [:brg] from comment #3)
> > > More countries than Brasil are being considered for first launch without
> > > NITZ support. IMHO, the functionality is very important and many feature
> > > phones already include it, maybe just as the only thing to set in the FTE. 
> > 
> > Precisely, if we keep this screen the suggestion here would be to rely on
> > NITZ when available, and switch to manual date/time setting + timezone
> > selection only when requested.
> 
> +1

on many if not all Android, if NITZ auto time is obtained successfully, the date/time setup will not appear. when you have no SIM and therefore NITZ would fail, then the date/time manual setting page will appear

Comment 8

[Gervase Markham [:gerv]]

Comment 7 seems like the obvious change. If this screen is buggy, let's keep it out of the sight of as many users as possible. If we have a good time via NITZ, skip it. If we don't, show it. That avoids the "we need to support more places than Brazil" problem.

Gerv

Comment 9

[David Scravaglieri [:scravag]]

Product owner, this is an open question.

Comment 10

[Peter Dolanjski [:pdol]]

I agree that not showing the screen if the network time can be leveraged is ideal, but wouldn't we still need to fix the timezone screen bb+ bugs anyways for the cases when the network time is not available?

How much work (and risk) is involved with skipping this screen and using network time (if available)?

Comment 11

[Chris Lee [:clee]]

(In reply to Fabien Cazenave [:kaze] from comment #4)
> (In reply to Beatriz Rodríguez [:brg] from comment #3)
> > More countries than Brasil are being considered for first launch without
> > NITZ support. IMHO, the functionality is very important and many feature
> > phones already include it, maybe just as the only thing to set in the FTE. 
> 
> Precisely, if we keep this screen the suggestion here would be to rely on
> NITZ when available, and switch to manual date/time setting + timezone
> selection only when requested.

This sounds like the ideal path forward.  Any objections from Daniel/Beatriz?

Comment 12

[Daniel Coloma:dcoloma]

(In reply to Chris Lee [:clee] from comment #11)
> (In reply to Fabien Cazenave [:kaze] from comment #4)
> > (In reply to Beatriz Rodríguez [:brg] from comment #3)
> > > More countries than Brasil are being considered for first launch without
> > > NITZ support. IMHO, the functionality is very important and many feature
> > > phones already include it, maybe just as the only thing to set in the FTE. 
> > 
> > Precisely, if we keep this screen the suggestion here would be to rely on
> > NITZ when available, and switch to manual date/time setting + timezone
> > selection only when requested.
> 
> This sounds like the ideal path forward.  Any objections from Daniel/Beatriz?

OK, trying to be very precise:

1/ When the device is switched-on first time, if there is no SIM Card or the device is connected to a Network that does not support NITZ it is impossible to determine the date/time/TZ automatically. In this case the device will show the same screen it is already available (with the bugs fixed) and no option to set-up the time automatically will be offered.

2/  When the device is switched-on first time, if there is a SIM Card, the device connects to a network that supports NITZ, and the date/time/TZ is retrieved successfully, the screen currently shown for selecting Date/Time/TZ will be skipped and the date/time/TZ setting will be configured as "Automatic". 

I agree with that behaviour (would like also to check with Ayman what does he think). I am not sure how risky is implementing this or whether we should block the release without this distinction implemented.

Comment 13

[David Scravaglieri [:scravag]]

We would take a patch for that before approval if it's a low risk.

Comment 14

[Fernando Campo (:fcampo)]

AFAIK, there's no way (in gaia) to know if the NITZ request has been successful, right?
Anybody can point me in the right direction if I'm wrong?

Comment 15

[Gene Lian (I already quit Mozilla)]

(In reply to Fernando Campo (:fcampo) from comment #14)
> AFAIK, there's no way (in gaia) to know if the NITZ request has been
> successful, right?
> Anybody can point me in the right direction if I'm wrong?

Yes, so far we have no way to confirm this.

Comment 16

[Fabien Cazenave [:kaze]]

The `time.nitz.available' setting can be used to know if the current carrier provides NITZ or not — at least, we’re using it in the Settings app (see js/date_time.js): no option to provide automatic time setting is proposed when `time.nitz.available' is false.

However, it can take a lot of time (more than an hour with my carrier) before this setting is updated, which means that:
 • if `time.nitz.available' is true, we’re sure NITZ is provided;
 • if `time.nitz.available' is false, there’s no way to know if NITZ is provided or not.

Gene, please correct me if I’m wrong here.

If that’s correct, Daniel’s proposal makes sense (comment #12): we can skip the timezone selection panel if `time.nitz.available' is true and a SIM card is detected.

We could also add an `nitz' field to our operator_variant.xml database to force automatic time setting for a few networks.

Comment 17

[Fabien Cazenave [:kaze]]

Gene, do you confirm what I wrote about `time.nitz.available'?

Comment 18

[Gene Lian (I already quit Mozilla)]

(In reply to Fabien Cazenave [:kaze] from comment #16)
> However, it can take a lot of time (more than an hour with my carrier)
> before this setting is updated, which means that:
>  • if `time.nitz.available' is true, we’re sure NITZ is provided;
>  • if `time.nitz.available' is false, there’s no way to know if NITZ is
> provided or not.
> 
> Gene, please correct me if I’m wrong here.

You're right. :) Basically, the NITZ info is a so-called *unsolicited* RIL event, which means we have no way to ask for a updated NITZ info from FFOS whenever we want one. We have to wait on the carrier to send the NITZ to us and then we can correct our system time.

For most of the carriers (obviously, not for Fabien's SIM card, though), a NITZ info will be sent to us when the SIM card is registered. That timing is very early, which is even before the first FTE page. However, we cannot always expect all the carriers behave like the same way.

Back to the usage of "time.nitz.available". Indeed, if the value is false, it doesn't imply whether the carrier is supporting NITZ or not. It simply implies whether the NITZ is available or not in our FFOS.

Comment 19

[Fabien Cazenave [:kaze]]

Nominating, as it is related to bug 873962 which is leo+.

Everybody agrees that it would be a pity not to rely on NITZ info when available: the FTE would be simpler, and the user experience would be better (time is automatically adjusted when necessary).

Comment 20

[Dietrich Ayala (:dietrich)]

Triage group agreed that while this might be worth considering, definitely adds unnecessary risk/noise at this stage of 1.1 release cycle. Definitely not blocking, perhaps would take patch for subsequent release.

Should really meet with UX & Product and come up with a definitive call here.

Comment 21

[ayman maat :maat]

(In reply to Fabien Cazenave [:kaze] from comment #19)
> Nominating, as it is related to bug 873962 which is leo+.
> 
> Everybody agrees that it would be a pity not to rely on NITZ info when
> available: the FTE would be simpler, and the user experience would be better
> (time is automatically adjusted when necessary).

Referencing wireframe pack: OWD_FirstTimeUsage_20120914_R2S1_V9.0
This is what was specified in the original set of wireframes for this back in sept 2012.

Comment 22

[ayman maat :maat]

..however the implemented method of selecting a timezone bears no resemblance to what was specified in the wireframes or produced by Visual Design and i would say rates probably quite low in terms of usability.

Comment 23

[Gervase Markham [:gerv]]

:maat: where is that wireframe available to view?

Gerv

Comment 24

[Fabien Cazenave [:kaze]]

+1 for having publicly visible wireframes.

(In reply to ayman maat :maat from comment #22)
> ..however the implemented method of selecting a timezone bears no
> resemblance to what was specified in the wireframes or produced by Visual
> Design and i would say rates probably quite low in terms of usability.

Hi Ayman!

If you’re referring to GMT-offset based timezones, I’m afraid we can’t do it. We had a face-to-face meeting in Madrid a few months ago about that: these timezones have to be in the [region]/[city] format to work — at least with the current code base, but that seems to be required by other use cases too (e.g. Calendar). To put it another way, we came up with this region/city selector because it was technically required, and asked for updated wireframes.

If the wireframes you’re referring to are new ones that take the region/city constraint into account, please make them public and I’ll be more than happy to propose a patch — but that will be another bug.

I agree the current timezone selection is not optimal (to say the least), and manual timezone selection is completely useless anyway if NITZ is supported: that’s why we propose to remove this screen from FTE unless NITZ is not supported.  This is what this bug is about, and your input about this particular point would help us a lot.

Comment 25

[Gervase Markham [:gerv]]

kaze: do you think we'll get to this any time soon, as an FTU user experience improvement?

Gerv

Comment 26

[Fabien Cazenave [:kaze]]

Gerv: I’d love to, but it’s been considered a non-blocking unfortunately. :-(
I have a couple NITZ-related bugs to look at this week, so maybe we’ll get some attention on that in the next few days.

I know Ayman is very busy these days, but pinging him in case he has a few cycles to reply to comment 24.

Comment 27

[ayman maat :maat]

(In reply to Fabien Cazenave [:kaze] from comment #26)

> I know Ayman is very busy these days, but pinging him in case he has a few
> cycles to reply to comment 24.

I am  maxed out right now with higher priority work, but will leave the NeedInfo request for me active so i can come back to this when i have capacity.

Comment 28

[Sam Foster [:sfoster] (he/him)]

Ted, seems like this dupes bug 826359 now, can you scan through and confirm? If there's any open questions, lets open new bugs for them

Comment 29

[Ted Clancy [:tedders1]]

You mean this bug (Bug 826359) dupes Bug 1026098?

Yeah, I agree. Marking it as a duplicate.