Computers suck

Chris made a good point in his last blog entry. Computers suck. So I’ve decided to rethink how computers work. Here is my new set of guidlines for how computers should work.

1) Computers should provide an intuitive interface that painlessly allows users to do stuff.

2) Computers should continue to be this way and not degrade over time.

Thats it. Those are my rules to how computers should work. The problem is that this is extremely hard.

This doesn’t actually seem very hard. To make an inuitive interface for a user, you ask the user what they want, and then design an interface to accomplish this task. This works great for computer scientists and software engineers who know exactly what they want to do. The problem is that most users don’t actually know what they want to do. Or if they do know what they want to do, they don’t know how they want to do it. Obviously, this is a challenge, but thats not what I want to talk about right now. I want to talk about my second rule: Computers should not degrade over time.

So why do computers degrade over time? There are four main sources of “degradation” that I see.

1) The operating system
2) Installed programs
3) The user
4) The hardware
The operating system

Anyone who has used Windows 95 is well aware of this problem. Inconsistent filesystems that corrupt system files, kernel crashes, etc. These are all extremely solvable problems, and most of them have been solved by modern operating systems. The OSX kernel, linux kernel, and NT kernel have all basically solved most of these problems. For the most part, the kernels themselves are extremely stable and extremely unlikely to crash in any scenario. This isn’t the most common cause today so I won’t say any more here.

Installed programs

Within this category there are two types of programs that degrade the computer experience. Unintended software installs (like malware) that purposely degrade the system is a serious problem. The answer to this problem is to require the user to explicitly give consent when software is installed, and eliminate any vulnerabilities that allow this mechanism to be bypassed. Even this, however, is not a fail-safe, since users often do not know what they want to be installed. This is a problem that lacks a solid solution at this point in time. (Hint: User education is not an acceptable answer).

The other type of program in this category are intended software installs that degrade software through improper/sloppy/lazy coding that causes unintended interactions to the detriment of system performance. Microsoft bloggers are constantly trying to educate software engineers how to write code that doesn’t have negative interactions. For instance, calling undocumented system calls is a Bad Thing. Writing directly to the memory of another process is also a Bad Thing. In a sense, the operating system is at fault for not isolating programs thoroughly enough. If each program was run in a sandbox with no interaction with other programs, there would be no degredations in the system’s user experience. This also means, however, that we would have a lower starting point for user experience, which violates rule 1. The challenge here is to design the operating system in a way that makes it difficult for programs to negatively impact each other, while maintaining seamless integration. This is Hard. Steps that Microsoft is taking towards this end include Limited User Accounts (LUA) and User Mode Driver.

Users

Users can also degrade their own user experience (Surprise surprise!). There are two competing interests here: the power users who want to be able to do anything they want, and “normal” users who should be prevented from doing things they “shouldn’t” be doing. In addition to this, a user should not have the capability of degrading the user experience for another user. Unix has long had this ability as a multi-user operating system. Try ruining the user experience for another user on a unix server. For all intents and purposes… you can’t. Windows NT has had this ability, but it has taken a large amount of work to make this tenable for a desktop user scenario. Limited User Accounts (LUA) will hopefully make this a reality for the average user.

The real problem is that the average user doesn’t understand why they should be “limited”. Try telling a corporate executive that he can’t do whatever he wants on his own computer. Try telling him that he isn’t allowed to be an administrator on his own computer. Make sure you prepare your resume, because you’ll be finding a new job. I think there is a subtle answer to this problem. Don’t call the users “limited”… call them “protected”

Hardware

This is actually an issue that is often overlooked. Three of my friends recently bought Dell B130 laptops. To be honest, they suck. Everything feels sluggish and unresponsive, which is unacceptable, considering that the specs are fairly reasonable: 512MB-1GB of ram, 1.6 Ghz Pentium M. This should be more than enough for windows XP, which is very resource friendly by todays standards (compared to Vista… but that’s a different story). The problem is that you get what you pay for. Dell entry-level computers are called entry-level for a reason. 500 dollars will not buy you an amazingly responsive laptop. I’m currently using a Gateway M285 laptop, which is in Gateway’s professional line of computers. The specs are not mind-blowing compared to the specs of the Dell B130, yet there is a significant difference in overall performance.

So in conclusion, what is the point I’m trying to make? Computers suck, and they tend to suck more over time. In the past, this has not been an important issue, since technology becomes obsolete faster than your computer starts to suck. In the future, this will become a more important issue. Degredation in user experience comes from many sources. Solving these problems is extremely hard, but the point is, they are solvable. It just may take us awhile to solve them.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>