Re­cent­ly, I at­tempt­ed to an­swer a ques­tion on SE.SE, which was a bla­tant XY prob­lem. The au­thor of the ques­tion mis­un­der­stood the prob­lem he was fac­ing, came up with a so­lu­tion which would only make the is­sue worse, and asked how to im­ple­ment this so­lu­tion tech­ni­cal­ly.

More pre­cise­ly, the per­son was com­plain­ing: “our users are be­ing sil­ly and close a form win­dow in­stead of press­ing the save but­ton.”—it is ob­vi­ous here that the user in­ter­face is com­plete­ly bro­ken, and needs to be fixed by match­ing the users' con­cep­tion of the piece of soft­ware.

I tried to ex­plain the is­sue, but, long sto­ry short, wrote a long an­swer that, while be­ing out­stand­ing in terms of the dif­fer­ent con­cepts, was rather poor in prop­er­ly com­mu­ni­cat­ing them, and re­quired a ma­jor shift in par­a­digm that the au­thor—and a few oth­er mem­bers—were not ready to make.

In my an­swer, I also men­tioned a dif­fer­ence be­tween the ap­pli­ca­tions that keep some­thing the user works on in volatile mem­o­ry, and the ones that per­sist it. See, when I work with a pho­to in Adobe Pho­to­shop and the pow­er goes off, my changes are lost, un­less I man­u­al­ly saved them pri­or to the out­age. How­ev­er, when I work with a pho­to in Adobe Light­room, flop­py disk but­ton is nowhere to be found.

From the per­spec­tive of the user, the Light­room par­a­digm makes sense, while the Pho­to­shop one is bro­ken.

For­get for a mo­ment about com­put­ers. Imag­ine that you are speak­ing with a col­league, and ask­ing him to per­form a task. You take half an hour ex­plain­ing the task in all the de­tails, but then you get an ur­gent call which abrupt­ly stops your con­ver­sa­tion with your col­league. As soon as you end your call, you come back to your col­league.

— So, every­thing's clear re­gard­ing the task?
— What task?
— The one I gave you.
— I'm sor­ry, I have no idea what are you talk­ing about.
— Wait, what? We spoke. Five min­utes ago.
— I don't re­call. Did you for­get to ask me to re­mem­ber our con­ver­sa­tion?

It feels weird, isn't it? And still, soft­ware be­haves ex­act­ly like this all the time.

Why would soft­ware prod­ucts do that?

His­tor­i­cal­ly, per­sis­tent mem­o­ry was not very good at fast writ­ing. In or­der to avoid slow­ing down the user, com­put­ers were stor­ing things in mem­o­ry, and used per­sis­tence only on rare oc­ca­sions. Many pat­terns em­merged, where the de­ci­sion to per­sist was giv­en to the user.

This came with a huge prob­lem. You are work­ing on Fri­day evening on an im­por­tant re­port. You just fin­ished it and you are about to press that mag­i­cal flop­py disk but­ton and go home, when sud­den­ly your com­put­er crash­es. How sad!

My cur­rent PC has an M.2 NVMe SSD with read and write speeds of 3 GB/s—that's near­ly half the peak speed of the RAM I had three years ago. So should the so­lu­tion be for the soft­ware prod­uct to just per­form a Ctrl+S at every user ac­tion?

That would prob­a­bly be a re­al­ly bad idea.

You see, if I'm work­ing with a large im­age in Adobe Pho­to­shop, sav­ing the mod­i­fied im­age every time I per­form an ac­tion is very like­ly not what I want. It would slow me down even with a 3 GB/s SSD, and things would get re­al­ly ugly as soon as I would work on a slow­er ma­chine. More­over, it would in­crease my elec­tric­i­ty bill. And, most im­por­tant­ly, this is ab­solute­ly not what I want—I may de­cide to per­sist the changes I make, but I may also de­cide to dis­card them.

