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

Cookies

[redcliffe]

Not so much a part of programming, but cookies on websites that have no legitimate reasons to use them annoys me a lot.

Re:Cookies

[jbn-o]

Same for me with Java(script), ActiveX, and any other such thing (this list does not include https—https is often a valid choice). Most sites don't need the Javascript they employ. Most sites don't need graphics at all. Most sites don't validate their markup. Most sites use markup to suggest layout (rather than using CSS). This is why I browse with textual browsers (links and lynx) whenever I can. When I can't, I use Mozilla with Java and Javascript turned off. I avoid a lot of hassle and insecure Java(script) implementations all at the same time. If I can't access the site, there's a good chance another better site will give me the functionality or data I'm looking for.

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!

Re:Pet Peeves/requests of an HCI designer

[leviramsey]

There should be a way to do anything with your hands on the keyboard whenever possible.

How could you watch pr0n if both of your hands were on the keyboard? Answer me that!?

Re:Pet Peeves/requests of an HCI designer

[Cuthalion]

I want a progress bar, and I want it to be accurate

You can't always. Sorry. Your example illustrates why, even. MSIE doesn't know how long connecting to a web site and downloading a page is going to take. Neither does Netscape or Opera. that's why none of these have an accurate thermometer bar as a progress indicator. They do have a 'I'm still doing something' animation, though. Which is about as good as you're going to get for some tasks.

Re:Pet Peeves/requests of an HCI designer

[Anonymous Coward]

"You can't always. Sorry."

You could do better than most MS apps do. For example, try copying a bunch of stuff over the network using Explorer --
"2 Minutes remaining"
(come back 5 minutes later) "30 seconds remaining"
(wait 60 seconds) "10 seconds remaining".

It does this Every Fucking Time!

Furthermore, the progress bar looks like it's based on file count rather than file size. And the stupid flying paper animation runs even if you pull out the network cable and the copy has hung, implying that something is happening when it isn't.

And these guys actually supposedly pay good money for HCI designers!

Re:Pet Peeves/requests of an HCI designer

[sharkey]

Opera has a progress bar that's pretty accurate. It doesn't use time as it's measurement, it uses the percentage on the requested page loading, as best it can tell.

Re:Pet Peeves/requests of an HCI designer

[mph]

The issue was connecting to a server, not receiving the page from it.

Re:Pet Peeves/requests of an HCI designer

[Kris_J]

I always assumed that while trying to connect, the progress bar showed you how long you had before a timeout.

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!

Re:Pet Peeves/requests of an HCI designer

[Ayende Rahien]

Well, maybe it's because it's an I/O issue, and, especially on networks, that isn't something that you can accurately predict?

windows registry

[fist_187]

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.

Re:windows registry

[dietz]

Well, not always...?

PuTTY, a free ssh client for windows, is a single file with no installer. It saves its settings in the registry, and personally, I prefer this, since it means I just have to delete one file to uninstall it. I can download it to a friend's computer, throw it on the desktop, and not have to hunt around the desktop for the prefs file it created when I want to delete it.

Sure, it leaves a few registry keys around, but as long as they're innocuous, I think that's a better solution that creating a file every time?

Re:windows registry

[xyzzy]

Well, strictly speaking, the program should

a) come with an uninstaller;
b) said uninstaller should wipe the registry keys

Re:windows registry

[Anonymous Coward]

Sure, but coming with an uninstaller means that it would have to come with an installer, and the fact that PuTTY doesn't come with an installer (it's just a single executable to download) is one of its best features, IMO.

Re:windows registry

[xyzzy]

True, yes, I agree that "completely self-contained" is a wonderful feature (have you seen tinyapps.org???). My basic tenet would be "if you need to use it (registry, whatever), you MUST provide a way to clean it up".

Re:windows registry

[paulywog]

Pretty off-topic, but that would be my favorite part about developing new .NET based software.... no more need for registering components in the registry!! What a crappy way of storing information!

Re:windows registry

[toast0]

for this example... PuTTY does have a command line option to clean up its registry mess....

Re:windows registry

[KyleCordes]

I would find it much more convenient if PuTTY would store its settings in a "putty.ini" file or whatever. That would be easier to move to another computer as needed. (It can be done now, by exporting the appropriate part of the registry.)

Re:windows registry

[NutscrapeSucks]

One thing nice about the Mac is that they app guidelines state that a program should be able to start without it's preference file (and should create new preferences with default vaules).

Most Windows apps will croak if they can't find their magic registry settings (or INI file, etc). All because the reg process is part of the installer and not part of the application itself. It would be nice if all apps worked like PuTTY!

Re:windows registry

[neilb78]

that single file program should check to see if [program].ini exists in the current directory...if not, create it and use it to store settings.

0) still only one file to install it.
1) no registry keys
2) still easy to remove

Re:windows registry

[Anonymous Coward]

And how does one store data? You may be suprised that your "Crappy way of storing information" is not different to the End User, its just easier to YOU. (All those config settings do go to the registry) The only way they don't is if you have fundamentally changed your method of programming. (i.e. You purposefully save to ini files, rather then to the "internal settings" shit.

Re:windows registry

[sconeu]

If you do save things in the registry, provide an import/export function so that you can take your settings with you when you upgrade/reinstall your computer.

Ordered Error Boxes

[dietz]

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.

Re:Ordered Error Boxes

[mudder]

Yeah, there's nothing more annoying than buying the latest and greatest piece of consumer software (Photoshop, Office, whatever) and finding that the code is underdocumented.

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.

Re:Standard widgets / UI elements

[Anonymous Coward]

Does the standard windows file->open dialog need improving? Maybe. Are you the one to do it? No.

Hopefully Microsoft's Office group will read your post.

Re:Standard widgets / UI elements

[Spoing]

Well, you just saved me some time in writing this up. Good job...

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:Standard widgets / UI elements

[Martin Blank]

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

True to a point. There are a number of programs I use that are simple, and yet use tooltips. I don't need them after a while, and they can start to cover up useful things. While I agree that tooltips are a Good Thing in general, having tooltips and an option to turn them off is a Very Good Thing(TM).

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.

Re:Tips from the Marquis de Sade School of HCI

[SilentChris]

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

Has anyone noticed this happening on Slashdot lately? There is nothing worse than typing a quick comment, clicking Submit, having Slashdot say you only waited 19 seconds instead of 20, then going back and having to redo the comment all over again!

Re:Tips from the Marquis de Sade School of HCI

[toast0]

i've never had the pleasure of upsetting slashdot's timer... but i would think you could just hit the reload button, and tell it to repost your data, assuming you didn't want to change your comment

Re:Tips from the Marquis de Sade School of HCI

[Anonymous Coward]

Maybe your browser doesn't remember what you typed in?

Re:Tips from the Marquis de Sade School of HCI

[Anonymous Coward]

Even better, if it's a web application, make sure that each page is extremely large, displays lots of extra unnecessary images and "if you like this, you might want to look at this" inclusions.

Clicking on anything to view detail should force the user to reload the entire previous page when they are done.

Any search the user does should provide any possible match, no matter how tenuous, in some pseudo-random order, especially duplicate entries. (duplicate entries should never actually appear under one listing either)

Does anyone recognize amazon.com here?

Re:Tips from the Marquis de Sade School of HCI

[sharkey]

Marquis de Sade

Looks like you misspelled "Microsoft".

Re:Tips from the Marquis de Sade School of HCI

[Anonymous Coward]

Testing the reload theory

Re:Tips from the Marquis de Sade School of HCI

[Anonymous Coward]

Hey he's right
-------------
Slashdot requires you to wait 20 seconds between hitting 'reply' and submitting a comment.

It's been 9 seconds since you hit 'reply'!

If this error seems to be incorrect, please provide the following in your report to SourceForge.net:

