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 fflorin@wikimedia.org 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 ward@c2.com 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 gtisza@wikimedia.org wrote:
I think there are four groups of errors, based on what the user can do about it:
intermittent errors in the AJAX request (network errors, server being busy)
bugs
session timeout - user needs to log in again
localstorage errors (strict security settings or quota exceeded, or even no localstorage support at all)
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 Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
On Oct 16, 2014, at 8:23 AM, Mark Holmquist mtraceur@member.fsf.org 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 mtraceur@member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist _______________________________________________ Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Fabrice Florin Product Manager, Multimedia Wikimedia Foundation
_______________________________
Fabrice Florin Product Manager, Multimedia Wikimedia Foundation