Closed Bug 911397 Opened 11 years ago Closed 10 years ago

setting timezone in FTE should use a default based on geolocation

Categories

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

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: pdehaan, Unassigned)

References

Details

(Keywords: ux-efficiency)

Each time after flashing my device I have to do the following:
1) Choose language.
2) Select a network.
3) Set a date and timezone; It's always wrong and thinks I'm in New York. Not sure why that is a default, but now I have to change my timezone and scroll through dozens of cities until I find Los Angeles, which is about 50-60% of the way through the list.
4) Turn on Geolocation.
5) Import contacts. (skip)
6) Turn on data sharing.
7) Enter an email address.
8) Skip the tour.


I guess my general confusion comes from steps 2-4. Why don't we ask for Geolocation *before* asking them to set a time and timezone? That way we already know what city/timezone they're in (if Geolocation can find them) and I wouldn't have to scroll endlessly trying to find Los Angeles (which is actually worse since I usually search for San Francisco/San Jose first then end up scrolling back up for Los Angeles).
At the very least, if the user did join a wifi network, can't we usually get a general location of them from their wifi/IP? I always see geo-specific banners, so I figure it cant be too difficult to ping a webservice which would try and resolve that for us. If the user doesn't have wifi set up, the workflow would still be the same for them, but for the +60% of people who probably set up the phone at home with at least some form of wireless signal from somewhere, auto setting the clock and timezone would make the first time user experience a lot faster.
Keywords: ux-efficiency
OS: Mac OS X → All
Hardware: x86 → All
Summary: setting timezone in FTE is unpleasant → setting timezone in FTE should use a default based on geolocation
Blocks: 915343
We now skip the Date/Time screen entirely if we were able to determine timezone from the network, tracked in bug 1026098. We'll also ask the user to confirm a guess based on info from any SIM cards. I think that covers a good portion of the issues described in this bug. There is still the open question of moving the geolocation screen ahead of Date/Time, but my gut is that even if the user does toggle on Geolocation, a fix and the resulting timezone data will not be available in time to preset the controls on the following screen. So that's part fixed, part wontfix. But *please* re-open if you disagree.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.