819986 - FTE: Date & Time Screen

Status: RESOLVED WONTFIX

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

Description

[Gervase Markham [:gerv]]

[I'm filing bugs on the FTE app, one bug per screen. Let me know if you need this split up finer.]

- The default time zone - Africa/Abidjan - is almost certainly the wrong choice. We should either pick something sane based on the user's already-chosen language, or use UTC, or leave it blank and make them enter a value before proceeding.

- In the list of regions, "Indian" is confusing, because it's also (almost) the name of a country, but when you pick it there's nothing related to India in the list. The names should be "Indian Ocean", "Atlantic Ocean" and "Pacific Ocean". I know this comes out of tz_data; can we use some l10n mechanism to substitute the strings?

- In the hour picker, sometimes picking a particular hour shows a different one in the summary screen! Which hours are broken is timezone-dependent, but not in an obvious way. In timezone UTC+00:00 Europe/London, hour 3 -> 5, hour 4 -> 2, and all the other hours work right. In the Moscow timezone (UTC+04:00), 5 -> 7 and 6 -> 4 and all the others are fine. This only happened when PM was selected, not AM. If it makes a difference, I was doing this testing at 3.40pm in the afternoon, which is between the two broken times. There is something very odd going on here!

- Also, why aren't we just getting the date and time from the mobile network anyway, or getting UTC time from GPS and simply asking the user to select their timezone?

Gerv

Comment 1

[Gervase Markham [:gerv]]

Bullet 2 turns out to be bug 808832.

Gerv

Comment 2

[Casey Yee]

cc Rafael,
Can you respond to the first bullet regarding default time zone.

Comment 3

[Gervase Markham [:gerv]]

In terms of avoiding controversy and reducing engineering effort, I suspect my first suggestion is a no-goer. The second suggestion is tricky because we don't have a UTC option currently (although we should). So I think we may have to go with the third option.

If we were able to get date and time from the mobile network, we could offer the user only a choice of places where that was the current time, which would be a much shorter list. But again, that's probably a significant re-engineering.

Gerv

Comment 4

[Rafael Rebolleda]

I agree, but with a somewhat low priority. We need tech feedback to see what's available when automatic set up has failed. I'm guessing language is all we can hold on to... not sure how easy that will be to automatically map to time zone. It might get tricky.

Comment 5

[Fabien Cazenave [:kaze]]

Most networks I’ve tried were able to set date/time properly, but if you select a wrong timezone it will modify the displayed time.

So I’d be tempted to just display the current date/time with a “Is this correct?” item (or “manual settings” button), and only propose users to manually set the date/time/timezone when necessary. </my2¢>

Comment 6

[Gervase Markham [:gerv]]

:kaze: we can't just display the correct time with "Is this correct?" because even if we get the time right, we need to know the user's timezone (unless mobile networks send that too?) because we need to get Daylight Savings Time right when they hit it. 

So, leaving aside all of the "Wouldn't it be nice ifs...", I say that setting it to _nothing_ to start with, and forcing the user to pick a value before proceeding, is actually better than setting it to Africa/Abidjan, which is a) random and b) means that if the user just says "yes, next, whatever" through the intro they'll end up with a device whose time is screwy.

Gerv

Comment 7

[Fabien Cazenave [:kaze]]

