Closed
Bug 809537
Opened 12 years ago
Closed 11 years ago
Notify the user clearly when they are offline with an understanding of the implications for calendar (sync, importing, etc)
Categories
(Firefox OS Graveyard :: Gaia::Calendar, defect, P3)
Tracking
(blocking-basecamp:+)
People
(Reporter: jsmith, Assigned: yurenju)
References
Details
(Keywords: late-l10n, Whiteboard: [mentor=jlal@mozilla.com][LOE:S], testrun 2,)
Attachments
(2 files)
Right now, if a user tries to sync a calendar that they previously imported (manual or automated sync) without a network connection (offline mode), no user feedback is given at all. We need to provide an error notification somewhere on the UI that indicates clearly to the user that they will not be able to sync events while they are offline. Note to drivers - this is the basis of user story CALENDAR-008 btw.
Reporter | ||
Updated•12 years ago
|
blocking-basecamp: --- → ?
Gaia triage : +, we do not want offline mutations. We need to block the user from doing offline mutations.
blocking-basecamp: ? → +
Updated•12 years ago
|
Priority: -- → P3
Reporter | ||
Comment 2•12 years ago
|
||
Per talking in triage, going to generalize this bug to - we need to provide notifications when the user is offline.
Summary: When I try to manually or automatically sync with an online calendar without a network connection, we need to notify the user that they are offline and cannot sync → Notify the user clearly when they are offline with an understanding of the implications for calendar (sync, importing, etc)
Comment 4•12 years ago
|
||
I am not really "blocked" here but how do you want to handle this? My first thought is to "gray out" those fields that cannot be used while offline and when clicked display a short message with a "status" building block (http://mozilla-b2g.github.com/Gaia-UI-Building-Blocks/#http://mozilla-b2g.github.com/gaia/shared/style/status/)
Flags: needinfo?(kyee)
Comment 5•12 years ago
|
||
I am not really "blocked" here but how do you want to handle this? My first thought is to "gray out" those fields that cannot be used while offline and when clicked display a short message with a "status" building block (http://mozilla-b2g.github.com/Gaia-UI-Building-Blocks/#http://mozilla-b2g.github.com/gaia/shared/style/status/)
I would recommend that we stick to the same pattern for these types of errors as we have for Email. https://www.dropbox.com/s/9jq2hy7l3lucehb/Mail-folders.pdf See pages 3, 4. If there is any sync errors we should display the error icon next to the calendar that the sync error is happening. If its an account error, all the calendars for a given account will have the error icon. We should also display the last sync/error next to the sync icon in the drawer as well.
Flags: needinfo?(kyee)
Updated•12 years ago
|
Assignee: nobody → jlal
Updated•12 years ago
|
Target Milestone: --- → B2G C3 (12dec-1jan)
Updated•12 years ago
|
Whiteboard: [mentor=jlal@mozilla.com][LOE:S]
Updated•12 years ago
|
Assignee: jlal → cbrocious
Updated•12 years ago
|
Assignee: cbrocious → venkks
Comment 10•12 years ago
|
||
Venkk, have you had a chance to look at this one yet?
Comment 11•12 years ago
|
||
Its very possible that we would need strings to convey this (though we could probably do without)
Keywords: late-l10n
Comment 13•12 years ago
|
||
Cody, Venkk is out for a few more days. Can you grab this one please?
Assignee: venkks → cbrocious
Comment 14•12 years ago
|
||
Can we get an update on this one?
Comment 15•12 years ago
|
||
I have the backend bits of this in place, but I don't have any free cycles to finish the frontend right this moment. Once I close the other bug I'm wrapping up, I'll jump back on this one; probably later today or early tomorrow.
Assignee | ||
Comment 17•12 years ago
|
||
I can help on this bug. James, do you mind I taking this?
Updated•11 years ago
|
Target Milestone: B2G C3 (12dec-1jan) → B2G C4 (2jan on)
Assignee | ||
Comment 18•11 years ago
|
||
Casey, thanks for the information about sync error and I would like to know about offline behaviour. James proposed to show a notification when user click sync icon on offline mode, and I also check the email behaviour on offline mode FYR, please see the attachment. what do you think about this?
Flags: needinfo?(kyee)
Comment 19•11 years ago
|
||
In a offline situation when the automatic re-try fails we should update the last sync status in the drawer. Users will be in and out of data and wifi coverage often so it would pretty annoying if we displayed an error every-time a sync error occurred. However in the scenario where the user manually taps on the sync icon and there is no connection we should alert the user with a error. The banner as suggested in Comment 18 would be suitable. The only thing I would change is removing the retry button since the sync button already exists in the footer.
Flags: needinfo?(kyee)
Comment 20•11 years ago
|
||
Handing this off to Yuren, Re #18: We have the basics for this implemented in the view class (using a building block). So it should be very easy to utilize this. We could implement a "Offline Error" and utilize the same system we have today. If your going to be at the workweek I can give you a quick walk through on Monday.
Assignee: jlal → yurenju
Assignee | ||
Comment 21•11 years ago
|
||
Thank you Casey, it should be a notification without retry button. James, I saw the code for showErrors and wrote some to show a notification when click sync icon on offline mode (but only use default error without l10n first). https://github.com/yurenju/gaia/commit/d4663d3d113f126256b1de360c353521f87bf52c if this is the right way to implement it, I will create a new error type 'offline' and string for this error. and see you at workweek!
Comment 22•11 years ago
|
||
Logic is right but see my comments in GH we need to make some changes so this works if the settings view has not been loaded and the final patch will need some tests.
Comment 23•11 years ago
|
||
Note: this bug should also cover the case where we try to add or delete an event while offline we need to show a similar error & abort. I am totally fine with doing it in multiple patches but this bug covers all online functionality (including sync which you just demonstrated ).
Assignee | ||
Comment 24•11 years ago
|
||
Pike, I would like to use the string 'error-no-url' for offline mode, but the string 'No connection. Check your Wi-Fi and try again.' should be modified to 'No connection. Check your configuration and try again.' Should I create a new string for offline or just modify the error-no-url? thanks.
Flags: needinfo?(l10n)
Comment 25•11 years ago
|
||
You should create a new string. A different question is if you should make the old use-case for error-no-url update to the new string as well.
Flags: needinfo?(l10n)
Assignee | ||
Comment 26•11 years ago
|
||
Attachment #699124 -
Flags: review?(l10n)
Attachment #699124 -
Flags: review?(jlal)
Comment 27•11 years ago
|
||
Comment on attachment 699124 [details]
pull request
Thanks, this looks good from and l10n pov.
Attachment #699124 -
Flags: review?(l10n) → review+
Comment 28•11 years ago
|
||
Comment on attachment 699124 [details]
pull request
Nice work!
Attachment #699124 -
Flags: review?(jlal) → review+
Assignee | ||
Comment 29•11 years ago
|
||
Merged. Thank you all! https://github.com/mozilla-b2g/gaia/commit/9f17f1a8fdc991952f948d9d97af5e0210a22d0e
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 30•11 years ago
|
||
UCID: calendar-008 https://moztrap.mozilla.org/results/case/61550/
Whiteboard: [mentor=jlal@mozilla.com][LOE:S] → [mentor=jlal@mozilla.com][LOE:S], testrun 2
Comment 31•11 years ago
|
||
fix verified in Build 2013-01-12-070202 for Unagi, however, the error message needs to be edited, new bug filed #830041
Status: RESOLVED → VERIFIED
Updated•10 years ago
|
Whiteboard: [mentor=jlal@mozilla.com][LOE:S], testrun 2 → [mentor=jlal@mozilla.com][LOE:S], testrun 2, burirun1.3-2
Updated•10 years ago
|
Whiteboard: [mentor=jlal@mozilla.com][LOE:S], testrun 2, burirun1.3-2 → [mentor=jlal@mozilla.com][LOE:S], testrun 2,
You need to log in
before you can comment on or make changes to this bug.
Description
•