We use a 'snackbar' (i.e. notification bar) to indicate the client's connectivity status. On spotty networks the snackbar changes states every few milliseconds and makes the app appear glitchy (i.e. bar is visually perceived as 'flicker').
The bar has the following states:
The snackbar is used in combination with the blue 'nightrider' when connected that indicates 'fetching messages'. When the green connection bar appears, it is sometimes shown at the same time as the fetching messages bar.
Click each button in this prototype to view the behavior: https://framer.cloud/MsLgV/
The best solution to remove the glitchy appearance is still to be specified, but it mostly has to do with:
• adding delays when we consider a change of state permanent,
• being more lax and forgiving
• smoothing the animation so it doesn't drop frames,
• forcing the state to be persistent for at least ~1000ms so it doesn't blink,
• only saying that you're Online after being Offline for a prolonged period, not every time we wake the app.
The basic requirement of this issue is UI smoothing.
When on a spotty network, the snackbar showing connectivity status shouldn't change as frequently as it does now, but still inform users of whether or not they are able to send and receive messages.
Please force an uninterrupted display of a state for 1000ms.
Snackbar and nightrider never appear at the same time. Snackbar takes precedence over nightrider. User will only see the nightrider if definitively _online_ and collecting messages.
Please also prevent the snackbar from displaying each time the user wakes the app from background. It's gratuitous, unless the app is having trouble connecting and remains _offline_ for some reasonable amount of time.
Feel free to propose additional solutions, we're not sure on the best approach here.
Test on spotty network
Consider reintroducing the snackbar to the Wallet depending on latest loading state indicators (https://github.com/status-im/status-react/issues/8443#issuecomment-539045418)
cc @errorists @rachelhamlin
@cammellos we discussed using the number of connected peers for chats the other day, if we base the connectivity status on that it could be less spotty don't you think?
It depends, we use that already for chat.
Currently we have:
Chat offline -> Chat is offline but the OS says we are online (peers count = 0)
Wallet offline -> Peer count > 0 but OS says we are offline
Offline -> Both chat and wallet are offline
Not sure we should be using peers count for Wallet, as the two things are not coupled, conversely, we should not be using OS online/offline for chat, as that proved to be very flaky.
So not sure, certainly we can delay to avoid flapping between states, regardless of what we decide, using peers-count for wallet as well it's a decision, don't have a strong opinion myself.
@cammellos @yenda @errorists @hesterbruikman considering this one for a bounty. It sounds like we need to do the following:
Are there actually two different offline statuses implemented @cammellos?
One if the network is poor, and another if the peer count is 0?
Or is that just happening behind the scenes?
Yes, I meant this is for a sensible engineer person to do a sensible implementation of the snackbar.
I can't prescribe the exact formula for that, but it mostly has to do with:
• adding delays when we consider a change of state permanent,
• being more lax and forgiving
• smoothing the animation so it doesn't drop frames,
• forcing the state to be persistent for at least ~1000ms so it doesn't blink,
• only saying that you're Online after being Offline for a prolonged period, not every time we wake the app.
Yes, the Knight Rider is meant to be shown when chat data is being loaded and should be used solo.
Correct, snackbar should take precedence as it is a prerequisite to be online for the Knight Rider to appear.
Knight Rider shouldn't drop frames, I know easier said than do :)
@rachelhamlin I think the appearance in these mockups matches the one we have currently?
This might require multiple attempts to nail the exact behaviour, that's fine! 🙏
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
__This issue now has a funding of 1.069 ETH (149.99 USD @ $140.31/ETH) attached to it.__
You're right @errorists! Buttons. They're buttons.
Okay—description updated & bounty applied. 🤞
Are there actually two different offline statuses implemented @cammellos?
One if the network is poor, and another if the peer count is 0?
Or is that just happening behind the scenes?
There are 2 offlines states, one is for the chat and one for the wallet.
The reason is that the one we use for the wallet has been very unreliable, many times not reporting connectivity while effectively we can send chat messages. Peer count is the only one we actually use for chat, while for wallet we are forced to use the OS / react-native-net-info capabilities
Should we bundle / display the wallet state together with chat connectivity in the Chat tab?
@errorists currently the snackbar has more states then the ones described in the issue:
How do you think it should be?
Connecting ✅ after coming back from Offline state or after having prolonged connectivity issues
Wallet offline ❎ - should be moved to wallet tab, don't show wallet state in chat
Chat offline ✅
Offline ❎ same as Chat offline for the purpose of Chat tab, if wallet is offline too, that should be displayed separately in the wallet tab
Connected ✅ follows Connecting once successful
sounds good, what about tabs like Profile/Settings, should we not show any connectivity state there other than Connecting/Connected (or not even those)?
Yes, I think this should be contextual to be understood - or - we need to be more explicit with the wording as to what exactly is offline and then having users read that. I prefer the first option, to separate wallet state into wallet tab, chat state into chat. if you're on airplane mode or something similar where there is no internet at all, then we could introduce a global snackbar state that appears uniformly on all tabs: 'No internet connection', since that's not our fault.
To be completely explicit, are you wishing for the copy to say this for each state @errorists?
Connecting ✅ after coming back from Offline state or after having prolonged connectivity issues
Wallet offline ❎ - should be moved to wallet tab, don't show wallet state in chat
Chat offline ✅
Offline ❎ same as Chat offline for the purpose of Chat tab, if wallet is offline too, that should be displayed separately in the wallet tab
Connected ✅ follows Connecting once successful
I think Offline is sufficient in any offline case, for both tabs.
Agree that a global Offline snackbar for a case like airplane mode could be nice as well.
Does anyone know what the current wallet offline state looks like? I've seen a loading state design from Andrei, never any indicator of disconnect.
are you wishing for the copy to say this for each state
yes, i think it's enough, alternatively 'Chat offline' - 'Wallet offline'?
Does anyone know what the current wallet offline state looks like? I've seen a loading state design from Andrei, never any indicator of disconnect.
I think this will need to be designed but the way I imagined is exactly like chat, cc @andmironov

Issue Status: 1. Open 2. Started 3. Submitted 4. Done
__Work has been started__.
These users each claimed they can complete the work by 3 days, 6 hours from now.
Please review their action plans below:
1) tbenr has been approved to start work.
it's been a while since I've collaborate on an issue. This one could be a good one...
Learn more on the Gitcoin Issue Details page.
You're approved @tbenr!
In addition to fixing/smoothing the behavior of the snackbar animation, could you also implement the Offline snackbar in the wallet module?
The possible connectivity states are captured in this comment. But regardless of which module is connected or disconnected, the copy should only ever read Offline or Connected.
@StatusSceptre sure, let me start with the main topic. I'll keep you informed
@tbenr Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
@StatusSceptre @errorists i see that it could be that thesnackbar could hold an error message like An error occured while fetching history, check the logs for details. Do we still need to support such messages to user?
@tbenr Certainly not :)
@errorists great. Sorry for the broken english 🤣
@errorists just want to double-check. Are you sure we want to remove also the message "History syncing offline, waiting for Wi-Fi." when user choose to sync only on wifi connection?
first, what does it mean, History syncing offline? if we were to keep it, somebody would need to make some sense out if this copy here. Either it's in sync or not, history is not syncing so what can I expect? this is as vague as ui labels go :) cc @rachelhamlin @hesterbruikman
@errorists a part of the text, what is meaningful to me is that we are communicating to the user he is offline because he configured wifi only and he can also interact to fix it ("Change")

