Make It Automatic

Over the holidays, my colleague Jeff Holt and I usually use the peaceful, interruption-free time to buff up our software. One of our design journeys last week was particularly interesting.

The application we were working on is an application that eats Oracle trace files for a living. You drag files into a pane in the app, or you can select them with our File › Load… menu option. It parses the files you load and displays information about them.

Since our application is complex and the files can be big (gigabytes), it saves information about the files you load in a little embedded SQLite database. That way, if you unload and reload a file (like when you switch your attention from one project to another and back), then the product will just show the cached data for the file without having to reprocess it. This trick makes you feel like our application is processing huge files instantaneously.

To do this, we need to store only about 500 bytes per file. It’s not much, but if you process thousands of files per year, then after a few years, the little database can end up consuming a few megabytes. In 2018, we decided not to worry about it yet. This year (2013), my little SQLite database had grown to 10 MB, and we decided it would be good now to add a feature to delete rows that aren’t helpful anymore.

Our first implementation was to add a new menu option called File › Clean Database… It’s a scary name. Sounds obviously Not Read-Only. It evokes questions: “What exactly, will clicking this option do? Could it result in a regrettable situation?” Somehow, we’d have to explain that to the user.

But how? We don’t make a User Manual for the application. That’s intentional. If a user has to read a manual to understand how to use our product, then our product doesn’t have a good enough user interface.

Jeff noted, “Cary, do you see the three dots on the menu option?” Yes I did. And I know what that means. It’s a convention that means there’s a dialog behind the click. So, I clicked it. The dialog, helpfully, said:

Your 10 MB Workbench database contains 27,356 unloaded files. Delete them? (You cannot roll this back.)

[ Cancel ] [ OK ]

Except it actually said this in an awkwardly wide dialog with no line wrapping. The no-wrapping problem bothered me, because I felt like the user deserved more information, like this:

  1. We use a SQLite database to cache the Workbench application’s files panel information.
  2. Each row consumes about 500 bytes.
  3. If you process a lot of files, you may want to clean up the database.
  4. This feature will delete rows for files that are not presently loaded.
  5. This feature will not delete a row if it has a tag applied to it.
  6. You cannot roll back this delete.
  7. But the risk of deleting too much data is low, because it can all be regenerated, simply by reloading the files.

I felt like a user deserved to know all these things before being comfortable clicking the button. But to change the dialog to one that could display seven steps like these would take more time than I wanted to invest.

Then I remembered: Whenever I find myself thinking about designing a popup dialog, I’m probably thinking about the wrong thing. Over the years, a rule about them has evolved:

The optimal number of popup dialogs for an application is zero. The justification process for creating a new popup dialog should be at least as difficult as the process for amending the Constitution of the United States.

—Cary Millsap

At the same time as I was revolted by the thought of a popup dialog, Jeff was revolted by the idea that a user would have to learn seven simple steps to be fully informed about using the feature properly. He said he’d rather delete the feature than have to explain seven steps about when to use it.

He was right.

Jeff’s revulsion was our turning point.

You see, someone who’s using our software has a job to be done. That job to be done is the whole reason that person is using our software in the first place. And that job to be done is never, “Hey, let’s take 15 minutes off to read this seven-step document about how and why this tool I’m using manages its own internal cache.”

The job to be done will Not. Ever. Be that.

This idea illuminated our path to the solution: We would eliminate the menu option. No menu option, no user manual, no popup dialog. Instead of a new user affordance, we would execute the feature automatically. Like this:

  1. Every time the application starts up, delete any recomputable cache information that hasn’t been used for a long time.
  2. Print information about the delete operation in the application’s log file. (Making our own software highly observable is vitally important to us.)

The result is a product that does more without asking more from the user.

That is what we want.


Leave a Reply

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