This is a screenshot my girlfriend took.
Freely translated, it says: "The system file is not suitable for MS-DOS or Microsoft Windows-applications. Choose Close to end program"
The file they're talking about is command.com.
The funny thing is, this popped up during an install of Microsoft XP Plus, which is apparently a valid windows-application that Windows can't run!

http://www.abandonia.com/forum/index.php?showtopic=2534

I see that problem so often I begin to be sick to talk about it.

Ah, I'll pass that link on. Thanks for the help, even though it was merely posted as humorous. here's another nice screenshot: 11111 posts!

First rule of good program design: Make your error messages telling. It doesn't matter whether this can be easily solved - the error message is pure nonsense.

I completely agree with you on this one Mr Creosote.

Most times error messages are very telling... for the developer...

I think this is more a psychological program. Software-Engineers neglect error-messages by nature, since they don't develeop their software to have any failures. Most times failure messages are built into programs, it is for debug-purpose.

And for interface-errors it should be impossible to get an error, due to the interface. For example, instead of getting "Write-Error! No Disk In Drive A:!", it should be impossible to give a write command, when there is not disk in drive a:.

Surely, creating a failure-immune interface is impossible, but not in mind of most self-sufficent software-engineers.

Edited by dregenrocks at 14:09 on March, 07th 2005

As logical as this may sound at first, I completely disagree. A program should always attempt to do what the user wants and not bully him and restrict his choices.

Don't get me wrong. I meant cutting out choices from the interface which give an error for 100% and nothing less, like the example shows.

I perfectly understood you, but I still disagree. I once had this discussion about about a frontend of CUPS. Some guy said it sucked, because it always showed all basic alternatives (local printer, network printer,...), no matter whether the computer even is connected to a network. His point of view was that it would be best to grey out all 'impossible' alternatives, i.e. if no print server was found running in the same network, a non-local option would be impossible to choose. Needless to say I disagreed, because what if I just want to switch on the print server later or even plug in the network cable later? I still want to be able to finish setting up the printer as it should be - because I do know better than the computer sometimes. Just an example, but I guess it should make my point clear...

But just from that moment, when you plug in/turn on the printer it's no more impossible to print with it. So, the perfect interface has to recognize this and to give you immediatelly the possibility to print on it (Plug & Play).

Of course, it's impossible to create a completely perfect interface, but it's still an important guideline and this is what I'm talking about in relation with the self-sufficent software-engineers.

Don't get me wrong - you're absolutely right that software developers still have a lot to learn when it comes to designing interfaces. See my initial post. However, this something can't be dumbing everything down until the user can't do anything but watch. Apple just loves this, and I hate them for it.