Are we assuming users are really dumb?

Update: This is a general criticism of modern development trends. Despite appearing on Planet GNOME, and referencing a current debate, this is not at all specific to GNOME. The point listed below was more a maintainer screw-up than anything else. It’s not a debate on good usability, because everyone has different opinions on it, none of which are right. The point you should be caring about is how users are treated. I know we’ve assumed too little of some people in Gaim and other projects. Not always, but often enough, and I know many other large projects do this as well. So please, focus on that part.

I completely agree with Davyd on the contextual information lost in notifications. I like GNOME, but I feel that we are taking a step back in this regard, and it’s leading me to wonder, are we assuming our users are really, really stupid and need hand holding?

Now, the Linux desktop is maturing, but there are a lot of areas that could be made easier. Things that confuse users. I hardly think “JPG” or “PNG” or “SSH” emblems are one of them. And really, do we think users have never seen JPEG or PNG files, have never heard of them, and would be confused and scared to use their desktop if they saw them?

If a user is connecting to a remote server and mounting it, they probably have some kind of understanding as to what SMB or SSH means. I mean, come on, they have to choose it first! It’s not some random technical thing we’re throwing at them. Context is good, and I know a lot of average users who prefer the context and turn on file extensions on Windows because they want to know what kind of file they’re actually working with.

The common question that I always hear is “but can my Grandma use it?” Are we really targetting senior citizens? If so, we’ve lost. Let’s take a page out of the proliferation books that McDonalds, Microsoft, and everybody else uses. It’s a simple one. Target people when they’re young! Contrary to popular belief, a number of teenagers use computers, and these teenagers understand things. They’re using bittorrent clients, maintaining websites, sending files across the Internet. Should we really treat them like they’re idiots? Sure, Grandma may not know what a JPEG file is, but I doubt she’s a heavy computer user anyway. Most likely, she plays solitaire, and I think her hand can be held with anything else. In the meantime, let’s not forget our younger users who really aren’t as stupid as we’re starting to treat them.

20 Ways to be a Good User

I don’t expect anybody who should read this to actually read it. A couple of users the past few days have inspired me to write this little guide.

  1. If you request support in a channel and nobody is around to answer within two minutes, make sure to voice your frustration and leave immediately. Make sure that you stay for no longer than four minutes in total.
  2. If a developer tells you the answer you’re searching for is in a piece of documentation easily accessible, refuse to read it, perhaps citing an inability to read. Your time is important, and the developer should know the answer.
  3. Don’t read instructions or information in detail. Glancing over it should be enough. If glancing isn’t good enough, repeat your question. Don’t add any additional information to this question, or it might confuse the situation.
  4. Remember, you use this software. You have rights. The developer’s personal life, work life, or stress level is completely irrelevant. If they don’t provide the level of help you expect, remember that this is not your fault, but theirs. They owe you support, and be sure to complain loudly in as many forums as possible.
  5. NEVER thank someone for their support. They’re working for your needs, and don’t deserve any gratification. Besides, thanking them gives them a sense of control, which you should attempt to keep for yourself.
  6. Your problem is the most important. The developer may have other people they are trying to help, but it’s unlikely that their problems are more important to yours. Be sure to explain this, loudly if necessary.
  7. If you are influential at all, your opinion matters more than anybody’s. Follow the previous rule, as it will definitely produce a positive outcome. Be sure to relate the developers in question to members of organized totalitarian political parties.
  8. The more supportive you are of a developer’s software, the more support you deserve.
  9. Don’t use punctuation or bother with the spell checking. This slows down the communication between you and the developer.
  10. Insult the developer. This establishes control which, as previously mentioned, is important. Support should be thought of as a battle. Popular insults include “asshole,” “mother f**ker,” “dipshit,” and “newb.” Insulting their mother is another good way of establishing control.
  11. If your problem is very important, make sure to complain loudly about the software in general on several popular forums. The louder you complain, the more likely it is that the developers will fix your problem.
  12. If you’re confused by the “support” that the developer is giving you, don’t feel bad, as this isn’t your fault. This is the developer’s fault. Developers live in a different world. They’re nerdy, geeky, socially inept people who aren’t able to clearly get points across. Tell them this, as they probably don’t realize it. It is sure to ease the communication.
  13. As a user, you’ve come to know this software, probably better than the developer. If the developer says something about the software, take it with a grain of salt. They’re only the creators. You’re the one that uses it.
  14. Don’t waste time by upgrading to a recent version of the software. The bugs you have are important, and upgrading may introduce new bugs. It’s best to get the current bug resolved. If necessary, inform the developer that they need to create a patch release. This is especially important if the software is several years old.
  15. You represent the majority of users. Your feature request is everybody’s feature request, and it isn’t a hard to implement, really. The developer should be able to do it RIGHT NOW. Drill this in to the developer when they start stating bullshit like “that feature requires a rewrite of our codebase,” or “that feature conflicts with this other feature,” or “we’ve never heard of anybody wanting this feature before.” They’re just lazy.
  16. If you have a family member or close friend that tells you a fact about a piece of software, and the developers try to tell you that your family member or close friend is wrong, they’re just jealous. They don’t want to acknowledge your family member or friend’s expertise, especially if your family member or friend can “program” Microsoft Office onto your computer.
  17. Documentation is essential to a program. Many developers will claim they have not had the time to produce extensive documentation, citing work or personal life or other bullshit as “reasons” for not spending time on this. Often, they will ask you to do it. Have no part in this, as it’s a trap. If nothing else, they will try to take credit for your hard work.
  18. It is your responsibility to fill out as many feature requests and bug reports as possible. Do not check for duplicates in the bug tracker, as the more redundant bugs that exist, the more likely the developer will notice and fix these bugs, or implement the features.
  19. Sometimes you just have to switch to a competitor’s program. Your problem may be trivial, according to the developer, but it’s still a problem, and if there is one problem, there may be many. What are the chances that the competing program would cause problems?
  20. If the program is open source, fork it. You can do it better. To gain press coverage, post on all the forums and popular news sites. You’ll gain more respect and developers this way.

I hope this has helped all the users out there.

NOTE: For the sarcastically-impaired (if you live somewhere in the vicinity of Betelguese, this includes you) do not actually take this advice.