Slashdot Mirror
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."
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!
One CPU cycle wasted on digital restrictions management is ONE TOO MANY.
call me old fashioned, but i hate it when programs use the windows registry- especially the "small" gimmicky ones that i'm probably going to delete in a month anyway. IMO, unless you write a program that depends heavily on the registry, use an .ini file instead. it makes the program easier to uninstall and makes windows overall less bloaty while you run it.
Somewhere on this page I have hidden my signature.
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.
-----
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.
- 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--
But whenever you add functionality to a program, ask yourself the question: "Could this be thought to be even remotely useful for someone to use from a shell script?" If the answer to that question is "yes", then make it available from the command-line as well. An example of software that really doesn't follow this guideline is most installation programs. Most sysadmins do not appreciate sitting in front of 10's or 100's of computers pushing "Next" and "Finish".
Secondly, follow GUI-guidelines wherever you can. Winamp (and most other mp3-players) are completely ridiculous. A gui built for usability would have larger buttons, standard focus mechanisms, less distracting eye-candy, etc...
Third, document your program, and not just for the beginner. It's when you want to see if the program can really help you with some esoteric stuff that you really need documentation.
Fourth, and most importantly: Make sure your programs do something useful. The world doesn't need another Visual Basic CD-player. Personally I need efficient theorem-provers, but that is kind of a hard problem to solve. But even simple things can have remarkable usefullness, e.g. the first visual text-editor/wordprocessor, spreadsheet, web-browser, etc... I believe there is still room for innovation.
I frequently use this one piece of software that has arbitrary filters on what it allows you to do.
... if you violate one of the software's rules then the error message that appears calls the user 'lame'
It has two main modes - a read mode and a write mode. Read mode is okay, the information is presented in a very configurable way which allows you sort, index and filter with the methods of your choosing.
Write mode is much annoying. There a minor peeves such as one of the text entry fields being too small and the options in a drop-down list are under-documented. There are also the artificial filters that I mentioned earlier which prevent many users from entering the data that they need or would like to.
For example, there is a limit on the input rate - only one block of data can be entered per 2 minute time interval. Even more annoying than this are the filters on what information can be entered. The main form of input is arbitrary English text - often in the context of computing, other technology and legal/ethical issues; yet it is difficult to enter highly formatted and structured text such as source code or bulleted lists of observations because this text can easily not conform to per-configured limits on the amount of whitespace, capitalisation and line length.
A final pet-peeve is insulting error messages; when users do something wrong it is due to ignorance with the system they're using or an honest mistake. It has long been realised that insulting users by blaming them is a bad thing to do; "You have chosen an invalid file" should be replaced with something like "That filename cannot be used because it is too long. Please reduce the length to less than 50 characters".
This final peeve applies to the software described above as well
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.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
Also, programs jumping to the front 50 times while they are starting up is really annoying. For a good laugh, start Word and VC++ at the same time and watch how many times they pull the "my splash screen is on top, "no, MY splash screen is on top" crap. If I start VC++ and then start another program right afterwords, I want to use the second program until I explicitly switch away. I do not want VC++ deciding that I need to see every step of startup - "Oops, the user has switched to another app, but never got to see me update this toolbar - better jump to the front, even though I am only 12% done starting up!"
Some other things:
1.) Favor self documenting code over separate comments when possible. Comments need to be maintained separately from code. Self documenting code does not get out of sync with the documentation, and is readable anywhere you use it. For example, if you are writing a function which converts an audio frequency to a wavelength, instead of calling the function CnvtFreqToWaveLen(), and documenting the fact that it takes KHz and returns inches, call it CnvtKHzToInches(). This way, any user of the function knows in what format to supply the input and in what format the return value will be, without relying on the docs being up to date.
2.) Try to construct your variable and function names such that your code reads like English. Rather than "if(hardwareInstalledFlag)" which does not tell you the meaning of the two states of the flag, use "if(hardwareInstalled)" and make sure that hardwareInstalled is TRUE if the hardware is installed. There are few things more annoying than something like runningFlag, where 0 means running and 1 means not running. If that is the case, call it hwNotRunning so you can say, "if(hwNotRunning)".
3.) Write stable code. The common myth that software is too complex to be truly stable is total BS. We have had extremely complex systems running out in the field for several years without a power cycle. Always check your assumptions (the hardest part can be identifying the assumptions you are making). If you find yourself saying that X or Y can never occur, then test for it.
4.) Never assume that the software understands the situation better than the user. MS Word's assumption that it understands the English language better than you possibly could is one of the worst examples (I used to work at Orban - Word 97 by default would silently fix any occurances of "Orban" behind your back with NO confirmation, and change them to what you OBVIOUSLY meant to type, "organ"). Something MS does not understand is that I am the user, and I may happen to decide that I WANT to start a sentence with a lowercase letter ("cvGetStub() is a function which...."). I should not have to be an expert at reconfiguring Word just to get it to allow me to decide what I want to type.
5.) Write self teaching programs. Instead of "Could not complete the requested operation," have your dialog explain what was missing, like, "one or more tracks must be enabled for RECORD in order to enter RECORD mode."
6.) Use descriptive variable names. Even most uses of 'i' in a 'for' loop are inapropriate. Instead of 'i', call it what it is, like dbRecordNum, rather than relying on the context ("oh, this loops maxDbRecordNum times, therefore 'i' must be the record index").
7.) Don't blame the user for your bugs. Never come across as condescending, as you do not know the context in which a message is actually going to be displayed. When the user can see that they are clearly running into a bug, but the software is chastising them for doing something wrong, that is very annoying. Dave Barry talks about the ScanDisk startup message in this context. "To avoid seeing this message in the future, behave, stupid user," is really annoying when you know that the problem was directly caused by the mistakes of the same programmers who are now blaming you. Sarcastically, it should read, "to avoid seeing this message in the future, run an OS which does not arbitrarily crash after having write-cached a bunch of crap that it never bothered to write back to the hard drive." Realistically, "This error could have been caused by turning off the computer without shutting down properly, or the system may have become too unstable to shut down properly."
8.) Use the mouse cursor CONSISTENTLY to tell the user about the state of the app. If you have a mouse arrow, the program should respond to your input. If you have an hourglass cursor, the program should ignore your input, not save it up to deluge the system with when it becomes un-busy. If the program is processing user input while performing some other task (therefore it is honoring your input, but may not get to processing it right away), there is a pointer/hourglass cursor that says just that.
9.) In general, get the user feedback right. This lets the user know that he really clicked the button that he thought he did, etc.. Don't mix control and status in general (some exceptions). It should be obvious which screen elements are used to do something, and which are used to report feedback.
10.) Do not try to maintain multiple copies of the same state information; for example, if you have a dialog box with 10 settings, don't maintain the state of the dialog elements as one thing, and the state of the internal settings as another. Always maintain a master copy of the state and update everybody who cares from that. So when you open the dialog, you don't display the last state of the dialog, you recalculate the state of the dialog from the master state of the program. So if you are maintaining a field in a dialog which contains a username: a) when opening the dialog, update username from the master state. Do not try to keep the dialog state in sync with the master state as you go. b) when closing the dialog, update the master state from the contents of the dialog. c) When the username changes (as a result of the dialog or anything else), perform the appropriate action to respond to it. d) When your program needs username, get it from the master state.
Enough rambling for now....
Why is Grand Theft Auto a much more serious crime than Reckless Driving?
Do not steal the focus, neither on startup nor for any sort of dialog box.
Respect my preferences. I do not have the default gray color scheme, so do not hardcode gray as your icon/toolbar/dialog background color, etc. Also recognise that I might have the taskbar docked on the lefthand side. I run across programs all the time that think that if they pop up a window at (1,1) it will be visible since the task bar is at the bottom of the screen.
Do not go against the sound effects or window animations that I have configured. I have some sound effects enabled, some disabled. Some people have no speakers or are at work and have sounds disabled. Same thing for window animation. I have most of it disabled, so don't assume that I enjoy those stupid animated "unrolling" menus.
Remember the window position/size and always open to the last state. I hate apps that are too dumb and must be resized/moved each time they are started. Usually this is related to the prior point about not having the standard windoze explorer configuration.
Do not use any pauses. Don't pop up an error window for 3 seconds (with no ability to make it go away) or some such nonsense.
Avoide the splash screen at startup. DO include a useful version number in the About dialog, with contact info and a website for updates. Avoid auto-detecting updates unless you are clear and upfront with the user before going out to the network.
Any time you report a filename in a panel or status display, please test your app with long filenames or filenames with multiple spaces. Often when processing files that reside in the "My Documents" folder, programs will try to report the filename but only output "C:\Documents and" when the file was really named "C:\Documents and Settings\Administrator.BOOCH\My Documents\Recorded Shows\file.avi". A related point, if you must abbreviate filenames to fit in a limited space, consider only showing the trailing bits (i.e. the actual filename and as much path as can fit) rather than the other way around, showing the higher level directories first and cutting off the subdirectories and filename.
Don't include the runtime if at all possible. I always respect a 500k install package over a 4MB one. Don't put any "common files" in my system32 directory if you can avoid it.
Use an intelligent installer. I want the program's directory completely removed when I uninstall, not left empty or with some small derelict file that the installer didn't know about. Same deal with the registry. Don't leave an empty key when your program uninstalls. I will disagree with other posters here, there's absolutely nothing wrong with using the registry intelligently.
I should not have to reboot to use your application, unless there are very special circumstances. Win2k is pretty good about this, actually. And for all that is holy, DO NOT make an installer that forces a reboot as the last step.
Tell the user what's going to be changed during installation, and give him or her a choice. The default for icons should be a directory under Programs in the start menu. DO NOT install an icon on my desktop or in my quick-launch bar without asking. DO NOT put your app directly on the start menu "root" menu.
Default install location should be Program Files, not a random directory off the root (like C:\MyApp) but in any case it should be presented as an option during install.
Do not add anything to my startup without asking. If I like your program and want it to run automatically at boot then I will either use a checkbox in your config screen or I will put a shortcut in the startup folder.
Don't litter my temp directory. Delete whatever temporary stuff you create.