Why we hate our PCs

An essay by Warren Montgomery (wamontgomery@att.net)


Personal computers are both one of the most exciting and most frustrating inventions of the past 30 years.  They enable us to do so much, but so often leave us frustrated at not being able to do things that ought to be easy.  There are certainly many more misformated documents, lost files, failing networks, and other problems with personal computers than there VCRs flashing the unset time, and far more effort is spent by users trying to solve those problems.  While buggy software and malicious attacks cause some of the frustration, I argue that most is simply a matter of poor design decisions and ignoring the learnings of the previous quarter century in designing usable, secure, and maintainable multi-user computer systems.  What I present here is a set of design principles, why they ought to be followed, and where they weren't.  I hope that some of the people who read this will think of these issues as they build new computer applications..

People should not be expected to wait for machines

An obvious enough principle on the face of it and one that was learned by the designers and users of timesharing systems.  On those systems a shared processor and storage meant that any job requiring substantial work was likely to take the computer substantial time.  This, more than anything else, is responsible for the fact that those systems all had elaborate scripting languages (shell, job control, etc.) for allowing the user to specify a complex task and allow the machine to complete it without further interaction.  Early on the time saved was spent on coffee breaks or non-computer work, but the most advanced shared systems all included capabilities to allow the user to move on to other work while the slow task was in progress.  These capabilities, like Berkley Job control in Unix, multiple windows on workstations and terminals, and batch execution commands allowed users to be more productive.  As shown below, the same principle really does apply to today's personal computers, even though they have several orders of magnitude more computing power.

Personal still doesn't mean fast

The fact that some things would be slow and the users might want to do something else was almost completely missed by the early designers of PC windowing environments.  They should have known better.  For one thing, "personal" computers always involve technology compromises trading speed in critical areas like disk transfer rates for low cost and low maintenance.  Graphical displays also meant that programs suddenly got much bigger, and unlike shared environments where commonly used programs were often already in memory, they had to be fetched from those slow disks every time the user started a program.  So, if anything, delays became more noticeable on personal machines than they had been in the timesharing world.   After 25 years of increasing processor speed, it still takes several minutes to start most personal computers, and 10+ seconds to start many, if not most applications, both well beyond the time a user can be expected to sit and wait.

Newer and bigger isn't always better

One problem that causes the slowdown is that programs are always getting more comprehensive.  When I first wrote this a couple of years ago  I discovered I had to update my copy of the Adobe Acrobat reader (see proprietary formats below) in order to read a paper I was reviewing.  I wasn't alarmed at this until I had done it only to discover that while my old version (4) loaded rapidly, the new one (6) took a lot longer.  The reason was clear if you scanned the messages -- it was loading a lot of software for things I would probably never use.  Most consumer appliances share the same problems of trying to do too much, but most have learned how to keep the  rarely used features out of the way.  Perhaps PC software designers need to go back and read some of the early papers on dynamic loading and linking to understand how to start up fast without all the excess baggage loaded but still allow the extensions to be loaded when needed.

No more dialogs -- please!

In spite of this, designers still cling to the notion that the user was fully attentive to the machine, fingers glued to mouse and keyboard and eyes glued to the screen.  Thus instead of accepting instructions once and allowing the user to turn away, programs were designed to interact with the user, asking followup quesitons and pointing out marginally useful information with dialog boxes that require user action before the machine moves on to the real work.  One of the greatest frustrations on a PC is to start off a complex task, like installing a new software package or scanning your machine for viruses, only to return an hour later and find it has made no progress because it's still waiting for you to answer one more question before it really starts.

It is most definitely not "OK"

One of the correlary frustrations with this behavior is that so many of the messages produced offer the user no choice but the inane "OK".  It is most definitely not OK that some program just encountered a fatal error and is going to shut down and take the last 3 hours of work with it, so please don't ask me to say that this deplorable behavior is "OK".

I said shut down and I meant shut down!

