FYI, I created this ticket for this issue, so we can update it together: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/953
It’s in this current cycle, and marked as ‘design needed’. Cheers, Fabrice On Oct 16, 2014, at 8:58 AM, Fabrice Florin <[email protected]> wrote: > 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) > > > _______________________________ 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
