GNOME Bugzilla – Bug 532148
Display error messages in video area instead of pop-up dialogs
Last modified: 2009-05-08 21:21:49 UTC
If possible, applications should avoid dialog windows that have only an OK button. In Totem, one such window shows "Error occurred: Location not found. [OK]" The intention of such dialog windows is to alert the user to some information, such as an error. But they are annoying, as they interrupt the user and require her to dismiss them before continuing with her task. If feasible, Totem should display such messages in the video area. Other information:
This seems to be more a UI issue than a GStreamer backend issue.
Then I mis-categorized the report - sorry. But it is in the correct product category, right? I thought that GStreamer was the one issuing the error messages to the GUI, in which case it should just show the message itself.
(In reply to comment #0) > If possible, applications should avoid dialog windows that have only an OK > button. What says that? I can't find it when looking through the HIG. > In Totem, one such window shows "Error occurred: Location not found. > [OK]" The intention of such dialog windows is to alert the user to some > information, such as an error. But they are annoying, as they interrupt the > user and require her to dismiss them before continuing with her task. If > feasible, Totem should display such messages in the video area. I don't think there's any need to display this message in the video area, unless it was displayed when you were half-way through playing a playlist?
*** This bug has been marked as a duplicate of 303942 ***
> What says that? I can't find it when looking through the HIG. I had a quick look, and I can't find it either. In that case, it needs to be added. But the bug report is based on a well-established UI principle: remove unnecessary user interaction. The OK monolog is such an interaction because no user input is required for the system to continue working. There is no choice to be made. Totem can continue working if it can. If it can't (because the file input is corrupt or whatever), the user's clicking OK will not fix that. So the user's click is wasted in either case. Apart from the unnecessary effort to point the mouse or dismiss it with the keyboard, the dialog also interrupts the user's flow of work, their locus of attention. This is why, for example, Mozilla now makes an effort to display its error messages in the browser window. > I don't think there's any need to display this message in the video area, > unless it was displayed when you were half-way through playing a playlist? I don't understand what you mean here. I have explained why the message should not be displayed in a dialog box that needs to be manually dismissed, or one that obscures the video area. The video area seems to me the most obvious place to display it. Another option is
(In reply to comment #5) > I don't understand what you mean here. I have explained why the message should > not be displayed in a dialog box that needs to be manually dismissed, or one > that obscures the video area. The video area seems to me the most obvious place > to display it. Another option is If the error dialogue is popping up for a file which wasn't found when half-way through a playlist, that's fair game for being removed, and having Totem simply skip to the next file in the playlist while displaying an unobtrusive error message somewhere else. See bug #303942. However, if the error dialogue is popping up after the user has explicitly requested a single file be played, it would be madness to remove it. The user will expect _something_ to happen in response to loading a file; whether it be the file being loaded, or an error message appearing explaining why the file couldn't be loaded. In this case, a very obtrusive error message is wanted, and the current dialogue works fine. It would not be "interrupting the user's flow of work", since their flow of work is waiting on a file to load.