Shutting the machine off is one of those situations where most people would like to simply flip a switch and walk away  -- not something you can expect to do with a PC.  You shut a car down by turning off the key and walking a way.  You turn your TV off and you don't expect it to pop up a dialog box asking if you really meant it.  When you flip a light switch, you expect the light to turn off.  Some of the misbehavior of PC systems is due to buggy software (i.e. systems that simply hang while still running rather than shutting down), but a major problem lies with programs which come  back and ask the user how to handle any work in progress.  Saving work in progress when the machine is shut down is highly desirable.  Unix systems generally did this too, but had to do it without help from the user, because in many cases the user "shut down" by disconnecting from the system and was no longer available.  Word, Outlook, Powerpoint, and others which insist on asking what to do with work in progress (and in the process stalling shutdown) would be much better off simply treating shutdown as a failure -- save the work in a recovery file and ask the user about it the next time the user goes to re-open the file or the task that was incomplete (not the next time the user does anything with the machine).  

On top of this though, PCs need to make shutdown a certainty.  With virutally all machines now having "soft" power switches which don't cut the power, there's no way to know if a PC will actually power down without watching it.  Someone who has just clicked on shutdown does not want to wait around to make sure it happens.  Imagine a power tool which just kept right on spinning after you flipped off the switch because of a bug in a driver somewhere (and lest you think that scenario is laughable, consider the fact that more and more tools are incorporating computers).

No I did NOT modify this file!

Saving work in progress is a laudable goal, but let's not be paranoid about it.  How many times have you gone to close a file that you just looked at only to have whatever tool you used to view it complain that you haven't saved it since modifying it?  I don't know what triggers this message.  Maybe printing it constitutes "modifying" it, but sometimes it seems that simply opening a file is sufficient to cause windows to believe I modified it.  Of course this behavior makes me suspicious that the machine has somehow been infected with "malware" that did modify the file, and if I save it I will be corrupting it

Commands and Options should be easily Visible

To use software effectively users need to understand both what it does, and all the ways of altering it's behavior.  Unix is often criticised for it's cryptic user interface, yet it had some simple and consistently implemented methods for figuring out what commands were available (list the directories in $PATH), what each one does (the "man" command), and what the options are (invoke the command with a question mark).  

Don't hide the options!


There's no question that presenting the capabilities of a tool in menus makes them easier to use at first at least, but once the user gets beyond what's found on the top level of the menu bar, figuring out where the command to change the font on the message or the password for my mail account becomes an easter egg hunt among far too many possibilities with little help available.  The "options" which control the general behavior of the program are oftne the hardest things to find, sometimes lurking under "edit", sometimes under "tools", sometimes under "file", sometimes requiring a right click, sometimes on the control panel, sometimes a right click on an icon somewhere, etc.  The result is that many users are forced to live with behaviors they find frustrating and annoying because they can't figure out how to change them.  Options should be placed consistently and easy to acdess.

Please let me change the defaults

A consequence of trouble in finding options is that it is often difficult to know whether a "default" behavior of a program can be changed at all.  Can I change the default layout in word for a pasted picture so it doesn't simply land on top of the text like spilled paint?  Can I do anything about those ugly margins?  Can I change the granularity of the hidden grid the controls where I place objects?  How do I get rid of those browser "enhancements" that came pre-installed but I'm not using and are simply occupying valuable real estate on my screen? Why do so many programs have to have firmly entrenched notions about where I should store their files that are simply wrong for me?  Power users spend hours undoing unwanted defaults growing more frustrated every time they do it.  There's no reason why all those defaults can't be changeable, and all easily accessed consistently.

The Grey Death

My award winner for the worst human interface design of all time would be "greyed out" menu entries.  These have the function of telling you in clear terms that the machine knows how to do what you want it to, but that it's not going to let you do it!  The problem of course is that most users have absolutely no clue why the one selection off the menu they really want to make won't select.  What should happen is that moving the mouse over a greyed out entry should produce a little explanation of why it's greyed out. not just a total lack of response.

