Experience from slow hotel connection


(Charles Walter) #1

I’m at a hotel in Costa Rica and many other guests must be using the wifi right now, because the Internet is awfully slow.

I thought it was interesting to see how Discourse behaved on a few instances. First, when tapping on the number of likes a post received, it appeared that there was no response. But indeed 5-6 seconds later popped the faces of who had liked my post.

Perhaps more importantly, I posted a reply, and saw that it posted, and then continued to navigate. But when I refreshed the topic, I noticed my post had not actually made it to the server.

Just wanted to share these experiences. I expect they can be simulated by applying throttling from Chrome developer tools. I don’t expect this to be the norm, but if there are easy things that could be done to let user know to hold on, might be worth considering for future roadmap.


(Jeff Atwood) #2

This is all a bit peculiar since discourse, as a JavaScript app, excels at exactly this kind of spotty connection scenario. It is not sending whole web pages and assets over the wire, it is only requesting the minimal set of JSON data necessary to redraw the screen with JavaScript.

To be honest, we haven’t focused on it particularly because we are naturally very good at it by dint of our original design choices; it would be like asking a cheetah if it could please just run a tiny bit faster.

Anyway, we are mixing two requests here:

  1. Displaying “loading…” indicators for read-only display actions that could take a little while

  2. Confirming that saves happen for save write actions.

I’ve used Discourse a fair bit on smartphone with connections going in and out and I’ve never lost a reply. So that’s concerning, but we’d need a repro. With a bad enough connection anything is possible, so who knows.

Probably the best thing to do is focus on case #1, and identify places where we should show a loading spinner if the network is so slow and so unreliable that even getting a bit of JSON over the wire will take a while. These are surely much more common overall.


(Sam Saffron) #3

I agree we can do a bit better with spotty connections and post staging, it is quite easy to repro, we just add a “sleep 5” into the controller that is saving the post.

When we stage a post I think we have a few options:

  • (super duper fancy) work offline, if it was not saved, try to save it again later when online (retry saves)

  • (fancy) if it has not been saved after say 1 second, we can display a message “saving post” - or change color to grey.

  • (simple) display “staged” content in grey, then turn it to black when the server knows the content was saved. (like lots of chat programs do)

@codinghorror which poison do you prefer here?

Regardless, if staged content does not get through a draft should be there, if that is not the case there is a bug here.

I find the naive (simple) approach to be pretty distracting for day-to-day usage, so would prefer we go with (fancy) at least.


(Jeff Atwood) #4

The simple behavior mirroring slack and other chat programs is best here. Simple is good!


(Felix Freiberger) #5

Don’t we already have the composer saying “Saving…” at the bottom of the screen to indicate saving is in progress?

(The letter avatar is weird here, by the way.)


(Sam Saffron) #6

On mobile, yes, not on desktop


(Felix Freiberger) #7

Here’s a screenshot from the desktop view:

I’m pretty sure I’m not imagining this thing down there :wink: