PEBKAC. Acronym for: Problem Exists Between Keyboard and Chair.

I have cofounded, and I run, a small software company that specializes in SSH client and server software for Windows.

SSH is a standardized protocol which specifies how a desktop program, called an SSH client, can connect to a back-end program running on another machine. The other program is called an SSH server, and the SSH standard specifies how the two programs can transmit files and information in a securely authenticated and encrypted manner.

If you have any experience with computers, I hope it's not too far fetched to expect that you have a vague understanding of what "client" and "server" means. A program that runs in a client role is proactive: it decides what server to connect to and what actions to request that server to perform. A program that runs in a server role is reactive: it waits expectantly to receive connections from clients, and responds to them as they arrive, in turn.

So, as I mentioned earlier, our company makes an SSH server, called WinSSHD, and an SSH client, which we call Tunnelier.

About a year ago, we introduced a built-in feedback feature into WinSSHD, which I hoped would make it easier for users to report any problems that they might experience, so that we can fix them.

And report they do.

Unfortunately, however, my expectations turned out to be... off the mark... about the quality of the feedback we would receive.

The very first thing that it became apparent we have to do was to introduce a minimal length requirement for the content of the feedback.

The feedback dialog, which is displayed automatically when a user uninstalls WinSSHD, has four components. There is text which explains that the user can provide feedback, but only if they want to. There is a text area for the feedback, and there are two buttons. One says "Send", the other says "Close". The instructions say that if you don't want to send feedback, just click "Close".

In the beginning, the only requirement to send feedback was that it's non-empty. This was insufficient. We got a barrage of feedbacks that said simply "blah" or "[expletive]" or "doesn't work". Such feedback, of course, is useless - and often just plain mean and insulting. So we now require that the feedback must have 40 or more characters.

The volume of useless feedback is now less, but even so, between 1/2 and 2/3 of all the feedback we receive is "abdfhkjghdfkjghfj..." - garbage characters repeated enough times to satisfy the 40 character minimum. Some feedback even seems angry because we "make" them type it in. Most of these people use an English version of Windows; and yet, they do not seem to realize that they could simply click Close.

Which brings me to the next most common type of frustrating feedback. These are people who have downloaded the SSH server instead of the SSH client, and do not realize their mistake. Here's one such case:
what is wrong with simple ftp transfers? This has a large learning curve, and I don't have a lot of time.

I uninstalled this before I even ran it.

Make it simple:
1. where do you want to connect
2. what is your login name
3. what is your password

That's about it.

terrible interface.
This is feedback from an apparently literate English speaker who has succeeded in downloading, installing, uninstalling, and forming a terrible opinion of WinSSHD, without even noticing the plentiful occurences of the word "server".

The sad thing, the tragedy, is that this is not exceptional. We get feedback like this every day. In combination with the people who send "abcdkjhkjshg" because they don't realize they can simply click Close, this constitutes the majority of our feedback.

Yes, we have also received feedback that was beneficial, and has helped us improve WinSSHD. The feature does help, despite the frustration. And even if all it did was let us know how many people were totally befuddled beyond our expectations - that would be helpful as well.

But still... there is so much of this.

I have already tried changing our download page to clearly identify which program is the server and which program is the client. The only thing that remains to be done is to physically separate the download pages, and attempt to lead the user to the right one.

Yet, I still have some doubts that it'll fix the problem completely.