Consistency is the real key

Consistency empowers users to do the right thing without having to think about it.  Consistency has been a key driver for PC applications, but not always achieved.  Inconsistent choices about where the options occur is only part of the larger problem.  Why, for example, can I display multiple word and powerpoint documents but not multiple spreadsheets at the same time?  In an immature field inconsistency is to be expected, but PCs are no longer immature.

Sooner or Later all disks fill up -- Plan on it.

If a rule of life is that you can never be too rich, a rule of computers is that you can never have too much memory, both in the machine and on disk.  PC hard drives have storage capacities unimagineable in previous eras, but digital media and bulky programs quickly fill them.  The trouble then is that the software often responds badly to the now completely unexpected condition of having insufficient space to save something. 

Please let me put the software where I want!

My last laptop had what seemed like a giant amount of space -- 15 gigabytes.  Unfortunately it was partitioned into two drives, one nominally for system files and one for user files.  The trouble is that as I installed and ran applications, I filled up the "system" drive.  An obvious solution would of course be to move some of this software elsewhere, but PC applications are often hard wired to put their files in standard places ("program files", "windows", etc.) and this proves to be quite difficult.  With a great deal of digging around I figured out how to move out some of the space hogs and limp along until the machine died for other reasons, but space management was a constant hassle. 

Those built in places were the root cause of another major source of problems -- naming conflicts with shared files and parameters, often caused by multiple versions of the same program or programs from the same family (e.g. office).  In most time-sharing environments, software programs were more self contained and capable of being installed anywhere.  There was never a problem in having multiple versions of the same program on a system (in fact having worked at the development site for at least 3 timesharing systems I'd say it was quite common to have "alpha" and "beta" versions of new releases co-exist with the production version).  In windows this is close to impossible, since all versions dump their files into the same shared directories, often overwriting earlier versions.  That laptop had pieces of at least 4 different versions of Word on it and depending on how you started it (click on a file, desktop icon, or startup menu) it tried to start different ones.  Only one, the last one loaded, was actually correct.

Death by log files, caches, and backups

 Compounding the problem of running short of system space is the hidden space consumed by files created and extended automatically by the system.  Most Windows operating systems keep a log of previous installation activity to be able to back it out.  This is good, but the file is hidden from normal views and consumes a LOT of space, causing you to suddely run out of space due to normal archiving as a result of software installs.  Many programs keep log files and rarely delete old ones.  Thus just normal use tends to fill up directories the average user probably has no idea exist.  Once space becomes tight, operations start to fail in mysterious ways.  If the user is lucky the system will at least hint at the space problem, but cleaning out all those logs and caches may be difficult to figure out, and is at best only a temporary reprieve as long as the software that produced them continues to fill up the space.

Never run downloaded code for the user without explicit and informed authorization

The door-to-door salesman rarely gets past the front door any more, and when they do they are never left alone.  People lock their doors to keep out unwanted guests.  Someone proposing to start a new service which required giving the delivery agent a key to your house probably wouldn't get very far, yet this is exactly the assumption behind way too much of the web and email system. Back in the early days of computing, when designers of shared machines began to consider security, one of the firmest principles was to be very restrictive in what programs you allowed users to run and what access they were given.  The notion that a user would be asked to take a program attached to a mail message and run it to read the contents would have been laughable, yet this is exaclty the assumption built into web browsers and email clients.  This single mistake is responsible for the billions of dollars in damage caused by computer viruses and worms every year.  There is no excuse for this and no reason users should continue to tolerate being forced to expose their systems to it.  It is, though, quite difficult to disable all of the "automatically executed content" features in web browsers and email clients.  The number of places that external programs and scripts can be run in fact makes it difficult to know if it is possible to block them at all.

Viewers should control what they see, not senders. 

One of the reasons for allowing executable content in web pages and email in the first place was to support what is in my view another design mistake -- the desire of the creators of web pages and email to assume control over what the user actually sees.  This was not always so.  The web, was based initially on the concept of representation independent markup languages, in which the composer describes what a piece of text represents (a heading, a link, a figure caption, etc.), while the receiver decides how he or she wants to view it (what font, what size, what color, what shape, etc.).  This has many benefits, including empowering users with unusual viewing devices or vision impairments to pick representations that work for them.  It did not, however, fit the model of the print world where layout designers decided what everyone saw, and it certainly didn't fit the model of an advertising driven business where advertisers would really like to have control over the user's eyeballs and prevent them from skipping the adds.  Soon, web pages and email dictated not only simple layout choices but included downloaded executable code for such things as animation and user dialogs.  Not a fatal security error yet, but unfortunately well on the way to disaster.  I don't know who first decided that the little scripting langauges sent along with emails and web pages needed to be able to do things like access your address book, send email, or change system defaults.  Probably someone just trying to make life easier for users (click here to install our new application), but alarm bells should have gone off with that one.

Information needs to be in Open formats.

Another common reason for accepting programs with your emails and web pages is to decode information passed along in proprietary formats.  Unix and the time sharing and workstation systems contemporary with it adopted as a firm principle that information stored in files should be in open formats, available to any program.  A  major reason for this was reaction against the problems caused by obscrure proprietary file formats in mainframe systems at the time.  Those were of course the difficulty of sharing files and the need to constantly update programs to cope with new file formats.  Sound familiar?  Unfortunately, many application vendors in the PC area got away with creating unique proprietary formats for their files making it difficult or impossible for a user to share a file with another user unless the recipient also has the same software.  This is the ugly secret behind Microsoft's success in gaining a near monopoly in office productivity tools.  It is also behind their success in web browsers, email, and many other application areas.  

Most of us CAN walk and chew gum at the same time -- don't assume we can't!

Another common failing of windows software is that it often targets the total novice at computers, at the expense of the power user.  While being novice freindly is important, it's also important to realize that most of the time spent at the keyboard is spent by people who use computers for several hours a day, and Novice freindly shouldn't make things harder for the experienced user.  Again, many earlier systems approached this by designing an underlying core system that was simple, and placing various "shells" on top of that, including those aimed at the novice, and those aimed at the power user.  The trouble with Windows (and for that matter the Macintosh), is that the "novice" user interface came first, and the entire system is designed around i's assumptions.  Some aspects of this have already been discussed, but here are some other consequences of that design:

Please let me read one window while typing into another

Previous multi-window systems in Unix and various other systems separated the concept of which window got the keystrokes (the input focus) from which window was physically on top.  While this might confuse a novice, it is a powerful tool for the experienced user, who can often find him/herself needing to refer to information in one application while typing into another.  This is a maddening task on a small windows screen, because there isn't enough screen space to display both windows side by side and windows insists that the one you type into be on top.  On other systems this was easy to do by putting the reference window(s) on top and leaving only a small portion of the typing window visible.  

Don't Steal my characters!

Another probably unintended consequence of windows insisting that the top window be active is that often times an application started in the background will suddenly spring to life and pop up on top of whatever you are doing and of course start stealing your characters and mouse clicks.  Most of the time this is simply annoying (yes, I know my anti virus subscription expired and I have new updates but I don't want to deal with that now), but you are lucky if  what you type doesn't trigger some disasterous behavior.  Aside from things that happen asynchronously, like software updates, "power" users will often find it useful to fire up applications without waiting for them (see speed above), but of course with windows you can't because the web browser you fired up because you thought you might eventually need it and didn't want to wait while it loaded all its plugins keeps popping up in front of the email you are trying to read because it simply assumes you are waiting for it.

Formatting Follies -- What I see should reflect everything I'm going to get

One quantum leap in user interfaces from previous computing systems to PCs was with tools capable of presenting and editing formatted information (What you See is What you Get).  Again, this is a great benefit to users to be able to see and work with the formatted copy, but it can also be the source of great frustrations, because the document actually does contain formatting that is not visible to the user and is processed in ways that are not obvious. 

Why did my document turn into a pumpkin?

One of the most common irritants is having a seemingly innocuous keystroke change the formatting of an entire document. A very common  problem is unexpected results from deleting the end of a line -- Often the format of the text you are working on changes to match that of text in front of you.  The basic design fault here is that Word, and perhaps other formatters, attach the formatting information to the end of the paragraph you are working on so that when you delete the paragraph break, the current paragraph takes on the format of what follows it -- This is of course almost never what the user wants and is often mysterious.  Most people think about documents linearly, and formatting commands apply to the text that follows the command, not the text that preceeds it.  Text formatters should adopt the same convention.  The reason people so often corrupt a document by deleting a line break with hidden formatting is due to another design problem:

Don't select the end of line unless I tell you to!

It is very common to want to select and delete the remaining text in the current paragraph.  Unfortunately, it is extremely difficult to do so without also selecting and deleting the magic "end of paragraph" mark which holds the key to formatting the text before the stuff you were trying to delete.  This is I believe because Word treats that mark as if it appears immediately after the last printed text, usually a very narrow character like a period, rather than beyond the end of the line on the screen.  The attempt by Word and other tools to make "smart" selections, extending the characters you told it about to include whole words, seems also to play into this.  Neither though fully explains the "document turned into a pumpkin" problem that seems so common..

Do what I say, not what you think I meant to say!

Back in the 1970's, systems that would "Do what I mean" was one of the goals of research in artificial intelligence.  While "smart" systems which attempt to figure out what the user really intended have become common in PC software, judging from the results it is still a topic more appropriate for research than for production use.   Sometimes when word tries to do something "smart",  you find it out in time to undo it, but often these "smart" maneuvers have wide reaching effects that aren't noticed until it is difficult or impossible to undo them.  I was recently entering some names and telephone numbers into a document and after a while was surprised to see that my data had become a numbererd list with rather large numbers -- it seems that word had taken a 3 digit area code typed at the beginning of a line as indicating that I was trying to enter a numbered list, and when I entered a new line helpfully pre-pended the next higher number to it.  The result was a good laugh and about 5 minutes of fumbling to rid the text of unwanted lists.   On several occasions I have received  a document that had somehow activated a "feature" whereby every formatting change I made to a normal paragraph of text was instantly applied to every "normal" paragraph in the document.  This was quickly compounded by the automatic formatting listed above, as entering a single number suddenly transformed every paragraph in the document into a numbered list element.  The effects of this disaster were impossible to completely undo and eventually left me with a document which displayed one line of text on every page because of extra whitespace added around the "normal" paragraphs in the page headers and footers that was not removed by "undo".   (I'm still trying to figure out how to get rid of the 2 inches of white space in front of  all my second level headings that "magically" appeared in a 100 page document)

What we have here is a failure to communicate

When the internet first moved beyond something to connect mainframes at universities and government sites, Microsoft all but ignored it.  Then, playing catchup, they bundled networking into just about everything.  The change of heart left a good deal of confusion in how PCs work in networked environment.

PC -- don't phone home

Early PCs were never connected to high speed networks and if they networked at all connected by phone.  That's still probably a common way home users connect.  Unfortunately PC software designers work and live in a wired and always on environment and have started to just assume that computers are always connected to the internet.  Thus many seemingly local actions may actually trigger software to try to connect to a network.  That alone was bad enough (Yes, I know I can't connect, that's why I clicked on Help to figure out what's wrong, no fair putting the help files on a web site!) Microsoft "solved" the problem by allowing Windows XP at least to automagically connect to your preferred internet service whenever a program wants access to the network.  This naturally results in a lot of unexpected attempts to communicate.  Many users, in frustration, grant their machines unlimited access to a phone line -- not a good idea.  Aside from the potential to interrupt anyone else using that line, it opens up the possibility that that cute little web page you downloaded is on the side dialing up a very expensive surprise for you when it phones home to a high fee number.  Even in an installation where the machine is connected to a high speed network the constant need of applications to "phone home" isn't a good idea.  Aside from putting unneeded load on networks and those home base web sites, and introducing another source of delays for users (one reason applications start slowly is that they often go looking for updates to central servers and those requests may not get prompt responses), those constant requests to communicate make it difficult to detect malware.  The one time my machine was infected (due to a careless click on an attachment that seemed to come from a system administrator) I caught it immediately because my firewall caught the program's attempts to communicate.  That wouldn't have happened had I simply granted unlimited access for programs to access theinternet, as many people do after having to deal with repeated requests by legitimate applications that they can't imagine accessing the network (for example, the Solitaire game)

Can we Talk?

Most PCs now come with local area network connections and software to share files and peripherals over networks.  This of course  means that most users have a new sense of frustration as they try to get this stuff to work.  The fact that the public newsgroups for discussing networking problems get hundreds of posts per day shouldn't surprise anyone who has tried to get their machines to talk with each other.  Neither should the fact that many of those problems are never solved, nor that networking is probably the biggest source of business for PC troubleshooters.  Networking shouldn't be rocket science.  The jumble of configuration parameters and options is one source of trouble, as are options that often don't make sense or little "fixes", like internet connection sharing or crossover cables intended to solve little problems that solve problems some folks have but get in the way elsewhere.   One of the great hopes of course was that with Windows XP, Microsoft would finally get it right and this would be easier.  It's no surprise that the discussion groups for XP carry more traffic about networking problems than those for earlier newsgroups.  

Again, the tendancy to try to do things for you seems to be one of the culprits.  Wizards that automatically configure the settings are great -- unless there's something just a bit unusual about your equipment and that automatic configuration breaks something.  Automatically configuring wireless networking is in principle a great idea -- periodically interrupting your wireless network to go looking for better ones wasn't such a good idea, at least not as long as the networking applications running over it were not designed to tolerate the loss of the network for a few seconds while this takes place.

A second problem is I suspect simply that too much of the networking software was designed for the "sunny day" scenario.  My computers at home are networked through a wireless LAN, but I suspect it's not a typical configuration.  The broadband internet connection connects to a wireless router and all the machines connect without wires.  That works fiine accessing the internet, but machine to machine networking (like printing and file transfer) have always been problematic.  I strongly suspect that's because each packet transferred between machines must traverse the wireless network twice (once to the access point and then again to the target machine, and the result is much more frequent networking collisions and packet loss than the software expects.  The result is that transfers almost always hang up moving large files and the failure is never recovered automatically. 

Maybe the fix is to insist that developers of networking software work with "bad" networking environments that will challenge the error recovery in their designs, rather than on clean corporate networks.

So, how do you fix this mess?

The problems noted above have been around for a long time.  It's easy to blame Microsoft, but they aren't entirely to blame as many of these problems also show up in software written by other providers.  A large part of the problem is that the computer software industry hasn't done well in learning from history.  The principles and problems here aren't rocket science, and they were "solved" by earlier generations of technology.  Too often a new crop of designers working in new technologies assumes that the new technology makes the hard lessons learned in previous technologies irrelevant.  They rarely are.  I've heard from structural engineers the claim that throughout most of modern history there have been major bridge failures about every 20-30 years, because that time is just long enough for a new crop of engineers working with new technologies and designs to start work lacking the insights of their predecessors or believing that the old learnings don't apply.  Perhaps our system of educating computer professionals needs to be more conscious of and more focussed on teaching the lessons of history.


There is a blame we all share in the poor quality of PC software: The fact that we aren't better consumers of software.  It's just too easy to take the software that came with your PC and not insist on something better.  If  a car maker performed as well as the PC software industry, that company would be out of business after having devastating losses due to lawsuits and recalls.  We need to apply the same standards, if not the same methods to the quality of software that we allow to run on our desktops.