810153 - Importing a calendar with a slow network connection - poor user responsiveness waiting for completion

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Calendar, defect, P2)

Description

[Jason Smith [:jsmith]]

Build

Device - Unagi

Hashes

  <project name="gaia" path="gaia" remote="b2g" revision="7ffd1c81db16bf0c6c3285a46259411d603109ca"/>
  <project name="releases-mozilla-aurora" path="gecko" remote="mozilla" revision="f059d3668a1acdeca0fac3c489205edcbe3c8779"/>

Steps:

1. On a slow network connection, try to import a remote calendar
2. Get frustrated clicking the save button repeatedly

Expected:

After an initial click to confirm importing the calendar, we should probably move back to original calendar main view (month view) and show that a calendar is actively being actively pulled. Another option at a minimum, is give the user perception of progress.

Actual:

If you click save, nothing happens. No UI change, nothing. On a slow connection, as a user, you are entirely confused what's going on, and probably would think something didn't work. In one scenario, you could get frustrated and start clicking the save button repeatedly. Eventually, the import completes and you switch back to the main UI.

Comment 1

[Jason Smith [:jsmith]]

Noming mainly because the perceived performance here really isn't good.

Comment 2

[Jason Smith [:jsmith]]

Note to drivers:

We either need to fix this bug to control a "one click" operation or fix bug 810187. I think this is the better bug to go after that may end up fixing bug 810187 by caveat.

Comment 3

[Alex Keybl [:akeybl]]

Milestoning for C2 (deadline of 12/10), as this meets the criteria of "known P2 bugs found before or during C1".

Comment 4

[James Lal [:lightsofapollo]]

Calendar syncs in steps (setting up an account is the same thing as a sync + path resolve step).

- Resolve path (first time the account is setup we try to find the right path)
- Authenticate
- Find calendars
- Fetch events for each calendar.

We will block until "Find calendars" using a similar screen to email which will provide some user feedback and hopefully prevent confusion.

This should provide us with a good balance between communicating state and allowing the user to take other actions as the majority of the time is spent fetching events where they will not be blocked at a loading screen.

Comment 7

[James Lal [:lightsofapollo]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6869

Pointer to Github pull-request

Comment 8

[James Lal [:lightsofapollo]]

Attachment: Semi-ugly login screen

Comment 9

[James Lal [:lightsofapollo]]

One additional string for the loading message. Kevin gave his r+ on the code side just need to get the string approved.

Comment 10

[James Lal [:lightsofapollo]]

I just made a quick change to ensure the string is identical to its email counterpart. I hope this makes it a bit easier.

Comment 11

[James Lal [:lightsofapollo]]

Comment on attachment 689447 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6869

Please see the properties file change.

Comment 12

[Axel Hecht [:Pike]]

Comment on attachment 689447 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6869

r=me.
The funky-caps for the inline string in the html is different in style than the other entities, not sure if that's good or bad.

Comment 13

[James Lal [:lightsofapollo]]

I will change the rest to the fUnKy case later on. It makes it easy to identify missed translations visually.

Comment 14

[Jason Smith [:jsmith]]

Verified. I'm getting a spinner while the import is in progress that gives clear indication of progress. Tested importing a couple of yahoo and google calendars.