Closed Bug 810386 Opened 12 years ago Closed 12 years ago

[FRE] Time Zone Selection is incorrect

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::First Time Experience
Platform:
All
Other
Type:
defect

Tracking

(blocking-basecamp:+)

Status:
RESOLVED FIXED
Project Flags:
blocking-basecamp +

People

(Reporter: padamczyk, Assigned: kaze)

References

Details

(Keywords: late-l10n, Whiteboard: Interaction)

Attachments

(6 files, 2 obsolete files)

screenshot
225.41 KB, image/jpeg
Details
patch proposal
190 bytes, text/html
vingtetun
: review+
Details
Timezone selection in Android FTE (1)
410.79 KB, image/jpeg
Details
Timezone selection in Android FTE (2)
386.69 KB, image/jpeg
Details
Timezone selection in Android FTE (3)
391.81 KB, image/jpeg
Details
Timezone selection in Android FTE (4)
419.44 KB, image/jpeg
Details
Attached image screenshot — 
The time zone values are incorrect, and there doesn't seem to be :30min values, ie for Newfoundland.
blocking-basecamp: --- → ?
Patryk, is this bug a dupe of bug 810217?
Venezuela also uses 30 minute markers, and Android phones have this feature added.   +'ing to see if this can get fixed.
blocking-basecamp: ? → +
Priority: -- → P3
Borja I guess you are the interface with the UX on your side.
Assignee: nobody → fbsc
Assignee: fbsc → nobody
[:vingtetun] This bug is about UX, because I need all the assets for the new timezones... What about opening 2 bugs, one for getting the assets and one for implementing it?
(In reply to Borja Salguero [:borjasalguero] from comment #4)
> [:vingtetun] This bug is about UX, because I need all the assets for the new
> timezones... What about opening 2 bugs, one for getting the assets and one
> for implementing it?

That's going to far with the bug system. Assets will be used only with the impl.
Assignee: nobody → fernando.campo
So let's gonna keep going with this bug, and wait for some UX feedback.

I'm gonna take it and try to hunt some UXers down for the assets :D
How will daylight savings time affect selection of timezones relative to GMT?  Or is the user expected to know that, e.g., Toronto is GMT-5 in winter, but GMT-4 in summer?
(In reply to Chris Peterson (:cpeterson) from comment #1)
> Patryk, is this bug a dupe of bug 810217?

I don't think so, this bug is about the time zones are specified incorrectly.
(In reply to Mike Habicher [:mikeh] from comment #7)
> How will daylight savings time affect selection of timezones relative to
> GMT?  Or is the user expected to know that, e.g., Toronto is GMT-5 in
> winter, but GMT-4 in summer?

Toronto for instance is always GMT-5. Perhaps we need a 4th row with a label: "Day Light Savings Time [Checkbox]"
(In reply to Mike Habicher [:mikeh] from comment #7)
> How will daylight savings time affect selection of timezones relative to
> GMT?  Or is the user expected to know that, e.g., Toronto is GMT-5 in
> winter, but GMT-4 in summer?

Toronto for instance is always GMT-5. Perhaps we need a 4th row with a label: "Day Light Savings Time [Checkbox]"
That checkbox would adjust the time in row  3 by 1 hour in this specific example.
(In reply to Patryk Adamczyk [:patryk] UX from comment #10)
> (In reply to Mike Habicher [:mikeh] from comment #7)
> > How will daylight savings time affect selection of timezones relative to
> > GMT?  Or is the user expected to know that, e.g., Toronto is GMT-5 in
> > winter, but GMT-4 in summer?
> 
> Toronto for instance is always GMT-5. Perhaps we need a 4th row with a
> label: "Day Light Savings Time [Checkbox]"
> That checkbox would adjust the time in row  3 by 1 hour in this specific
> example.

And then there's Saskatchewan, which doesn't observe daylight savings time; or rather, is permanently on it[1].

1. http://en.wikipedia.org/wiki/Daylight_saving_time_in_Canada#Saskatchewan

I think a much better solution is to let the user pick his/her _region_, and to have the software figure out what time-zone that is, and whether or not DST applies.
Component: Gaia → Gaia::System::First Time Experience
This needs a definitive decision from IAs that worked on it. Rafa or Ayman. Then assets will be created.
i am looking into it steve.
ok guys, I need some input from the team before i can move forwards with this. What I am seeing is: 

1) that the time zone selector that was specified on page 19 of OWD_FirstTimeUsage_20120914_R2S1_V9.0 that was supposed to be implemented in both first time user experience and settings area has not been implemented in either place.

2) we have two very very different implementations of *a* timezone selector in both the first time user experience and the settings area of the phone

I need to understand what we are implementing before i can propose a propose a viable solution. So, who can explain to me the intention of the architecture of what we are implementing for time zone selection in the first time user experience and in the settings area? ...or is it the case that these are temporary 'placeholders' and we are actually implementing what was specified in detail on page 19 of OWD_FirstTimeUsage_20120914_R2S1_V9.0?

Please let me know so that I can propose a solution for you.
Can you help me understand why we need this at all? The timezone is set automatically from the radio signal, even without a SIM card inserted.
(In reply to Andreas Gal :gal from comment #15)
> Can you help me understand why we need this at all? The timezone is set
> automatically from the radio signal, even without a SIM card inserted.

Hi Andreas

From a UX point of view, based on the knowledge i have acquired from designing other Operating Systems, there are many reasons that precipitate the desire for a facility by which the end user can manually control the timezone of the device. I will outline only two primary categories of reason for you:

	1) user control and flexibility in use
	2) error recovery

1) user control and flexibility of use

Apart from being good design practice to give the end user control over their environment and therefore flexibility in its usage, I have previously been made aware of situations whereby the end user wished to have their phone (or one of their phones) set to a time zone that was different to the one they were currently in. Two primary scenarios cover this:

S1.1) The end user crosses into another time zone for a limited (short) period of time and wishes to maintain the time of the timezone they have come from and calculate local time (when they have to) for themselves. This is apparently quite true for a subsection of users who either regularly or irregularly cross backwards and forwards between timezones in a single day.

S1.2) The end user is located in one timezone but but for a period of time wishes to maintain the time of a different timezone on a device. Apparently there is a group of end users who desire to do this because they are located in one timezone but are either a) intensely conducting business with others in another time zone (they even change their sleeping patterns to align with the destination time zone due to business commitments) or b) are regularly contacting family who are located in another timezone  using a specific device. In both of these scenarios the desire for the device to inform the end user of the time in the place they are making contact with overrides the desire to know the time in the place where they are currently located.