Take Adobe Light­room. Here, all the changes are al­ways per­sist­ed, au­to­mat­i­cal­ly. But they are not per­sist­ed in the same way a Ctrl+S would do in Adobe Pho­to­shop. What hap­pens is that I can al­ways close Light­room, re­open it lat­er, and go back through every change I made to the pho­tos. Light­room doesn't au­to­mat­i­cal­ly rewrite the pho­tos. Quite the op­po­site: it nev­er changes the orig­i­nals. In­stead, it stores only the his­to­ry of the changes I do.

Many oth­er mod­ern ap­pli­ca­tions be­have the same way. Google Keep, for in­stance, keeps the ver­sion his­to­ry of the notes. Oth­ers, how­ev­er, use a dif­fer­ent ap­proach. In What­sApp, for in­stance, drafts are al­ways per­sist­ed, but you can't go back. This makes sense. While Light­room is all about ex­per­i­men­ta­tion where it is very like­ly for a user to want to go to some pre­vi­ous edit­ing step, and Google Keep is oc­ca­sion­nal­ly about long notes that were edit­ed for a long time and rep­re­sent quite a lot of ef­fort, What­sApp is for rel­a­tive­ly short mes­sages that are ex­pect­ed to be send to the re­cip­i­ent rather quick­ly—a his­to­ry is pret­ty much use­less in this sce­nario.

Some soft­ware prod­ucts also use a no­tion of com­mitt­ment—an ac­tion by which the user tells that he fin­ished the work he was do­ing. In What­sApp, the com­mitt­ment is the fact of click­ing a but­ton to send the mes­sage to the re­cip­i­ent. In Light­room, it's the ex­port func­tion that would pub­lish the JPEGs to a re­mote ser­vice. In Vi­su­al Stu­dio Code, it's the ac­tu­al Ctrl+S—yes, the IDE per­sists the changes to a spe­cial lo­ca­tion, so that you could close the IDE with­out sav­ing, and when you come back to it, your changes are still there as if you nev­er closed the IDE in the first place. As I write this ar­ti­cle, my blog en­gine per­sists all the changes to the data­base. Com­mitt­ment, in this case, would be an ac­tive ac­tion for my part of pub­lish­ing the draft.

His­to­ry per­sis­tence and com­mitt­ment pat­terns are two ex­cel­lent ideas from the per­spec­tive of user ex­pe­ri­ence. They bring elec­tron­i­cal de­vices much clos­er to the real world.

If those ex­cel­lent ap­proach­es are used in Adobe Light­room, why wouldn't Adobe use them for Pho­to­shop as well? I would guess that this is all about the same hard­ware con­straints. You see, in Light­room, while there is an orig­i­nal raster im­age, all changes that are ap­plied to it are not raster. High­lights ad­juste­ment, use of a heal­ing brush, or crop­ping are all rel­a­tive­ly tiny in space to store. This makes it pos­si­ble to per­sist all those changes on the fly, with min­i­mal im­pact on hard­ware. Pho­to­shop is a bit dif­fer­ent: while some us­age is sim­i­lar to Light­room's, there are also many cas­es of di­rect raster changes, which could quick­ly grow to megabytes or even gi­ga­bytes of data to be writ­ten. I would guess that, at some point, Adobe de­vel­op­ers would find a way to get rid of the flop­py disk but­ton, but we're not here yet. Mean­while, the but­ton is a re­minder of the lim­i­ta­tions—both soft­ware and hard­ware—but by no means a pos­i­tive thing that needs to ex­ist, un­less it ex­ists in a form it is used in Vi­su­al Stu­dio Code—to act as com­mitt­ment, and not a will­ing to per­sist the changes.

Save but­ton is re­as­sur­ing

When dis­cussing this sub­ject with a col­league, he made an in­ter­est­ing re­mark. It is re­as­sur­ing, he said, to have the flop­py disk but­ton.

