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."
Everytime i learn a new software package, I invariably get to the point where I did what I wanted, but then wonder to myself, "Self? How did I do that?!!!" Have an option to log all mouse clicks, keystrokes, informative output, errors, and anything else that may help the user recreate what has been done.
A seperate program than analyzed this log file and returned an optimized log (how the user could do it better/faster/smarter) would be brilliant.
The masses are the crack whores of religion.
Hell, I love this thread.
Netscape has this horrible habit of hanging ALL the open windows when ONE of them has problems with a TCP connection. This is because the windows share the event loop as far as I know. This is dumb. I think Galeon is the only browser that does this right, and you have to switch the behaviour on. (Someone correct me please).
Another peeve: Programs are sometimes like annoying marketing types who think they own you. I am a customer and I will bloody well do what I want on my machines, so deal with it.
Intrusive programs that install things in my Windows taskbar that pops up every 5 minute to ask for an update and (God forbid) install themselves as a taskbar on my desktop. (Hello, someone at Creative Labs!! Are you reading this???)
The same goes for programs (Hello, Apple Quicktime!) that simply assumes that it is now the default handler for GIF, PNG, BMP and everything else in the universe, just because it can vaguely handle it (after asking me EVERY time if I want to upgrade to the "pro" version. NO I DONT. SO FSCKOFF NOW).
To put in simple terms, MY DESKTOP DOES NOT BELONG TO YOU; AND I DO NOT THINK YOUR "!" PROGRAM IS THE END-ALL AND BE ALL OF EVERYTHING IN THE UNIVERSE.
Programs that send out info over the net without my permission. MY DATA DOES NOT BELONG TO YOU EITHER!
Capitalism is about the strong surviving. It is also about the weak going down and I fully intend to help the system by voting with my feet against programs that are written by power-hungry marketing types who want to take over my machine.
More rants: Games that do not let me change the keyboard mappings. I live in Germany, where the keyboard is weird. I like my games in English. I will happily remap my bloody keys, but please MAY I? And on a Jerry keyboard the a key is NOT above the z key!
And while we are on the subject, if you are going to do 3 language version of your program, just put ALL of them on the SAME CD from now on? Please? Few programs are so large that the multi-language stuff does not fit (possibly recorded speech in Games, I will give them that). I don't want to import all my games, and there are many expats here who like to play in good ol' Eengleesh.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
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?
In one project I worked on, there was this homemade progress bar which would update about 4 times over the course of connecting to a piece of hardware (which took about 15 sec.). Since it only updated a few times, there were several times over the course of these 15 seconds where nothing would appear to be happening (keep in mind, a wait of just a few seconds can seem very long and be very distracting, especially if it is something you are doing repetetively). Since it was connecting to external hardware, every time the progress bar would stop moving, you would reflexively think, "did it stop because of an error, or is it still connecting?"
I got really annoyed with this progress bar, especially since I had to do about a million connects to verify my fixes, so I threw in enough extra updates to the progress bar that it kept on moving the whole time you were connecting.
Boy, were the customers impressed! I got a bunch of calls about how much faster and more reliably the software was connecting to the hardware. Of course, it wasn't connecting any faster, and this was before I had fixed any real connection bugs, so it wasn't connecting more often, either. It is just that when it was working, you knew it was working, and when it failed, it stopped right away.
The lesson I got from it is that user feedback is what creates the user's perception of what is going on. If a progress bar keeps stalling, the user's intuition is that the program is having some sort of trouble completing the task.
Why is Grand Theft Auto a much more serious crime than Reckless Driving?
I love that in Linux I have a choice. For CD-Burning, I can use a bloated GUI app (I like Gtoaster), or I can use the command line. I can copy a cd the same way: /dev/cdrom > win2k.iso
cat
and then burn it just as easily
cdrecord -speed=12 win2k.iso
How easy is that???
I also found a new favorite way to play cds or MP3s,
I can use
mpg123 --random *.mp3
to play every MP3 I have in that directory
or I use
cdcd to play a cd.
I have a CHOICE in using a Command Line OR a GUI.
If you're not a Liberal in your 20's, then you have no heart.If you're still a Liberal in your 30's you have no brain.