Design Fallacy - Lesson 1

Design and deliver only What you Need

Recently I was writing a WSS (Windows Sharepoint Services) utility to help my user to eliminate some tedious repeatative.

Due to the access restriction for documents in document library, the sys admin need to customize the security setting for certain document library in the wss site. This is quite a tedious task as new site is created quite often and each site has a few document library. It takes many mouse clicks to accomplish the process.

I figure that it is possible to write a utility to automate this series of tasks using the WSS SDK. As i am writing this utility as a personal favor, there are not proper requirements, no time constraint and no limit to features.

Halfway through development, i was kind of stuck thinking what is the best way to present the UI and I realize i make a design philosophical mistake that many people tend to make as well.

The problem here is overdesign and attempt to go beyond the requirements.
The admin only need three functions:

1. Add a predefined list of domain users into the new site.
   
2. Remove the default groups from the document library.
   
3. Add the new groups/users into the document library with specific permission.
   

The admin only need a simple car and I was on my way to build a car with turbo engine with backfire. I was trying to build a general document library administration
tool instead which is way more comprehensive.

Obviously, my utility application will be able what the sys admin want to do and even
more. But when I sit down and think of the usability issue, I quickly realize it was too ambitious, too general and too much functionalities.

Having more is not a bad thing, but it is not always a good thing either. Having more functionality than necessary mean the user need to have more interaction
with the application.

So, the problem is :

1. The more functionality the application have, the more interaction the user need to do.
   
2. The more interaction the user need to do, the more decision the user need to make and the more discoveries the user need to make.
   
3. The more decision the user need to make, the lower the productivity the user become.
   
4. The more discoveries the user need to make, the more distraction the user is going to have and the less usable the application become.
   

Eventually the user will find the application too complicated for simple purpose and revert to the old ways of doing things. Then all your hard work will go into drain.

The best application is not one with many features, rather it is one with the function that solve the user's problem at heart efficiently.

By focusing only on the absolute requirements and nothing more:

1. You will need less development time which will drive down cost.
   
2. Simple application with less but important functions.
   
3. You will have a simple application which require minimal learning curve.
   
4. User is more productive because the application does not require them to make decision.
   

So, I went back to design the application just to have only that three functions and nothing more. It took me only half a night to complete the application and ready to ship by the next day. And most important, the application is way much easier to use.

The lesson here, focus only on core requirements and nothing else. Don't make your life and your user's life complicated. Just because you can do something, doesn't mean you have to do it. You don't show value by delivering more functions, rather by showing user you understand their real problem and solve it in the most elegant way.

Bad Error Message Hinder Productivity

I was writing an C# Console application which I use System.Web.Mail.SmtpMail to send
email out. System.Web.Mail.SmtpMail internally use CDO for Windows 200 (CDOSys) to
send the mail out.

While my application was running, I got an exception when calling the SmtpMail.Send()
method. The exception message was :

Could not access CDO.Message object.

At first thought, the exception could be due to one of the following reasons:

• The CDOSys.dll component is not registered properly on the machine.
  
• The application does not have enough permission to read the registry and instantiate the component.
  

So, I went on to search the MSDN for the possible cause and mitigation of error. I found a few KB articles and try the settings suggested in the articles and still not luck. I try a couple more things to try to get it work. After half an hour, still nothing was working.

So I decide to reference the CDOSys.dll using COM interop in my C# project and replace the original code with calls to CDO.Message directly. When I ran the application, the exception message I got was :

Unable to connect to SMTP server

Now, things become helpful.I check my SMTP server setting and found out that I gave the wrong IP. I type in the correct SMTP Server IP, ran the app again and everything work now. I move on to put back my original System.Web.Mail.SmtpMail code with the correct SMTP Server IP and get everything working. This whole process took me only 5 minutes.

If the System.Web.Mail.SmtpMail.Send() throw an exception with more precise message, it would have save me 30 minutes time for looking at the wrong thing.

The lesson here is :
If you does not return a meaningful exception/error message which precisely describe the error, you will drive your user nuts and mislead them into looking at the wrong remedy. This will essentially make your API/application less usable.