Browser type
User ID/Nickname or AC
What steps caused this error
Whether or not you know your ISP to be using a proxy or some sort of service that gives you an IP that others are using simultaneously.
How many posts to this form you successfully submitted during the day
* Please choose 'formkeys' for the category!
Thank you.

Re:Tips from the Marquis de Sade School of HCI

[CaptainZapp]

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

Nah! Make sure, that a minimum of two dozen popup adds for Herbal Viagra, Penis Extension Pills or Chats with "19 years old Cindy" fly around the screen. This has two major advantages:

You, the developer, makes some extra dosh on the adds

This will teach those losers never again to press the "Back" button, especially if there are a lot of nudie popups of ol' Cindy flying in his face and his boss is standing behind him (or even better, her).

Re:Tips from the Marquis de Sade School of HCI

[Preposterous Coward]

Nope, this has happened to me too... and it can also happen if /. hiccups and returns a 404 after timing out. Bye, bye message text.

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:Computing pet peeves

[Raven667]

Context sensitive help should not merely repeat the error message, it should explain the issue

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.

Re:Computing pet peeves

[DeadSea]

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.

Windows users are used to having programs in the start menu. Putting an icon there requires an install proccess. Goodness forbid that you want to integrate with Windows further by adding a right click menu to explorer.

Copying a program's directory should allow you to move a program from one computer to another, with all options intact.

Copying a program from one computer to another should allow you to move the program from one computer to another, with the default options. Under no cicumstance should user data be stored with the program. It is bad for backup, bloating the size of your backups. It is bad for privacy, if you give a friend an application and all your data by accident. It is bad for multi-user systems because storing data and program together is inherently single user. User options should be stored in the user directory. Copying the program directory and the user directory should copy the program with all options.

Re:Computing pet peeves

[CounterZer0]

a program that is conformant to the Made for Windows Guidelines can NOT do most of this. They are required to have an installer, and are required to store pertinent information in the registry. Besides, if you know what you're doing - reading info from the registry can be faster than reading it out of a text or xml file!

Re:Computing pet peeves

[sharkey]

If you offer resizable windows... try them out at at LEAST 1600x1200 pixels, and make sure they still use the screen space.

Go down to at least 640x480 too. As a number of our users have deteriorated sight, the apps that require 800x600 or higher to get the whole thing on the screen are inexcusable.

Re:Computing pet peeves

[Kris_J]

Goodness forbid that you want to integrate with Windows further by adding a right click menu to explorer.

If you do this, please make sure you can turn it on and off through an options menu in the program, not just during install.

And speaking of install, be nice to file types. If you want to grab hold of some file extensions, save the previous association and give people a way to restore it. Especially if you're grabbing .gif and .jpg. Equally, give the users an easy way to reassociate your extensions with your program if an app takes them away.

document everything

[oyenstikker]

Document every function in detail. Every single one. Not just the most common ones, ALL OF THEM. Do it in an organized manner. Linked HTML files with a complete table of contents. Window's help is very bad. Provide a man-type page for the executables and their options. Configuration should be in a text file (provide a GUI for it if you like, i won't use it.) and provide several common example setups and a few complex ones. Document every directive and option. Teach someone who hasn't seen the program before and have him/her write a 'getting started' manual. And DOCUMENT EVERYTHING.

Re:document everything

[jbn-o]

Provide a man-type page for the executables and their options.

Yes. I can not stress this enough. On Unix manpages are the norm for application documentation. Not (tex)info pages, not webpages, not plain text files, not ChangeLogs, not undocumented source code. If your app doesn't have proper documentation, your app isn't finished being written.

I hate hypertext docs.

only a gui available

[joto]

I really hate it when programs I have to use are entirely GUI-based. I want to automate as much as possible, and having the ability to create a simple shell-script for doing what I want is really useful. Not that I don't appreciate having a nice gui, I really do.

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.

Re:only a gui available

[oyenstikker]

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

My home stereo is black with buttons clearly labeled in white. The CD player is the only component that needs a display, and it only needs a very simple one. So why do mp3-players have junkloads of eye candy crap all over the place?

Design the exterior of a box that would do what your program does. Make it easy to look at and easy to understand. Mimic that in your GUI.

Could you imagine if someone made a computer controlled toaster?! It would have heat level indicators, time prediction displays, options to control heat, proximity of the coils to the bread, ejection speed, coil temperature, and tell you how many bread crumbs were in the bottom. Noone could ever figure out how to use it.

Re:only a gui available

[Pope]

Right, and if all those options were left out to keep the design simple, geeks would endlessly bitch that they weren't allowed to micromanage their toaster! :)

Re:only a gui available

[andy@petdance.com]

The CD player is the only component that needs a display, and it only needs a very simple one. So why do mp3-players have junkloads of eye candy crap all over the place?

Why do dogs lick their balls?

Because they can.

Re:only a gui available

[Altus]

I certainly agree with your first point (and the others actualy)

As a mac user I am always annoyed at the number of apps that dont support apple-script when they realy should, it realy doesnt take that much more time to write your program well and add in the necessary hooks for applescript, it can also help for testing, a basic smoke test can be automated and this can realy cut down on the amount of time QA wastes on screwing with builds that just arent going to work.

and if your developing on MacOS X give your user all of the scriping ability possible, from shell to applescript.

Re:only a gui available

[edbarrett]

Design the exterior of a box that would do what your program does. Make it easy to look at and easy to understand. Mimic that in your GUI.

But make sure your mimicry of the real world doesn't override the usability of your GUI.

Re:only a gui available

[sysiphus]

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

True, the GUI is weak. Just make sure you do the one thing WinAmp does best as far as usability: basic keystrokes. The 5 most important keys are:
Z - X - C - V - B, which does:
back, play, pause, stop, next. These are EXACTLY the same pattern on the keyboard as in the GUI, and are just one button to hit. I still use WinAmp on my Win computers, just because there's no CTRL key just to pause.
Actually, iTunes is better yet, just hit the arrow keys to skip and change volume (L-R, up-down respectively), and space to play/pause.

Lots of people here are saying to allow keystrokes for EVERYTHING. I say to make stupid-easy keystrokes for the stuff the program does most (play modes for media.) I've gone through dozens of MP3/media players looking for ones with more features, but keep coming back to WinAmp because I can just use it. I do this with LOTS of applications, and will frequently switch to ones that I can use. Just make it easy for everyday use, even if you want to make it have a bazillion fully configurable features.

Re:only a gui available

[Anonymous Coward]

better yet, download one of the hotkeys plug ins , set them up to seom function keys and change the song without having the first click on winamp. most convenient.

Re:only a gui available

[xtremex]

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:
cat /dev/cdrom > win2k.iso

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.

Re:only a gui available

[Anonymous Coward]

Secondly, follow GUI-guidelines wherever you can. Winamp (and most other mp3-players) are completely ridiculous.
Amen! Winamp is terrible. It is so difficult and unpleasant to use. Avoid the very disturbing current trend of "real world device mapping".

Re:only a gui available

[Ayende Rahien]

> I really hate it when programs I have to use are entirely GUI-based. I want to automate as much as possible, and having the ability to create a simple shell-script for doing what I want is really useful. Not that I don't appreciate having a nice gui, I really do.

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

Well, you've got the wrong impression, you've this ability in windows for a very long time, it's called window shell host scripting, there isn't much in windows that you can't do with it.
And it's certainly true for all the installation programs that I'm familiar with.

log it

[oyenstikker]

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.

Re:log it

[snowlick]

Think about Photoshop without the history feature. I would have shot myself several times by now. Seriuosly though, most of my better/faster knowledge has come from talking to other users. So a list of how to do things quickly would be best made during beta testing, and released with the documentation.

Then your 'most efficient' log file would be updated, and shared among all users through the web. Connectivity! BWAHAHAHAHA!

Yeah..

[redhotchil]

My pet peeve is when the computer program is so horrible it cannot read my mind to pick out exactly what I want it to do, before I even think the thought and the do it before I have completed the thought, doing it nothingless than perfectly and surprising me everytime with a new rendered female and conjoining voice. But maybe I'm just picky..

