Thank you all for bringing this up! For now, my recommendation would be to provide a way to report errors, and include a link to our FAQ, where we could recommend actions the user could take about them.
Pau, could you please investigate a design solution for reporting such errors? It seems reasonable to let people know when something goes wrong, and what they can do about it. Thanks, Fabrice On Oct 16, 2014, at 8:38 AM, Ward Cunningham <[email protected]> wrote: > Without being fully aware of the issues here I will suggest that expired > sessions is only the beginning of what can go wrong. We've been hunting > "Unexpected Network Change" errors only to find that it is a chronic problem > that depends on many layers of dynamic behavior beneath the ajax call. > > https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/433 > https://code.google.com/p/chromium/issues/detail?id=166593 On Oct 16, 2014, at 8:37 AM, Gergo Tisza <[email protected]> wrote: > I think there are four groups of errors, based on what the user can do about > it: > > 1. intermittent errors in the AJAX request (network errors, server being busy) > 2. bugs > 3. session timeout - user needs to log in again > 4. localstorage errors (strict security settings or quota exceeded, or even > no localstorage support at all) > > 1. and 2. could be covered by something like "there was an error, please > retry and report it if it persists". 3. is very rare and will cease to be at > the next page load so it's probably OK to ignore it. > > I'm not sure about 4 - that's something that needs user intervention, and a > source of complaints (there have been reports that it is impossible for anons > to disable Media Viewer, which I suppose is caused by this). Localstorage > settings are a poweruser feature though, not sure how to communicate about > them. > _______________________________________________ > Multimedia mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/multimedia On Oct 16, 2014, at 8:23 AM, Mark Holmquist <[email protected]> wrote: > On Thu, Oct 16, 2014 at 05:09:15PM +0200, Pau Giner wrote: >> If there can be an error we need to be prepared to deal with it. >> For designing a proper solution I need some more information. Which kinds >> of errors can be produced and at which point of the workflow? Is there a >> way to solve them without user intervention? Is there some information we >> can provide to help the user to solve them? Will retrying later be a likely >> way to solve the issue? > > I think the only *expected* problem we can have will be expired session. > We'd need to load the page while logged in, then have it open for many > days (30?), then the user tries to disable the viewer. That would cause > a token error (like we've seen in UploadWizard) and the user would need > to log in again. > > Unexpected errors include bugs in how we construct the request, bugs in > the API, network errors based on the user loading a page and disconnecting, > but we can usually get a sane message from any of those errors automatically. > >> From the process of disabling, the only error point I can imagine is >> clicking on the "disable/enable" button and the action not taking effect >> because the place where we store such info fails to do so (I don't know if >> that is an external server). For this kind of error, we can just inform >> using a standard MediaWiki notification bubble with some message along the >> lines of "It was not possible to disable Media Viewer due to some technical >> difficulties. Please try again later." and keep the panel opened so that >> the user can try again. In any case, we should not show the confirmation >> popup if the action had no effect. In any case, I'm making here some >> assumptions since I don't know the internals of the process. > > This means not getting any additional details from users who report the > issue - inferior to our current error reporting, which gives us some > error message along with the failure notification. > > A standard mw.notify bubble wouldn't work, though - the reason we're > thinking about this at all is that the disable dialog is overlapping the > notifications as it is. > > -- > Mark Holmquist > Software Engineer, Multimedia > Wikimedia Foundation > [email protected] > https://wikimediafoundation.org/wiki/User:MHolmquist > _______________________________________________ > Multimedia mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/multimedia _______________________________ Fabrice Florin Product Manager, Multimedia Wikimedia Foundation https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
_______________________________________________ Multimedia mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/multimedia
