Early on when I started using PlayCanvas I accidentally deleted my Scripts folder. One of my partners did the same thing weeks before I did it and he had no clue what had happened. I was a bit lucky and was able to figure out what had happened. It comes down to a combination of some very bad behavior in the Editor as well as user inattention.
I recently did this again and deleted a complete scripts folder while cleaning up a finished project. Fortunately, I had forked the project specifically for the purpose of cleaning out old files since I know that such cleanup can easily lead to erroneous deletions. So I had a perfectly good âlive copyâ and only lost a bit of my clean-up work. So, no files were ultimately lost. But it annoyed me that I could make this same mistake again even though I knew about this âtrap.â So I went back and double checked the Editorâs behavior, and I now consider this to be doubly poor design because the Editorâs behavior virtually invites the user to make the mistake. Hereâs an outline of what is happening and what has probably caused the deletion of a LOT of Scripts folders.
The problem starts when you look at the selection of a folder in the Assets panel. There are actually states for a selected folder. Iâll call one âsoftâ and the other âhardâ. With a soft selection, the folder is highlighted orange and the folder contents are shown, but nothing is shown in the Inspector panel. If you click the folder again, the folder name is back-shaded with a dark gray band and the inspector panel will now show information about the folder. And this is is where the problems begins.
If you right-click a script while the Scripts folder is hard selected, you will get the context menu for the item you right-clicked over - as expected. That menu will show references, give you the option to edit, and to delete the file. But if you choose âdeleteâ from this context menu, you wonât delete the script?!?! You will actually delete the entire Scripts folder!!!
In fairness, the Editor will warn you that you are about to do this. But that warning is visually the same as the one given when you delete an asset except that it says âDelete Folderâ instead of âDelete Assetâ. So you have been warned ⌠but in the most subtle and misleading of ways. The user would have no good reason to expect that heâs deleting a folder, and will be mentally assuming that the warning is about the file heâs asked to delete. Weâve all been habituated to click-through these warnings. So the user clicks Delete and loses all of his scripts in one fell swoop.
The situation is worsened by the fact that the right-clicking over other kinds of assets does not result in this behavior!!! So the userâs normal expectations are further reinforced when the user repeatedly has no problems when deleting other kinds of assets⌠It is only when an Asset of type â.jsâ is right-clicked over that we get this problem. So when a user has just gone through the repetitive task of deleting many objects, materials and images and then moves on to do the same with left-over and legacy scripts, he is doubly likely not to notice the warning that he is about to delete a folder. It is a new and unique behavior from the editor.
Possible solutions:
-
Donât let a context menu for a file switch its context to a folder for when deleting from the context menu. Thatâs just horribly unexpected behavior.
-
Make the warning for all folder deletions visually different from the one used for asset deletion. Maybe put lots of red color on it. Perhaps a big âSTOPâ sign.
-
Require two step confirmation for folder deletions. It probably isnât necessary to go to the extra steps of typing out the command as is done (super good design BTW) for deleting projects. But a second panel that says something like. âHey - you are about to delete a FOLDER that has XXX number of files!!! Are you sure you really want to do this?â would stop most people in their tracks because they could hardly help but notice that the change in pattern from one confirmation panel to two. Maybe put a big red âSTOPâ sign on this panel as well.