Numeric Error Codes

[Anonymous Coward]

That's an easy one, numeric error codes when something goes wrong. Having to look up a four-digit error code every time you get an SQL error message is a major PITA and I hope the person who wrote the SQL Server error handling system rots in hell !!

Re:Numeric Error Codes

[toast0]

on the other hand, as others have pointed out, a numeric error code is easy to find on google, regardless of what languages you understand

Re:Numeric Error Codes

[verbatim]

What I don't like are numeric codes that have no meaning.

Example; I was working with this old DOS package and migrating it to NT (no source code available). At one point, when requesting a certain menu, it would spit out a long error number. Completly meaningless to me.

We call the software support people, give them the code. "File not found" he says. Okay, which file (this program was written in some form of COBOL and had no less tan 400 files - not including the acutal data files). "Oh, I don't know, the number just tells us that a file is missing."

Even after re-copying EVERY SINGLE FILE over it still didn't work.

The solution:

FILES=30

The error SHOULD have been something like Not enough file handles... But noooooooo. They have to be 1337 and use a cryptic number that even THEY don't understand. Woop!

heh.

Re:Numeric Error Codes

[Guy Harris]

on the other hand, as others have pointed out, a numeric error code is easy to find on google, regardless of what languages you understand

Yeah, it's really easy to find an error code of 2 on Google if some lamebrained UNIX application reports only numerical error codes. No tons of false hits to dig through, no sirree.... ("Can't open file: error = 2", indeed. Pfui.)

Besides, just because you've found a page with the error code, that doesn't mean you understand the language that page is in.

If you want to give a numeric error code, GIVE A HUMAN-READABLE ERROR MESSAGE WHILE YOU'RE AT IT, so that if you do understand the language you don't have to go to frigging Google (or to some frigging header file) to find out what the hell it means.

Perhaps these are obvious, but...

[bzcpcfj]

my top two gripes are resource management and DLL hell.

Once closed, programs should give back the resources they used. And if you must use a custom version of a standard DLL, put it in the program directory rather than screw up every other program that uses, say, mfc40.dll.

Flexability

[The Whinger]

Flexability is a MUST with all software.

If I find an app that does exactly want I want but has no way of outputting the result in a format I can use easily its annoying.

If I want to use an app in conjunction with another couple of apps it must fix in seemlessly. I don't want to have to download the source code to fix a strange "side effect".

Directories on File/Open

[tigersha]

One thing that really pisses me off are programs that always open on some stupid place (usually MY Docsuments or something stupid).

If I open something, and next time I go to a dir, the program should use the same dir as the last time I opened something, or the same dir as the place where the current file is saved. ALways going to My Documents or god know what is stupid, and very annoying. The Initial Directory of File/Open should track the current open file's location.

Re:Directories on File/Open

[LoonXTall]

MRUD (most recently used directory) lists are more useful on systems designed to be single-user but are being used as multi-user. When I stick something in C:\LXT\GFX, I can quickly reach that directory next time even if someone else has saved in C:\WINDOWS\DESKTOP\Important\Docs in the meantime.

Pet peeves

[Anonymous Coward]

Young upstarts who want to do things the right way when I'm just trying to get out of work by 5 PM.

Behaviour blocking.

[spt]

I frequently use this one piece of software that has arbitrary filters on what it allows you to do.

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 ... if you violate one of the software's rules then the error message that appears calls the user 'lame'

Re:Behaviour blocking.

[autocracy]

Wow. Sounds pretty shitty. Why would anybody ever want to use something like that? Oh, wait... (sidenote: one of those filters caught me the first time I tried to submit this)

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

Screen Resolution/Font Size

[mjstrom]

When you have a GUI, make sure that you test that it looks the same with different resolutions and smaller/larger fonts that you developed with. Make sure the GUI looks good from 800x600 small fonts to 1280x1024 large fonts...

Errors

[tigersha]

Oh yeah, while I am working with Notes, another thing.

Error messages should tell you WHERE the !"!" error happened as well as What happened. If I have a form with 50 fields an error such as "Number expected" does NOT HELP!!!!! "Number exptected in Field for variable " is a good error message. Just tell me WHERE error was.

Lotus Notes is full of this sort of crap. The weird thing is, the system can pretty much give you a load of help with an error since it has the context available when it happened. For instance, Notes knows pretty damn well in which field is is evaluating the formula when it croaks. Why not just tell me too???

This does not just go for Notes, many systems do this (Xerces XML parse, for instance, does not tell you in which line of your XML file it discovered the problem.

Re:Errors

[Mr. Slippery]

Lotus Notes is full of this sort of crap.

Lotus Notes is crap. Such a pointless piece of bloatware I have never seen before. Having to use it is the single biggest pain in working for IBM.

Come to think of it, all non-standard "groupware" should be takne out and burned, and replaced with standard e-mail, internal newsgroups, and a few simple web-based apps.

Re:Errors

[cr0sh]

I once saw an error on a NT4 box when my supervisor was upgrading a piece of software on the server. The error?

Imagine a small dialog, with a title of "Error", no close button, a small text questionmark in the middle (nothing else!) and an "OK" button.

To this day we still don't know what it means (and if I was in charge, I would never buy another thing from that company again - but alas, not my decision).

So, yeah - I agree - good error handling should be paramount. I would also add that the error handling should distinguish between errors that are minor annoyances, but processing can continue, and those which bring the software to a halt, and it must be terminated. Plus, you should ALWAYS trap for errors in every instance, even in those situations where you are positive an error can't happen - because that is where it WILL happen. So, use you error trapping everywhere you can. Finally, if the error is a missing field or something not entered right - in addition to explain what the error was, and where it is - highlight the field, and put the focus on that field so that the user can IMMEDIATELY change it to something more appropriate (maybe even change the tool tip if it exists to reflect what should be in the field)...

Re:Errors

[Anonymous Coward]

I'm going to agree with you in general that Lotus Notes is crap, but you have to remember that it's a development platform, not an applicaiton.

What happened with your problem is that the *developer* didn't check for errors and put in an appropriate message, and therefore the thing is throwing a programmer error back to the user. This is equivalant to throwing a Java stacktrace back at the user if they made an input error. If you push Help, you actually get the programmer help guide.

(It's been many years since I did this, but I think it's a simple as adding "@Fieldname Error: @Error" somewhere.)

Of course, Notes is designed for non-programmers to throw up simple tracking (etc) apps, so it probably should handle this better.

Anyway, Notes is pretty much dead for anything except mail. IBM says Java Java Java.

Re:Errors

[Anonymous DWord]

I think my favourite message is "An unknown program has caused an unknown error in an unknown module." Instant bluescreen.

Re:Errors

[Mr Z]

Mac has a similar one (that I encountered often when using MS Word 4 on it back in the System 7 days):

Application Unknown has unexpected quit with Error -1

It's only a half step removed from putting up a dialog box that says "Something bad happened. [OK]"

--Joe

Common mistakes

[tigersha]

While I am ranting...

I understand the thing with type vs. untyped programming languages. I now untyped languages have rapid protoyping advantages, but that does not mean you should check EVERYTHING at runtime.

Some things CAN be checked at compile/save time and I want to know BEFORE I run the thing that I misspelled the one name of a routine or method or whatever.

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.

Re:Alt-Esc: a better Alt-Tab

[toast0]

wow, i did not know about alt-esc, thats very nice to know about... thanks :)

Re:Alt-Esc: a better Alt-Tab

[Anonymous Coward]

That's sweet. I hate the way alt-tab doesn't switch windows until you release it. Thanks.

No per-application skinning

[Toraz Chryx]

Applications that look totally different to the rest of the OS bug me, this includes (but is not limited to)

Windows Media player
winamp
trillian
ICQ

etc etc

IMHO, all applications running under an OS, should look LIKE the OS, and work in a similar manner (from a GUI standpoint)

