Closed Bug 806657 Opened 12 years ago Closed 12 years ago

when adding a new Google calendar, no feedback to user after hitting "save"

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 810153

People

(Reporter: dietrich, Unassigned)

Details

(Whiteboard: [mentor=jlal@mozilla.com][LOE:S])

I hit save about 5 times, because nothing happened. Then the app surprisingly closed the pane without any user interaction, and started loading calendars.
blocking-basecamp: --- → ?
Is this a polish? as I test, after I press "save" the screen will return to main page and see it's loading
qawanted: how long is the delay between save and returning the main page?
Keywords: qawanted
OS: Mac OS X → Gonk (Firefox OS)
QA Contact: jsmith
Hardware: x86 → ARM
I think it's variable, depending on network+server response time. The UI stays responsive instead of blocking on that variability. However, the whole pane should close, instead of staying open until the operation completes. Right idea, implemented in the wrong part of the flow. Some possible solutions: * Pop up a progress overlay, preventing any user action until the operations complete. This blocks the user, but would reduce confusion - "i finished, but my calendar items aren't here. did it work?!" * Close the UI immediately, putting the user back in the main view. Their calendar items fill in. Possible confusion if slow network - "i finished, but my calendar items aren't here. did it work?!" * The above, but with a progress indicator somewhere in the calendar primary UI.
Keywords: qawanted
Removing qawanted mainly since I think Dietrich answered the question in detail.
blocking-basecamp: ? → -
This absolutely should make it into v1, in fact we have "in-progress" css classes added/removed from the containers as is so this could be a pure-styling fix depending on how we want to handle it. Keep in mind the process of finding their calendars is much quicker then syncing all the events. Both are totally separate requests/processes so we have quite a bit of flexibility here. However I don't think waiting until the full sync has completed is a good idea, even with maximum optimization event sync will take a good deal of time on slow connection. -- This is a good mentored bug too, not too hard but delivers critical value.
blocking-basecamp: - → ---
Priority: -- → P3
Whiteboard: [mentor=jlal@mozilla.com][LOE:S]
Did you mean to renom the bug?
Hello James, I can work on this. i have gaia setup to work on B2G Desktop on OSX.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.