I'd phrase it differently like To receive new messages connect to Wi-Fi. I've pinged the copywriting crack team to help figure this one out :)
please consider also (on connection error to mail server):

and (error getting messages from connected mailserver):

@cammellos do we still need any of the above? the 'error occurred' one is as helpful as a door handle on a zipper ;)
lol. btw @cammellos is :sync-state in app-db still used? if not, how can I see if wallet is really online. it seems to me we relay on general connectivity status and peers count only:
https://github.com/status-im/status-react/blob/67e6ab6055afd1ce7ffb29937708372e2d1eaee4/src/status_im/subs.cljs#L320-L334
@tbenr Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
@gitcoinbot there is a PR ready to be reviewed: https://github.com/status-im/status-react/pull/9568
@tbenr great work! Please bear with, as we're making our release cut for v1 this week and will likely be a tiny bit slow to review.
@tbenr Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
@tbenr Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
@StatusSceptre OK don't worry :)
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
__Work for 1.069 ETH (135.96 USD @ $127.19/ETH) has been submitted by__:
@StatusSceptre please take a look at the submitted work:
⚡️ A tip worth 0.16030 ETH (20.31 USD @ $126.68/ETH) has been granted to @tbenr for this issue from @StatusSceptre. ⚡️
Nice work @tbenr! Your tip has automatically been deposited in the ETH address we have on file.
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
__The funding of 1.069 ETH (135.42 USD @ $126.68/ETH) attached to this issue has been approved & issued to @tbenr.__
Additional Tips for this Bounty:
Most helpful comment
@gitcoinbot there is a PR ready to be reviewed: https://github.com/status-im/status-react/pull/9568