-
-
Notifications
You must be signed in to change notification settings - Fork 643
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve messaging when realm push notifications are not enabled #5802
Improve messaging when realm push notifications are not enabled #5802
Conversation
1da6c0c
to
b4151ce
Compare
This comment is about how this revision relates to the spec in #5785. It shows where the spec is followed, and also where and why it's contradicted in some parts, which we can discuss (maybe on CZO).
✅
✅
In this revision, I did the first bullet point but not the second; see #5785 (comment). In the "may not be working" cases, I've preserved the link to the in-app troubleshooting screen, which now has a link to the troubleshooting article. The article link is new in this revision; see a screenshot in the comment after this one: #5802 (comment) .
✅ Here is the switch in action: |
This comment is about additional changes that were easy or seemed natural to do, but not covered in the spec in #5785. Google Play Services message changedIn the troubleshooting screen, I shortened the message
to just
because in theory the Services could be available on the device, just disabled or otherwise made unavailable to Zulip. Bold realm name in user-facing messageWhere possible, in the new UI message
, the realm name is bolded. You may have noticed this in screenshots in my previous comment. (This wasn't possible in the native-iOS popup that comes up when you tap a warning icon in the "Pick account" screen.) The realm name is freeform user-generated content, and I think bolding it is an easy way avoid funny miscommunications by delineating the content from the rest of the message, which is in our voice. (Probably no one would really make a joke realm named "people like you" or something… But in theory some kind of accident could happen, and I'd rather prevent it than think about how likely it is, in English or in any other language we offer the app in. 😛) The new "silence" setting:
Following Alya's comment #5785 (comment), I've just made the new "silence" setting always be there. The troubleshooting screen now links to the troubleshooting articleOn the troubleshooting screen, you can now tap a row to open this link:
Alerts in the troubleshooting screen are un-boldedSee the previous pair of before/after screenshots. Here's the same pair again, but in dark mode:
Now, bold text like "support@zulip.com" stands out from surrounding text, as initially intended. It's easy to change the color of that text if it's too light in light mode or too dark in dark mode. Linking to Help Center instead of RTD:The home-screen banner's "Learn more" button now links to instead of . Ditto for the row
when it appears in the notification settings. Screenshots showing where these links appear:
Other messages also shown in more placesThese two places—
—will now also give one of these explicit messages if it applies:
instead of the vague message
Other things |
b4151ce
to
b0fc040
Compare
Revision pushed, addressing Alya's comments on the issue up to here: #5785 (comment). Here in the PR thread, I've correspondingly updated the screenshots/commentary above. |
All the decisions make sense to me! |
Maybe we should update the warning banner to refer to the troubleshooting guide, not just support? "... not arrive. Please refer to the troubleshooting guide or contact support@zulip.com with..." ? |
… guide As suggested by Alya: zulip#5802 (comment)
Done, and thanks for the review! Revision pushed. @gnprice, over to you when you're feeling better from your sore throat. 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks to you both for all the work on this!
I've read through the code, and it all looks good; one small comment below. Now catching up on the discussion thread.
src/account/AccountItem.js
Outdated
// appear in the UI. As of writing, notifProblemShortText doesn't use its | ||
// realmName param except in a case where we have server data for the | ||
// relevant account. When we have that, `realmName` will be the real realm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this true?
Ah I see, it's because:
- notifProblemShortText only uses the realm name for the ServerHasNotEnabled problem;
- useNotificationReportsByIdentityKey only returns that problem when we have server data.
Tricky. Maybe worth spelling out a bit more: "in a case where" -> "for a NotificationProblem which we only select when".
OK, all LGTM with that one comment above about clarifying a comment. @chrisbobbe please go ahead and merge when ready after that. |
977835a
to
05e7ef3
Compare
… guide As suggested by Alya: zulip#5802 (comment)
I suppose the Services could be available on the device, just disabled or otherwise made unavailable to Zulip.
…exts These all seem to have gotten the right size and color by accident, from global defaults. But given ZulipText's API, passing both of these is the right pattern for these subparts of UI strings. We never intend to discard a locally chosen color or font size just because we're putting a dynamic value into a translated UI string.
In the message for NotificationProblem.ServerHasNotEnabled, we'd like to make the realm name bold. Now, when we do that, its weight will still be distinct.
One of the Role.Admin conditions had actually been going the wrong way, showing the admin message to non-admins and the non-admin message to admins. Fortunately that was on the notification troubleshooting screen, which you can't have reached unless the server had been set up for notifications earlier in the mobile app's session. Fixes-partly: zulip#5785
We'll use this soon for a caller that needs a LocalizableText and can't use a LocalizableReactText.
…tions In particular, the message > Push notifications are not enabled for {realmName}. can now appear in these places: - on the "Notifications" button in the settings screen - in the dialog shown when you tap a warning icon on the active account in the "Pick account" screen. Before this, both of those places would just say: > Notifications for this account may not arrive. which was less definitive than we would like. (If the server hasn't enabled push notifications, then they definitely won't arrive.) In this commit, we also start using those same two places to give other actionable feedback as it applies: > Notifications are disabled in system settings. > Notifications require Google Play Services, which is unavailable. For the "Google Play Services" message, this commit also causes it to appear on the "Troubleshooting" button in the notification settings screen. (When the "not enabled for {realmName}" case or the "disabled in system settings" case applies, the notification settings screen already has appropriate messaging, since before this commit, that doesn't involve the "Troubleshooting" button.) Fixes-partly: zulip#5785
…tions" Fixes-partly: zulip#5785
And also on ServerCompatBanner, since it seems right to be consistent between the two banners. Fixes-partly: zulip#5785
We're about to add a link to the notification troubleshooting guide, and it seems cleanest to do these as rows instead of ZulipButtons.
…tsAction This doesn't belong here. It's already present in the PerAccountAction union, so nothing to do after removing it here.
… guide As suggested by Alya: zulip#5802 (comment)
05e7ef3
to
0dbcf8f
Compare
Thanks for the review!
Done. |
Many screenshots and some discussion coming soon; I'll post in messages after this one. 🙂
Fixes: #5785