I have been using Miro for several years. So, it isn't that I was unfamiliar with the user interface. However, I am still bewildered that how did I remove all the TED videos I had downloaded instead of deleting the one sentimental video I intended to delete.
A major part of the problem was the poor response of Miro on the netbook. I had clicked the delete option on the video as it was playing. It did not seem to have worked. I deleted it from the video list and clicked on a menu option to confirm deletion. I clicked on the form several times as it did not seem to respond. I clicked multiple times because on the netbook, I often needed to click twice for Miro to queue my download request.
Since nothing seemed to be happening, I suspect that I must have clicked on remove podcast option absentmindedly. I am hoping that I had clicked on a confirmation screen after I clicked on remove podcast. It would have been a very unfortunate programming issue if one of my earlier clicks had been taken as a confirmation for the deletion of the podcast!
This is, obviously, nothing more than a minor 'disaster' or, more precisely, an irritation. It does raise the issue of how does the software UI behave in a sluggish environment. Can we code UI in such a way that the intentions of the user and their interpretation is not distorted by performance issues of the application?
We also need a better alternative to the confirmation screen. I doubt if anyone reads the confirmation screen before clicking after the first few times. So, how about a confirmation screen after the event with an UNDO button instead of an OK?
A major part of the problem was the poor response of Miro on the netbook. I had clicked the delete option on the video as it was playing. It did not seem to have worked. I deleted it from the video list and clicked on a menu option to confirm deletion. I clicked on the form several times as it did not seem to respond. I clicked multiple times because on the netbook, I often needed to click twice for Miro to queue my download request.
Since nothing seemed to be happening, I suspect that I must have clicked on remove podcast option absentmindedly. I am hoping that I had clicked on a confirmation screen after I clicked on remove podcast. It would have been a very unfortunate programming issue if one of my earlier clicks had been taken as a confirmation for the deletion of the podcast!
This is, obviously, nothing more than a minor 'disaster' or, more precisely, an irritation. It does raise the issue of how does the software UI behave in a sluggish environment. Can we code UI in such a way that the intentions of the user and their interpretation is not distorted by performance issues of the application?
We also need a better alternative to the confirmation screen. I doubt if anyone reads the confirmation screen before clicking after the first few times. So, how about a confirmation screen after the event with an UNDO button instead of an OK?
No comments:
Post a Comment