We start­ed ex­plor­ing to­geth­er what ex­act­ly is re­as­sur­ing, or more pre­cise­ly, why the lack of a save but­ton is mak­ing him anx­ious. It ap­peared that when he uses ap­pli­ca­tions such as Google Keep on his smart­phone, he would still pre­fer hav­ing a flop­py disk but­ton there. Pro­gres­sive­ly through our dis­cus­sion, it ap­peared that the per­son was not con­fi­dent that per­ma­nent per­sis­tence is ac­tu­al­ly work­ing as ex­pect­ed, as he had no clue how it ac­tu­al­ly works. Tak­ing Google Keep as an ex­am­ple, if I'm writ­ing a note, is the note per­sist­ed af­ter every key­stroke? Or at reg­u­lar in­ter­vals? Or when a user per­forms an ac­tion, such as switch­ing to an­oth­er note, or clos­ing the ap­pli­ca­tion?

The prob­lem is that the very same per­son had no ac­tu­al idea what hap­pens when he asks an ap­pli­ca­tion to save a file that he's mod­i­fy­ing.

Let's take an ex­am­ple of a file stored on a hard disk. I edit it, close the ap­pli­ca­tion, and when asked if I want to save the changes, I say “yes.” Half a sec­ond af­ter the ap­pli­ca­tion is closed, there is an out­age. When I turn the PC back, what should I find?

There are two im­por­tant things here.

First­ly, the op­er­at­ing sys­tem doesn't nec­es­sar­i­ly write the file im­me­di­ate­ly to the disk. It may cache the data, tell the ap­pli­ca­tion that the file is saved, and per­form the ac­tu­al save a bit lat­er.

Sec­ond­ly, hard disks have use in­ter­nal cache to en­hance read/write per­for­mance. When asked to write a file, the op­er­a­tion would ter­mi­nate usu­al­ly be­fore the file is ac­tu­al­ly per­sist­ed on the hard disk plat­ters. It may also be com­plete­ly in write cache, or par­tial­ly on plat­ters, and par­tial­ly in cache.

This means that af­ter the out­age, you may find the last ver­sion of the spread­sheet you saved, or the orig­i­nal ver­sion, or a cor­rupt­ed file (de­pend­ing on the file sys­tem and on the way the ap­pli­ca­tion ac­tu­al­ly per­forms a file save).

Oth­er types of stor­age re­quire even more con­sid­er­a­tion. If you're us­ing a di­rec­to­ry that is syn­chro­nized with the cloud, the ac­tion of press­ing Ctrl+S means ab­solute­ly noth­ing. It may take sec­onds or even min­utes be­fore the new ver­sion reach­es the cloud. Or, some­times, not at all, if there is a net­work is­sue, or the syn­chro­niza­tion ser­vice is down.

Imag­ine a ma­chine that uses RAID 6 and also per­forms back­ups to an off­site data cen­ter once per hour. If you want to be con­fi­dent that the file was saved prop­er­ly, you need a bit more than a Ctrl+S. You would need to start by check­ing the sta­tus of your RAID. If there are two fail­ing disks, too bad—you could pos­si­bly lose your mod­i­fi­ca­tions in a very short time—as soon as one of the re­main­ing disks fails. Any­way, af­ter check­ing RAID, you'll wait for an hour for the repli­ca­tion to take place to the off­site data cen­ter. Fi­nal­ly, you'll have to ver­i­fy that the repli­ca­tion was suc­cess­ful.

Save but­ton may be per­cieved as re­as­sur­ing, but it only hides the com­plex­i­ty of the ac­tu­al process. Users want to be­lieve that Ctrl+S is enough to keep their file safe, while in re­al­i­ty, the ac­tion means lit­tle about the ac­tu­al per­sis­tence of the data. In fact, it doesn't cor­re­spond to “the changes are now per­sist­ed,” but rather “the changes were en­queued to be per­sist­ed at a lat­er mo­ment, de­pend­ing on the ex­act mean­ing of per­sis­tence and the lev­el of re­dun­dan­cy that is re­quired for this type of in­for­ma­tion.” The save but­ton is there­fore ac­tive­ly mis­lead­ing, and doesn't give to the user more con­trol of data per­sis­tence, com­pared to the per­ma­nent per­sis­tence ap­proach.