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

Pet Peeves/requests of an HCI designer

[base3]

1. There should be a way to do anything with your hands on the keyboard whenever possible.
2. The Escape key should always do just that.
3. If the app is going to try to hold my hand, give me the option to turn it off.
4. If it's a Windows app, follow the darned CUA guidelines !
5. If there's an operation that's going to take a long time, give me a progress indicator.
6. But if you're going to give me a progress indicator, make it mean something--don't let it move across like the progress bar on MSIE when it can't connect to a site.

I'm sure there are about a hundred more that I can't think of this early in the morning. Good luck!

Standard widgets / UI elements

[Jon Peterson]

Contrary to what some people think, it is not clever or funny to funky new widgets and dialogs in place of standard ones. Does the standard windows file->open dialog need improving? Maybe. Are you the one to do it? No.

Other peeves include:

Not having tooltips. Tooltips are good. Use them. Everywhere.

Useless error messages. I know it's a pain but there's nothing worse than a regularly re-produceable error state that gives no information.

Useless help files. If you don't have time to create help documentation, then don't bother to do any. It's a waste of user time looking though unhelpful help files.

I'd re-iterate what others have said about progress bars. I'd also add:

* Threading. Be able to do two things at once. I don't care what the app is calculating, I should still be able to move the window and have it re-paint properly at all times.

* Interruption. I should be able to cancel anything the app is doing. I hate waiting around for an app to timeout on some operation.

Tips from the Marquis de Sade School of HCI

[alecto]

You know better than your users. Include lots of wizards and bots to guide them. Don't allow them to disable them--it's for their own good.

If your program had been doing something in the background and was minimized or covered, be sure and let the user know it's finished by popping up! If this can be accomplished while the user is in mid sentence in a document or an IM, so much the better. The user paid good money for your application--you should be letting him know he got his money's worth!

When performing processor intensive operations, don't waste cycles telling the user what's going on. To an astute user, the wait cursor is more than sufficient--if he has so little faith in you that he thinks your application is locked up, fie on him.

Never repaint the screen while performing processor intensive operations--once again, performing repaints requested by the operating system interferes with the arduous task at hand for the application.

If your application is a game, be sure and use keys that are near the hotkeys for the operating system. For example, an ideal Windows game would use Alt for fire and Tab for missiles. Other combinations are left as an exercise for the reader.

If you write more than one application, be sure that the as few keyboard shortcuts as possible are the same between applications. Even better: take an innocuous, commonly used keyboard shortcut in one of your apps, and make it do something potentially dangerous in the other. For example, our alumni at Microsoft wrote Word to use Ctrl-Enter for a page break. In Outlook, when typing a message, this sends it immediately. If a user was typing a rant to his boss, he should have thought of that before putting venom in his draft email!

If yours is a web application, be sure the "Back" button never operates.

If a user fills out a form and it doesn't pass your rigorous validation checks, return him to the form and ensure that none of the entries he typed are filled in. If he made a mistake in the one you caught, who knows what other mistakes are in there? Can't be too careful!

When validating a form, once you catch an error, report it and make the user fill it out again. There's no value in pointing out all the failed edits, since you're going to clear the form for him anyway, right?

Next week's lesson: Desigining effective product upgrade notification dialogs.

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.