I heard the other day that the difference between ranting and constructive criticsm is the offering of a solution so let me rant first and then I will offer a possible solution. So first the problem. I sent out an e-mail with a Microsoft Project 2007 .mpp file attached. I heard back from one of the people that I sent it to that they could not open the file. I wasn't sure if it they had an older copy of Project or didn't have Project installed on their computer. I decided to go into Project and do a "save as" on the file to an older version and print a XPS file that I could also e-mail. While saving to the older version I saw that I could save to Excel and decided that might be a better option. I ran through the wizard asking me what columns I wanted saved to the Excel workbook. I foolishly clicked on the button to add all and then had to go through and delete most of them since they were not populated in the Project file. After cleaning up my mess I finally got through the whole wizard and clicked on finish only to get a message that the Excel workbook couldn't be created because of security settings with a somewhat terse message on how to fix the problem. I was able to do the 2 steps to get to the dialog box where the instructions started and reset the security settings. The second time through the wizard I was much faster and I was eventually able to save the file. My complaint was with the error. I shouldn't have ever had to see it. I can see 3 possible solutions to this problem.
1. The option to save to an Excel file could have been disabled. I would have seen that there is a possibility and could have looked in the help file to figure out what I needed to do. I am not sure how effective this would be because I would have likely determined I didn't have the correct driver or something and instead printed to the XPS but at least I would have known that when the sun, moon, and stars all align just right I might be able to save as Excel.
2. I could have been told that my security settings wouldn't let the wizard finish and asking me if I wanted the security settings to change. I don't really like the idea of a "black box" security change and would be tempted to say no most of the time but given the amount of time that I had invested in this (100% my fault) I might have been tempted to accept the option and try to undo it later.
3. The second screen of the wizard (you know the one after the splash screen that nobody bothers to read) could have checked the security settings and told me that I couldn't finish without making some changes. It could link to a help file with accurate instructions and a full discussion of the tradeoffs I was making by changing the security setting.
Option 3 seems so simple and certainly like it should be the logical choice so why wasn't it taken? I have no idea. I *suspect* that the reason might be that this particular feature wasn't tested or that it was automatically tested. I can see automatic testing being the most likely culprit. If I were given a specification for a feature that says if a certain security feature is set a message should appear and the file shouldn't be created I am pretty sure I could write an automated test to determine that is what is happening. Since I might only have to watch it run once if even that many times to make sure the test ran correctly and then I wouldn't have to think about it any more. I could also see reusing another test to fill out the dialog box so it wouldn't be like you were taking a lot of time to set up everything.
My solution to the problem would be to have the automated tests run at least once manually during each product development cycle to make sure that they still make sense and that they test the correct functionality. I am not sure what the cost of all this manual testing would be verses the amount of complaints Microsoft gets from customers but there should be some way for Microsoft to check the number of calls coming into PSS and just check the tests that are designed around those features.