Three small problems with the 'connected to server' banner - and a single solution for all three

[LinuxOnTheDesktop]

1. The user may fear that closing the 'connected to server' banner will abort his/her connection.

2. At least on my computers (using Firefox - on Windows and Linux) the banner obscures a username (edit: or whatever at the time happens to be at the top of the chat window).

3. After one closes the banner, it pops up again after a while. Is there any point to that? The user who wants the banner gone must close it again. EDIT: And when the banner reappears, all the contents of that pane jitters. That's really not great.

Suggestion to solve all three problems: turn the banner into text, i.e. remove its close icon and possibly its colouring, and put it in the left pane. In that pane, it will not obscure anything (thus solving 2) and so will not need to be closable (solving problems 2 and 3).

[LinuxOnTheDesktop]

Also:

4. it is unclear whether the browser is merely cosmetic. That is: will closing it sever the connection to the server? Actually - and if I may say so - that is a question that I need answered before I start using the site in earnest.

[elimisteve]

Closing the notification does not sever anything.

[LinuxOnTheDesktop]

elimsteve: right; thanks.

[jimmcgaw]

@elimisteve I'm going to second some of the usability issues noted in here. This alert shows up every time you switch back to the browser / tab after a short time of being idle or away, it obscures the top navigation on mobile web (for me, this happens in mobile Safari), you have to dismiss it every single time, the dismiss button is small and easy to miss clicking. So, I vote we alter this somehow.

One idea: as suggested above, we could make this a text notification that renders for a short duration, then auto-dismisses, and which doesn't obscure any vital content.

Another idea: we could have a "connection status" icon that is clearly visible somewhere, and which switches between clearly differentiated "connected" and "disconnected" status icons as the connection changes.

I vote for the latter, because we should be saving the "notifications" / "alerts" real estate for other more important use cases.

Thoughts?

[elimisteve]

@jimmcgaw Interesting ideas, and I agree the notification is annoying. How about we just don't trigger this notification? Then if we feel like we're missing context/visual cues that we're connected, we do as you just described, where we indicate connection status (if that doesn't make the UI feel too busy), or show a notification toast.

(If only for future reference, I will note that react-toastify is really great.)

How's that sound?

[jimmcgaw]

I'm good to nuke it for the time being. I would think that a "connection error" message should show if the user tries to do anything and the connection is bad, instead of telling them they're connected.

Ok Alarm

[elimisteve]

lol nice vid.

Sounds good. Yeah right now, existing connection notification or not, if the user tries to send a message when offline it'll just fail. What Slack does here seems pretty good, where the message appears to have been successfully sent for a couple seconds no matter what, but if it actually fails then an error shows up on the message itself saying so, along with a Try Again button.

I've thought that maybe each message should have a tiny spinner next to it while it's being sent, which then disappears when the message send is successful. Then the message would show up immediately in the UI like Slack, which would perhaps make the app feel a bit faster than it does now when on a slow internet connection, and achieve this without making it look like the message successfully went through when it didn't; wouldn't want users to send a last message then close the tab before the send completes. But maybe the spinner would make things feel slow and so it's not worth it; I'm not sure.

But all that's overkill for now, I'd say; we've got higher priority things for now.

[elimisteve]

Created an issue to keep track of all this: #288

[jimmcgaw]

I thought about discussing that with you. Instead of just sending a message, it adds it to an async queue of messages to send to the server immediately, so the UI doesn't have to block on the server. A success / error message could be displayed when the server replies, with an optional retry affordance. I think this could be done easily with a service worker, IIRC.

[elimisteve]

That plus also retrying (exponential backoff?) when offline (and thus no error message comes from the server, of course) sounds pretty ideal, yeah 😃.