0

I don't know if someone has already come up with a swiss-knife solution to the problem, but I want to discuss a possible one with you.

Suppose that you are on a "New Post" type page and have to do with a user having a very slow connection (keep in mind, this could also apply to a large upload from a user having a fast connection).

A way to tackle this problem (and that's rather trivial to implement) could be to regularly (maybe transparently) save his post's actual state in his browser (eg. LocalStorage) and on submit send it chunkified to the server.

What changes is that as he presses submit he would be immediately redirected to the pseudo-post page (loaded from his browser) like his post was really sent, but nobody else will actually see it till it is.

In the background, the server keeps in sync with the browser and gets the missing chunks from it. If the client disconnects the operation will continue as soon as it reconnects.

Is this good from a UX point (I think that Firefox still shows that ugly warning when you want to save something on the LocalStorage) or it's better to stick with a loader?

Otherwise, what's your solution?

Improve this question
2

Adding to previous answers, you could try to use MeteorJS if you are looking for a specific technology.

MeteorJS as well as other JavaScript frameworks make use of "Data Reaction", this means that it loads all the templates only once and then it just focuses on submitting data to the server without needing to reload the page.

To answer your question more precise, you can use this "reactive" principles so your users only need to load the whole application views once.

If you feel the need to warn about connection delays, I'll suggest a cool loader or something similar to @PrashantKrish suggestion, personally I love when an app "talks to me" like that.

Improve this answer
1
  • 1
    Didn't know about Meteor.js but it looks cool. Gonna definitely try that, thanks!
    – myth
    May 27 '14 at 21:22
3

Showing user immediate feedback is perfectly best idea but not when it is the reality. These are dark UX practices honestly. It is good to be honest rather than faking. Put up a message on the screen that "Hey hero, seems there is technical snag with your hand held, do not worry we will get this posted while you work with other stuffs, go ahead, carry on we got it!" (obviously shorter and cool message can be displayed and not lengthy one as what I have written). Always keep the user posted because he really wants one, if he/she doesn't that can always be enabled or disabled as part of user interaction settings personalisation.

Improve this answer
1
  • @myth yes very true and that is why I added a point in the end to give user option to personalise such setting. If your project is ready to invest then start the activity of detailed user profiling.
    – PrashanthKrish
    May 27 '14 at 17:51
2

Instagram uses a similar model. It shows UI updates prior to there actually being a server-side update.

http://www.fastcodesign.com/1669788/the-3-white-lies-behind-instagrams-lightning-speed

excerpt:

Instagram Always Pretends To Work

What Instagram labels as “optimistic actions” really boil down to something far simpler: Always make it look like the service is working, even when it’s not. In your Instagram feed, this idea plays out to the “like” button. Have you noticed that whenever you click it, even deep down in a subway, that like button lights up? If your connection is broken, of course you can’t upload the bits of data to a central server to inform a friend that their photo of last night’s dinner was simply divine. But registering the action gives positive feedback to the user. It’s a lie, sure, but it’s a white lie. No one gets hurt banging their heads in frustration, and the like can always be uploaded later.

Is it a good idea? I think it really depends on all the specifics of your situation. As you point out, if you get an alert about local storage, that's probably more annoying than a slight network lag.

Improve this answer
1
  • 1
    StackExchange does the same. UI is updated before the action is sent to the server. When you (or they) have networking problems the UI registers a vote and then comes up with an error message. Not sure whether the UI then corrects itself (I don't have networking problems that often) or whether it should - when the request was sent you don't know whether it was or was not handled correctly before you get a response back from the server, so "correcting" it when you don't get a response may even be "faulting" it...
    – Marjan Venema
    May 29 '14 at 10:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.