Re:No per-application skinning

[Pope]

I totally agree.

And as soon as one does it (read: the classic Macintosh philosophy of HCI), the Skinning Bitches rear their ugly heads and start complaining they they can't customize their new Appz with the 733t k3wl Hello Kitty theme or whatnot.

It bears repeating: Interface first, candy later.

Re:No per-application skinning

[Toraz Chryx]

At the very least, if you MUST include per application skinning, also include a fallback mode where the applications gui is displayed in a normal manner.

(NOT using a skin that looks like the default OS, but actually using the stock OS routines to draw the window)

if they want to be so skinning-friendly, don't screw up the guys using Windowblinds :)

Re:No per-application skinning

[Anonymous Coward]

"(read: the classic Macintosh philosophy of HCI)"

Of course, Apple tells the developers to write to a "appearance manager" that was advertised to support skinning (back in Copeland hype days). Just that nobody should release themes except for Apple.

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.

Re:My personal preferences:

[fsck!]

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

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.

Re:My personal preferences:

[ElOttoGrande]

It would be nice if all programs had an option to change keybindings to whatever you want rather than be stuck to the manufacturer defaults.

p.s. i'm aware most KDE2 apps already do this.

Re:My personal preferences:

[NutscrapeSucks]

One of the things I have long wished for would be if Microsoft added MS Office-style menus/toolbars to the base Windows API. (If you haven't reall dug into Office, you have nearly complete control over all menus, toolbars, and keybindings, and it's been that way since Office 4.2.)

Re:My personal preferences:

[xtremex]

Yes...KDE2 apps do this. In the KDE control panel, you can change keystroke bindings USER wide, or per application.

Find a better focus group.

[mckwant]

I suspect those who frequent /. are not the people to ask about software that "sells well." Just a hunch.

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:Interface Hall of Shame

[LSD-OBS]

--------
And also, never hard-code the colors for window/dialog backgrounds, fonts
--------

Damn, beat me to it! :)

Re:Interface Hall of Shame

[Anonymous Coward]

making sure these people are sufficiently computer-experienced as to not make 'what's a right-click?' type statements

I've seen studies that only 10-20% of users use right-click. So if your UI depends on lots of right-clicking and your testers are only the right-click types, you are going to come to an incorrect conculsion. (That's probably what happened at IBM when they were testing OS/2 PM, which was completely right-click heavy. Assuming they did test OS/2 PM, that is...)

Re:Interface Hall of Shame

[xtremex]

Only 20% right click? WOW. I always right click, just to see if there are any options. If only 20% right click, how many use the MIDDLE button (a la UNIX/Linux)? (Both buttons if you have a 2-button mouse)

Intelligent colour schemes

[LSD-OBS]

One of the things I hate most is apps and web pages which screw up when running on a machine with a non-default colour scheme.

I like my white-on-black colour scheme very much, thanks. Why do certain apps/web pages find it neccessary to set a foreground colour to black, but then leave the background colour alone? Great, now the only way for me to read that is to highlight the text or change my scheme back.

Moral of the story: Either set BOTH foreground and background colours to what you want (and for goodness sake, make it user-configurable), or LEAVE THE COLOURS ALONE.

Jakob Nielsen

[DaoudaW]

Check out Jakob Nielsen's Usability Website. Much of his current writing is on web design, but prior to that he spent alot of time researching application usability. Very insightful! Provides a consistent framework for approaching the usability problem.

Apple Hater!

[KDENCE]

My biggest pet peeve would be the one that would invlolve you writing software for the mac, however if you are writing for Windows. anything goes man. Think about it if the program sucks, someone will just hack it and fix it for you. It is such a lovely community!

UI guidelines

[SilentChris]

There are UI guidelines for most OS's/Windowing systems. Some are fairly strict (MacOS), while others are more lenient (Windows). Above all: follow them. There is no reason why an app that works with documents should do anything other than give you an open dialog box when pressing Ctrl-O. Same thing for people who think it's "clever" to recreate exit and minimize buttons - use the tools that already exist, don't make up your own.

Always remember, there are people with PhD's who have spent years studying this stuff. Even if you're a good programmer, don't think you can outdo most dialogs. They are two completely separate computer science fields.

Re:UI guidelines

[frankie]

There are UI guidelines for most OS's/Windowing systems. Some are fairly strict (MacOS)

Unless you are Steve Jobs, in which case you may throw your own rulebook right out the window. Damn do I hate QT Player.

platform parochiality

[Snafoo]

I really, really hate it when an app isn't cross-platform and/or doesn't have a compatible implementation available under other platforms. My job entails switching back/forth between linux and windows many, many times; having patches of stability such as Mozilla, vim and (Win|G)cvs is great.

Network issues

[Minupla]

Lots of GUI stuff, but there's much more to a program then how it looks or what you click on. My pet peeve is network handling. Networked applications need to, at a minimum:
1) Be secure. Check for buffer overflows, check it twice. If the other computer sends you a megabyte of As, what will your application do?
2) Be ethical. I can't count the number of times an application has tried to leak confidental information out my internet connection. Unless your program has a legitiment reason to use it, it doesn't need to get my username, my owner info off my windows, the box's ID number, etc and send them out through the network connection.
3) Be efficient. Plan ahead, how will your network application be affected if your usership grows 1000x? (Gnutella) Will it work over a VPN? Test it at different bandwidths, make sure it falls back gracefully if required. There are chunks of the world, even in north america where a 9600bps internet connection is a sign of a really good day.
4) Be RFC complient. Nothing sucks more then to have your router taken out by an application that screws up and spews random info out the eth0 port. There should be no circumstances where your program can break any of the appropiate RFCs.
5) Provide hooks. Sendmail is still in use for a reason. It does its job, and hands off subsequant tasks to external programs, allowing us to change out local delivery agents as we change our ways of storing mail, for instance.
6) Include some sysadmins in your beta group. You'll sell more software if the IT dept doesn't commit ritual suicide each time a user buys a copy of your software.

Just my .02 Orionan credits.

More ....

[rogerl]

Always allow the user to pick the data directory. For example in Internet Exploder, (mis spelling intentional) the user can not choose where the bookmarks are saved, so when you reload Windows, you lose all of your bookmarls / favorites.

Never ever assume that the user wants your program to run all of the time. Example: Real Audio

Always allow the user to disable the program if he or she does not want it to run at startup.

Do not make the user upgrade and do not assume that we want to be notified of upgrades.

Do not just assume that your program will be the default program.

Do not hide settings deep within the registry.

Never

Re:More ....

[Anonymous Coward]

Always allow the user to disable the program if he or she does not want it to run at startup.

How about: Allow the user to enable the program, if he or she wants, to run at startup

Re:More ....

[Captoo]

Are you sure it shouldn't be called Internet Exploiter? I like you comments. I think your post should be modded up.

Re:More ....

[sconeu]

No, it's Insecure Exploder.

Pop up windows

[ajw1976]

If you're writing a web application, do not have several pop-up windows appear at random.

Eliminate the emotion...

[Kefaa]

There is a lot of good feedback here. Some of it written in the best prose I have seen in a while. Almost every entry had something great in it.

You began your entry with: In an effort to improve my coding skills, what are Slashdot readers' biggest pet peeves when it comes to software?

First and foremost, remember you are writing code. Some of it will be great. A lot of it will be mediocre, dull, or poor. The biggest mistakes I see in developers, even "old" developers is an inability to admit they created something poorly. Part of it is pride, and part of it is the desire to avoid "fixing it".

If you wish to be at the leading edge, get over the emotion. We are not calling your children ugly or discussing the virtue of your mother. It is code. Look for people to criticize and complain, bitch and moan. Then decide if they are right, or if you took a new direction on purpose. (Hey, someone thought Open office should open all the applications at one time.)

