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--

Re:windows registry - why and why not

[CharlieG]

I appreciate your 'Old fashioned'ness, but I'll tell you why most apps use the registry:

Because back in 1995, Microsoft said "Stop Using INI files if you want to be compliant" People went along

I use a mix. The is ONE advantage to the registry - if your company uses roving profiles, it allows your settings to follow you - this is nice, but other than that, I agree use INI files

Alt-Esc: a better Alt-Tab

[xdc]

• 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)

In Windows, use Alt-Esc to switch between all windows, including properties dialogs and other windows normally ignored by Alt-Tab.

Still, I totally agree with your suggestion. I find it really irritating when a program seems to have hung, and it turns out that it had merely popped a dialog box underneath all of the open windows.

My personal preferences:

[mfarah]

IMNAAHO, a good application must:

• if it has a basic user mode, then it MUST have a power-user mode. I hate it when an app won't let me do what I want, forcing me instead through stupid menus.
  
  
• Configuration files are GOOD. For a user who groks the app, it's much quicker to edit the .CFG (.ini, rc, whatever) than having to go to the configuration menu/window. Let him do so if he so wishes. Configuration files should be properly commented, too.
  
  
• On-the-fly reconfiguration. This heavily depends on the type of app, but as few options as possible should require restarting.
  
  
• Take the pain to write a GOOD help section. Windows apps, for example, have a well organized help system, with perfectly useless content. Have
  some friends that know nothing of the app come by and try it, and record whatever they ask. Have some power-users come, grok the app, and THEN record whatever they ask. Meaty help, please.
  
  
• An app should do whatever it's supposed to do, and interface properly with other apps that do other stuff instead of trying to do it itself. For example, tin (the Usenet news client) doesn't have an internal text editor, but rather invokes your editor of choice (vi, EMACS, TSE, whatever). Bloat is bad.
  
  
• Batch mode is good. Let me use an actual example: I once had to convert 300+ files from .GIF to .PNG. With an interactive app, this takes more or less 30 seconds of user input for EACH file, and it would have been tiring as hell. Instead, I decided to use some Unix utilites (gif2ppm, ppm2xpm and xpm2png in a chain), took some minutes writing a shell script to process each file, and left the job on its own while I got to do other stuff... and it took less overall time.
  
  
• If you port your app to different OSs, they MUST behave in the same way in each system (obviously there's a limit held by an OS ability to do something). For example, "save file" can't be F2 in Windows and CTRL-S in Unix.
  
  
• If yor app contains an internal scripting language or something like that, document the source and let the users access it. (The TSE editor is a great example of this).
  
  
• If your app contains a lot of internal power (usually this is the case for apps with an internal scripting language), an internal command line sometimes helps solve easily some tasks. I kid you not.
  
  
• Organize the app's files neatly into subdirectories. Having to search for a saved document in a 500+ files directory, especially when you don't know the exact name of the file, and there are internal ones that could be them, too, isn't pretty. A "saved documents" directory is good.
  
  

That's all I can think of for now.

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.

Re:Standard widgets / UI elements

[Kris_J]

Interruption. I should be able to cancel anything the app is doing.

I'll even be more specific. If you have a cancel button, make sure it works, and quickly. There are few things in the computing world more annoying than a cancel button that doesn't do anything.

Re:Pet Peeves/requests of an HCI designer

[dstone]

The Escape key should always do just that.

I'm pretty sure "Escape" means "begin an escape sequence" (ie, ASC 27 xx xx xx). While we're on the topic of legacy key names though...

The Return key doesn't return anywhere.
The Scroll Lock key doesn't prevent scrolling.
The Break key doesn't break.
The Print Screen key doesn't print.

We forget about those crazy, legacy key names and ignore them, but I'm always impressed how new users gravitate towards them and (reasonably) expect big results!