Computing Pet Peeves?

Matthaeus asks: "I'm a 3rd-year CS student who will most likely be writing end-user applications after graduation. Naturally, I would like my apps to sell well, so I want to minimize user annoyance as much as possible. In an effort to improve my coding skills, what are Slashdot readers' biggest pet peeves when it comes to software? For example, my largest pet peeve is when a program steals the focus from another program while I'm typing. Maybe other software developers could take notice of this discussion also."

Comments

Computing pet peeves

[ka9dgx]

• When the program thinks its smarter than I am, and trys to keep me from doing things that I want because it knows better. (This is a vague nonspecific emotion thing, but it tops my list)
• Modes... never use modes if you can avoid it
• Windows applications that pop up a dialog box that gets lost behind windows.... thus inadvertently creating a mode that you can't get out of (because alt-tab can't get you there)
• If you offer resizable windows... try them out at at LEAST 1600x1200 pixels, and make sure they still use the screen space.
• An application shouldn't need an install program... you should be able to copy the files to a new folder, and the first time it runs, it should just work... no registry crap, etc.
• Don't put any DLL files anywhere else on the system, it's not bloat to keep your own DLLs, it's safer these days.
• Copying a program's directory should allow you to move a program from one computer to another, with all options intact.
• You should be able to operate the program with just the keyboard. A possible exception for paint programs.
• Make sure the tab order is the same as the visual order on the display.
• Context sensitive help should not merely repeat the error message, it should explain the issue.

There's more... but it's time for work.
--Mike--

Interface Hall of Shame

[Masem]

If you haven't already visited it, please go and bookmark The Interface Hall of Shame. While it's unfortunate that they've not really added much to it, leaving most of their examples of programs that tried to bridge the GUI changed between 3.1 and 95, many of the examples of bad component use, dialog use, and error messages are certainly valid.

And another tip that I've not yet seen posted - Always always have people beta test the interface for you, without supplying them help files or the like (making sure these people are sufficiently computer-experienced as to not make 'what's a right-click?' type statements). If possible watch them and take notes, or better, videotape them to review them. An excellent GUI will require no additional help files in order to understand, such that any help that is actually included would be supplimentary to understanding the more advanced features. (Of course, this does not mean to use Wizards for anything. GUIs should have minimal text on the screen to start).

And also, never hard-code the colors for window/dialog backgrounds, fonts, or the like. I know of people that don't use the default grey for window or black text, and it's amazing how many programs are unusable because they try to draw (fixed) black text on (user-selected) black backgrounds. I know Win32, Classic MacOS (and would expect OSX to have it too), and both KDE and GNOME have the appropriate hooks that you can grab what the user-selected color scheme is instead of fixing it to your own colors.