Especially @pginer, but others can chime in -
The disable/enable dialog is coming, but we need to be able to display errors. Is there a decent way to show errors in the dialog(s)? Do we need a new design for that? I don't think there's any particularly prevalent error we need to worry about, but I'd rather not get caught without info when people do get errors for whatever reason.
Thanks,
Hi Mark,
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?
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.
Pau
On Thu, Oct 16, 2014 at 4:46 PM, Mark Holmquist mtraceur@member.fsf.org wrote:
Especially @pginer, but others can chime in -
The disable/enable dialog is coming, but we need to be able to display errors. Is there a decent way to show errors in the dialog(s)? Do we need a new design for that? I don't think there's any particularly prevalent error we need to worry about, but I'd rather not get caught without info when people do get errors for whatever reason.
Thanks,
-- Mark Holmquist Software Engineer, Multimedia Wikimedia Foundation mtraceur@member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJUP9pNAAoJEEPl+wghkjzxhPwQAKYvUkg4x1BRvnHCmTb++EDB asTMGNcGrgCLZRXG6l/49n/85lcIbYSVEOl9P86aCSNFvkuphfcmj/PZkXpx9bNq wZboSCLkGqVI1RDuORvRs9H8DnpYSIs2IPG7HXKX7ToGjDQTrGwb6JjoH+qGBblC aXa57+grK4IK/R4ArcySr594XFep9Un4Cw4MmHubon6ETj5mw+KzgpVek61FJorz kupzO2aObKXytodG/Qc6JaOV/yWcjAfsRNE007cUlVJGmGq9TCjAqxVs6euJ0kyQ XGZrGpi23eY7itPetRJegM7xQd9Oj2oskzhK37Qy0RzGrzVmhj/6b6aQN6asnIsg p0L9c6DRdKN6ttAoe4SxczXpE3lYb4vEeShLPlpnF9JUOGRfYyZi5MiqrKo1Rsj6 WJw8wPSjxY+TR05K4umlX1TEd7aMMYDux5qi96tWVVhesml47sL9pxT/j/Q6sh8E ijkZ/zw4wzUZLgsFYqM2IO3nQ8McwY6gxmfpVtayek5CZT8/Fv2dmzPVDjC2M8vp e8tDi7rKcrIdJ453CFESX20gV0xQNe5Sgg5o8Q5AO3RUbOzajT4BhAECSRFdjVTT eioH+/zrt6JzQmFMERIpaHyvZVTYCOaA1OnVUa5clprRdJ14lQE/juuJPfOhT/4q 5hcJvg70gr8zdGMSACbS =Cxzc -----END PGP SIGNATURE-----
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
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.
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.
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: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
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
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
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.
Would it be possible to make the standard notification bubbles to be visible while Media Viewer is open (e.g., moving or adjusting the style of the .mw-notification-area element)? I think it is better to reuse our standard methods of communication when possible.
FYI, I created this ticket for this issue, so we can update it together:
I added an initial mockup and notes. Regarding where to direct users to I would not just redirect them to the FAQ unless there is a specific question about the current issue (in which case we should link to that section). In general, we may want to link to a place where users can report their issues (talk page ? phabricator?)
Pau
multimedia@lists.wikimedia.org