2) error recovery

Errors happen and we must give the end user the ability to recover from them. I will outline two scenarios for this:

S2.1) There is a problem with network time precipitating the device displaying the incorrect timezone. In order to recover from this error (and therefore get satisfactory usage out of their phone whilst the problem was rectified) the end user wishes to manually set the timezone.  Verizon and ATT recently had a problem like this, and this is how a section of end users behaved in order to overcome the problem and maintain comfortable phone usage.

S2.2) The phone is displaying an incorrect timezone. However the error is that the phone also has either no SIM card inserted, or the SIM card is inserted but cannot connect to a network, *AND* the phone is also not connected to a wireless network either because one is not available or because there is a problem with the phones WiFi receiver. The user therefore wishes to adjust the timezone of the phone because they have either:

	S2.2.1) acquired the phone in one timezone and are turning it on for the 'first time' in another one
	S2.2.2) traveled from one time zone to another and their SIM card does not connect to a network in the new timezone and they have no wireless network to connect to (or they wist to connect to). However they wish to use their phone as, say, a watch and/or alarm clock for the period of time they are there.

These are a few of the outline reasons as to why we need to include this feature, and cannot solely rely on the timezone being set automatically from a signal. I hope that clarifies for you. Should you wish to discuss further, please do not hesitate to contact me.

