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.
One that I see a lot in "unpolished" programs is when several error boxes pop up at once and you have to close them in a specific non-obvious order (presumably in a LIFO pattern, but that's not always obvious depending on how your window manager is setup to create new windows).
Also, I hate it when code is under-documented.
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.
-----
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.
If I could add, have an error number along with the error message. For example instead of having a box pop up saying "You can't do this here", have it say "Error: ABC1234: You can't do this here". It is much easier to search by the error number in the online help and on Google then by the text of the message. This goes double when you app is localized in different languages.
-- Remember: Wherever you go, there you are!
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
I've got to disagree with you there. A user sitting at a computer shouldn't have to know that XYZ Pro was originally developed for the Florp2000 platform and not the Shebang Station, and therefore uses Control-Meta-Z to frobnicate. All of the other applications on her Shebang Station use Alt-Z for that common function.
Ported programs should BE PORTED, NOT COPIED. Use whatever keystrokes are expected by the users of that environment.
Some programs commits an action on a load of documents/entities. Sometimes this takes time. IT happens.
So I just selected 9512 docs, and ran the script just before I went home in the expectation that it will be finished tomorrow morning when I come back because it takes 4 hours. Fair enough.
Now at doc #1273 there was an error. Your program has 5 choices:
a) Simply give up and crash/stop without telling me what you already finished.
b) Pop up a dialog box to inform me, stopping the process.
c) Mark the things that are finished and stop, so I can continue
d) Mark the things that are in error and do the rest anyhow.
e) Rollback ALL the changes (or better, give me choice AT THE END)
So which do you pick? Here is a tip.
a = very bad. If you do this, I hope you burn in hell.
b = bad. VERY few things anny me as much as a program that stops in the middle for an innocuaous pice of crap with a dialog box. Pop up the thing AFTER the fact (if it is now serius and ask me if you should continue).
c = Semi-annoying
d = Good.
e = Excellent.
if you really want to goto the deepest level of hell, throw away my selection for a) and b) while you are at it, too. Really smart.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
What an average slashdot reader wants in a program is completely different than the vast majority of computer users.
The majority of people on slashdot are programmers, unix administrators, and the like. These types of people usually want different things than most mainstream computer users.
If you're going to write opensource software, go ahead and follow their advice.
If your intention is to make money, take a look around and see what programs are making the most money. Say what you want about Microsoft and AOL, but you can't deny they make a shitload of money.
My best advice is this: Ignore everything you read on slashdot. Look at which software companies are making the most money, then try to determine why people are spending money for their programs.
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.