(In reply to Gervase Markham [:gerv] from comment #6)
> even if we get the time right, we need to know the user's timezone
> (unless mobile networks send that too?) because we need to get Daylight
> Savings Time right when they hit it. 

Ugh, I wasn’t aware this was required for DST adjustments.
Rafa do you confirm?

> So, leaving aside all of the "Wouldn't it be nice ifs...", I say that
> setting it to _nothing_ to start with, and forcing the user to pick a value
> before proceeding, is actually better than setting it to Africa/Abidjan

To be sharp, the default timezone is empty — not Africa/Abidjan. That’s a UI bug: there should be an “undefined” or “default” item in the list to match the empty timezone case.

I think we should leave the timezone to undefined/default unless the user explicitly changes it.

Comment 8

[Gervase Markham [:gerv]]

OK. So this bug is: 'The timezone selectors in the First Run experience do not have a "Please Choose..." or "Undefined" or similar item, and they should. And the user should not be permitted to advance until they have chosen.'

Gerv

Comment 9

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

Triage: BB-

qawanted on the timezone issue
- In the hour picker, sometimes picking a particular hour shows a different one in the summary screen! Which hours are broken is timezone-dependent, but not in an obvious way. In timezone UTC+00:00 Europe/London, hour 3 -> 5, hour 4 -> 2, and all the other hours work right. In the Moscow timezone (UTC+04:00), 5 -> 7 and 6 -> 4 and all the others are fine. This only happened when PM was selected, not AM. If it makes a difference, I was doing this testing at 3.40pm in the afternoon, which is between the two broken times. There is something very odd going on here!

Comment 10

[Fabien Cazenave [:kaze]]

(In reply to Gervase Markham [:gerv] from comment #8)
> OK. So this bug is: 'The timezone selectors in the First Run experience do
> not have a "Please Choose..." or "Undefined" or similar item, and they
> should.'

+1, this is definitely a bug.
More generally, a better timezone selector would be nice to have — and it’s being worked on.

> 'And the user should not be permitted to advance until they have chosen.'

That’s the part I’m not sure about. The question is:
1/ do we *need* users to select a timezone? 
2/ or do we *want* to enforce a timezone selection?

Re: 1/, I think we don’t need it if automatic date/time is available, but I might be wrong.
On my device, timezone selection didn’t work before my recent patch (two weeks ago) though automatic date/time worked fine. Howerver, choosing a wrong timezone breaks the automatic date/time. Maybe that’s specific to my operator (Free mobile, in France), maybe it wouldn’t work with Vivo — that’s why I asked Rafa about that in comment #7.

Besides, in the Settings app it’s *either* automatic date/time setting or manual settings (including timezone selection). I might miss a point, but the current FTE screen looks like we’re forcing manual date/time/timezone settings where an automatic setting would probably work fine.

Re: 2/, that’s a pure UX question. If it’s a UX decision not to rely on automatic date/time by default, and if everybody understands that choosing a wrong timezone will produce a time offset, I’m fine with that.

Comment 11

[Fabien Cazenave [:kaze]]

Rafa:
 • is automatic date/time setting available with the targeted network?
 • do we need a proper timezone selection to make automatic date/time adjustment work (e.g. daylight saving changes)?

Thanks in advance for sharing the light here, and sorry for the noise I make. :-s

Comment 12

[Gervase Markham [:gerv]]

Actually, you are probably right - if they are having automatic date/time selection, it'll also automatically update the date/time when DST changes.

Gerv

Comment 13

[Luke Crouch [:groovecoder]]

I just turned my phone on and the "Select day" screen started on 1980 with no clear way to quickly change the year?! Had to tap thru 1 month at a time to get to December 2012!

Comment 14

[Luke Crouch [:groovecoder]]

Attachment: FTE Date/Time screenshot

Comment 15

[Luke Crouch [:groovecoder]]

I also noticed the map shows Mountain time highlighted even though I picked America & Chicago.

Comment 16

[Fabien Cazenave [:kaze]]

(In reply to Luke Crouch [:groovecoder] from comment #15)
> I also noticed the map shows Mountain time highlighted even though I picked
> America & Chicago.

Yes, that’s a known bug: images don’t match the timezones — still waiting for UX assets to fix it. Ayman, Rafa?

Comment 17

[Beatriz Rodríguez [:brg]]

(In reply to Fabien Cazenave [:kaze] from comment #11)
> Rafa:
>  • is automatic date/time setting available with the targeted network?
In Spain we do not have NITZ but it is available in Brasil for instance.

Comment 18

[Rafael Rebolleda]

Assets are being developed. Victoria is the main contact for them, although she's not the one producing.

Comment 19

[Josh Carpenter [:jcarpenter]]

Any progress here?

Comment 20

[Gervase Markham [:gerv]]

This bug is getting pulled out of shape. The issue I think we should be fixing is this:

(In reply to Fabien Cazenave [:kaze] from comment #7)
> To be sharp, the default timezone is empty — not Africa/Abidjan. That’s a UI
> bug: there should be an “undefined” or “default” item in the list to match
> the empty timezone case.
> 
> I think we should leave the timezone to undefined/default unless the user
> explicitly changes it.

In other words, this is about fixing the fact that the timezone defaults to Africa/Abidjan. If a bug is needed for replacing the image assets, please open another one :-)

Gerv

Comment 21

[Fabien Cazenave [:kaze]]

(In reply to Josh Carpenter [:jcarpenter] from comment #19)
> Any progress here?

I probably won't work on this before the basecamp release unless it becomes BB+. This should be a trivial fix though.

(In reply to Gervase Markham [:gerv] from comment #20)
> If a bug is needed for replacing the image assets, please
> open another one :-)

⇒ bug 817021

Comment 22

[Jason Smith [:jsmith]]

This isn't polish btw. It's a very silly mistake that happens very obviously at the beginning of the usage of the phone.

I'm renoming cause I don't think we can make a fundamental mistake like this right early on during first usage of the phone and manage to get the country, location, and the time wrong repeatedly through using this UI. It's a 100% probability of hitting this problem and it looks too embarrassing not to fix before ship.

Comment 23

[Jason Smith [:jsmith]]

My issues I hit on this screen basically was:

1. The country and state was wrong
2. Fixing the country and state - time is now wrong
3. Fix time - now we're good

Always occurs - tested in two different timezones as well.

Comment 24

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

Triage: Comment 22 and comment 23 should be dup of bug 817021

Comment 25

[David Scravaglieri [:scravag]]

Definitely not a duplicate.

Comment 26

[David Scravaglieri [:scravag]]

This issue must be splited, so we will be able to track and block separately if needed.

Comment 27

[Fabien Cazenave [:kaze]]

I think we have three UX issues here:

1. if no timezone is selected, the selector shows Africa/Abidjan instead of undefined/undefined;
2. the timezone is neither detected automatically nor defined by any setting;
3. if the user selects a wrong timezone, the time will always be wrong (offset).

As a reminder, selecting the timezone is *NOT* required to have a proper time display. Automatic time updates work out-of-the-box in Brazil (see comment 17) without any timezone selection. Worse, I think that this FTU screen forces a manual time setting, which will be done wrong by many (most?) users, whereas the automatic time setting would work fine.

My take would be to rely on the automatic date/time in the FTU app and only offer to select a timezone when the user wants to switch to manual date/time (like it's done in the Settings app). This question still hasn’t been answered, we really need some UX input here. Please read this bug (I know it’s a long one) and tell us if we really want to force a timezone selection in the first-run experience.

Comment 28

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

Triage: BB-, tracking-b2g18+
the time zone shows incorrect map is fixed in bug 817021. the remaining UX bug is actually not having an impact to have proper time display (comment 27)

Comment 29

[Jason Smith [:jsmith]]

(In reply to Joe Cheng [:jcheng] from comment #28)
> Triage: BB-, tracking-b2g18+
> the time zone shows incorrect map is fixed in bug 817021. the remaining UX
> bug is actually not having an impact to have proper time display (comment 27)

Well...actually it does. If you select a timezone, a wrong time is selected. Obviously you can fix it by tweaking this yourself, but it is inherently wrong.

Anyways, someone needs to break this bug up. I'll take care of this.

Comment 30

[Jason Smith [:jsmith]]

Breaking this out into three separate bugs and closing this out:

* bug 826283 for an incorrect timezone default
* bug 826285 for automatic detection for the timezone
* bug 826286 for an incorrect time on timezone selection

Comment 31

[Gervase Markham [:gerv]]

Bug 826359 filed on removing this screen entirely.

Gerv