Stand up and get out more. Hermits are unwilling to run an idea by anyone because they take everything personally. So they code, and code, and code and then we refit, retrofit, and enhance afterwards. Talk your boss into putting a white board in the aisle and run coding decisions, access questions, and design considerations past anyone willing to stick their head out. You will get garbage and gems. However, you will get more to think about and that will certainly improve your coding. (Especially if someone points out that opening all the office applications at once may be an issue.)

[BTW - I picked on open office because it is an issue that has been beaten to death. Some would say this horse was whipped to death only to have us start on it's children. ;-) I strongly recommend everyone try the most recent stable version of Open Office. You may be very surprised, what OSS can get you.]

Things that drive me crazy...

[SagSaw]

1. Console based programs without a command history.

2. Programs with no undo button.

3. Counter-intuitive key bindings. (ex: Hitting backspace in a form field in IE should not take me back.)

Hall of Shame

[alange1]

This site hasn't been updated recently, but has many great examples of what not to do.

Pet Peeves?

[Lando]

It appears that you are talking more about interface design than programming.

For what it's worth, check out "Interface Design" by Peter Bickford ISBN 0-12-095860-0. Its a bit dated but provides a reasonably good introduction and foundation for interface design...

Networking

[tigersha]

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.

Re:Networking

[my_second_fish]

I didn't notice it before, but in a similar line of things, most programs do NOT need a "systray" icon. If you are running, and you're meant to be a TSR-styled program, all well and good. But if you are not actively doin anything.. get the hell out of the tray.

For example, I gotta stare at this damn ATI icon in my Systray that..oooh.. allows me to change resolutions and adapter properties.. -i can already do that- .. what i -cant- do, is turn the friggin icon off. same thing with Creative Lab's Audio Device Manager.. how many people actually have multiple sound cards? get rid of the damn thing! .. Toss in AOLIM and ICQ's status markers .. if i got the friggin buddylist up, chances are I can see what my status is.. and I dont need a little marker up top to tell me. If yer gonna have a systray icon.. make it worthwhile, or make it hideable (like winamp)

and everyone else is stressing good documentation, which i agree with.. but for heaven's sake.. DONT make it only available via the web. sometimes an internet connection isnt available. -all- documentation should be locally available.

fish

Re:Networking

[Shadowlion]

is turn the friggin icon off

You should be able to. In Settings->Advanced, one of the ATI-installed Tabs is called "Other" or "Misc" or something, and has some blue circle-checkboxes in it that allow you to turn off the icon in the system tray.

Re:Networking

[WhyCause]

turn the friggin icon off

I just remove ALL of the ATI crap from the registry in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Run

You don't need it (unless you use the color matching, etc. that it enables), and you can get to most of the options it pops up elsewhere.

'course, that's the first thing I do when I get anywhere near a new PC that I'm going to have to use a lot. Right after I take almost everything else out of the Run reg key, and delete everything from the StartUp directory in the Start menu. Windows runs real nice when I'm finished with it.

Re:Networking

[smatthew]

god - i'm probably going to get flamed for mentioning this, but here goes.

you do you know that is MSIE there is an option to open each window in a seperate thread? Makes it so if one window crashes the other keep on plugging away. I really wish more browsers did that.

Note: I do not use MSIE, i just support it for end users.

Error handling

[tigersha]

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.

Re:Error handling

[clintp]

You missed my personal favorite:

f) Variation of b: pop open a dialog box for each error and continue processing. The joy of finding 8,347 modal "Error 92 [OK?]" dialogs on your desktop in the morning, and having to close each one of them to get back to the application to diagnose it earns you a special place in hell.

Proprietary Software License

[extrasolar]

Its at the point now that we have a choice between proprietary and free software. I'll choose the free software everytime.

If you are going under a proprietary license anyway, take care in the license you are going to use. Try to give your users some concept of rights to the software they license from you. Such as being allowed to run on a multi-processor machine or being allowed to modify some of the files bundled with it (graphics, text files, etc.). You can even publish the source code while retaining propriety of the software.

Its comfortable being able to know how the software I rely on works and the ability to make changes (hopefully legal) if its broke.

Also...it should never crash and be completely bug free :)

Who is your audience?

[lupetto]

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.

Re:Who is your audience?

[Anonymous Coward]

Nonsense, the vast majority of /. users consider themselves programmers - the rest of the world rightly calls them script kiddies.

Here's a few

[hether]

Probably all mentioned already, but here's a few of my suggestions:

Don't change my window focus. Your program is not necessarily the most important one running. Besides I might have it running in the background for a purpose - like I don't want my boss to see it.

Allow me to turn off (and permanently turn off) programs that run automatically. That includes turning them off via their icons in the system tray.

Make sure that I can do things without a "wizard" to help me out. A wizard is nice for the unknowing, but is not for everyone.

Let me choose whether or not I want to check for updates periodically on the web. I might not want the new version of your program for any number of reasons.

Don't send data automatically from my computer back to your company - even for error reports.

Don't make me register before being allowed to see the property settings. (Hey Real - this one's for you)

Don't give errors with just code numbers. I don't know what error CC344 is or why it has occured and giving me the error number doesn't tell me anything. It might help you while developing, but change it to something meaningful before release.

Self-documenting code, etc.

[andaru]

Programs which steal the input focus bug me, too. You should be able to operate your computer with the monitor turned off if you remember the right keystrokes without some program popping up and changing the context.

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

Re:Self-documenting code, etc.

[Kris_J]

There is obviously an event that can be triggered that causes drop-down menus to disappear. Internet Explorer uses it whenever it finishes loading a page (or even a frame) but Mozilla does not. If I've got a batch of IE windows loading pages I can't use the menu in any other program because it keep disappearing. Don't do this. Whatever it is, don't do it. Assume that users will be running your program in the background and just as you shouldn't pop to the front and/or grab the focus, don't keep collapsing their menus.

Re:Self-documenting code, etc.