In the mean time it would be super to connect with whoever has been overseeing the design of the timezone selector in-between me delivering the wireframes on 14th Sept and now so that i can understand where we are at and efficiently propose UX solutions to the bugs related to timezones here in bugzilla....as and f.y.i. I have spoken directly with Josh and he is unsure who it is....so, anyone?
(In reply to Andreas Gal :gal from comment #15)
> Can you help me understand why we need this at all? The timezone is set
> automatically from the radio signal, even without a SIM card inserted.

I think this scenario will not work until bug 714355 is implemented
(In reply to ayman maat :maat from comment #16)
> (In reply to Andreas Gal :gal from comment #15)
> > Can you help me understand why we need this at all? The timezone is set
> > automatically from the radio signal, even without a SIM card inserted.
> 
> From a UX point of view, based on the knowledge i have acquired from
> designing other Operating Systems, there are many reasons that precipitate
> the desire for a facility by which the end user can manually control the
> timezone of the device.

hi Ayman, I understand the need for a (power) user to change their time zone setting, but is this step necessary for *every* user's First Run Experience?
(In reply to Chris Peterson (:cpeterson) from comment #18)
> 
> hi Ayman, I understand the need for a (power) user to change their time zone
> setting, but is this step necessary for *every* user's First Run Experience?

Adding to Ayman's list above, there could also be security implications: an incorrectly-set clock could prevent us from properly validating security certificates, which could prevent connecting to WiFi (do we support cert-based auth on WiFi?) or it could prevent us from connecting to SSL-based services, like email or OTA updates.  (It could also allow expired and possibly-compromised certificates to be used.)

It seems to me that being able to set a correct time is something so fundamental that we should always give the user the option of doing so, even if the form is pre-populated using network values.
(In reply to Chris Peterson (:cpeterson) from comment #18)
> (In reply to ayman maat :maat from comment #16)
> > (In reply to Andreas Gal :gal from comment #15)
> > > Can you help me understand why we need this at all? The timezone is set
> > > automatically from the radio signal, even without a SIM card inserted.
> > 
> > From a UX point of view, based on the knowledge i have acquired from
> > designing other Operating Systems, there are many reasons that precipitate
> > the desire for a facility by which the end user can manually control the
> > timezone of the device.
> 
> hi Ayman, I understand the need for a (power) user to change their time zone
> setting, but is this step necessary for *every* user's First Run Experience?


Hi chis

You are absolutely right.

referencing wireframe pack 'OWD_FirstTimeUsage_20120914_R2S1_V9.0' page 7, 16, 19:

the original specification (in flow page 7) was that confirmation of date and time (wireframe 'set date and time' page 16) was only required 'if no SIM found or WIFI was selected' . The the changing of timezone (wireframe timezone picker on page 19) was an optional step from this page.

Therefore the option/step to change time zone setting was never specified to be a 'step necessary for *every* user's First Run Experience'.

I am Still looking for the designer who has been overseeing this and the timezone selection in the phone settings area.
(In reply to Mike Habicher [:mikeh] from comment #19)
> (In reply to Chris Peterson (:cpeterson) from comment #18)
> > 
> > hi Ayman, I understand the need for a (power) user to change their time zone
> > setting, but is this step necessary for *every* user's First Run Experience?
> 
> Adding to Ayman's list above, there could also be security implications: an
> incorrectly-set clock could prevent us from properly validating security
> certificates, which could prevent connecting to WiFi (do we support
> cert-based auth on WiFi?) or it could prevent us from connecting to
> SSL-based services, like email or OTA updates.  (It could also allow expired
> and possibly-compromised certificates to be used.)
> 
> It seems to me that being able to set a correct time is something so
> fundamental that we should always give the user the option of doing so, even
> if the form is pre-populated using network values.

(In reply to Mike Habicher [:mikeh] from comment #19)
> (In reply to Chris Peterson (:cpeterson) from comment #18)
> > 
> 
> It seems to me that being able to set a correct time is something so
> fundamental that we should always give the user the option of doing so, even
> if the form is pre-populated using network values.

Agreed. That is a very reasonable argument you are putting forward for adjusting what was specified in the wireframes on page 7 and something i had not considered. I would therefore suggest that we always allow the user to validate/confirm timezone, date and time.  This would mean that the user would always see wireframe 'set date and time' (page 16) in the first time user experience.
Blocks: 813120
Blocks: 814094
ok, so, following a meeting with :kaze who is coding the timezone selector in the phones settings area it has been decided that, due to code freeze, we have to follow the overarching architecture as defined in the phone's settings area for setting the timezone. This is:

1) User selects a continent from a list of continents.
2) User selects a city from a list of cities associated to the selected continent.

As outlined in previous conversations this information architecture is fraught with UX issues: 

1) users not knowing what continent they are on
2) large lists of cities associated to each continent precipitating...
3) ...increased cognitive loading
4) ...redundancy in information delivery as the listing of 'user relevant options' is merged with cities that are not relevant to the timezone they are wishing to select
5) ...users not being able to identify a city within the list that is relevant to the timezone they are trying to select and 
6) ...reduced reinforcement to aid their selection
7) and therefore increased user error
etc etc.

The proposition also has an impact on the build blocks:  

1) The recommended BB to be used to choose the appropriate continent/country/city is a value selector (which is a system component), but in this case we will need to use a kind of nested value selector component that is not yet designed.  

The above listed items will be taken into consideration as much as possible as we evolve the UX architcture for the timezone selector. 

Before i can move forward I am waiting on :kaze to deliver me a full listing of continents and each continents associated list of cities. I would also like the timezone that each city belongs to.
I don't see this as a blocker for v1.  Can we remove/defer this from the FRE so we can focus on other blockers at this point?  This is causing a lot of additional cycles we don't have right now.  

Josh/Patryk/Ayman, feel free to follow-up with me offline.
(In reply to Chris Lee [:clee] from comment #23)
> I don't see this as a blocker for v1.  Can we remove/defer this from the FRE
> so we can focus on other blockers at this point?  This is causing a lot of
> additional cycles we don't have right now.  
> 
> Josh/Patryk/Ayman, feel free to follow-up with me offline.

Personally I dont see how we can consider either removing or deferring timezone selection from first run experience. 

However the removal / deferral of features is not my call... Over to you josh [:jcarpenter]
Whiteboard: Interaction
Attached file patch proposal (obsolete) — 
Stealing. The timezone selection doesn't work in the Settings app either, so I’m trying to fix both bugs at the same time.
Assignee: fernando.campo → kaze
Comment on attachment 686184 [details]
patch proposal

This patch fixes the timezone selection in both the Settings and FTU apps. Beware:
 • selecting a timezone now requires two <select> menus (= continent/city)
 • I’ve used a lot of shared stuff, let me know if that’s OK:
     - /shared/resources/tz.json
     - /shared/locales/tz.ini
     - /shared/js/tz_select.js

Note that the graphical visualization of the timezone in FTU is still incorrect, and some timezones are missing. The code is ready now, fixing this only requires some CSS + a few PNG images — feel free to open a follow-up.
Attachment #686184 - Attachment description: work in progress → patch proposal
Attachment #686184 - Flags: review?(21)
Comment on attachment 686184 [details]
patch proposal

Sounds good. Code is now shared and the functionnality works. If there is any additional UX works it should be on a different bug.
Attachment #686184 - Flags: review?(21) → review+
I had to revert part of this for breaking the build

build/webapp-zip.js:265: Error: Using inexistent shared resource: timezones.json from: settings.gaiamobile.org
make: *** [webapp-zip] Error 3
cjones@beast:~/public_html/gaia[]$ rgrep -n timezones.json *
apps/settings/index.html:27:    <link rel="resource" type="application/json" href="shared/resources/timezones.json"/>

Presumably the settings app shouldn't be including that anymore?
Attached file regression fix (obsolete) — 
NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): the patch above
User impact if declined: Gaia doesn’t build
Testing completed: Gaia builds now
Risk to taking this patch (and alternatives if risky): none
Attachment #686740 - Flags: review?
Attachment #686740 - Flags: approval-gaia-master?(21)
ooops, sorry, I didn’t see it’s been reverted I was in a hurry to fix it. :-(

(In reply to Chris Jones [:cjones] [:warhammer] from comment #29)
> Presumably the settings app shouldn't be including that anymore?

Exactly. My bad.
Attachment #686740 - Flags: review?
Attachment #686740 - Flags: approval-gaia-master?(21)
Attached file patch proposal — 
Same patch, without the regression.
Attachment #686184 - Attachment is obsolete: true
Attachment #686740 - Attachment is obsolete: true
Attachment #686746 - Flags: review?(21)
Keywords: late-l10n
Just found this thread. One comment on current implementation: the list of cities under "America" is very, very, very loooooooooooong.

Any change we can cull that list down to a few per time zone?
Not just America, btw. Each continent has same problem.
(In reply to Josh Carpenter [:jcarpenter] from comment #36)
> Not just America, btw. Each continent has same problem.

When we met in Madrid I shown Kaze and Ayman the way in which Android minimizes this problem, Android reduces the number of cities shown and groups some of them together. Can we try to reduce the number of cities based on that implementation?
That would be possible, yes. The main difficulty here is to know which cities can be grouped together: the UTC offset is not enough, we have to make sure that grouped cities are in the same time zone and switch to Daylight Saving Time on the same day.

Another approach could be to group cities by UTC offset; but if the UX rationale is that users don’t know in which continent they live, I doubt they know in which timezone they live…

As bug 816940 has been marked BB+, grouping list items will be easier. A three-step selection could be considered.
How about a search box where the user can type in a city name, even if just to narrow the list?
(In reply to Fabien Cazenave [:kaze] from comment #38)

> Another approach could be to group cities by UTC offset; but if the UX
> rationale is that users don’t know in which continent they live, I doubt
> they know in which timezone they live…

Yeah I don't think this will work, for the reason you cite.

> As bug 816940 has been marked BB+, grouping list items will be easier. A
> three-step selection could be considered.

Let's try to avoid that. :)

(In reply to Mike Habicher [:mikeh] from comment #39)
> How about a search box where the user can type in a city name, even if just
> to narrow the list?

We should solve this for users without requiring text entry, IMO. It is important to the their first impression of the device that the FTE is as smooth and painless as possible.
(In reply to Fabien Cazenave [:kaze] from comment #38)
> That would be possible, yes. The main difficulty here is to know which
> cities can be grouped together: the UTC offset is not enough, we have to
> make sure that grouped cities are in the same time zone and switch to
> Daylight Saving Time on the same day.

I suspect grouping of cities would be done by time zone? eg: Vancouver, Portland San Francisco, Los Angeles, etc? That's a lot of text to fit in one row, however... We really only get "Vancouver, Por..." 

Daniel, can you shed a bit more light on the Android approach? My device is dead at the moment.
I've added some screenshots. Please note that not all the cities in the same zone are grouped in the same row, only those that are very related are linked together. Android's FTE list includes around 120 rows.
Time zones assets for the illustrative (small) map in the screen previous to the selection overlay, are completed with the 30 min and 15 min zones. Please update all images in here: https://www.dropbox.com/sh/9ouyxp4udjsia4o/_QEd1Gb9d1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: