Usability Pains

by Karel Thönissen

Today we had another nice usability pain. Okay, something went wrong during the writing of our software and we decided to rollback to a previous version. For good reasons these earlier versions are stored on the central server computer in a folder that is not accessible from the workstations. However, I did not realise this immediately; luckily, this restoring does not happen too often. So I opened the folder with the previous version of the source code and made a copy from the server to my workstation. Fine. I open the folder and it is completely empty! Oh dear! I develop heart problems. Then I realise that I had not logged in under an account with permissions to the source code folder on the server. But why the hell failed Windows-XP silently? Why did not it offer me the opportunity to change accounts? If this had been part of a script, then nobody would have noticed the problem until days later.

• Never fail silently

Then I realised the problem. Unfortunately, my Windows-XP does not allow me a log-in on the Windows-2000 server under another account with sufficient permissions. Another usability pain. (Or is it possible and I just do not know: another usability problem)

• Allow users to change accounts on the fly

So I had to go to the server to log-in appropriately and push the folder from the server to my workstation. I open the folder with the network neighbourhood on the server. I want to open the folder for my workstation so that I can copy the folder to the Shared Documents folder of the workstation. Wrong idea. Windows 2000 does not know that the Shared Documents folder should be freely accessible, so it asks me to provide name and password for the workstation. Strange, that is what I wished I had on the workstation! I log-in and copy the folder to Shared Documents. I go over to my workstation, and guess what, the folder has been placed in the Gedeelde Documenten-folder (this is the Dutch translation for Shared Documents). So the folder has different names under different circumstances. I can imagine all kinds of problem coming from that.

• Use immutable names for system resources, unless you want to break scipts, programs, telephone support, etc.

Okay, the older version of the source code folder has arrived at last on my workstation. I start our main development project that is placed in the folder. Delphi is launched and compiles the code. I run the code, which immediately fails, due to my own error: the software fails at run time if it is not started from a certain folder. I close all files in Delphi, but so not close Delphi itself. I drag the source code folder to its correct context. The progress indicator is at 75% when the move-command is interrupted because someone is using some of the files somewhere for some reason. The error message from Windows provides no clue who held what lock for what reason, but I immediately suspect Delphi: I closed all files, but it still held one lock on a file. Therefore, moving that file was not possible. So I must close Delphi and then start it anew, another 30 seconds blown away. I remove the 75% complete copy of the folder that was placed in the correct context, and try again. Ready in less than 2 seconds, that cannot be correct. Not only had Windows done me a disservice by not telling me exactly what was wrong, it had also left the folders hoovering between here and there. There was a part in the old location and a part in the new location, but you are never sure whether these two parts add up to the whole.

• Always provide meaningful error messages
• Never leave the system in an unknown state

So I must go back to the server and start the whole procedure a new. What a waste of time and energy!