Timeline for What's the longest acceptable delay before an interaction starts to feel unnatural/requires an error message?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 18, 2015 at 13:53 | history | bounty ended | CommunityBot | ||
| Aug 18, 2015 at 11:41 | comment | added | finiteattention | Absolutely agree with all of this — wherever possible we should strive to make it not the user's problem. Really what I am trying to understand is how to cope with error states where it is likely that the error state will continue (API unavailable, etc). I'm nervous about loading too much of this onto the client; users may lose a lot of work if the client cannot sync for a long while, but is giving no feedback about this to the user, so they carry on working. It's a cross-platform service so they expect changes to stay up to date and follow them around (e.g. onto mobile). | |
| Aug 12, 2015 at 18:54 | history | edited | Daniel De Laney | CC BY-SA 3.0 |
added 20 characters in body
|
| Aug 10, 2015 at 20:07 | history | edited | Daniel De Laney | CC BY-SA 3.0 |
deleted 65 characters in body
|
| Aug 10, 2015 at 20:00 | comment | added | nightning | "But he shouldn’t have to re-draw anything, the system attempt to re-send." That statement is key. Drawing for the user isn't about making a connection between point A to point B. It's about putting ink/color on a canvas to depict something. A system that stops the user between strokes is interfering with the drawing process. It's a much better experience to implement a "syncing" vs "up-to-date" indicator like how Google Docs/Sheets does. Only if a catastrophic error happens should the system regretfully inform the user that their data is lost. | |
| Aug 10, 2015 at 19:57 | history | edited | Daniel De Laney | CC BY-SA 3.0 |
deleted 124 characters in body
|
| Aug 10, 2015 at 19:45 | history | edited | Daniel De Laney | CC BY-SA 3.0 |
added 438 characters in body
|
| Aug 10, 2015 at 19:33 | history | answered | Daniel De Laney | CC BY-SA 3.0 |