[J'raxis]

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

This is more of a library issue than the programmers fault, since most C coders probably just use perror("") or strerror(errno) and forget about it. This leads to ingenius errors like:

bash: /.: Is a directory
cat: foo: Cannot access
junkbuster: Unable to connect: Operation now in progress
cpio: failed - Success

The last one being the result of calling strerror() while errno=0. Read through /usr/include/errno.h to get an idea at how terse some of these errors are.

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").

Good advice for a huge loop (what the hell is some_ptr->foo[i] 600 lines down and five indents in?), but not necessary in small code, I would think. This is more than self-explanatory:

for( i = 0; i < ARRAY_LEN; ++i) {
something[i] = something_else[i];
};

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.

I guess you don't like strpcy(), strncat(), strcspn(), or strstrncpspostrstritok() much, do you? :)

Re:Self-documenting code, etc.

[Mr Z]

Good advice for a huge loop (what the hell is some_ptr->foo[i] 600 lines down and five indents in?), but not necessary in small code, I would think.

Agreed. Indeed, most variable naming schemes fall over at the endpoints, and what you're really left with is a matter of taste at some point. I gave one of the guys here a ribbing because he had essentially this in his code: const unsigned int unityconstant = 1; Uh, yeah.

I personally have no problem with short, meaningful names. Don't make me type ArrayOfStructuredElements[IndexIntoArrayOfStructur edElements]->CounterFieldInStructure += ConstantValueOne when a[i]->cnt++ is sufficient.

--Joe

Re:Self-documenting code, etc.

[J'raxis]

Hah, you should be glad youve never coded using Macintosh APIs. I havent touched it in years, but they had function names about that bad. DoSomethingRealSimpleWithDialog( theDialogPtr, theWindowControl, someDialogFlags, ... ). Give me six-letter POSIX functions over that any day.

Re:Self-documenting code, etc.

[J'raxis]

BTW, did he actually have a purpose for calling 1 the unityconstant in specific places, or did he just replace every 1 in his code with unityconstant? I mean, we use things like EOF, TRUE, FALSE, NULL, EINVAL, and so on all over the place; these are all just alternate names (#defines, enums, const ints) for tiny ints like 0 and 1, but in context they make more sense.

Re:Self-documenting code, etc.

[Mr Z]

In this case, it was being used as the starting term in a polynomial evaluation for Chien Search. I just looked at the code, and the constant is not quite 1, but rather 0x01010101 (because the code is SIMD-optimized, and is doing the same computation in parallel on four different bytes in one word).

In this context, I would've named the constant something like "ones", or "one", or maybe even k01010101, rather than a five-syllable name. (Rarely do you need the word 'constant' in a variable name, and 'one' and 'unity' are usually synonyms.) In fact, many of the variables in that file could've been given more terse, yet more descriptive names. I'm firmly convinced it's an art.

Of course, I suppose you could go the other way and have all 2 thru 4 letter variable names, as I did in the IDCT (same page as above). Of course, in that case, I was mostly using the names that Chen used in his paper on the IDCT. (I implemented Chen's decomposition of the 8-pt IDCT.) For other things, though, I have no qualms calling a rounding term rnd or an input pointer i_ptr. Calling it inputPointer is a waste of my 80 columns.

--Joe

Don't Throw Away My Input

[Detritus]

The one thing that drives me crazy is programs and web applications that cheerfully discard 30 minutes of typing because there was a network error or I hit the wrong key.

Programs that steal the focus from the current foreground program are also very annoying. I'm typing in a sentence, some program steals the focus, and it does random bad things when it interprets my keystrokes as commands.

documentation that doesn't reflect customization

[Lepruhkawn]

If hate it when an app allows me to customize it and then presents documentation that is written like everyone uses the default configuration.

The easiest example is in games.

If I can remap the TURN-ON-FLASHLIGHT key from L to G, then don't give me a tutorial that says "now press L". I press L and nothing happens. What is it supposed to do?

I have to lookup up the default key bindings to figure out what command that's supposed to execute.

If your application's commands can be executed in ways that can be customized, refer to the abstract command not the default way of executing it. Or refer to both at the same time.

Of course, the ideal is that the documentation or tutorial dynamically reflects the customizations I make (some games do this right--in the example, the tutorial would tell me to press G).

Here are some tips.

[bedessen]

(these are assuming the platform is Windows)

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.

Re:Here are some tips.

[PCGod]

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.

I cannot tell you how much this annoys me. For the love of doG, if you MUST start your program on startup, please at least put it in the startup folder where I can see it. My mom's work system was lagging like crazy and I went to investigate. I removed about 8 or 10 different programs from the registry that were starting on their own. Yet another reason I use Linux From Scratch. I know wtf my system is doing at least.

Environment variables suck

[PD]

Why?

Program runs in xterm A, but not xterm B. Why? A missing slash in a variable somewhere.

No problem, I'll just use my super powerful administration tools that I have for environment variables. Those tools are called "set" "export" and are used by typing out long strings by hand without making a mistake.

Progress bars and human perception

[andaru]

Amusing anecdote about progress bars:

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.

Re:Progress bars and human perception

[Kris_J]

I remember a Umax scanner with a progress bar that updated only twice during a full-page scan. It sat at nothing for two of the colour passes, then jumped to 66%, then sat there for the last pass, then jumped to 100% then sat there for ages while the data was transferred to the Mac. Every time. Since then I have taken progress bars with a grain of salt.

Re:Progress bars and human perception

[Monkelectric]

We have a saying, "the last 1% is always the longest." Taking note of the fact that progress bars (especially in install-shield apps) always seem to stick at 99% :)

Re:Progress bars and human perception

[Anonymous DWord]

I just installed Windows 2000 for a friend a couple of days ago. When I was copying over his old stuff (HD to HD), the progress bar kept jumping up the wrong way. When it hit '941873 minutes remaining,' I took a screenshot. Too funny. Yeah, I'm gonna wait a little over 654 DAYS for Windows to copy 2 Gigs of data. :-P

Re:Progress bars and human perception

[Anonymous Coward]

Ya, it's amazing how some really obvious windows bugs that I noticed in win95 are still an issue even in winxp today. Like the one you mentioned and the magical changing icons bug on your desktop to name another.

Demographics of Slashdot

[andaru]

I wonder what percentage of the people out there are actually real programmers or engineers?

There are certainly a few people responding who seem to have "been there" to a greater or lesser degree.

Other usefull (and obscure) shortcut keys

[Bistronaut]

Here are some that I use quite often:

• To save form data in IE (e.g. for later reference) before you submit it, hit alt-F4
• To do an auto-save across multiple applications, hit ctrl-alt-. a few times (has to be the period on the numeric keypad with numlock off)
• For a hidden easter-egg game in Windows, hit winkey-r (that's the key that has the Windows logo and 'r') and type regedit. The object is to delete as many of the evil keys as you can before time runs out. (I know you don't see a timer, but you'll know when time runs out).

;-)

Windows

[Anonymous Coward]

My biggest pet peeve is that darned Windows splash screen when I start up. Bahahahaha!

Whoo-hoo, I'm ragging on MS! Isn't it crazy, posting something like that on Slashdot? Let those karma points roll on in! Glad I'm signed in to collect 'em.

Big fonts!

[rufusdufus]

Make sure all your dialog boxes work with "Large Fonts". This helps two classes of people: one is people with poor vision, and the other is people with very high resolution monitors.

Nothing is more annoying than having a non-resizable dialog box with two letters of a sentence in it because the font is too big.

Re:Big fonts!

[Webmoth]

Or, for that matter, the Windows desktop properties dialog box which, when the screen is set to 640x480 and large fonts, is larger than the screen so you can't see to click on the buttons... or, in some cases, see the fields where you change the resolution and font sizes. Of course, these values can't be changed in a text file, and finding them in the registry is like looking for pi in the output of /dev/random.

So that needed documented.

[LoonXTall]

If you put in features, document them! The only thing that shouldn't be documented are the easter eggs.

YES!!! You have a Clue!!

[Anonymous Coward]

Anyone who disagrees with the parent post shall be cursed to using Netscrape 4.x on CDE (Solaris)!! You will writhe in agony as you hit Alt+Left to go Back and watch helplessly as you rotate left one workspace!

If you want to add a new feature...

[Kris_J]

If you're putting functionality of any kind, whether core or UI, into your program that isn't already popular, with obvious "standards", then look around to see what other people are trying to do in the same field. Get to know other developers that are producing complimentary products and agree on small standards so that your products co-operate. Research emerging standards and incorporate them if you were going to do something similar anyway. Who knows, you might strike it lucky and be one of the first to include the next popular feature. I guess I'm saying, don't reinvent the wheel -- if even one person looks like they've come up with a workable solution, help evolve that rather than creating a new religion.

Where possible.

Be modular, develop for the low end.

[Kris_J]

My fastest computer is a 266MMX with 64MB of RAM. I rarely use more than 20% of the features of any given software product. Where possible, produce a software product that's modular such that features I'm not going to use can be removed. If this means you have a tiny little core product and most of your functionality lives in plug-ins, great.

Keep things optimised. If possible, release your plug-in standards so that real zealots can rewrite some of your modules in assembler for better performance. Don't assume you can get anywhere near fully optimised the first time. Encourage a community where people write routines optimised for all the weird stuff out there. Look at D.net with it's MMX core v's it's 3Dnow! core.

There is a huge user base out there with old PCs. For every 30MHz you shave off the requirements for your product you probably increase your potential market by 10%. A modular app properly optimised over time should find it's minimum system requirements go down not up. If MS worked like this you'd be able to run the core of Windows 2000 on a 386 and basic editing using Word 2000 would only need 4MB of RAM. Not everyone needs to play movies on their PC.

Re:Be modular, develop for the low end.

[aoeuid]

Perhaps increase their user base by 10% in those third world countries where their software is probably pirated anyway.

Sanity checks

[LoonXTall]

Make sure your program knows what's going on. Case in point, I have a mouse which works without a hitch under Linux (X and gpm), but which does random stuff (clicks and pointer warping) under Windows sometimes when I move it. The most recent episode created a toolbar on the left side of the screen containing the contents of C:. How it did this is a complete mystery, since no toolbars may be added because of poledit settings...

Scandisk..

[rufusdufus]

Haha I'm afraid this one is partly my fault. The goal of running scandisk at startup was to reduce the number of product support calls with questions about how lost clusters got on the users harddrive. The main reason of course is people just turn the computer off without shutting down, which doesnt let the file system complete whatever task its performing. Now originally the idea was scandisk would run, clean up any 'problems' and continue boot.

But then cold reality stepped in and two things happened: one, people didn't like seeing scandisk run, and didnt understand why it was running, and two, user Ed jumped in and decided to fix this problem with a message.

So the message is for that segment of users who arbitrarily turn their computer off, rather than shutting down. But of course there is a bugaboo that if the system crashed, you still get the message, because there is no way to tell the difference between a crash and pulling the plug.

In the big scheme of things, that message relieves more confusion than it causes.

Re:Numeric Error Codes; handling

[Webmoth]

It's fine if your application returns numeric error codes. It makes the code a bit simpler so say "if x does y, error=2" than "if x does y, error='user is an idiot'".

HOWEVER, your program should also have an error handling routine and an error database. So, if the program returns error code 2, the error handler looks it up in the database and returns to the user "Error code=2. User is an idiot."

Even better would be to list possible solutions to the error! ("Possible cause: User doesn't know his head from a hole in the ground. Suggested solution: Buy a clue.")

Where to store per-user config data

[jbn-o]

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.

I'm not sure exactly what you mean by "no registry crap" but since you insist on a Microsoft Windows-centric list of peeves, it's worth noting that the registry is the currently preferred place to store per-user configuration data. ".ini" files are outmoded by the registry. As another /. poster noted, don't forget that multi-user MS Windows installations are becoming the norm (Windows 2000 and XP are used a lot now). Single-user Windows systems (all DOS-based Windows, Windows 95, Windows 98, and Windows ME) will become the exception and eventually be outmoded too (as many MS Windows versions on that list already are).

No matter what the operating system, I fully expect applications to heed the accepted norms for the operating system it's running on—on MS Windows that includes using the registry where needed (not flat files of configuration data). On Unix systems that means using rc files or (if the app has a lot of state to maintain between sessions) .appname directories in the user's homedir with an rc file inside that dir.

App developers that violate the UI norm are almost always wrong to do so. The user suffers because an exception to the rule is created which makes the app harder to use in a way that scales up. It might be a pain supporting multiple schemes for saving per-user config data, but that's just part of being a cross-platform application developer.

Integrate your software into the system smoothly

[jbn-o]

You don't need it (unless you use the color matching, etc. that it enables)

I apologize to WhyCause because this is not a genuine response to that article, but WhyCause's phrasing was just too good to pass up.

If the software you're writing has a new feature, integrate it into the existing system-provided way of doing that thing rather than making a whole new program or UI panel for your own stuff. For instance, if your program allows the user to have a brand new resolution for their screen (say, 649x485), add that resolution to the resolution list the system provides rather than making a new UI panel to ask "Turn on 649x485 display?".

Integration need not squelch innovation. Take pains to make it easier for the user to access new functionality through UIs they are already familiar with.

Disabled command items

[wimbat]

Any greyed out menu item or tool button should provide a mechanism to explain why it is not available. The explaination should indicate the specific condition which has disabled the item. A possible implementation would be to use a tool tip.

Re:documentation that doesn't reflect customizatio

[jbn-o]

I agree, but good luck getting people to see the wisdom of referring to the mouse's "menu button" or "selection button" (or somesuch) instead of "right button" and "left button". I try to write documentation that applies to lefties as well as righties and sometimes I encounter righties who aren't interested in documentation that makes them think about tying the functionality to the button (instead of the physical orientation of the buttons relative to their body). In other words, some righties want the docs to assume all mouse users are righties just because most are (just like your documentation complaint assumes everyone's using the default keymapping just because most users don't alter defaults).

Focus, people!

[Anonymous Coward]

Heh, someone already said it, but as a direct response to your "peeve": do you know many, many window managers have a "newly mapped windows get focus=no", no? Everybody knows this.

What, using Windows? Well... if a reasonable number of people request this then it will be done. Or not.

option I would like.

[Anonymous Coward]

There's a graphics app I use frequently, and I really wish I had an option to set a timer so I could have it auto save at timed intervals, and also an option save it under a different file each time............

Language! localization sucks balls..

[radja]

ok.. here's one of my pet-peeves: localization. I hate it. Causes all sorts of annoyances: menu-items translated differently across apps, english dialog and localized yes/no buttons (from the OS), urgh..

//rdj

Learn from past user behavior

[KlausBreuer]

One thing that seriously bugs me is how *stupid* programs are which assume that they're smarter than me.

For example, some programs will always start at a certain directory when saving data (C:\My Documents\). I have never, ever, saved anything in there, switching away (always to the same directory, G:\Data\Source\FFT\) every single time.
Why can't the program simply remember that?

And, oh yes, I'm adding my voice to the people who hate focus-stealing programs.

Re:Learn from past user behavior

[Anonymous Coward]

One of the prime reasons that I switched from using Windows to a Linux system was because I was fed up with an operating system that assumed that I didn't know what I was doing.

With access to source code, you can - should you be so inclined - change default behavior of a misbehaving app. I've done it a couple of times.

Web Apps and Browsers

[alico]

Nothing can be worse than the script kiddie launching many broswer windows with java script when i visit a page or even worse changing my default homepage. As far as standlone applications go I would like it that when i check the "dont ask me again" the software is polite enough not to ask me again, i have seen that with a few applications. auto/pre-installs are evil too but we can always use good undos. as much as possible of every action should be reversable.

Tech Support Pet Peeve

[screwballicus]

User: "The server is down."
Me: "Could you describe in detail the nature of the problem you are experiencing?"
User: "I can't get my mail. The server is down."
Me: "And you are using the same username and password which you use to connect to the Internet?"
User: "I don't want to be connected to the Internet. I want to download my mail."

Rule #1 for entry-level users calling into tech support:

1) "The server is not down. You are an idiot".

In such circumstances as Rule #1 does not apply and the server is actually down, it being our fault:

2) "The server is not down. You are an idiot".

bare functionality, and SPEEDINESS.

[Herr_Nightingale]

Develop a FAST, cleanly coded and preferably efficient app first with bare functionality, then you can add the usual bloat - or better, don't add it.

Avoid splash screens beyond the initial installation sequence (assuming Windows install). They detract from any product by their intrinsically intrusive nature - somewhat like pop-up ads, IMHO.

Re:bare functionality, and SPEEDINESS.

[J'raxis]

Splash screens are, however, necessary if the program has a long start-up sequence (Photoshop comes to mind). Or do you want to sit there wondering if the system is hanged when its really loading filters, fonts and so forth into memory? Splash screens that require you to click to dismiss them, or simply come up for advertising purposes are quite useless.

Re:bare functionality, and SPEEDINESS.

[Herr_Nightingale]

I'd say PhotoShop is a prime example of a bloated splash-screen. I don't mind little 'loading bars' but watching Photoshop load is just painful.
Side note: Speaking of Photoshop, I don't use even a fraction of the abilities of the program, and I'd appreciate the ability to take out the extraneous parts (ie, filters I'll never need, etc) that simply slow down loading. Since started using Paint Shop Pro 7 (I'm not a bitmap pro, what do I need PS for anyway???) things have been a lot nicer.. Hence my desire for SPEED and bare functionality...,.

Re:bare functionality, and SPEEDINESS.

[PyroMosh]

I think you answered your own question on that one. Photoshop is aimed at "bitmap pros" only. It's not aimed at the casual graphic artist or even the average webmaster or end user (read: it's not for you). That's why it costs so much. While it may be "nice" to select features to install, Adobe probably realizes who it's developing for and is catering to them. People who *will* need many/most of those features and who (as likely as not) do not want / know how to remove them.

I agree with you in sentiment, but Photoshop is a bad example here. Did you really pay $600 for a program that you just wanted to play with? Somehow I doubt it. That's why PSP is a $100 product (and people like you and I use it.) and Photoshop is a $600 product, because basically only graphic professionals use it. Anyone that is not a professional (or professional caliber) artist who's using Photoshop is probably pirating it, since most people can't / won't pay $600 just to occasionally remove red-eye, crop, or resize little Billy's school portrait for their geocities homepage.

Hell, I can't even justify it and I deal with graphics DAILY as part of my job. PSP works great for me!

Getting back on the subject of the article, like I said, I do agree with you in principal. And I believe that a setup like MS Office has is ideal. EVERY-FSCING-THING is configurable to either install to hard drive, run from CD, or prompt when needed. (IIRC, it may be slightly different) That, in my opinion is ideal for an especially large application or large suite of programs.

Keep in mind this is the *advanced* setup. Setup will prompt you for either "typical" or "advanced" install. This in IMHO is as it should be.

One last thing, don't do like Netscape's taken to doing with that. IF you install many Netscape products (not to single just them out, but they come to mind as an example), there is a similar "typical" and "advanced" dialog. Click on "advanced" and everything is grayed out! It makes you install (for example) Navigator *and* AIM *and* NS Mail *and* Winamp, etc...

Don't fall into the Henry Ford Trap... "You can have your Model T in any color you like. As long as it's black."

Re:Numeric Error Codes; handling

[Guy Harris]

It's fine if your application returns numeric error codes. It makes the code a bit simpler so say "if x does y, error=2" than "if x does y, error='user is an idiot'".

HOWEVER, your program should also have an error handling routine and an error database. So, if the program returns error code 2, the error handler looks it up in the database and returns to the user "Error code=2. User is an idiot."

*Poof*, there goes the simplicity from the first paragraph. It'd be simpler for the programmer not to have the error handing routine or error database, but, as it appears we both agree, it'd be wrong, as it'd make life more complicated for the user.

Even better would be to list possible solutions to the error! ("Possible cause: User doesn't know his head from a hole in the ground. Suggested solution: Buy a clue.")

Yes, definitely (at least in cass where a solution can be listed; for example, it's not clear what solutions to "No such file or directory" exist, other than "type the path name correctly" or "make sure the file you want to process actually exists before you try to process it"); that's why, for example, if Ethereal can't open a capture device, it suggests "Please check to make sure you have sufficient permissions, and that you have the proper interface or pipe specified", as the problem is often that somebody's not running it as root on a machine where only root can do capturing.

Windowing and etc.

[Herbmaster]

• Don't use a tabbed-window interface when multiple windows would do (and would allow more multi-tasking by the user)
• Don't use a rooted-window interface EVER. I might have something in the background which didn't need obscuring.
• Use OS standard interfaces and controls so I can make use of my system mods, scroll wheels, and alternate input devices, the way I want and expect to.
• If you're displaying any amount of text, don't use an ugly san-serif font. Arial is unnacceptable.
• If a function/feature of your app is useful globally, don't make it bound to the "main" window of your program; make it available from everywhere.

Two or three words.

[ClayJar]

Read-only filesystem.

With a read-only filesystem, trying to create .ini files cannot succeed. Writing to the registry will. (You can, with a bit of tweaking and a ram disk, actually boot Win9x from a CD.)

More tips

[Anonymous Coward]

Make sure you code in C. I can't underestimate the importance of this in creating a truely awesome user interface. It may not seem there's an obvious correlation between using C and the interface you make with it, but trust me...

Down the road a few years, when the company you code for wants to make a new version, they may try to (GASP!) make the user interface easier to use. This is the last thing you want, since, if you wanted ease of use, you'd have used easier users.

Using C gives you advantages, such as (if you comment your code liberally with unhelpful remarks, such as a function with a comment that only states the function's name), they will be unable to figure out what you did. Then, they will have to pay you more to fix what they will think (wrongfully, of course) that you should have done right in the first place, but it will also allow you full control over the revamped UI, and give you the opportunity to insert more helpful comments like:

/* Print something here */

for instructions like:

printf("%s, %s, %c[x], Blah blah blah");

which will really help them know what you did when they review your source later. Remember always have a driver keep the car running for quick getaways.

Anonymous Programmer

Common Config Collection

[Anonymous Coward]

However you do your back-ends, please, PLEASE, PLEEEEEEASE put all of the configurable options in one place, tabbed, indexed, or whatever. Use shell scripting if you like, but don't hide options on the fourth or fifth level of some damn menu, especially when the submenu doesn't say exactly what you are configuring. All configuration should be accessable from one location, even if you have to tab it across the top and down the left or right side. You can add links to configure specific items without showing the master config dialog, but please make sure that the configs you do elsewhere can be viewed and changed from the master config dialog. Make it so you can select a default type to save in, if for example, you are making a word-processor, instead of forcing the user to go through three or four levels of child-windows just to save-as something other than your programs proprietary non-open file-format. When I hit alt-s or control-s, or click the little floppy disc in the tool-bar, it should ALWAYS save it as *.RTF (for example) instead of *.HWP if I tell it to do so. (I shouldn't have to specify *.RTF, or whatever, each time.)

Make it possible to turn all those stupid toolbars on and off.

And don't do as another poster suggested, using tool tips for everything. Do you have any idea how ANNOYING that is? I have dealt with a few of these benighted programs, and my experiece has lead me to scream things like:

I can't point to anything on the screen, I just want to type! Please? I push the mouse to the lower right corner and a tooltip pops up to say 'This is the lower right corner of the screen. Left click and drag to freely resize the window, or doubleclick it to auto-size/un-autosize the window', I point the mouse to the extreme top of the screen, and a tooltip appears below the pointer's tail that says 'This is the application bar. If it's active, the bar will appear %ACTIVE.TITLEBAR.COLOR% with %ACTIVE.TITLEBAR.TEXT.COLOR% text in %ACTIVE.TITLEBAR.TEXT.FONT% at %ACTIVE.TITLEBAR.TEXT.SIZE% points. If it's inactive, the bar will appear %INACTIVE.TITLEBAR.COLOR% with %INACTIVE.TITLEBAR.TEXT.COLOR% text in %INACTIVE.TITLEBAR.TEXT.FONT% at %INACTIVE.TITLEBAR.TEXT.SIZE% points...'

IT TAKES UP HALF THE DAMN SCREEN! STOP IT! THE OKAY BUTTON DOES NOT NEED A TOOLTIP TELLING ME IT'S THE FRIGGIN' OKAY BUTTON! OKAY?

Sorry.

And yes, I agree with the other post, call it seconding the motion, that I should be able to cut my mouse-cord off and still be able to use the program. The point & drool interface is perfect for art and music, but not much use for anything else except dumming the UI down to the AOL Luser level.

Jus'ai Mai deux csen'taeux.

The I'm-the-most-important-app-ever syndrome

[dmadole]

Pretty much everything else mentioned here is great, right on the mark, so I won't repeat anythin already mentioned.

One I didn't see that I hate is those applications that assume they are the most important application in the world. You know, the ones that install icons in the Start menu, on the desktop, in the system tray, put themselves in the startup folder, and so on.

Either ask during the install if I really want all that crap, or only install into the start menu. Obviously, this is a mostly Windows-centric issue.

Killing the ATI icon (was Re:Networking)

[NaDrew]

You should be able to. In Settings->Advanced, one of the ATI-installed Tabs is called "Other" or "Misc" or something, and has some blue circle-checkboxes in it that allow you to turn off the icon in the system tray.

I don't know how long I had to deal with that stupid ATI icon in the system tray until I read that. Thanks!