|
Rationale
I propose a new usability guideline:
* Show always an error message if something does not work
Backends must bequeath error messages to their frontends. (Exception handling)
Also error messages should be translated to other languages.
If I connect my computer with the network, it doesn't work and I don't know why, I'm disappointed. If I want to start an application and it doesn't, I'll want see the reason.
If someone tells me "I can't start my application", I want to know the reason to help this person.
Easy error messages like "You hadn't connect your computer with a network" or "This application isn't anymore installed" do help any user too. For difficult problems ("Your hardware with ID x is defect. Technical Notes:") you can call someone, who can read your error message.
There should be a option to send software errors to a bug database (launchpad). (e.g. syntax errors in python application, error in communication between frontend and backend can only be a bug and no user blame)
Another example: "No plugins found" in Quod Libet. Why?
Tags:
(none)
|
|
Propose your solution
Attachments
No attachments.
Duplicates
Comments
|
|
No one can be against such a proposal. However, its implementation may be tricky. In most cases, what you seem to expect is that software provide standard error messages. Unfortunately, this is almost impossible. This might be possible within Gnome applications for instance, but making sure that OpenOffice and the kernel send similar signals looks very, very difficult.
Another criticism of your idea can be that sometimes, the error message you get is the most precise possible, even if you are not satisfied with it. Let's say you want a software to open a file. The soft tries, and can't. The only thing the soft can say about it is "I am not able to open this file". Maybe the name is incorrect. Maybe the file does not exist anymore. Maybe the file exists but you are not allowed to access this file. Maybe your hard drive is dying and the file system is corrupted. All these errors would require very different reactions from the user. But all the soft can see is that it can't open the file, and it must react in the right way: either opening an Error window, opening a default file, running another program, proposing the list of recent files... All these things are software specific, and can hardly be handled by the system.
|
|
|
The Good - Yes it is a good idea to have a standard API across all applications for reporting errors in much detail as possible. Not just an error message but something more detailed.
The Bad - No it is not a good idea to always display an error when something goes wrong. Have you worked with Vista lately. The problem with a lot of error messages and popups and warnings is that you start to ignore them after a while and just click OK to continue. There needs to be a definite level of error and a way to switch of stupid warnings. Also there is no need to display an error if there is no user interaction required to reasonably fix an error. Also an error that just says OK to continue does not help at all and just dirties the desktop. There is several alternatives to indiscriminately displaying error dialogs and there needs to be a way to make it easier not more difficult for developers to provide appropriate information.
|
|
|
Arnaudus:
> Let's say you want a software to open a file. The soft tries, and can't. The only thing the soft can say about it is "I am not able to open this file". Maybe the name is incorrect. Maybe the file does not exist anymore. Maybe the file exists but you are not allowed to access this file. Maybe your hard drive is dying and the file system is corrupted. All these errors would require very different reactions from the user. But all the soft can see is that it can't open the file, and it must react in the right way: either opening an Error window, opening a default file, running another program, proposing the list of recent files... <
The software can see any error, the system does told the software. Backends must bequeath error messages to their frontends.
function open_file(path)
try
var file = new File(path);
catch(e)
alert(e);
/* Alert Output:
Error: the name is incorrect.
Error: the file does not exist.
Error: the file exists but you are not allowed to access this file.
Error: your hard drive is dying and the file system is corrupted.
*/
return file;
|
|
|
@natureflow: your post is a bit confusing because it's not clear whether you're describing a perfect world or if you're trying to illustrate what already exists. I agree that the kernel returns some informative messages; there are differences between "No such file or directory" and "permission denied" for instance. But often, the cause (and thus the solution) of the problem is unknown (for instance: the file does not exist: have you moved the file, have you deleted it, have you made a typo in the file name?).
In any case, the consequences of such an error are software specific. Some softs should do nothing (for instance, Nautilus should just do nothing in case it is unable to open an image for a preview, just display all other files in the directory), others should exit (Latex has to stop for instance because there is no point going on without input file), others (OpenOffice...) should display an error message etc. So I don't see how the environment (e.g. Gnome) could centralize and handle error events.
So, if the point is to propose "Display meaningful error messages and handle errors proprely" as a guideline for Gnome softwares, I fully agree. This should be the case for any software.
|
|
Yfrwlf
wrote on the 27 Sep 08 at 18:03
|
|
|
You're right, a program that encounters an error that is run in X should have that error message displayed in the GUI, and when run in a terminal have it displayed in the terminal and not in X.
If this requires making a fourth standard stream so be it, but I think just displaying anything from error stream 2 on the GUI would be fine.
Fortunately, users don't have to drop to the command line much anymore, but there are some instances where they do and one of the biggest is a program not doing anything whatsoever when a user runs it because the program encountered an error. This leaves the user feeling uneasy and it certainly isn't a helpful desktop system.
|
Post your comment
|
