There’s already a few other posts about the perils of complex software. Features are faults is one. The more we ask a program (or any system) to do, the more likely something will go wrong. This post is about various time saving features that backfire, when some feature promises to save me time but ends up costing more. Or in short, when the smart feature is really stupid.

Some time ago, I needed to install Ubuntu to for competitive research. Download the ISO, start VMWare, and voila, the install wizard takes it away. Instead of making me drive through the Ubuntu installer, the VMWare smart install offered to do all those mundane tasks for me. But something bad happened and what I was left with was an Ubuntu system that allowed me to login at a graphical prompt, but then left me staring at an empty desktop with no means of interaction. Not even so much as an xterm. Logging in on a virtual console helpfully informed me that installation was in progress, but after leaving the system in this state for some time, no progress was observed. I had a very pretty but otherwise useless husk of an Ubuntu system. This may have been a recoverable error, but I wasn’t sufficiently motivated to find out.

I started over and declined the smart install offer, fancying myself a skilled operator. What was the difference? Whereas the smart install asked for a username and password in a Windows styled dialog, the Ubuntu installer asked for the same in a GTK styled dialog. Otherwise, the installation proceeded almost identically, but when it came time to login, I was greeted with a working desktop environment with icons and widgets and whatnot. All in all, I’d say the smart install saved me about seventeen seconds by preselecting the correct timezone, but cost me about ten minutes by forcing me to do the whole thing over in order to get a working installation.

Not the last time VMWare decided to outsmart the user.

Just recently, Apple screwed up Universal Links something fierce. As the old adage goes, if there’s a feature, it’s going to break. Which means if you add a new feature to a rather critical aspect of your program (is there anything more critical to a browser than opening links), it will be very bad when it breaks. A minor time saving feature designed to spare users the indignity of double tapping the home button to switch apps now meant they were unable to browse the web at all. That’s some serious time savings!

I had a vaguely similar experience, where due to the magic of XDG and dbus, Firefox found itself the registered application handler for files of type zip archive. I’d click a link to download a zip file, Firefox would save it off somewhere in tmp, and then dutifully launch the helper application, Firefox. This second Firefox didn’t know any more about zip files than the first one did, but it did know to save the file in tmp and launch the helper application.... Other users don’t have this problem, so it was apparently all my fault, but a somewhat less smart software suite only capable of performing the dumbest actions would have saved me from my own smartness. (I really do pick on Firefox too much, but I haven’t given up hope.)

Despite my affinity for plastic circles, I also use the Netflix streaming service with a Roku. As part of their ongoing campaign to convince me this is a mistake, the Netflix app auto updates itself from time to time. One update changed the main navigation screen to be much more dynamic. No longer is my saved list of what to watch at the top, now it floats around in a sea of suggestions. Presumably this aids discoverability, but here’s the thing. I already discovered a long list of things to watch. That’s why I saved them. Making me scavenge around to find my list is even more annoying than the initial effort of finding things to put on the list. (The Amazon app is similarly dedicated to helping me find things to watch, but not watching the things I’ve already found.)

They really double downed on making the list feature a pain by autoplaying every movie upon selection. Now I can’t add or remove a movie without playing the beginning. Fortunately, I don’t have a data cap at home, but it still causes my receiver to switch audio modes, leading to annoying clicks and pops as it settles in. Not appreciated. My thumb was already on the OK button. If I really did want to watch the movie, pressing it twice isn’t so hard. In exchange for convenience nobody could possibly need, I’m forced to deal with aggravation I can’t avoid.

Also worth considering is that smart designs have the unfortunate property of sometimes failing only partially, worsened by their own internal error handling and recovery. The smarter the design, the more partial and subtle the failure may be, but no less devastating. Remember when Xerox copiers would swap numbers? A copier which churned out blank pages would be infinitely better than one that prints subtly modified copies.

The design of a system should always consider failure modes, and most importantly, recovery. If a smart program fails, will I know? If I do know, will I be no worse off than I started, or will I have to spend even more effort cleaning up just to get back to zero?

It’s been twenty years since the introduction of Clippy. We should know by now that if users have trouble with a difficult task, the solution is not to make the task more difficult. One might imagine the difficulty of task for various users as a bell curve. If we naively squish the curve, as if by pressing down with a finger, we end up with a bimodal distribution, where the task is now easy for one group of users and impossible for another. This is not an improvement.